(S,G) entry in RP

anilrs3 · ‎11-06-2012

Hi,

I am testing a Multicast scenario in which multicast will be tunnelled accross the Point to Point GRE Tunnels. RP will have GRE tunnel towards the CPEs in source and client sites and will be running MBGP accross the GRE tunnel (Attached the diagram).

In RP , PIM-Sparse mode is enabled only on the GRE tunnel interfcaces towards the CPEs in source and client site. PIM Sparse Mode is not enabled on any WAN interface of the CPEs.

RP and the other CPEs are running BGP with the PE for unicast routing updates.

This multicast domain is using PIM Sparse mode and using static RP. RP will advertise it's RP address via MBGP towards the CPEs in source and client sites so that the CPEs can successfully perform RPF lookup towards the RP for group to RP mapping.

When i send Multicast traffic from the source towards a multicast group address then I can see that the RP is installing (S,G) entry even if the incoming interface of the (S,G) entry is showing as Null. That is (S,G) entry still installed in the mroute table of the RP even the RPF lookup towards the source is failing and at the same time Multicast traffic is sending from the source to the client sites via RP as RP is the root . (No Shortest path tree will be built by using the command "ip spt threshold infinity").

So my question is :

1. (S,G) entry is installed in mroute table of the RP with incoming interface is Null. Why this (S,G) entry is installed in mroute even the RPF lookup towards the source is failed (Incoming interface is Null) ?

2. Even if (S,G) entry is installed why it is not timed out because of RPF failure towards the source (Incoming interface = Null).

I have attached a high level digaram which will give a clear idea about the issue.

Can some one please tell me why it is happening like this ?

Please let me know if some thing is not clear !!

Thanks,

Anil.

Peter Paluch · ‎11-14-2012

Anil,

If I understand you correctly, you are tunneling your multicast traffic through GRE tunnels while the unicast traffic continues to be routed through physical links, not via the GRE tunnels. If that is correct, have you statically modified the multicast routing table so that the RPF check is performed against the GRE tunnels instead of physical interfaces? This is a major thing.

The command should be ip mroute 0.0.0.0 0.0.0.0 TunnelX .

Best regards,

Peter

anilrs3 · ‎11-14-2012

Hi Peter,

You are right. But i don't want to use default mroute for RPF check , instead i use specific subnet as source for multicast. But if some reason multicast is sourcing from an unknown source then RPF lookup is failed and traffic from source up to the RP is using unicast source register msg and not native multicast.

So the end result must be : If multicast source from an unknown address then the packets must not forward by using source reg msg .

Cheers,

Anil.

Peter Paluch · ‎11-14-2012

Hello Anil,

But if some reason multicast is sourcing from an unknown source then RPF  lookup is failed and traffic from source up to the  RP is using   unicast source register msg and not native multicast.

I do not believe this is a correct statement. If the RPF check is failed then the packet is dropped without any further processing. A packet is forwarded via the PIM Register messages to the RP if and only if it passes the RPF check, and the (*, G) state is not created at all or the (*, G) entry is in the registering state.

So  the end result must be : If multicast source from an unknown address  then the packets must not forward by using source reg msg .

I do not understand this statement. Can you explain it in more detail please?

Best regards,

Peter

anilrs3 · ‎11-14-2012

RPF lookup will not be performed for the unicast source reg msg. Once RP decapsulate uni source reg msg then (S,G) entry will be installed and will use that entry to forward the traffic only if the incoming interface is NOT null (ie. pass RPF lookup).

But the strange thing is even (S,G) is installed with incoming int as Null and i can see multicast packet is forwarding. After doing more debugs, i say that packet is forward from source up to the RP by uni reg ms, which is strange ans must not happen. I think this is some technology limitation or a grey area.

Please check the output from RP ( No SPT is built in this design, only using shared tree)

CE#sh 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, E - Extranet,

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

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

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - Sending to MDT-data group,

V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

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

(*, 239.195.0.3), 00:09:55/00:03:22, RP 9.9.9.9, flags: S

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Tunnel102, Forward/Sparse, 00:09:55/00:03:22

(10.0.183.2, 239.195.0.3), 00:09:38/00:03:29, flags:

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Tunnel102, Forward/Sparse, 00:09:38/00:03:22

(172.21.36.2, 239.195.0.3), 00:09:38/00:03:29, flags:

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Tunnel102, Forward/Sparse, 00:09:38/00:03:22

CE#sh ip rpf 10.0.183.2

failed, no route exists

CE#sh ip mroute count

Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics

3 routes using 1578 bytes of memory

1 groups, 2.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.195.0.3, Source count: 2, Packets forwarded: 634, Packets received: 642

RP-tree: Forwarding: 6/0/100/0, Other: 14/7/1

Source: 10.0.183.2/32, Forwarding: 314/0/100/0, Other: 314/0/0

Source: 172.21.36.2/32, Forwarding: 314/0/100/0, Other: 314/0/0

Peter Paluch · ‎11-14-2012

Hi Anil,

But the strange thing is even (S,G) is installed with incoming int as  Null and i can see multicast packet is forwarding. After doing more  debugs, i say that packet is forward from source up to the RP by uni reg  ms, which is strange ans must not happen. I think this is some  technology limitation or a grey area.

Once a first-hop router starts registering its source using PIM Register messages, it will continue to do so until it receives a Register-Stop message from the RP. The fact that it does not stop registering means that either it is not getting the Register-Stop, or the RP is not sending them at all. So my original question holds: does the RP know how to reach the source?

Best regards,

Peter

anilrs3 · ‎11-18-2012

There is no RPF interface for this source inorder to send reg stop msg. Here RP will fail in RPF lookup for this source. If RP know how to perform RPF lookup for this source then there is no problems and in such case multicast will work fine.

Peter Paluch · ‎11-18-2012

Hello Anil,

I apologize but I have to say that I do not understand whether you still have some questions or you are just pushing forward your own answers to your own questions, in which case I cannot be of more help. It seems you are trying to answer yourself, without reading my own suggestions and questions carefully. Otherwise, you would answer at least the one question that keeps repeating itself: does the RP know the path towards the multicast source? Note I'm not asking about RPF, I am merely asking if there is a unicast route in the RP's routing table towards the sender. I have asked this question several times, and so far I have not received a straight 'yes or no' answer.

Best regards,

Peter

anilrs3 · ‎11-18-2012

Sorry from my side , as i think i made some confusion here !! . Ok , there is unicast route back to the source.But that is not relevent here.

My question is how i can prevent multicast to be forwarded by RP even if there is no RPF neighborship back to the source. I can see that multicast is forwarded by using source register msg which will be process switched. That means there is no native multicast from source up to the RP in order to forward streams. So if the source is from an unknown unicast address , how RP can stop forwarding multicast towards the client .

Thanks,

Anil.