Help with Multicast - multicast traffic not crossing WAN

Unanswered Question
Sep 4th, 2009
User Badges:

Hi


I've deployed multicast configuration but I'm can't see multicast traffic coming down the wan.


Here's what I've done:


vlan 50 is where the servers are sitting at site1 and they need to receive mutlicast traffic from site 2 vlan 8.


Site 1:


Switch1


interface Vlan50

ip address 10.44.50.253 255.255.255.0

no ip redirects

no ip unreachables

ip pim sparse-mode

standby 50 ip 10.44.50.1

standby 50 timers 1 2

standby 50 priority 120

standby 50 preempt


WAN link at site 1 switch1:

!

interface GigabitEthernet1/0/50

no switchport

ip address 10.10.51.105 255.255.255.252

ip pim query-interval 1

ip pim sparse-mode

load-interval 30


Site 1 Switch 2:


interface Vlan50

ip address 10.44.50.254 255.255.255.0

standby 50 ip 10.44.50.1

standby 50 timers 1 2

standby 50 priority 105

standby 50 preempt


WAN link at site 1 switch2:


interface GigabitEthernet1/0/51

no switchport

ip address 10.10.51.145 255.255.255.252

ip pim query-interval 1

load-interval 30



Site2 Switch1:

interface Vlan8

ip address 10.45.8.254 255.255.255.0

ip pim sparse-mode

standby 8 ip 10.45.8.1

standby 8 priority 110

standby 8 preempt delay minimum 60

hold-queue 2048 in


WAN link at site 2 switch1:

interface GigabitEthernet1/43

ip address 10.10.51.106 255.255.255.252

ip flow ingress

ip pim query-interval 1

ip pim sparse-mode

ip route-cache flow


Site2 Switch2:

interface Vlan8

ip address 10.45.8.253 255.255.255.0

ip pim sparse-mode

standby 8 ip 10.45.8.1

hold-queue 2048 in


WAN link at site 2 switch2:

interface GigabitEthernet1/4

ip address 10.10.51.146 255.255.255.252

ip flow ingress

ip pim query-interval 1

ip pim sparse-mode

ip route-cache flow


Can someone see a reason why Site 1 vlan 8 isn't getting multicast traffic for multicast group 239.255.3.20.


Just so you are aware we have an appplication that is sending the multicast via tcp across the wan link then multicasting it into site 1. I want to remove this application and instead have multicast traffic traverse the wan link in raw form.


Any thoughts?


Thanks in advance

Dan

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Peter Paluch Fri, 09/04/2009 - 02:58
User Badges:
  • Cisco Employee,

Hello Dan,


I assume you have the "ip multicast-routing" or "ip multicast-routing distributed" configured on your switches as your configuration requires Layer3 multicast routing.


What does the "show ip mroute" say about the group 239.255.3.20? Is the outgoing interface list Null or does it contain correct interfaces? Also, you are using PIM-SM - is there a RP (rendezvous point) router known to all your multicast-routing switches?


Best regards,

Peter


dan_track Fri, 09/04/2009 - 03:44
User Badges:

Hi


Thanks for your reply.


Yes I have in all sites ip multicast-routing configured. Here's the MSDP config's in each site:


Site1 Switch1:

ip multicast-routing distributed


ip pim rp-address 10.44.100.100

ip msdp peer 10.44.100.252 connect-source Loopback1

ip msdp keepalive 10.44.100.252 10 30

ip msdp cache-sa-state

ip msdp timer 1


Site1 Switch2:


ip multicast-routing distributed


ip pim rp-address 10.44.100.100

ip msdp peer 10.44.100.253 connect-source Loopback1

ip msdp keepalive 10.44.100.253 10 30

ip msdp cache-sa-state

ip msdp timer 1



Site2 Switch1:

ip multicast-routing

mls ip multicast flow-stat-timer 9

mls aging long 64

mls aging normal 64

mls flow ip interface-full

no mls flow ipv6

mls nde sender version 5

no mls acl tcam share-global

mls cef error action reset


ip pim rp-address 10.239.45.1

ip msdp peer 10.45.255.253 connect-source Loopback1

ip msdp cache-sa-state

ip msdp originator-id Loopback1


Site 2 Switch2:

ip multicast-routing

mls ip multicast flow-stat-timer 9

mls aging long 64

mls aging normal 64

mls flow ip interface-full

no mls flow ipv6

mls nde sender version 5

no mls acl tcam share-global

mls cef error action reset


ip pim rp-address 10.239.45.1

ip pim spt-threshold infinity

ip msdp peer 10.45.255.254 connect-source Loopback1

ip msdp cache-sa-state

ip msdp originator-id Loopback1


Any thoughts on this?


Thanks

Dan

dan_track Fri, 09/04/2009 - 05:05
User Badges:

Hi,


The show ip mroute is quite long, here's an abstract from it:


(*, 239.255.3.20), 16:27:22/stopped, RP 10.44.100.100, flags: SP

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list: Null


(10.44.50.34, 239.255.3.20), 01:29:51/00:02:58, flags: PT

Incoming interface: Vlan50, RPF nbr 0.0.0.0

Outgoing interface list: Null


dan_track Fri, 09/04/2009 - 05:21
User Badges:

Hi Guys,


Any thoughts on this, could this be related to autorp? do I need to enable this on both sides. If I do what problems could come up with this enabled?


Thanks

Dan

Peter Paluch Fri, 09/04/2009 - 05:49
User Badges:
  • Cisco Employee,

