Solved: Re: Configuring IGMP / Multicast on Cisco 2600

MadhuK7555 · ‎07-30-2009

Hi,

I am trying to setup a multicast video server over two PCs. The setup is very simple.

I have at one end a WindowsXP PC connected directly to FastEthernet0/0 port of the 2600 router. I installed VLC media player and trying to stream a video to a multicast address 225.1.1.15 over UDP protocol. This is my server

On the other end is a WindowsXP PC connected directly to FastEthernet0/1 port of the 2600 router. I use VLC media player to join the multicast address that the server uses.

| CISCO 2691 |

PC1----------------|FastEthernet0/0||FastEthernet0/1|------------------PC2

(192.168.4.10) | (192.168.4.5) (192.168.1.5) | (192.168.1.30)

I have enabled Multicast routing on the router. IGMP v3 on both interfaces. PIM in dense mode.

I used wireshark to capture the packets on the PCs. I have verified that normal end to end traffic flows fine. For example, pings work, regular HTTP streaming works perfect. But Multicast is the issue.

I see that the client side is behaving perfectly. The router sends a IGMP v3 general query. When I open a VLC player and open the network stream on the multicast address I can see a IGMP report on the wire. On the router I can see that 192.168.1.30 has joined the multicast group.

The problem is with the server side interface. The FastEthernet0/0 port doesn't even know that multicast traffic is flowing to it. There is no activity on the LEDs. It is dropping all the packets on the interface arriving from the server (192.168.4.10).

I have tried everything that I read in the Cisco manuals. Tried setting static Mcast routes, changed different PIM modes, setup RPs, performed RPFs. You name it.

Now I am desperate for help. This is very important project that I am involved. Could someone please take some time to help ?

Sorry about the long description. I can provide additional debug logs on request. For now I am attaching some logs which I think might be useful.

Peter Paluch · ‎07-31-2009

Hello,

The TTL is your problem here. The TTL may never be decreased down to 0. As your IP packets are sent out with TTL 1, after first routing their TTL would be decreased to 0 which is illegal. As a result, such packet will not be routed away from the segment on which it was transmitted.

Try to install a different version of VLC and try further to play with its settings. Your multicast IP packets absolutely have to have TTL higher than 1.

Best regards,

Peter

View solution in original post

MadhuK7555 · ‎07-30-2009

Also attaching the IGMP settings.

Jerry Ye · ‎07-30-2009

Hi,

In both of your FE, you only need these two multicast commands if you are doing PIM dense mode:

interface FastEthernet x/x

ip pim dense-mode

ip igmp version 3

Also, in the global config mode, these commands are not required

ip pim rp-address 192.168.4.5

ip mroute 192.168.4.0 255.255.255.0 10.10.10.10

HTH,

jerry

MadhuK7555 · ‎07-30-2009

Hi Jerry,

Thanks for replying. I tried what you said and still no multicast activity. "show ip igmp groups" show the multicast address joined by the client. But client is not receiving anything except querries from the router. Also "show ip mroute count" show 0 sources and zero packets forwarded.

----------------------------------------------------------------------------------------------------------

Router#show ip mroute count

IP Multicast Statistics

3 routes using 2144 bytes of memory

3 groups, 0.00 average sources per group

Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second

Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.255.255.250, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0

Group: 225.1.1.11, Source count: 0, Packets forwarded: 0, Packets received: 0

--------------------------------------------------------------------------------------------------------

Here is my running config

Router#sh run

Building configuration...

Current configuration : 686 bytes

!

version 12.2

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Router

!

enable secret

!

ip subnet-zero

!

ip multicast-routing

!

interface Loopback0

ip address 10.10.10.10 255.255.255.255

!

interface FastEthernet0/0

ip address 192.168.4.5 255.255.255.0

ip pim dense-mode

ip igmp version 3

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.168.1.5 255.255.255.0

ip pim dense-mode

ip igmp version 3

duplex auto

speed auto

!

ip classless

ip route profile

ip http server

no ip pim bidir-enable

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

login

!

end

--------------------------------------------------------------------------------------------------------

Any others suggestions from you ?

Jerry Ye · ‎07-30-2009

Hi,

Can you save the configuration and reload the router.

After the router comes back online, can you ping from the source PC to the client PC. When that is successful, start the multicast steam from the source first, then have the client join the multicast group. Then can you capture the output of the command netstat on both PC. After that is done can you capture the output of show ip mroute.

Regards,

jerry

MadhuK7555 · ‎07-30-2009

Jerry, I tried as you said. Still no luck. Here is the mroute.

--------------------------------------------------------------

Router#show ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report, s - SSM

Outgoing interface flags: H - Hardware switched

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:08:17/00:02:36, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/1, Forward/Dense, 00:07:17/00:00:00

FastEthernet0/0, Forward/Dense, 00:07:22/00:00:00

(*, 224.0.1.40), 00:08:29/00:00:00, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/0, Forward/Dense, 00:08:29/00:00:00

(*, 225.1.1.15), 00:03:47/00:02:36, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/1, Forward/Dense, 00:03:48/00:00:00

----------------------------------------------------------

