Advantage of vNIC redundancy pair

[christopher.eakin]

Can some one give me an advantage of using a vNIC redundancy pair template versus just have two vNIC template.  I've not been able to find much info.

Thanks.

[padramas · Accepted solution]

Hello,

On a high level, it eases out managing vNICs or VHBA pair which needs to have same set of configuration

Cisco UCS Manager Network Management Guide, Release 3.1 - Network-Related Policies [Cisco UCS Manager] - Cisco

For example, consider blades with two vNICs where each vNIC traffic needs to go through different FI path.

With vNIC template redundancy pair feature, secondary vNIC template synchronize the shared properties from primary templates and reduces error ( MTU, vLAN , etc ) between two vNICs.

Let me know if you need more information.

Thanks

Padma

[cowboycraig73]

deleted

[cowboycraig73]

After a new search found this, and it's helpful:

A "redundancy pair" duplicates the vNIC on one FI to the other FI on failure.

The following configurations are shared when using template pairs:
• Network Control Policy
• QoS Policy
• Template Type
• Connection Policies
• VLANs
• MTU
• Statistics Threshold Policy

The following configurations are not shared when using template pairs:
• Fabric ID
• CDN Source
• MAC Pool
• Description
• Pin Group Policy

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-central/GUI-User-Guides/Network-Mgmt/1-5/b_CiscoUCSCentral_NetworkManagementGuide_1-5/b_CiscoUCSCentral_NetworkManagementGuide_1-5_chapter_0100.pdf

[EndOfLine]

Question, when utilizing "redundancy pairs" and one of your FI's fails or reboots, will the corresponding vNIC still have connectivity over the other FI?  

I have two vNICs (vNIC-VDI-A and vNIC-VDI-B), the -letter specifies the FI.  And Fabric-A goes down.  vNIC-VDI-A was the primary template and B is the secondary.  Will A recreate on B and continue passing traffic?  

[Riaan van Niekerk]

In addition to what Steven said,

Think of the vNIC template redundancy pair as the configuration plane, with the actual settings pushed down to the vNIC (e.g. VLANs & VLAN groups) being the data plane. If the configuration plane (UCS Manager or FI with the primary vNIC template) goes down, traffic will still flow as before the outage, on the remaining data plane component (e.g. the FI with the secondary vNIC template). You will just not be able to make any changes while the configuration plane (UCSM, Central) is down. I am not sure if you would be able to make changes to the primary vNIC template when the configuration plane is down but the data plane with the primary vNIC template is down. (I suspect it will take the config, e.g. apply on Fab-B but not Fab-A, but I may be mistaken)

[Steven Tardy]

No.

Sounds like you are confusing two topics.

1. Redundancy (two vNICs with matching configuration as you can only configure one of the two vNICs in UCSM) and
2. Fabric Failover (a phantom vNIC which will get activated if the vNIC path fails).

Given two redundancy pair'd vNICs as you describe and the OS is doing active/backup or active/active.

When one vNIC goes down, it goes down and traffic from the OS is expected to transition to the "other" remaining vNIC.

-- Full stop.

If you do the "Enable Failover" checkbox, then it would do what you describe and transparently activate a previously created phantom vNIC with a path through the "other" FI.

It is generally not advisable to use both UCSM Fabric Failover and OS NIC Teaming which may appear to be a belts-and-suspenders approach but may cause some unexpected interactions.

--

UCSM Fabric Failover : Think of this as "hardware" based active/backup teaming. One path goes down, the other path is activated but the OS knows nothing of what happened. This is great for server admins who are unfamiliar with OS teaming. . .  Give 'em one vNIC which _should_ never go down.

UCSM Redundancy Primary / Secondary : Think of this as giving two matching configuration vNICs (Same VLAN, MTU, QoS, etc) but the OS is responsible for teaming the pair of vNICs properly. OS admins will want to make both active to use all the bandwidth, but these vNICs are pinned out different upstream port-channels / connections. And MAC moving *frequently* from one connection to another will make the upstream network VERY unhappy.[1]

[1] https://www.cisco.com/c/en/us/support/docs/servers-unified-computing/ucs-b-series-blade-servers/200519-UCS-B-series-Teaming-Bonding-Options-wi.html

[EndOfLine]

Thanks to you both.  I have always implemented an A & B vnic for my virtual environment, but I see utilizing the Primary/Secondary simplifies the configuration since they have the same settings.  I appreciate your thorough answers and the link.  Cheers.