UCS and Multicast

[james21970]

All,

We are experiencing an issue with some virtual Kemp LB's in our environment where they are not functioning properly with regard to multicast, and their HA.

We came across a doc that seems to point to a possible solution:

https://supportforums.cisco.com/thread/2013429

I'm no multicast wizard, but one thing that's throwing me is this whole concept of specifying a querier within the VLAN. I am assuming that there has to be a layer 3 device in that VLAN (specified by the IP address of the querier) to perform this function?

Can someone explain the nuances regarding the querier?, or if anyone has had any similar issues in the UCS environment when dealing with muticast, I'd appreciate any information you could provide.

[cralvara]

Hello James,

I hope that you are doing great.

According to our internal documentation referencing to the igmp snooping on FabricInterconnect, it is necessary to have deployed a multicast router.

Here there is part of the documentation.

In terms of Fabric failover, when you enable this on a UCS blade's vNIC, this really only affects unicast traffic and not multicast.  This is because the unicast forwarding table is sync'd between the two FI's using CFS (Cisco Fabric Services), so after a failover occurs, the Interconnect can simply issue a gratuitous ARP (GARP) and traffic is virtually unaffected. In terms of multicast traffic, when a fabric failover event occurs the following happen:

• Some event happens and the primary path fails
• The primary instance of the vNIC goes down, and the multicast stream stops flowing
• The standby instance of the vNIC on the remaining fabric becomes active
• The secondary Fabric Interconnect issues a GARP to notify upstream which of the MAC move
• The Fabric Interconnect send a IGMP global leave to the upstream multicast router
• The global leave triggers a multicast group specific query on the multicast router, but if the vNICs are still in the bring-up process which means it will miss the first query.
• After the query timer expires, the multicast router will send an IGMP Query to all vNICs
• The UCS host will respond with a join response and the multicast stream will resume.

As you can see, multicast convergence relys on the standard IGMP timers and during this period there could be a short loss of traffic.

There are a couple ways you can minimize (but not eliminate) traffic disruption

1. Adjust the IGMP Query timers on the upstrem multicast router.  Increaseing the frequency will minimize the failure period, but will add IGMP traffic.
2. If the UCS hardware (Fabric Interconnect & IOM) support it, you can prevent any “blackholing” traffic upon failure until re-acknowledged.  The fabric port channel would simply re-hash the traffic to the remaining members.  Without the fabric port channel a single IOM-FI link failure will affect all pinned traffic indefinately until the chassis is re-acknowledged, and pinned is re-applied.

Hopefully, this information will help you.

Best Regards

Cristina Alvarado

Cisco Virtual Engineering - Partner Help

[admin11111]

Christina,

Thank you for your time on this, but we are not having an issue with regard to FI failover, we are having an issue where the customers virtual Kemp Load Balancers are not communicating correctly when on different B series blades (when on the same blade, they communicate fine).

My issue with this configuration of the querier, is that the docs seem to suggest that you can specify a querier by IPv4 address even though there isn't an SVI or other layer 3 device that actually owns that IP.

Ultimately, I'd like to know what specifically is needed in the UCS environment in order for VM's that live on blades that use multicast to communicate to function properly.

Thank you,

James

[admin11111]

You don't need a SVI interface to configure the Multicast Querier in the FI, you can use the IP address of UCS Manager for it.

[admin11111]

You don't need a SVI interface to configure the Multicast Querier in the FI, you can use the IP address of UCS Manager for it.

[james21970]

All,

I was able to sort this out by utilizing the 'disable-loop-detection' command on the 1k (under the veth port profile) for the specific protocol that the virtual kemp load balancers were using. Just fyi to anyone else having this type of issue, you may need to check the type of protocol with a sniffer, as our server guys stated that the docs specified CARP, but wireshark showed VRRP, so when I first disabled loop detection for CARP, the LB's still weren't working, but when I disabled it for VRRP, it began working fine.

James