Hi Dan,


You do not need the AutoRP because apparently on all switches you have your RP configured statically. The question is, why does the mroute table contain NULL oif list for the multicast group in question.


Try to proceed from the switch nearest to the servers and check the "show ip igmp group" whether it knows about the multicast group in question. If yes, the group should be indicated with a VLAN SVI interface indicating that the SVI interface is connected to a network with receivers. Now, from this switch backwards to the source, watch for the "show ip mroute" entries regarding this multicast group - they must have their RPF neighbor identified and their oif list must not be NULL.


Best regards,

Peter


dan_track Fri, 09/04/2009 - 06:50
User Badges:

Hi,


Thanks for the advice. Here's my ouptuts


Site 2 Switch1:


show ip igmp group

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.3.20 Vlan8 28w1d 00:02:13 10.45.8.38


show ip mroute:

(*, 239.255.3.20), 27w6d/stopped, RP 10.239.45.1, flags: SJC

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Vlan8, Forward/Sparse, 27w6d/00:02:49


Eigrp prefers the wan link on this switch (port gi /43) to go to site 1. So then on site 1 I connect to switch1 (port gi 1/0/50) (bear in mind my application lives on vlan 50):


sh ip igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter Group Accounted

239.255.3.20 Vlan50 18:11:37 00:02:44 10.44.50.24


show ip mroute:

(*, 239.255.3.20), 18:12:40/stopped, RP 10.44.100.100, flags: SP

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list: Null


Not sure how to explain this, any thoughts?


Thanks

Dan



Mohamed Sobair Fri, 09/04/2009 - 11:09
User Badges:
  • Gold, 750 points or more

Hi Dan,


Could you please give us a simple drawing of your current Network design and how the Multicast server and recievers are connected?


We could help furhter if we understand more the topology?



HTH

Mohamed

Mohamed Sobair Mon, 09/07/2009 - 03:49
User Badges:
  • Gold, 750 points or more

Hi Dan,


1- Before going to any step, could you please clarify why you have 3 different static RPs mapping on your switches? What is the current RP for the group 239.255.3.20 in your topology?


2- from site1 Switch 1 and Switch2 what is the output of (sh ip mroute) & (sh ip igmp snooping group).



HTH

Mohamed

dan_track Wed, 09/09/2009 - 01:52
User Badges:

Hi,


I managed to solve the problem. Basically the problem was that Site 1 had a local RP address. But the mutlicast group in Site 2 was bound against Site2's RP.


All I did was add an ACL in Site1 to state that the multicast group that PC's in Vlan 50 in Site 1 want to subscribe to they need to map to the RP address in Site2.


My problem was with my understanding, I thought that different RP's would communicate to inform each other about what multicast group's they have bound to them. Is there a way to set this type of communication up?


Thanks

Dan

Peter Paluch Wed, 09/09/2009 - 02:00
User Badges:
  • Cisco Employee,

Hello Dan,


I'm glad you got it running.


Regarding your information about the multiple RPs - that's what the MSDP is for. I have seen it in your configuration - I admit I have not checked it thoroughly - but once a RP receives a multicast stream from a source to a particular group, it uses the MSDP to inform the other RP about the existence of this sender and group. The second RP can then send the Join message towards the sender to create a branch of the multicast distribution tree.


However, your network is quite simple. You would be completely fine with a single RP, I believe. Do you have any special need to have two RPs?


Best regards,

Peter


dan_track Wed, 09/09/2009 - 02:26
User Badges:

Hi,


Thanks for info. I do need two RP's for the simple reason that we have developers in Site1 that use multicast for development. If I have one RP in Site2 then Multicast's from site1 will have to traverse the WAN link up to Site 2 RP only for them to be sent back to Site 1.


Is my understanding correct? Am I right in thinking every multicast packet will do the traversing?


Thanks

Dan

Peter Paluch Wed, 09/09/2009 - 03:25
User Badges:
  • Cisco Employee,

Hello,


Regarding the traffic flow: A multicast traffic flows from sender to the RP and from the RP to the recipient only if your network insists on using the shared multicast distribution tree. A shared multicast distribution tree is called shared because the part from the RP down to recipients is shared by all flows from all sources to a particular multicast group.


However, the Cisco routers by default do a switchover to a shortest-path multicast distribution tree as soon as they receive the first multicast packet from a particular source. As soon as the first multicast packet traverses from the sender through the RP to the end router onto which the recipient is directly connected, that router will know the sender's IP address. It can therefore send the PIM Join message directly towards the sender, thereby creating a new branch of multicast distribution tree through which the multicast traffic can be sent on the shortest route between the source and the destination. After that, the entire shared branch eventually prunes itself off the RP-rooted multicast distribution tree (unless it is on the shortest path to the source) and what remains is a multicast distribution tree over the shortest path between the multicast sender and the recipient.


Check out this PDF - it's very descriptive:


ftp://ftp-eng.cisco.com/ipmulticast/training/Module5.pdf


So don't worry - your multicast stream should not be going over the RP and back for too long (a couple of milliseconds, a second perhaps, but not longer). By the way, the command that controls the switchover to the shortest-path tree is ip pim spt-threshold 0 where 0 is the threshold in kbps when the switchover should take place - zero means immediately.


Best regards,

Peter


dan_track Wed, 09/09/2009 - 03:58
User Badges:

Hi Peter,


Many many thanks for that descriptive reponse. Life is now so much clearer :).


I'll review the pdf plus add points.


Thanks

Dan

Actions

This Discussion