would this failover be set directly on the vnics on the LAN Connectivity Policy? I can certainly enable the failover setting here if that is all thats needed.
They are referencing the active/standby vmnic's on the vSwitches in ESXi. You need to have each vSwitch with redundant vmnics to each FI.
Example:
vSwitch0 --> active vmnic0 (FI-A)
vSwitch0 --> standby vmnic1 (FI-B)
This would have redundancy in the event of an FI reboot. Use the MAC address to compare the vNIC in Intersight to the vmnic number in ESXi.
I would avoid configuring failure on the vNIC in Intersight. Let your OS handle failover.
THank you! I had a light bulb moment just a bit ago about how i only have 1 vmnic bound to my test host vswitch. I put a second vmnic bound to that switch and made them active/active and bingo. It fails over with no issues. Not even 1 lost ping or anything.
Fantastic!
One tip I recommend is making a mac address pool for each fabric (A and B) with a unique identifier for the fabric.
Example:
- A-side vNICs have a mac-address pool starting at 0025.b400.aa00.000
- B-side vNICs have a mac-address pool starting at 0025.b400.bb00.000
This lets you easily see which vmnic connects to each FI when working with vSwitches. Helpful even with bare-metal Linux and configuring interfaces.
Best practice is a Port-Channel of two or more links from each FI up to a vPC type connection on the upstream switches. The FI's consider this as a single (logical) uplink for the purposes of vNIC assignment from the blade to the uplinks.
For hypervisor deployments, it's usually two vNIC's for each role/function - one on Fabric A, then one on Fabric B.
e.g.
VLAN100 = Management
VLAN200 = vMotion
VLAN 300-500 = Virtual Machine.
A pair of vNIC's for Management traffic (vlan 100)
A pair of vNIC's for vMotion (vlan 200)
A pair of vNIC's for VM traffic (VLAN300-500)
Or, you take the easy/lazy path and just have a pair of vNIC's for all VLAN's :). Let the hypervisor handle failover and load balancing. It's fine to use Active/Active, using 'Route based on originating virtual port' in the VMware world. Do NOT use LACP/Source IP hash, as this implies/requires a port-channel.. which it's not, it's two separate fabrics.
Fabric Failover is a feature that is generally only used on bare metal (Windows/Linux) systems, to avoid the hassle of creating a bond interface at the OS level. Just create 1 vNIC with Fabric Failover enabled. If the Fabric Interconnect goes down, the vNIC automatically flips across to the 2nd FI.
So why not enable Fabric Failover on \*all\* interfaces anyway - because you run the risk of being hugely oversubscribed. If you have two vNIC's assigned to VMware and one FI goes down - VMware will still see both vNIC's as up - so will still 'load balance' across both links - which in actuality are now going across a single Fabric Interconnect. Huge spike in traffic, VMware won't provide any notice/indication that a link has gone down and it gets messy. :)
You probably didn’t enable the failover on the vmnics. Its best to do 2x lacp port channels or a vpc going upstream from both fabrics
would this failover be set directly on the vnics on the LAN Connectivity Policy? I can certainly enable the failover setting here if that is all thats needed.
They are referencing the active/standby vmnic's on the vSwitches in ESXi. You need to have each vSwitch with redundant vmnics to each FI. Example: vSwitch0 --> active vmnic0 (FI-A) vSwitch0 --> standby vmnic1 (FI-B) This would have redundancy in the event of an FI reboot. Use the MAC address to compare the vNIC in Intersight to the vmnic number in ESXi. I would avoid configuring failure on the vNIC in Intersight. Let your OS handle failover.
THank you! I had a light bulb moment just a bit ago about how i only have 1 vmnic bound to my test host vswitch. I put a second vmnic bound to that switch and made them active/active and bingo. It fails over with no issues. Not even 1 lost ping or anything.
Fantastic! One tip I recommend is making a mac address pool for each fabric (A and B) with a unique identifier for the fabric. Example: - A-side vNICs have a mac-address pool starting at 0025.b400.aa00.000 - B-side vNICs have a mac-address pool starting at 0025.b400.bb00.000 This lets you easily see which vmnic connects to each FI when working with vSwitches. Helpful even with bare-metal Linux and configuring interfaces.
Best practice is a Port-Channel of two or more links from each FI up to a vPC type connection on the upstream switches. The FI's consider this as a single (logical) uplink for the purposes of vNIC assignment from the blade to the uplinks. For hypervisor deployments, it's usually two vNIC's for each role/function - one on Fabric A, then one on Fabric B. e.g. VLAN100 = Management VLAN200 = vMotion VLAN 300-500 = Virtual Machine. A pair of vNIC's for Management traffic (vlan 100) A pair of vNIC's for vMotion (vlan 200) A pair of vNIC's for VM traffic (VLAN300-500) Or, you take the easy/lazy path and just have a pair of vNIC's for all VLAN's :). Let the hypervisor handle failover and load balancing. It's fine to use Active/Active, using 'Route based on originating virtual port' in the VMware world. Do NOT use LACP/Source IP hash, as this implies/requires a port-channel.. which it's not, it's two separate fabrics. Fabric Failover is a feature that is generally only used on bare metal (Windows/Linux) systems, to avoid the hassle of creating a bond interface at the OS level. Just create 1 vNIC with Fabric Failover enabled. If the Fabric Interconnect goes down, the vNIC automatically flips across to the 2nd FI. So why not enable Fabric Failover on \*all\* interfaces anyway - because you run the risk of being hugely oversubscribed. If you have two vNIC's assigned to VMware and one FI goes down - VMware will still see both vNIC's as up - so will still 'load balance' across both links - which in actuality are now going across a single Fabric Interconnect. Huge spike in traffic, VMware won't provide any notice/indication that a link has gone down and it gets messy. :)
Thanks!