Re: Ethernet Bridging

I'm not really recommending it other than to point out it is an option. I
do have at least one customer who elected to go this way and is more than
happy with it - admittedly they have some network savvy people there.

I think it's fair to say that even ethernet bridging confuses the average i
admin - hell networking confuses a fair proportion of them. They should get
out and learn more instead of limiting their solutions based on what they
are comfortable. with.



On Wed, Aug 21, 2013 at 6:27 AM, DrFranken <midrange@xxxxxxxxxxxx> 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


Attention: This electronic document and associated attachments (if any)
may contain confidential information of the sender (SHAZAM Network) and

is

intended solely for use by the addressee(s). Review by unintended
individuals is prohibited. If you are not the intended recipient: (i) do
not read, transmit, copy, disclose, store, or utilize this

communication in

any manner; (ii) please reply to the sender immediately, state that you
received it in error and permanently delete this message and any
attachment(s) from your computer and destroy the material in its

entirety

if in hard copy format. If you are the intended recipient, please use
discretion in any email reply to ensure that you do not send

confidential

information as we cannot secure it through this medium. By responding

to us

through internet e-mail, you agree to hold SHAZAM, Inc. and all

affiliated

companies harmless for any unintentional dissemination of information
contained in your message. Thank you. (2)
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.