Re: AP Multicast Mode

Steven Williams · ‎07-28-2011

I am currently configuring Multicast on my WLC 5508's and had some questions about the configuration that Cisco Documents go through.

The AP Multicast Mode options are unicast or multicast, when I select multicast mode it wants me to enter a multicast group address. I have 7 of them that clients need to be able to join, so what do you do in this case? I did setup a multicast direct stream in the WLC with the range of my multicast addresses and changed the QoS on the WLAN, then enabled multicast on the AP radio's. Now my question is: I left the AP multicast mode setting to unicast because I could enter one addresses, which I knew wouldnt work, so how do I know multicast is working on my wireless devices without having a wireless capable NIC to capture packets using something like wireshark?

weterry · ‎07-29-2011

The Multicast Address specified in "Multicast-Multicast mode" is actually an Address for the WLC to talk Multicast to its APs. This is not the addres your clients are talking to.

So basically what happens is that a multicast packet is receieved at the WLC, and the AP sens a Multicast CAPWAP packet out to its APs (different address, because this is a CAPWAP packet destined to APs, not the destination of the inner packet).

Anyhow, APs join the multicast group you said in the Multicast-Multicast config and they'll recieve the packets (assuming you infrastructure config works).

Unicast mode is how you test regular client side multicast....

If your question is: How do I know if Multicast-Direct is working..... that is a good question. I suppose if you have it configured and your clients are receiving the multicast stream, something must be working right whethers it direct or not.... I wonder if there is some statistics on the WLC that show it?

Steven Williams · ‎08-04-2011

Has anyone worked with video over wireless? Like a Vbrick solution? I am struggling with a very strange problem and before I open a TAC case I want to see if anyone has any input.

I have 7 streams of live TV. All of them work great except two that are bad quality. The two that are bad are very choppy and pixelated.

If I change those channels to another stream they work just fine. Now when my AP multicast mode is set to unicast these are the results I get, all streams work great except the two. Now I switch my AP multicast mode to multicast and use an unassigned multicast IP address and those two bad streams start to work great, but only for about 5 to 7 minutes then the connection just drops completely and I can't view any channels anymore. So something is not working with the AP multicast. I have my controller VLAN set with ip pim sparse-dense and my AP/Client VLAN set with the same. The streams work great on the wired network and I have other multicast applications that work on the network so I know the network is configured for multicast. Where do I start looking?

Steven Williams · ‎08-05-2011

Alright here is what I have, attached is the debug bcast all test file and heres some info I have.

Stream Multicast IPs in question: 239.100.1.4

Client accessing stream: 10.210.1.50 (MAC - 0022.69A4.437C)

Stream started at 9:35:40 and then stopped at 9:39:09

Stream started at 9:42:48 and then stopped at 9:46:07

Stream started at 9:49:42

So it seems like the stream is active for about 4 minutes.

Multicast is running on both 2.4 and 5.0 GHZ, the same problem on both ranges.

Steven Williams · ‎08-05-2011

http://ciscocertstudyblog.blogspot.com/2011/03/cisco-5508-wlc-5-min-timeout-bug.html

Seems kind of like my problem but I only have 1 WLC5508 using the multicast address of 239.100.1.10.

Steven Williams · ‎08-05-2011

What does this mean?

join group 239.100.1.4 and vlan = 301 is not there adding...

weterry · ‎08-05-2011

I've never looked into multicast/broadcast debugs like this before...

But it looks to me like the log shows up the first time a client in that vlan joins a multicast group?

So each time a client joins the same multicast group, if its a client in a different vlan then it adds the group? I think?

So your debug shows the client added to the group at 14:35:01 and 14:42:48...?

*bcastReceiveTask: Aug 05 14:41:18.896: IGMP packet received over vlanid = 301 from DS side

*bcastReceiveTask: Aug 05 14:41:18.896: received an IGMP query for multicast vlan = 301 address 239.100.1.4 intfnum = 13

*bcastReceiveTask: Aug 05 14:41:18.896: no client for the address

