dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1849
share rss forum feed

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply to DarkLogix

Re: [Config] AP1242AG question

said by DarkLogix:

I saw that it skipped some sequence numbers, showing that it missed some data.

Was it TCP or UDP data being transmitted? If it's UDP, remember UDP doesn't use sequence numbers.

Original Link Here, but the "ip igmp snoop" command...

IGMP snooping allows switches to examine IGMP packets and make forwarding decisions based on their content. You can configure the switch to use IGMP snooping in subnets that receive IGMP queries from either IGMP or the IGMP snooping querier. IGMP snooping constrains IPv4 multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically to forward IPv4 multicast traffic only to those ports that want to receive it. With Release 12.2(33)SXJ2 and later releases, IGMP snooping also constrains multicast traffic to VPLS interfaces.

IGMP, which runs at Layer 3 on a multicast router, generates Layer 3 IGMP queries in subnets where the multicast traffic needs to be routed. For information about IGMP, see Chapter 37 "Configuring IPv4 Multicast Layer 3 Switching."

...I've really got to read up on multicast again... but glad you got your problem figured out DarkLogix See Profile

Regards


DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3

1 edit
It was the debug sequence numbers that were skipping.

A problem I read about when looking to have the debug data go to vty. Because the way the buffer works sending the debug messages to vty they get sent via UDP so if the interface buffer gets full it drops the debug message.


DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3
reply to HELLFIRE
I think its more of IGMP not being handled properly by the AP.

per the posts that I found it seems the 1242 (and maybe other cisco AP's, though maybe fixed at some point) doesn't handle multicast properly.

it should have seen that there was a wifi client listening for multicast and another sending multicast, but instead they didn't see each other via multicast and the multicast didn't reach anything other than the AP.

so wireshark didn't see it because it was constrained to the wifi side of the AP only.
--
»Death Star Petition


tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1
said by DarkLogix:

I think its more of IGMP not being handled properly by the AP.

per the posts that I found it seems the 1242 (and maybe other cisco AP's, though maybe fixed at some point) doesn't handle multicast properly.

it should have seen that there was a wifi client listening for multicast and another sending multicast, but instead they didn't see each other via multicast and the multicast didn't reach anything other than the AP.

so wireshark didn't see it because it was constrained to the wifi side of the AP only.

igmp is a layer-2 join mechanism for mcast streams.
when a host wants to join an mcast stream -- it sends a join-request upstream. for devices that are "in the way" -- they 'snoop' the igmp and forward it along upstream -- until the tree is constructed to the source -- or some device who is aware of where the source is via pim, etc.

igmp snooping is a mixed-bag of support out of the box (i.e. enabled by default).

from what it appears -- cisco ap's are disabled by default.

dot11 igmp snooping-helper
should help snoop the mcast source and forward it along.

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."


DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3
Well it looks like "ip igmp snooping" was on by default on mine.

Doing "no ip igmp snooping" on the AP fixed it.
--
»Death Star Petition

HELLFIRE
Premium
join:2009-11-25
kudos:18
...which makes me wonder why it was an issue in the first place. As the chunk I quoted said, it's so a device can
figure out how to forward multicast traffic. IIRC it has to be one SOMEwhere along the physical chain of devices
so it can figure out where it has to go... unless turning it on in two places along the chain screws it up somehow...

I hate a mystery right before going to bed....

Regards


tubbynet
reminds me of the danse russe
Premium,MVM
join:2008-01-16
Chandler, AZ
kudos:1
i would venture a guess of the following (based on this article -- i'm knee-deep in ccie lab and don't want to break too much focus)

»wiki.stocksy.co.uk/wiki/Cisco_12···eirdness

if this is indeed the truth -- it may seem that for every 'non-native' bridge-group -- you may need to tell the access-point to snoop igmp. by disabling 'igmp snooping' you won't have any igmp being forwarded upstream (i.e. if you had wired hosts performing the same functions) -- and everything will be isolated.

i think with the snooping helper -- you'll sniff igmp, bridge them to wired, as well as push them over the wireless -- but that is pure speculation on my part.

i haven't messed with autonomous a/ps in a long time -- everything i've done is controller-based.

q.
--
"...if I in my north room dance naked, grotesquely before my mirror waving my shirt round my head and singing softly to myself..."

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:9
reply to HELLFIRE
It's a bug. It simply doesn't handle multicast correctly. (common failing of wireless gear.)

IGMP snooping allows the device doing the snooping to filter multicast to what's actually needed on a link. Without this "hack", all multicast traffic is flooded as broadcast traffic.


DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3
said by cramer:

It's a bug. It simply doesn't handle multicast correctly. (common failing of wireless gear.)

IGMP snooping allows the device doing the snooping to filter multicast to what's actually needed on a link. Without this "hack", all multicast traffic is flooded as broadcast traffic.

My understanding is IGMP snooping trades CPU for bandwidth.
It builds a table of what is listening for multicast and then if something sends a multicast it only sends it to those listening, thus saving bandwidth on the non-listening ports. (kind of like a switch to a hub)

but on the AP1242AG (possibly other models too, and possibly fixed in a newer IOS) it just dead ends multicast at the radio, so even another wifi device won't hear the multicast.

By turning snooping off (the default is on, thus why the command didn't show up in the running config, but the no form does show up in the running config)

Its just a matter of a bug that IGMP snooping doesn't work on the AP.
--
»Death Star Petition

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply to cramer
You wouldn't happen to have a bugID would you cramer? Funny that it still hasn't been fixed yet, but there's been wierder ones...

Regards


DarkLogix
Texan and Proud
Premium
join:2008-10-23
Baytown, TX
kudos:3
said by HELLFIRE:

You wouldn't happen to have a bugID would you cramer? Funny that it still hasn't been fixed yet, but there's been wierder ones...

Regards

do we know if its been fixed?
I'm running the IOS listed below, but I think theres a newer version, but I don't have access to download it I don't think.
c1240-k9w7-mx.124-10b.JDA
--
»Death Star Petition

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:9

1 edit
Depends on who you ask... 12.4.10b-JDA3 (GD) is the lastest on that path. Cisco lists 12.4.21a-JY as the latest, but 12.4.25d-JA2 is the last image published (14-Sep-2012) I'm running 12.4.25d-JA -- I guess I should test this.

And no, I have no clue what the bugID(s) may be. (if they exist, or if they're visible outside Cisco.)

[EDIT]
Tested. And it works... well as badly as I expect multicast streams to "work" via wireless. (that being even 1.5Mbps is too fast for it)
ap#show ip igmp snooping groups vlan 1
Vlan Group Version Port List
---------------------------------------------------------
1 239.255.0.1 v2 Dot11Radio0
1 239.255.255.250v2 Dot11Radio0

239.255.0.1 is the HDHR (streaming PBS) [For the record, it won't unicast a 19Mbps stream either; 13-14 works]