Re: Ethernet failover during vios upgrades -- MIDRANGE-L

we use VIPA on the IBM i for Ethernet fail-over
the following has worked for years. no system outage because of one Ethernet failure.

pardon the formatting

Internet Subnet Line Line
Address Mask Description Type
1.2.3.4 255.255.255.255 *VIRTUALIP *NONE
1.2.3.2 255.255.255.0 ETHLINE1 *ELAN
1.2.3.3 255.255.255.0 ETHLINE2 *ELAN

*VIRTUALIP
Preferred interfaces
Internet address . . : 1.2.3.2
Internet address . . : 1.2.3.3

Route Subnet Next Preferred
Destination Mask Hop Interface
*DFTROUTE *NONE 1.2.3.1 1.2.3.3
*DFTROUTE *NONE 1.2.3.1 1.2.3.2

the route setup will have outbound connections use the VIPA address(which is the DNS) that helps FW and mail relays.

Bryan

Rob Berendt wrote on 12/18/2020 8:17 AM:

I upgraded 6 vios partitions to 2.2.6.61 then 2.2.6.65 this week. I hope to get them upgraded to 3.x sometime soon.
Each Power system has 2 vios partitions with a shared Ethernet adapter setup.

On each power system I would upgrade one vios partition through both upgrades. Then I would upgrade the other vios partition through both upgrades. All this time I was running the following from a dos prompt without any failures:
ping someIBMilpar -t
Did one power system with no complaints.
Did another power system with no complaints.
Did the main guy this morning. Weird. (of course).
Pings never failed. Ever.
During the upgrade:
You could log on and do a DSPJOB but if you tried to look at messages or joblog it would lock up. ?Volume of data?
I just kept plugging through the upgrades while the Swiss Guards kept the hordes at bay. Then it stayed working.
IDK if there was an issue with 2.2.6.61 which was resolved by 2.2.6.65 or if one or the other vios partition being down or what was the issue.

I do know that I failed to follow this advice:
"Failover the Shared Ethernet Adapter (SEA) manually to another VIOS. See best practice section in the previous post."
Previous post referred to:
https://theibmi.org/2020/07/16/new-vios-releases-affect-the-shared-ethernet-adapter-sea-functionality/
<snip>
It was very untypical behavior, ping from a workstation works, new 5250 session was possible to open, but submitting any IBM i commands resulted with 5250 session freeze. In another words, from session A, I execute command WRKACTJOB, and the session freeze, while it was still possible to open a new session B or..C... and so on. However, any command executed resulted with a freeze job.
</snip>
Further reading leads me to believe it was introduced in a few releases, including 2.2.6.61, but was fixed in 2.2.6.65
This situation is EXACTLY what we experienced.
Note: when you download 2.2.6.65 from Fix Central it clearly is an indent to 2.2.6.61. The download also has a small subset of the files that 2.2.6.61 had. So this is why I didn't go directly to 2.2.6.65.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com