Multicast RPF issue -- need help!

[Julio Garcia]

thanks for help guys but abandonning question

[james-worley]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[David Trocki · Accepted solution]

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