Blog
i can

« Planning for Solid State Drives | Main | Achieve Faster IFS Save Times Using SAV With ASYNCBRING »

January 24, 2012

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83545a5d153ef016761008ccf970b

Listed below are links to weblogs that reference Ethernet Link Aggregation in IBM i:

Comments

Needs some work though.
Item 1: Let's say you spread one line across two ports. One port drops.
You will not see any notice. Not in QSYSOPR, DSPLOG, STRSST, anywhere. I
compare this to losing a drive out of a raid 5 parity set and not getting
any notice. There is something on DSPLIND which will show you that - but that's a lot trickier to monitor with many of the standard monitoring tools sold for the i (ie Messenger Plus and others).
Item 2: Let's say one of the ports is down when you vary on the line (like you did an IPL while still waiting for the telco or network admin to fix the issue). Ok, so now your line is varied on, with only 1 link active. Line gets fixed. You cannot bring the second port active without varying off/on the whole line. That's a wee bit too disruptive for my tastes.

Rob,
It's great to know that you have experimented with the new features. The IBM i development team always listens to feedback from our clients and is aware of these concerns. They are working to address these concerns and while I cannot share specifics, you will probably see changes in a future 7.1 technology refresh.

Dawn

"Tip: IBM i Aggregate Ethernet Lines, Creating and managing aggregate Ethernet lines on IBM i 7.1" was just published this week on the IBM i developerWorks site.

http://www.ibm.com/developerworks/ibmi/library/i-ethernetlines/index.html

Dawn

It's
very fine but is ONLY for hardware adapters NOT for Virtual I/O Adapter true VIOS (but AIX yes).
Will be in new TR?

Jan: As you say, IBM i does not support virtual Ethernet ports in aggregate line descriptions. However, we are always looking for ways to improve our TCP/IP availability, and will take your concerns into account. I hope to respond with more detail in the near future.

Ok, I've created 2-port aggregation and we tested it via IP. Pulled out 1 cable, then vice versa - OK. When 2 cables are disconnected - no link, naturally. But when we returned just one cable - we were unable to vary on the line flying on one wing. We needed to plug the second, vary off and finally vary on. What I am doing wrong? Some additional parameter to adjust? Or just to wait for yet another PTF?

Dmitri:

Do I understand your scenario correctly?

1. vary on line with both ports plugged (working fine, verify LINK UP status for both ports in the last panel on DSPLIND)
2. unplug 1 port, plug it back in (one port goes LINK DOWN, then LINK UP)
3. unplug the other port, plug it back in (again, that port goes LINK DOWN, then LINK UP)
4. unplug both ports (both go LINK DOWN, line description goes FAILED or RCYPND)
5. plug one back in (expect that port to go LINK UP, line description to go back to ACTIVE)

If I have described your actions correctly and the behavior is not as I describe, please contact customer support so we can collect debug data.

Thanks!

Hi Colin,
sorry for long silence, near middle of July I went on vacations. Yes, you described my actions correctly. The system has all the recommended PTFs as of July 2, was not updated since. Next week I'll be there. Now it is in production already but these ports are not used yet. Now closer to steps 4 and 5. Unplugging 2 ports we have no link and quite naturally. Everything goes down. But when we plugged back only one cable, not only the link did not go UP by itself but also it was not possible to force it UP. And when we plugged both ports - as well neither it went UP by itself nor it was possible to force it UP. We needed to forcedly vary off both ports and only then we were able to vary them on and reestablish communications. IC says: "If the system detects any configuration errors, the line description does not vary on successfully. Any ports that fail to establish link when varying on are not aggregated until the line description is varied off and back on." This may explain the behaviour but doesn't make me happy. I think it is easy to reproduce such a scenario having simple V7R1 machine and Cisco switch. If meanwhile there were any PTFs touching etherchannel please inform me if possible. TIA.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.