Re: Ethernet Bridging -- MIDRANGE-L

First discontinuing the HEA was essentially unintentional. When they got to the point where it was no longer supported they couldn't put it back. Besides the HEA had other weird limitations of it's own. Future stuff may fill that gap but it's done now so.....

As to bridging it works great and it's not just for 3 or more LPARs, it works with 2 as well (or actually even 1!) And with the right magic incantations the bridge with allow IBM i to use 802.1Q VLANs too!

As you read, DO NOT put an IP address on the bridge itself. This is bad and will burn CPU especially should you attempt any comm trace. At least IBM lets you, put an address on a bridge in Cisco gear and you shut down the bridge!

Remember it's the bridge operating in promiscuous mode so that it can learn who's on the inside and who's on the outside so it can bridge all 'interesting' packets and ignore the others that causes the issue here. Because the adapter is seeing every packet if there is an IP address there then IP gets the packets too and that's a lot of extra work.

You can use just one physical line on the IBM i Host partition and have that bridge to the desired internal VLAN. Then you can put a virtual adapter on the host partition to that VLAN as well. The IP traffic for the host then goes to the internal VLAN and then back out across the bridge.

The bridge itself appears to use virtually no CPU at all as long as you follow IBMs recommendations.

- Larry "DrFranken" Bolhuis

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

On 8/20/2013 1:10 PM, Mitchell, Dana 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)