And this says at 14:41:18 a packet capture in from DS to that mcast address, but the WLC I guess doesn't think anyone is on to list to it?

The latter comes from:

*bcastReceiveTask: Aug 05 14:41:16.821: Timeout: Removing mgid[1775] entry from Table

*bcastReceiveTask: Aug 05 14:41:16.821: Sending IGMP leave message on interface [13], vlan:[301]

*bcastReceiveTask: Aug 05 14:41:16.821: IGMP message send succeeded src 10.210.1.2 and dst 239.100.1.4, hdr len 32,message type 17

So at 14:41:16 the MGID 1775 was removed from the WLC and it sends a "leave" for vlan 301?

So if you look at just your client address, we see:

Line 6567: *bcastReceiveTask: Aug 05 14:38:09.112: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 6602: *bcastReceiveTask: Aug 05 14:38:09.611: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 7076: *bcastReceiveTask: Aug 05 14:38:29.613: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 7149: *bcastReceiveTask: Aug 05 14:38:31.115: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 7200: *bcastReceiveTask: Aug 05 14:38:42.614: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 7290: *bcastReceiveTask: Aug 05 14:38:44.614: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 7799: *bcastReceiveTask: Aug 05 14:39:02.116: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 8148: *bcastReceiveTask: Aug 05 14:39:10.118: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 11402: *bcastReceiveTask: Aug 05 14:42:48.140: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 11542: *bcastReceiveTask: Aug 05 14:42:50.639: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 11886: *bcastReceiveTask: Aug 05 14:43:05.639: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 12132: *bcastReceiveTask: Aug 05 14:43:11.140: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 12218: *bcastReceiveTask: Aug 05 14:43:22.141: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 6567: *bcastReceiveTask: Aug 05 14:38:09.112: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 6602: *bcastReceiveTask: Aug 05 14:38:09.611: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 7076: *bcastReceiveTask: Aug 05 14:38:29.613: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 7149: *bcastReceiveTask: Aug 05 14:38:31.115: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 7200: *bcastReceiveTask: Aug 05 14:38:42.614: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 7290: *bcastReceiveTask: Aug 05 14:38:44.614: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 7799: *bcastReceiveTask: Aug 05 14:39:02.116: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 8148: *bcastReceiveTask: Aug 05 14:39:10.118: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 11402: *bcastReceiveTask: Aug 05 14:42:48.140: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 11542: *bcastReceiveTask: Aug 05 14:42:50.639: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 11886: *bcastReceiveTask: Aug 05 14:43:05.639: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 12132: *bcastReceiveTask: Aug 05 14:43:11.140: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c
Line 12218: *bcastReceiveTask: Aug 05 14:43:22.141: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

My assumption is that 3 minute GAP in the middle is why we clear the mgid? I'm not sure why there is GAP though, it looks like these are packets from the client that regularly come in... I guess if we dont get it we clean up the table?.

Steven Williams · ‎08-05-2011

This is very frustrating. There is nothing that gives me any indication on where to look.

weterry · ‎08-05-2011

Perhaps its time to reach out to TAC?

Either way, if it were me, I'd be trying to figure out what was happening here:

Line 8148: *bcastReceiveTask: Aug 05 14:39:10.118: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 11402: *bcastReceiveTask: Aug 05 14:42:48.140: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

You said the stream stopped at 9:39:09 and started at 9:42:48.

Thats exactly when the debug says it stopped receving report packets from your client... so my untrained eye would say that the client stopped sending something related to mcast, and the WLC timed out the stream untill the client send the packet again 3.5 minutes later....

The question is why didnt the client send it (whatever it is)?

So, I would be curious to see a capture from the clients point of view to make sure the client thinks it is sending whatever this is..... and then I guess i'd be looking at a capture of the wired infrastrcture to make sure that packet is making it to the wlc?

I'll be the first to admit that I don't know the details of multicast. Is it possible this is an "igmp snooping" type issue?

Steven Williams · ‎08-05-2011

packet from the client would be awesome, but I do not have a Wireless NIC capable of doing so, what my options on the client side?

