cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
309
Views
0
Helpful
5
Replies

CBS220 lots of "invalid RX" IGMP

train_wreck
Level 1
Level 1

So I have a flat network with a CBS220 as the main switch off of the router and a second CBS250-T-D that is powered by the 220. I have enabled IGMP snooping and enabled the IGMP querier on the 220, and enabled IGMP snooping (without querier) on the 250. In the 220 CLI i see large amounts of "Invalid RX" packets increasing regularly:

                IGMP Snooping Status
                --------------------

    Snooping                        : Enabled
    Report Suppression              : Enabled
    Operation Version               : v3 
    Forward Method                  : mac 
    Unknown Multicast Action        : Flood


                Packet Statistics
    Total RX                         :  85830 
    Valid RX                         :  16211 
    Invalid RX                       :  69436 
    Other RX                         :  0 
    Leave RX                         :  5 
    Report RX                        :  16206 
    General Query RX                 :  0 
    Specail Group Query RX           :  0 
    Specail Group & Source Query RX  :  0 
    Leave TX                         :  0 
    Report TX                        :  15910 
    General Query TX                 :  115055 
    Specail Group Query TX           :  55 
    Specail Group & Source Query TX  :  0

 I THINK multicast is working, as I have 2 Sonos devices that join to the 239.255.255.250 group, and the web interface correctly identifies which ethernet ports they are connected to. Also when I start avahi-daemon on my Linux PC it will join the group as well, and I can ping the group address and I get unicast replies back from both of the Sonos.

So what's going on with the invalids? Thanks in advance.

5 Replies 5

@train_wreck hi, this can be due to faulty cable/SFP. can you try #sh interface and see if you can find any CRC errors..?

Please rate this and mark as solution/answer, if this resolved your issue
Good luck
KB

Zero errors, and the copper-port-test feature reports all good.

train_wreck
Level 1
Level 1

Hmm well actually there are 0 CRC but it looks like a ton of "input errors"? This is from the CLI on the 220, g/2 is connected to the 250

 

GigabitEthernet2 is up
  Hardware is Gigabit Ethernet
  Auto-duplex, Auto-speed, media type is Copper
  flow-control is off
  back-pressure is enabled
     8083250 packets input, 1649346442 bytes, 0 throttles
     Received 23556 broadcasts (1059121 multicasts)
     1 runts, 3892195 giants, 0 throttles
     3892449 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     1059121 multicast, 0 pause input
     0 input packets with dribble condition detected
     16958192 packets output, 15051713059 bytes, 0 underrun
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 PAUSE output

 

Ruben Cocheno
Spotlight
Spotlight

@train_wreck 

Maybe try to do a wireshark, and look for IGMP traffic and/or that potentially can increase those counters. No sure if you doing filtering on the IGMPv3, epdening on the capabilities of that CBS.

Tag me to follow up.
Please mark it as Helpful and/or Solution Accepted if that is the case. Thanks for making Engineering easy again.
Connect with me for more on Linkedin https://www.linkedin.com/in/rubencocheno/

I can see during a tcpdump that the counter increases whenever any multicast traffic is received. Group query traffic will do it, and the Sonos periodically send discovery packets UDP dport 1900 to the multicast address, and that traffic will increase the counter as well. This is all IGMPv2, no filtering. Like I said, multicast seems to be operational, so it may just be a reporting bug. I can post decrypts of the multicast traffic if requested. ("-vX" switch in tcpdump)