Dallas,
Per direct discussion, this request is best handled by our PM team which addresses enhancement requests. Your Cisco account team was part of this discussion so hopefully they have already followed up and contacted PM Community.
For reference to others reading this thread...
Yes, we do implement NIC Bonding. The term “bonding” is used by many different vendors and translate into different capabilities, but in short, we have implemented NIC Bonding based on the RedHat kernel. As you can see from the following, RHEL has various bonding modes which offer different capabilities. https://www.thegeekdiary.com/red-hat-centos-how-to-create-interface-bonding/
The ISE implementation is essentially providing Mode 1 functionality, i.e. “Active Backup -- One NIC active while another NIC is asleep. If the active NIC goes down, another NIC becomes active.” We do not implement the capabilities available in other modes such as Load Balancing or link aggregation. Teaming is another option within some operating systems including RHEL, but our implementation is not based on Teaming, so I will be sure to replace references to “Teaming” with “Bonding” in my BRKSEC-3699 presentation.
Feedback from TAC was the following:
I have checked into this and you can connect the ISE appliance to both FEX modules using active and standby NICs, there are no caveats for this topology, however on this case is recommended to use the “vpc orphan-ports suspend” command, this is in case that vPC peer link fails, the secondary switch will bring down all its connected vPC ports, assuming those vPCs are up in the vPC primary switch, this makes the switch to bring down also the orphan ports on that situation if your appliance is using active-standby type of teaming, so you want to force a physical shutdown on the link for the teaming software to change the traffic to flow on the other link.
It should be configured on both vPC switches because you cannot predict which switch is the vPC secondary on some later time.
Regards,
Craig
