× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



My own take on proxy ARP is refer to Drs. 1st, 3rd, 5th, and 7th comments.

I know good network folks that can't really figure it out.

It's really number 6 that counts. When it works, it works great, but troubleshooting it is a miserable task when things go wrong.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 8/20/2013 1:27 PM, DrFranken wrote:
I would not recommend proxy ARP.

1) Most i Admins are confused by Proxy ARP.
2) It works at the O/S Level so it's going to use more overhead.
3) Most i Admins are confused by Proxy ARP.
4) You need to understand subnetting to make it work.
5) Most i Admins are confused by Proxy ARP.
6) It's not a very standard thing and will be hard to troubleshoot
especially compared to Bridging.
7) Most i Admins are confused by Proxy ARP.

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 8/20/2013 2:23 PM, Evan Harris wrote:

> If the guest partition and the host partition are on the same network
> (which they must be if you want to assign an address to the adapter) then
> you might be better using proxy ARP to assign an address to the guest.
> https://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/rzalm/rzalmtcpip.htm
>
> Personally I have found the Ethernet Bridging a really useful solution. The
> chief advantage is it allows me to use one PORT per multiport NIC for a
> partition (or partitions) rather than having to assign an entire card.
>
> I found the HEA a bit clunky but only used t a couple of times.
>
>
> On Wed, Aug 21, 2013 at 5:10 AM, Mitchell, Dana<dmitche@xxxxxxxxxx> wrote:
>
>> Has anyone worked much with 'Ethernet Bridging Between IBM i Host and IBM
>> i Guest'? We are working on adding a 2nd LPAR to a production machine and
>> I thought it would be a good idea to just one an Ethernet port on the first
>> machine and bridge traffic from it to the new LPAR. After doing some
>> research on the subject, I found this document:
>> http://www-01.ibm.com/support/docview.wss?uid=nas8N1011193 it explains
>> what needs to be done very well but comes with one caveat:
>>
>> Important Note: IBM suggests that the selected Ethernet resources be used
>> for only layer-2 bridging and not for IBM i TCP/IP configuration. There is
>> a significant increase in processor usage for any host traffic that uses
>> bridged resources. In addition, any line description that is used for
>> bridging receives many frames that are not useful to the TCP/IP stack.
>> These frames use unnecessary processing resources. The virtual Ethernet
>> line on the host does not require an interface. You only need the physical
>> and virtual lines active for the bridge function to work. You should not
>> have an interface on the physical line used for the bridge either. Create a
>> separate physical line& interface for network traffic on the Host.
>>
>> If I'm reading this correctly it seems IBM is implying that the bridging
>> function is too much overhead to both service the host partition with IP
>> traffic and bridge traffic from LPAR#2 also. So by my math that makes
>> this facility pretty useless until you get to 3 or more LPARs. Is anyone
>> doing this now, and can verify that is it or is not too much overhead?
>> Why oh why did they discontinue HEA?
>>
>> Dana

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.