cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
450
Views
0
Helpful
4
Replies

Bad Hop Count, Not a GW, NoPort UDP messages from IGMP Join & SSDP

Devinder Sharma
Level 1
Level 1

Hi All,

At an existing customer, I enabled IGMP Snooping Querier (and by default IGMP Snooping is enabled) for a L2 environment, created  a separate VLAN for Wired SmartTVs that need to use Multicast streams from TV service . While all looks good, looking at the output of  "show ip traffic", I can see a number of Bad packet count. Drilling down and down a "debug ip error" , it clearly shows that with source of 0.0.0.0 and dest of 255.255.255.255 (DHCP requests) by TVs, logs it as UDP NoPort. Similarly, lots of SSDP and IGMP join and query response messages which will by standard have TTL of 1, and after going thru the switch, somehow it is stripped of TTL, so it also shows up as Bad Hop count. Then there are many IGMP packets that are shown as No Gateway error, which are simply join messages going to the streaming server within the same vlan / subnet.

While I understand that these are not errors but somehow notifications, but why will they be counted as such. And customer is concerned that these informational messages, keep piling up and he needs to periodically need to issue "clear ip traffic"

Does anyone know of command to tell the switch to not log these messages under the ip traffic stats,  just like we can do with logging discriminator for syslog?  And the switches are 2960X running last available IOS code.

Thanks so much.

4 Replies 4

Devinder Sharma
Level 1
Level 1

Here is another recent thread on similar topic. In my case though, there is no multicast routing and it is all L2 within same subnet.

https://community.cisco.com/t5/routing/bad-hop-count-224-0-0-2-224-0-0-5-behavior/td-p/4809206

Interesting thing is that TTL cannot be decremented by a switch if it is not routing the packet out of its subnet. Similarly IGMP join messages from TVs to multicast group message, are not to be routed and thus there should be no gateway error message either.  Thanks

Devinder Sharma
Level 1
Level 1

We did another test. Added a 2960G switch, which again has all Gig ports and trunked this up to 2960X. Moved 2 TVs  off of the 2960X and onto 2960G and 2960G has no above issues. The issues are only on 2960X switches that are set up as IGMP querier (for backup just in case querier switch were to go down).  These 2960X switches when looking under show interface summary or show interface gi 1/0/x, has the Total output drops that are reflected as OQD under show interface summary. Only on the TV ports on 2960X and not on the streaming server port.  No QoS setup, so all buffers should be available. Further 2960X has double the buffer size for 2960G. And streams are really low bandwidth of the order of 5Mbps. But performance on 2960G (which is non querier) is better than 2960X.

Devinder Sharma
Level 1
Level 1

Quick debug ip error output from 2960X. We can see that DHCP packet (which is 576 bytes as per RFC) is being flagged as error. The mDNS packets from 10.10.10.x TV subnet to 224.0.0.251 are sent with TTL of 1 as per RFC and should not be logged as notgateway error as they are supposed to stay within subnet.

Apr 10 11:45:05.879 EDT: IP: s=10.10.10.36 (Vlan10), d=234.10.5.42, len 32, dispose ip.hopcount
Apr 10 11:45:06.530 EDT: IP: s=0.0.0.0 (Vlan10), d=255.255.255.255, len 576, dispose udp.noport
Apr 10 11:45:06.533 EDT: IP: s=10.10.10.1 (Vlan10), d=255.255.255.255, len 335, dispose udp.noport
Apr 10 11:45:06.680 EDT: IP: s=10.10.10.52 (Vlan10), d=234.10.6.51, len 32, dispose ip.hopcount
Apr 10 11:45:07.278 EDT: IP: s=10.10.10.79 (Vlan10), d=224.0.0.251, len 300, dispose ip.notgateway
Apr 10 11:45:07.278 EDT: IP: s=10.10.10.18 (Vlan10), d=224.0.0.251, len 311, dispose ip.notgateway
Apr 10 11:45:07.575 EDT: IP: s=10.10.10.66 (Vlan10), d=234.10.5.200, len 32, dispose ip.hopcount
Apr 10 11:45:07.722 EDT: IP: s=10.10.10.33 (Vlan10), d=234.10.5.218, len 32, dispose ip.hopcount
Apr 10 11:45:10.126 EDT: IP: s=10.10.10.82 (Vlan10), d=234.10.5.16, len 32, dispose ip.hopcount
Apr 10 11:45:11.199 EDT: IP: s=10.10.10.40 (Vlan10), d=234.10.5.160, len 32, dispose ip.hopcount
Apr 10 11:45:11.528 EDT: IP: s=0.0.0.0 (Vlan10), d=255.255.255.255, len 576, dispose udp.noport
Apr 10 11:45:11.559 EDT: IP: s=10.10.10.88 (Vlan10), d=234.10.5.14, len 32, dispose ip.hopcount
Apr 10 11:45:12.122 EDT: IP: s=10.10.10.60 (Vlan10), d=234.10.7.78, len 32, dispose ip.hopcount
Apr 10 11:45:13.171 EDT: IP: s=10.10.10.55 (Vlan10), d=234.10.6.156, len 32, dispose ip.hopcount
Apr 10 11:45:13.999 EDT: IP: s=10.10.10.38 (Vlan10), d=234.10.5.181, len 32, dispose ip.hopcount

Devinder Sharma
Level 1
Level 1

Looks like it is such an obscure subject that most community members never ran into this.

Review Cisco Networking for a $25 gift card