I have a SPAN monitor session setup to capture both tx/rx on a port 9 (see below). And I can see the multicast count ticking up on port 9. But none of the multicast packets show up in the SPAN session (and they don't seem to be making it across the switch). How can I figure out what's going on?
Another baffling thing is that, if instead of connecting to the port 9 directly, I connect through another small dumb switch (and then to the Catalyst), things seem to work. The multicast frames show up in the SPAN session, and they show up at the other end.
SwitchB#show monitor session 1 Session 1 --------- Type : Local Session Source Ports : Both : Gi0/9 Destination Ports : Gi0/10 Encapsulation : Native Ingress : Disabled
So does G0/9 have the multicast source or client attached and can you clarify how you are seeing the multicast count ticking up on that port?
Aside from that, IGMP should be enabled by default, but check with the following command:
sh ip igmp snooping detail
Also, check the muticast groups and associated ports:
sh ip igmp snooping groups
SwitchB#sh ip igmp snooping detail Global IGMP Snooping configuration: ------------------------------------------- IGMP snooping : Disabled IGMPv3 snooping : Disabled Report suppression : Disabled TCN solicit query : Disabled TCN flood query count : 2 Robustness variable : 2 Last member query count : 2 Last member query interval : 1000 Vlan 1: -------- IGMP snooping : Disabled IGMPv2 immediate leave : Disabled Multicast router learning mode : pim-dvmrp Robustness variable : 2 Last member query count : 2 Last member query interval : 1000 Topology change : No
SwitchB#sh ip igmp snooping groups <no groups>
Hmm...by default IGMP should be enabled. Is there anything in the config like "no ip igmp snooping"?
If so, you may want to try enabling it. Once enabled, if there is an active multicast it will show up with the "sh ip igmp snooping groups"
Also, once enabled you may see it in the span session.
Yes, I disabled it because I wanted to eliminate that as the problem. But the behavior is the same in either case.
With IGMP snooping turned off, the switch ought to be flooding multicast to all ports, without looking for a listener.
Wasn't aware that you turned off the IGMP to see if it would flood the multicast. Agree, and like the idea of trying that. However, with it turned on the "sh ip igmp snooping groups" command will indicate if the switch is forwarding (or at least thinks it is) any active multicast to the appropriate ports.
So is the device on port 9 the receiver and in the span do you see at least the joins/IGMP protocol?
Without the dumb switch, is port 9 working and your just not seeing it at the SPAN port or it's jut not working all around?
Another suggestion would be to configure port 10 just like port 9 (same VLAN) and then re-initiate the span. I've had span issues before that that has fixed.
I have a 2960 and can test it out relatively easy, unfortunately it wouldn't be until Monday when I'm back at work.
Yes, the device is on port 9, and the SPAN destination is port 10 (where I am sniffing the traffic). The eventual destination for the multicast traffic is elsewhere, across a couple of routers. I can see IGMPv3 and unicast in the SPAN just fine. I can see the counter for multicast on port 9 ticking up as well - so it does seem to register the multicast frames. Only, they don't show up in the SPAN, nor do they get switched to the other end.
As a first step, I just want to figure out what the switch is doing with these multicast frames. Does it just drop them? Is there a way to turn on verbose logs for port 9? I can see many supported debug commands, but how does one see their output?
Then next I'd want to figure out why it starts working if I connect the device to port 9 indirectly, through another small switch. The multicast frames show up in the SPAN, and make their way across the switch to the other end.
If it matters, the device is 10/100 and probably some old hardware. The small switch in the middle that makes things work is a 10/100/1000. That would point to something to do with auto-negotiation, but why would it affect only multicast (and not unicast)?
I have a C2960S-48FPD which is probably a newer model than yours, but see the multicast packets just fine in a span session. Not sure how much help this will be but:
1- As per my earlier post, turn IGMP snooping back on and with an active session up do the "sh ip igmp snooping groups" command. It should show the active multicast group and associated ports:
Vlan Group Type Version Port List
623 126.96.36.199 igmp v2 Gi1/0/26, Gi1/0/48
2- You can try "debug ip igmp snooping" which may also provide an indicator as to what is going on.
3- Clear the controller counters with the "clear controllers ethernet-controller" command and then check the multicast frames in and out of the interface(s) with the "sh controllers ethernet-controller f0/9" command
4- It certainly is puzzling that with the small switch inserted, everything works fine. Might be something there as you have said. May want to try moving to another port, possibly at the higher end of thew port numbers. Not sure of the 2960 architecture, but the intent would be to move it to a different ASIC
Thanks for looking this up.
Turned out to be a stupid problem. There was a VLAN header on the frames that was causing the switch to drop them. SPAN wouldn't show these frames to me (don't know why), but counted them in the stats. Wireshark wouldn't show the headers to me because the driver strips them off. Worked with that other switch in the middle because the switch was stripping off the VLAN header (dunno why - I suppose, because of the way it was configured).
Check this command
switch (enable) show span
Destination : Port 6/2
Admin Source : Port 6/1
Oper Source : Port 6/1
Direction : transmit/receive
Incoming Packets: disabled
Learning : enabled
Multicast : enabled
Filter : -
Status : active
Total local span sessions: 1