Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
5760
Views
1
Helpful
5
Replies

UCS and Multicast

james21970
Level 1
Level 1

‎08-11-2013 08:56 AM

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.

5 Replies 5

cralvara
Level 6
Level 6

‎08-12-2013 07:24 AM

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

0 Helpful