Daniel’s Lego coach has 4 bedrooms, 2 baths, a kitchen & a dining room..
Thanks to everyone for the congrats on #6. Still no name but I will be sure to get an update out once we figure that out. Autumn & the kid are resting now after their breakfast. For those wondering about stopping by, Autumn did say she is feeling up to a few visitors this afternoon; give me a call on my cell. We did not make it to Church today, so the baptism will likely be on the eighth day at St. Luke’s, but I will follow up with those details too.
Bye Bye NIC Teaming
One of the coolest and, in my opinion, most undersold features of Cisco UCS is the ability to enable fabric failover for a vNIC.
In UCS, vNICs are virtual interfaces that are created and presented to a blade. The host will see these virtual interfaces instead of the underlying hardware itself. When you create a vNIC, you choose to create it on either fabric A or B and there is an option to enable failover.
The most significant problem I have experienced in the past with redundant servers is with NIC teaming. The norm for this is to run an Intel or Broadcom driver to configure two interfaces as either active/active or active/passive and trust the driver in the operating system to detect a failure and begin transmitting on the redundant NIC. This is great in concept, but in practice is not so simple. The NIC vendors cannot assume much about the upstream network gear and usually need to handle failover in a way that keeps the switching infrastructure in the dark. Their methods to detect and signal failover are often proprietary and, in my experience, buggy. It is not uncommon for us to take down a network component that should be redundant for maintenance only to see a few servers drop off the network because their teaming drivers failed to work properly.
With fabric failover the operating system sees one NIC, a scenario that operating systems and drivers have been able to successfully handle for years. When a failure occurs it is handled the opposite of NIC teaming, the NIC hardware and switching infrastructure handle the failover and the operating system is kept in the dark. It is very fast. In our tests with UCS in end-host mode it was about the order of magnitude of VMotion with only a single missed ping. When the failure is resolved the vNIC moves back to its primary fabric and is often undetected in a ping test. Very cool!
From what I understand the fabric failover functionality is available in all initial NIC options for UCS but only on Cisco Palo adapters in the second generations with other vendors planning to add the functionality back in later releases. For now Cisco Palo seems the most flexible option because you get fabric failover as well as the ability to create as many vNICs as you’re likely to require.
Bye bye NIC teaming..