weterry · ‎08-05-2011

I meant a wireshark capture from the clients point of view (not wireless sniffer from the client). If you run wireshark against you wireless card, you should see all the packets you send an recieve (not 802.11 stuff). It should look just like if you did it from the LAN interface.

802.11 stuff from a real wireless sniffer would be awesome though

All this is going to tell us though is during the mcast outage whether or not the client is keeping up his side of the conversation....

In other words... if you the client stops sending these packets... but it keeps recieving mcast and suddenly mcast stops (times out from wlc) then I'd say why did the client stop?

If the mcast stops... but the client still sends those packets... then that tells me the packets must just not be making it to the wlc? (or the client stops sending them because the mcast stopped, which means the mcast would have stopped upstream for the WLC?

Honestly, you've got quite an interesting scenario from my perspective and I'm real interested to find out what the root problem is.

Steven Williams · ‎08-05-2011

Client Wireless card is not an option in wireshark. So I need to enable something?

weterry · ‎08-05-2011

The wireless card isn't even listed? How about this, can you put the client WIRED in the same vlan, and get a working wireshark capture from the LAN interface for a 10 minute stream? This way you can at least characterize what it "should" look like...

I'm not sure how you fix wireshark to see your wireless adapter... I've never run into that before, its always been listed as just another network card to capture from...

Steven Williams · ‎08-05-2011

ok I got it, it is labeled as microsoft, not the actual name of my wireless NIC ( I <3 Windows )

So the file is like 97 meg so to big to attach but heres what I got at the beginning of the stream, mid stream, and end stream.

Beginning Stream :

724 8.209437 10.210.1.60 239.100.1.4 IGMP V2 Membership Report / Join group 239.100.1.4

Mid Stream I have mostly H264 and RTP protocols, along with some pings to the multicast address, but I also noticed I have some joins in mid stream too. Is this normal?

736 8.278025 10.101.11.23 239.100.1.4 H264 PT=DynamicRTP-Type-96, SSRC=0x58A01E08, Seq=24891, Time=2734061237, Mark FU-A

737 8.295892 10.101.11.23 239.100.1.4 RTP PT=DynamicRTP-Type-97, SSRC=0x58A02DA8, Seq=45011, Time=2499209973, Mark

836 8.620254 10.210.1.60 239.100.1.4 IGMP V2 Membership Report / Join group 239.100.1.4

994 8.933420 10.210.1.50 239.100.1.4 ICMP Echo (ping) request (id=0x0001, seq(be/le)=41711/61346, ttl=128)

And here is end Stream:

76232 196.618731 10.101.11.23 239.100.1.4 RTP PT=DynamicRTP-Type-97, SSRC=0x58A02DA8, Seq=50896, Time=2505236228, Mark

76233 196.633273 10.210.1.50 239.100.1.4 ICMP Echo (ping) request (id=0x0001, seq(be/le)=42646/38566, ttl=128)

76234 202.120928 10.210.1.60 239.100.1.4 IGMP V2 Membership Report / Join group 239.100.1.4

76235 204.121006 10.210.1.60 239.255.255.250 IGMP V2 Membership Report / Join group 239.255.255.250

weterry · ‎08-05-2011

I'm assuming these messages are the same thing we see in the WLC debug:

836 8.620254 10.210.1.60 239.100.1.4 IGMP V2 Membership Report / Join group 239.100.1.4

(WLC debug was:

Line 6602: *bcastReceiveTask: Aug 05 14:38:09.611: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 7076: *bcastReceiveTask: Aug 05 14:38:29.613: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

Line 7149: *bcastReceiveTask: Aug 05 14:38:31.115: Recieved Igmp v2 report packet from client 00:22:69:a4:43:7c

So what if you filter your wireshark to show you only the Membership Report packets...?

I'm assuming during your stream you see them often but whenever the stream stop showing up there is a gap in these packets as well?

It might be later this weekend before I can review any more of this. I'm not hearing anyone else chime in here, so my suggestion would be to open a TAC case and ask for help as well....