IP Multicast on Cat2960 issue

Wolfgang Maier · ‎10-21-2015

Hi @all,

I have a weird multicast problem.

I´ve setup multicast routing in our network.

Multicast is working so far but the Receivers attached to the Catalist 2960 Switches receive the stream in a very poor quality (pixel images, distorted sound, choppy image flow)

The Source is a VLC Stream to the group 239.193.0.1 with a TTL=12 . However the same stream on the same VLAN only on a Catalyst 3560 or 2950 is playing smoothly. Based on this information, I think there´s something wrong at the 2960 end but I can´t fugure what. igmp snooping is active and I can see the mroute and querier.

I had a look at the network utilization and on the receivers where the stream is working (attached to 3560/2950) have a network utilization of around 1Mbit/s The other receiver where the stream is choppy the network stream is around 4Mbit/s....weird.

Can someone help me out? Thank you

Wolfgang Maier · ‎10-21-2015

Now I´ve found out that if I connect the 2960 Switch to the 3560CX switch streaming works *confused*

Peter Paluch · ‎10-22-2015

Hello Christian,

This issue is confusing indeed.

One thing, though: Can you confirm that when you had your 2960-PST connected directly to the SiteB switch, all ports on the 2960-PST and the corresponding port on the SiteB switch were operating at at least 100 Mbps, full duplex? Are you configuring any of these parameters (speed and/or duplex) manually at any point in your network?

Best regards,
Peter

Wolfgang Maier · ‎10-22-2015

Good day Peter,

thank you for your reply. Yes, the trunk ports are all 1Gbit/s and the ports towards the receivers are 100Mbit/s.

I also noticed a lot of drops on the interfaces towards the receivers but only when the 2960-PST is directly connected to the 6509-V-E (Site B)

FastEthernet0/2 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 6899.cd3d.ad82 (bia 6899.cd3d.ad82)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 12/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1772366
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 4992000 bits/sec, 454 packets/sec
     5666 packets input, 747531 bytes, 0 no buffer
     Received 1479 broadcasts (1108 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 1108 multicast, 0 pause input
     0 input packets with dribble condition detected

This drops are constantly increasing which would explain the bad quality of the stream. But why are these packets dropped?

I thought OK, lets check the core switch there must be something. And here is what i found out :

IP statistics:
Rcvd: 2032682421 total, 574453407 local destination
         0 format errors, 0 checksum errors, 40270311 bad hop count
         6 unknown protocol, 528722 not a gateway
         0 security failures, 0 bad options, 8527652 with options
Opts: 4 end, 0 nop, 0 basic security, 0 loose source route
         0 timestamp, 0 extended security, 4 record route
         0 stream ID, 0 strict source route, 8527648 alert, 0 cipso, 0 ump
         0 other
Frags: 3 reassembled, 0 timeouts, 0 couldn't reassemble
         2213 fragmented, 0 couldn't fragment
Bcast: 115203121 received, 3150421 sent
Mcast: 22500620 received, 20975346 sent
Sent: 630567240 generated, 1135212704 forwarded
Drop: 78437506 encapsulation failed, 0 unresolved, 0 no adjacency
         3172490 no route, 0 unicast RPF, 0 forced drop
         0 options denied, 0 source IP address zero

This counter is increasing also. But this would mean that the multicast stream has a TTL issue. On the source I´ve double checked VLC. These are the stream options

:sout=#rtp{dst=239.193.0.1,port=5004,mux=ts,ttl=12} :sout-all :sout-keep

If there is indeed a TTL issue, why does the stream work flawlessly on a 2950 and 3560 ?

I dont have any clues.

Best regards,

Christian

Wolfgang Maier · ‎10-22-2015

To exclude any issues with TTL I´ve measured the multicast traffic on Site B:

All packets are send with a ttl value of 10.. so this wouldn´t be a issue

Jon Marshall · ‎10-23-2015

This really is confusing.

Is all the routing for vlans done on the 6500s ?

When you see the problems what do unicast pings show ie. do you also see higher response times via that switch ?

When you have the 2960 directly connected what do -

"sh ip igmp snooping groups"
"sh ip igmp mrouter"

show and is there any difference in the outputs when you connect via the 3560.

Jon

Wolfgang Maier · ‎10-26-2015

Hi Jon,

yes, routing is done on the 6509. The pings from and to the receiver are all <1ms no packet loss.

Here is the output from the 2960:

Vlan      Group                    Type        Version     Port List
-----------------------------------------------------------------------
250       239.193.0.1              igmp        v2          Fa0/1, Gi0/3
250       239.255.255.250          igmp        v2          Fa0/1, Gi0/3

Gi0/3 is the trunk to the 6509

sh ip igmp mrouter isn´t available as this are L2 switches.

I get the same output on the 3560/2950

Christian

Wolfgang Maier · ‎11-03-2015

One step further: thanks to our nice support tech who suggested to set the trunk from 1Gbit/s to 100Mbit/s.

Now, with a 100Mbit/s Trunk all drops on the int fa0/1 dissapeared and the multicast stream works as expected.

The total bandwith of the stream on that trunk interface is 5 Mbit/s (avarage) so this can only be a buffer problem.