Jerry, Please let me know what information you want me to check from the netstat messages. I cannot disclose actual messages that I see due to some confidentiality. Sorry for the incovenience...

Thanks.

Jerry Ye · ‎07-30-2009

Hi,

From the output, I don't see the multicast source is sending stream to 225.1.1.15 address

Incoming interface: Null

Can you check your server configuration? Also, I am interested to see the netstat -an output on the server, where the Foreign Address should bve 225.1.1.15.

Regards,

jerry

Peter Paluch · ‎07-30-2009

Madhu,

You have said that you are using the VLC to stream the multicast traffic.

I had a problem last year that had very similar symptoms. It turned out that the VLC was sending the multicast stream with TTL in IP headers set to 1 so it was not possible to route it further. The solution was then simple - to increase the TTL in the VLC streaming settings.

Can you have a look at that and perhaps verify using the Wireshark that your VLC is sending multicast IP packets with a TTL higher than 1?

Best regards,

Peter

MadhuK7555 · ‎07-31-2009

Hi Peter,

Thanks for taking a look into this. Like you mentioned I set the TTL to 3 in the VLC streaming options but for some reason the wireshark shows that the outgoing IP packets still have a TTL of 1. This could be a problem on the VLC software.

Said that, I have only one router on my way to the end PCs. Shouldn't TTL of 1 be good enough to route ? Note that the two PCs are on different subnets.

Server -- 192.168.4.10

Client -- 192.168.1.30

Thank You.

Peter Paluch · ‎07-31-2009

Hello,

The TTL is your problem here. The TTL may never be decreased down to 0. As your IP packets are sent out with TTL 1, after first routing their TTL would be decreased to 0 which is illegal. As a result, such packet will not be routed away from the segment on which it was transmitted.

Try to install a different version of VLC and try further to play with its settings. Your multicast IP packets absolutely have to have TTL higher than 1.

Best regards,

Peter

MadhuK7555 · ‎07-31-2009

Hi!

You nailed it! The problem was with the VLC media player. Even after setting the TTL > 1 it was sending packets at TTL 1. So I went back to previous version of VLC which let me send out with TTL > 1. Immediately without any further config changes in the router I could receive the video on the other client.

So basically the whole problem was because of the TTL.

Jerry and Peter, I appreciate your help in this issue.

Thank You very much!

MADHU :)

MadhuK7555 · ‎07-31-2009

Hi Jerry,

Thats exactly what is intriguing to me as well. The incoming interface is always null. Should I set anything on the router FE interface that will let it identify the incoming interface ?

What should I check in the server configuration ?

Jerry here is the netstat output. As you doubted I couldn't see 225.1.1.15 in the foreign addresses list. But I can see them going out on the interface using wireshark.

--------------------------------------------------------------------------------------------------------

Active Connections

Proto Local Address Foreign Address State

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING

TCP 0.0.0.0:664 0.0.0.0:0 LISTENING

TCP 0.0.0.0:1032 0.0.0.0:0 LISTENING

TCP 0.0.0.0:5800 0.0.0.0:0 LISTENING

TCP 0.0.0.0:5900 0.0.0.0:0 LISTENING

TCP 0.0.0.0:8081 0.0.0.0:0 LISTENING

TCP 0.0.0.0:16993 0.0.0.0:0 LISTENING

TCP 10.227.198.87:139 0.0.0.0:0 LISTENING

TCP 10.227.198.87:3186 74.125.19.99:80 CLOSE_WAIT

TCP 127.0.0.1:1025 127.0.0.1:1026 ESTABLISHED

TCP 127.0.0.1:1026 127.0.0.1:1025 ESTABLISHED

TCP 127.0.0.1:1028 0.0.0.0:0 LISTENING

TCP 127.0.0.1:5152 0.0.0.0:0 LISTENING

TCP 192.168.4.10:139 0.0.0.0:0 LISTENING

UDP 0.0.0.0:445 *:*

UDP 0.0.0.0:500 *:*

UDP 0.0.0.0:4002 *:*

UDP 0.0.0.0:4500 *:*

UDP 0.0.0.0:8081 *:*

UDP 0.0.0.0:8082 *:*

UDP 10.227.198.87:123 *:*

UDP 10.227.198.87:137 *:*

UDP 10.227.198.87:138 *:*

UDP 10.227.198.87:1900 *:*

UDP 127.0.0.1:123 *:*

UDP 127.0.0.1:1093 *:*

UDP 127.0.0.1:1191 *:*

UDP 127.0.0.1:1900 *:*

UDP 127.0.0.1:3993 *:*

UDP 192.168.4.10:123 *:*

UDP 192.168.4.10:137 *:*

UDP 192.168.4.10:138 *:*

UDP 192.168.4.10:1900 *:*

-------------------------------------------------------------------------------------------------------

Thanks for your continuing support...!

Jerry Ye · ‎07-31-2009

I am glad that you fix the problem. Thanks Peter.

Regards,

jerry

Peter Paluch · ‎08-02-2009

Jerry,

I remember banging my head around the same issue for a couple of hours and making an idiot out of myself in front of my students :) So I had a great motivation for actually remembering what was the cause of my ordeal then! :)

Anyway, thank you very much. I am glad we've found the solution.

Best regards,

Peter