Multicast RPF issue -- need help!

Answered Question
Sep 2nd, 2010
User Badges:
  • Bronze, 100 points or more




thanks for help guys but abandonning question


Correct Answer by David Trocki about 6 years 10 months ago

So the failure to forward the packets is certainly because the RPF check failed.


Source: 192.168.50.50/32, Forwarding: 0/0/0/0, Other: 11750/11750/0


Your mroute statement defines where you expect the source multicast to come from.  So it would be something like


ip mroute 192.168.50.50 255.255.255.255

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
james-worley Thu, 09/02/2010 - 07:42
User Badges:

Hi Rob


I feel your pain, I've spent many an hour troubleshooting Multicast! The most common reason I have found for it not to work is RPF failure.


When you say 'when i change the streamer ip address to something random, eg 192.168.50.50' is this random IP address in your IGP? If not I would expect a possible RPF failure.


Why do you want to set the source with an IP address not within the sources real subnet?


Rgds

James

Giuseppe Larosa Thu, 09/02/2010 - 07:44
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Rob,

if you are in PIM SM and not in PIM SSM if no one want to receive group


you need the right mroute or a unicast route for the new source it is not clear if the new source is 192.168.50.50 you need an mroute for it


Hope to help

Giuseppe

Julio Garcia Thu, 09/02/2010 - 07:53
User Badges:
  • Bronze, 100 points or more

Hi Guys thanks for your replies,


Yes this IP address is not in IGP , nor do i wish it to be in IGP -- basically its a customer who cant change his IP


Im not doing source specific multicast , just sparse mode.


Hope this info helps,


I dont really know much about adding static mroute , what do i need to add , could someone give an example ?


note the reciever of multicast is 2 hops away

David Trocki Thu, 09/02/2010 - 07:59
User Badges:

can you post the results of a sh ip mroute count?


Also, check if your incoming interface is correct in relation to your desired outgoing interface.  The incoming interface and desired outgoing interface cannot be the same, or the OIF list will be null.


Incoming interface: FastEthernet0/1.200, RPF nbr 10.43.10.1

Julio Garcia Thu, 09/02/2010 - 08:08
User Badges:
  • Bronze, 100 points or more

Hi David,


thanks for reply,


outgoing interface is normally fa 0/0  , ( or fa 0/1.100 in case of failure )



I cant show the ip mroute count at the moment , but can later today if you still need.

David Trocki Thu, 09/02/2010 - 08:11
User Badges:

Take a show ip mroute from when it is working, and then one from after you change the IP address and it starts to fail.

And then also take a show ip mroute count.

Julio Garcia Thu, 09/02/2010 - 08:16
User Badges:
  • Bronze, 100 points or more

no probs David , will get this info.




Just out of curiosity ,


Is there any best practise when using sparse mode with customers? Obviously if they are the sources , asking them to dictate IP addressing is going to be tough.

David Trocki Thu, 09/02/2010 - 08:30
User Badges:

As long as your routing tables are correct this shouldn't normally be a problem.  RPF checks will use your unicast routing table if there are no static mroutes.  So your customers just can't use subnets that your routers are unaware of.

james-worley Thu, 09/02/2010 - 08:41
User Badges:

Rob


Assuming your in an enterprise environment, RFC2365 and 3171, offer some guidelines on addressing (although they may have been superseded). If you running good old fashioned IP id assign the customer a mulitcast group address. If your running MPLS and the customer is in their own VPN i'd encourage them to use any address they like in the 239/8 range. If you a SP and the customer is running public mulitcast then they will need to be assigned an address by IANA

Julio Garcia Thu, 09/02/2010 - 13:24
User Badges:
  • Bronze, 100 points or more

Details from Source router  when stream is working ( when multicast streamer = 10.43.10.10)



(10.43.10.10, 239.10.20.30), 00:02:22/00:03:29, flags: TA
  Incoming interface: FastEthernet0/1.200, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:00:12/00:03:17


Group: 239.10.20.30, Source count: 1, Packets forwarded: 70033, Packets received: 132413
  RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 10.43.10.10/32, Forwarding: 70033/473/1355/5132, Other: 132413/0/62380




the reciever (a 3560 switch- pim neighour) which is 1 hop away ...


(10.43.10.10, 239.10.20.30), 00:01:03/00:02:55, flags: JT
  Incoming interface: GigabitEthernet0/20, RPF nbr 10.11.11.10
  Outgoing interface list:
    Vlan500, Forward/Sparse, 00:01:03/00:02:28

Group: 239.10.20.30, Source count: 1, Packets forwarded: 46, Packets received: 28
  RP-tree: Forwarding: 5/0/1085/0, Other: 4/0/0
  Source: 10.43.10.10/32, Forwarding: 41/1/761/0, Other: 24/1/0

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



when things not working , streamer = 192.168.50.50


At Source Router...



(192.168.50.50, 239.10.20.30), 00:02:33/00:00:26, flags: P
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null



Group: 239.10.20.30, Source count: 1, Packets forwarded: 0, Packets received: 11748
  RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
  Source: 192.168.50.50/32, Forwarding: 0/0/0/0, Other: 11750/11750/0



no mroute details of S,G on the 3560 switch

Correct Answer
David Trocki Thu, 09/02/2010 - 13:37
User Badges:

So the failure to forward the packets is certainly because the RPF check failed.


Source: 192.168.50.50/32, Forwarding: 0/0/0/0, Other: 11750/11750/0


Your mroute statement defines where you expect the source multicast to come from.  So it would be something like


ip mroute 192.168.50.50 255.255.255.255

Actions

This Discussion