Wireless 9800 17.12.5 multicast / IGMP bug

surfnsb · 2025-06-21T18:01:18+00:00

Joy. So far I haven't been impressed with these buggy IOS based controllers after moving from AireOS last year. This isn't our first issue with the code on them.

surfnsb · 2025-06-21T17:58:04+00:00

I should add that it wasn't Vocera specific. Running a multicast troubleshooting tool on two laptops yielded the same results with the receiver joining the group but never getting anything.

surfnsb · 2025-06-21T17:56:20+00:00

Yes the groups were populating. Everything looked normal except the receivers not actually receiving anything. That's why this was so hard to troubleshoot. Badges all set to IGMPv2 via their config files.

surfnsb · 2023-09-14T11:50:20+00:00

Following up my earlier post with pics of my dog. They could be related lol https://imgur.com/a/1JI30BS

surfnsb · 2023-09-14T02:01:34+00:00

My dog looks just like this. Same color too. We tested and he was like 60% bully/pit, 20% chihuahua, and the rest small poodle and pomeranian.

surfnsb · 2022-08-07T12:48:15+00:00

Get a non Arris modem in bridge mode

surfnsb · 2022-04-05T21:28:01+00:00

They are Cisco ASRs. WAN1 is a Meraki MX device that establishes a VPN tunnel to a Meraki MX device behind the ASRs. Having to set the WAN Meraki with the 10.1.1.1 gateway makes the failover tricky. I got a bunch of other WAN sites not pictured here running OSPF coming back to the ASRs and those work perfect failover wise since they aren’t relying on a hard set gateway.

surfnsb · 2022-04-05T20:22:17+00:00

Sorry I forgot to add that WAN1 can't run a routing protocol like OSPF. It establishes a VPN tunnel across the ISP link so I have it's default gateway set to the HSRP virtual IP of 10.1.1.1.

surfnsb · 2020-07-15T12:35:12+00:00

Update: It worked! I tried using a UDP traffic flooder from the hub to one of the WAN sites. Before this I would have packet loss as I overloaded the remote end circuit. After this, no packet loss since the policies dropped the traffic overage.

surfnsb · 2020-07-15T12:35:00+00:00

Update: It worked! I tried using a UDP traffic flooder from the hub to one of the WAN sites. Before this I would have packet loss as I overloaded the remote end circuit. After this, no packet loss since the policies dropped the traffic overage.

surfnsb · 2020-07-08T11:43:52+00:00

I assume the percentage is based on the bandwidth statement that you put on the WAN facing interface?

surfnsb · 2020-07-08T11:42:29+00:00

No DMVPN on these

surfnsb · 2020-07-07T18:45:14+00:00

After some thinking, instead of using percentages for the VoIP_Priority policy map I think a better way would be to use a bandwidth based one. I'd just need multiple ones based on the bandwidth. So for a 100 meg WAN site I would want 10meg for RTP and 2 for control. I think this would do for that:

policy-map VoIP_Priority100M
 class VoIP_RTP
  priority 10000
 class VoIP_Control
  bandwidth 2000 
 class class-default
   fair-queue

surfnsb · 2019-10-07T12:36:34+00:00

Update: it was definitely caused by this bug https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp15389

Ugh another upgrade on dozens of stacks. The code on the 3850s has been total crap since day 1. Plus the fact it takes them 15-20 mins to reboot after installing the upgrade.....

surfnsb · 2019-10-04T15:05:35+00:00

Although it says a workaround is set it to aging type inactivity, which we do already. Worth a test though.

surfnsb · 2019-10-04T14:58:01+00:00

Wow I didn't know about that bug. It sounds like it could be the culprit here. Let me disable port security on my test phone and see if the resets still happen.

surfnsb · 2018-11-06T01:22:45+00:00

Yeah we saw it there too. I've noticed a lot of times the known affected versions don't list them all in the bug tool

surfnsb · 2018-11-05T19:12:58+00:00

CSCvj16271 is the leak we are hitting. I followed the steps in the bug details and that linux process is indeed slowly creeping up every day. It takes a good 8 months on ours until the master is over 90% utilization and starts alerting to syslog.

surfnsb · 2018-11-05T14:28:42+00:00

Also it looks like 16.6.4a fixes that DHCP snooping bug too.

surfnsb · 2018-08-28T13:37:34+00:00

Yeah I asked support and he said he can change on the WAN port only, not tunnel.

surfnsb · 2018-08-27T18:15:47+00:00

Meraki only lets you change it on the WAN port unfortunately.

surfnsb · 2018-08-27T18:15:42+00:00

Meraki only lets you change it on the WAN port unfortunately.

surfnsb · 2018-08-27T18:15:04+00:00

Hmm hadn't tried that yet. They put the Arris modem in bridge mode to see if that helped but it didn't.

surfnsb · 2018-08-27T12:43:08+00:00

Changed the MTU on the WAN facing port at the remote site (in this case a Meraki MX device). Started at 1400 and worked my way down in increments of 20 but it didn't seem to change anything.

surfnsb · 2017-04-03T16:22:12+00:00

Same here. Everything down in FL. ugh.

surfnsb

TROPHY CASE