Multicast: RPF… Part 6

In our test network

R1, R2 and R3 are in the same RIP routing domain

All these routers are configured for a PIM-SM mode operation

The RP address is set to R3’s fa1/0 interface

Notice that each router configured with this information establishes a tunnel towards the RP

At R2

A “show ip interface brief” shows

Digging into the interface tunnel0 details

The tunnel was created by PIM process to join the RP which is R3

The tunnel protocol/transport is PIM/IPv4

It is described as a PIM Register Tunnel for RP 12.1.1.3

A “show ip cef” on the RP address,

enables R2 to determine the tunnel source

before we move on let’s check that Client1 responds to multicast ping from Server2

We add a new direct link between R3 and R1 in the subnetwork 13.0.0.0/24

And include it in RIP domain

Another ping from the server shows that’s something went wrong

At R3,

The flow is accepted and flaged as SPT-bit set

The incoming interface and outgoing interface lists are correct and forwarding

What happens at R1? The last hop router towards the destination (Client1)?

The (S,G) is not there

The outgoing interface information is correct

But the incoming interface information is wrong : set up to Null

The Reverse Path Forwarding neighbor points to 0.0.0.0 which is none

The RP information is correct

What about the tunnel that is built towards the RP?

The tunnel is up! which means that R1 has found a route towards the RP in its routing table

Now the route to get to the RP is directly through the link between R1 and R3

Why PIM fails to install a correct information for 226.0.0.1?

Let’s debug

The debug shows the RP-reach (PIM-SM signalling) was received from a non-RPF interface for the group 226.0.0.1 and consequently was dropped

A “show ip rpf” checks that no entry exists at all for 12.1.1.3 the RP

By default the rpf picks the route dynamically from the ip unicast routing table

But why it does not work in our case?

Why the route through R2 succeeds? But R3 not?

What is special about the direct link between R1 and R3?

What is special about R3-facing R1’s interface?

It is not a pim interface!

Let’s enable pim (either dense or sparse) processing on this interface

Now the rpf shows

The rpf entry should be pim (dense or sparse) enabled and originated (by default) from the ipv4 unicast base…

In the mroute table

The (*,G) entry information is now correct

But the ping is still not working…

In the mroute table, no (S,G) is present: the source is not seen!

In fact,

A debug shows that the packet is received but fails the acceptance checks

Per the precedent rpf, the packet from the source is expected to arrive on the newly added fa1/1 interface

It is only received on the fa1/0 interface

R3 does not send packets on its fa 1/1 interface facing R1 because pim (forwarding part) is not enabled on it

Let’s enable PIM-DM (dense mode) on this interface then,

Now the ping is working…

Per RIP, the direct link between R1 and R3 is optimal but it happens that this link is congested and that eventually it’s more preferable to get through R2

To get the multicast flow through R2 we need that pim sparse mode signalling towards the RP succeeds (building the tunnel and accepting RP-reach messages) and that packets arrives on the new rpf interface

In the mroute table the incoming interface should switch to fa 1/0 and the RPF nbr to 21.1.1.2 (R2)

Let’s try to change the mroute table entry (RP information) statically

Now the entry is marked as “Mroute” to denote a static configuration

The rpf on the RP shows and RPF type of multicast (static) instead of unicast (rip) in the previous snapshot

The rpf on the source ip address shows

The rpf intreface is correct and enabled for pim

The rpf route comes from RIP database

An “ip cef” on this route confirms this information and matches the source flow incoming interface to the interface this route passes by…

We disable pim on the R3 interface facing R1 and redo a show rpf at R1

And nothing has changed!

Rpf still get the RPF neighbor information not from pim process but the rip routing protocol

We check that the pim neighborship is down and that 13.0.0.3 update source is the rpf corresponding rip route

The flow continues to flow directly from R3 to R1

Let’s delete the static mroute entry we’ve configured for the RP

And configure a new one for the source…

And deactivate pim on R3 direct link to R1

In this case is pim needed on R1 interface facing R3? let’s deactivate it and check,

The flow continues…

Which may lead to the conclusion that pim is not necessary on R1 fa1/1 (for rpf on R1)

BUT it is contradictory with our first finding!

It seems that the router keeps working with some wrong information

or a contradictory information between what the rpf table shows and what the mroute entry shows

Let’s “clear ip mroute *” everywhere in the network…

Now things are more coherent and back to our original problem,

And,

Which required us to activate PIM on R1 fa 1/1 interface for it to be included in the RPF table and then validate the corrsponding mroute entry…

atlink'admin

Learn More →

Leave a Reply

Translate »