This operational problem with passive backup configurations just never goes away. After over 30 years of networking I consider this design to be a bad practice nearly guaranteed to fail.
If you want the backup path to be there when you need it, then it must be in production, period. An active backup path, meaning with a live unique IP address, allows for production monitoring. I further advocate that all paths support dynamic routing protocols to provide automatic recovery with applications utilizing a loopback address advertised to the network for connectivity. Most routing protocols will recover in a time frame that is short enough to allow active TCP/IP connections to stay alive during the failover, making the failover transparent to the applications and eliminating end user outages (just a bit of a slow down while failover occurs). The quickest is OSPF. All mainframe routing protocols provide mechanisms to eliminate the entire corporate routing table from being managed by the host instance, just the default route. This design further can allow for not just an active backup path but also load sharing between the paths. In other words, "VIPA," adapted to the specific OS' networking capabilities, is a best practice. This post is not meant as a criticism of Mr. Levy's situation which may have constraints, technical or organizational, that preclude these best practices from being adopted, but as a general statement of networking best practice for high availability. Both the host administrators/systems programmers and router administrators must acknowledge that the network does not stop or begin at the Ethernet cable and work together. Networking has its equivalent of "gen jockeys" who can configure but do not truly understand the technologies with which they work. Harold Grovesteen Levy, Alan wrote:
We have a vswitch defined here as follows: VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 3 Maxconn: INFINITE PERSISTENT RESTRICTED NONROUTER Accounting: OFF VLAN Unaware State: Ready IPTimeout: 5 QueueStorage: 8 Portname: UNASSIGNED RDEV: FA00 Controller: DTCVSW2 VDEV: FA00 Portname: UNASSIGNED RDEV: FB00 Controller: DTCVSW1 VDEV: FB00 BACKUP This vswitch was defined over 1 year ago and at that time failover was tested successfully. This works great and worked great until this past Sunday. Our network group was doing maintenance and brought down the primary osa FA00. The switch did not fail over to the FB00 osa. They had to back out their changes. We found out this week that sometime in the past year, one of the cables to the FB osa became unplugged (there are no other servers connected to that switch). Our network group actively checks the LAYER-2 (MAC) addresses display on the Cisco switches where the OSA connections are plugged. They only see the MAC address of the primary interface on the VSWITCH. The backup VSWITCH port does not show a MAC address on the Cisco switch. They would like to actively monitor both interfaces so that if a real problem occurs on the backup interface, it can be detected PRIOR to a VSWITCH failover. Since they currently can't monitor those connections they never noticed it had a problem. Then when we really needed the backup it wasn't there and we experienced an outage. Is there a way to have both the primary and backup OSA interfaces show a MAC address on the Cisco switches? ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
