This blog is a part of a serie of blogs about multicast routing:
- Multicast routing: a step by step
- Multicast routing: PIM dense
- Multicast routing: From the source
- Multicast routing: Hold ASM for a moment
- Multicast routing: Rather than dense, sparse it and let’s meet at rendez-vous point
- Multicast routing: RPF
Previously we’ve introduced multicast routing and PIM protocol operation in dense mode. In this blog, we’ll check the operation PIM multicast routing protocol from the source perspective. The next figure show our test topology:
Our multicast network is 3 router R1, R2 and R3, 2 servers: Server1 and Server2, one local to clients and the other is far away behind R3 router
Lets find out how R3 handles Server2 source multicast trafic? that is not local to clients…
R3 is the only UP router for the Server2 trafic. Upon sending of the multicast trafic, let’s check on R3 what happens…
the mroute
The next figure shows the output of mroute table (that shows forwarding information) by using the command show ip mroute:
the R3 mroute table show a correct source (ip addre 12.1.1.254) for the multicast trafic (pings in our case) towards the group 226.0.0.1 and incoming interface (Fastethernet1/0) but a Null outgoing interface list
the mrib
The mrib which is the ip multicast routing information base (not the mroute ou multicast routing table seen before) shows the output in the next figure:
The source of trafic is added successfully ant flagged as A (for accepted) but no clients appears under the show ip mrib client
the mfib
Similarily R3 the mfib table shows that the incoming interface (Fastethernet1/0) is accepting under SW Forwarding field but, all packets are being dropped (check the third term of 2/0/2, this counter corresponds to Other counts: Total/RPF failed/Other drops, in the legend)
No SW forwarding was into play
The third term of 2/0/2 shows 2 drops
let’s check the reason of these drops
A debug on mfib shows that these packets were dropped because of no forwarding interface
the output of the debug command (the last line for example) show that because of no forwarding information the packet from she Server2 is being dropped by the MFIBv4 forwarding process
Back to the mfib table (after lauching more trafic from the source)
In the output of the show ip mfib we check that the Fastethernet1/0 (R3 interface facing the Server2) the trafic is no more accepted flagged as NS which means Negate Signalling
No SW forwarding
The “Other” counter indicates a total of 35 drops, 13 due to RPF (which is new to the first test)
A debug ip pim shows nothing… PIM is not into play yet
enable PIM
Let’s enable a downward PIM neighbor
We brought up R2 router and PIM neighborship
PIMingly The neighbor is UP and added to the (*,226.0.0.1) which now in the forwarding state at R3 level as show in the next figure:
A debug ip mrouting indicates that upon the reception of the trafic the mroute entry is created
trafic being pruned
We check the status of the mroute toward the specific group 226.0.0.1 up and running. The incoming interface list is correct and so the outgoing interface list (please notice the keywork Prune added to the PIM mode of operation of this interface in Dense mode).
We check the mfib table. The Forwarding counts shows 2 forwarded packets.
The source is pruned and the “Other” counter is incrementing
From the beginning only 2 packets were SW forwarded. let’s clear mfib counters and check again.
We remark the NS flag for negate Signalling added to the FastEthernet1/0 interface and redo the test. We check that the flow is in mroute.
R2 sends a prune request which supposes that it has received a multicast packet from the source (and that no client is seen yet)
This is confirmed at R3 mfib (upon the reception of prune message from R2, the flow is dropped)
Let’s check what “debug ip mfib pak” says?
We send exactly 3 packets from the source and get the output in the next figure:
First of all the signalling was needed to determine the outgoing intreface. Then TS (no idea!), FS (fast switching) and PS (process switching) accepted forwarding of the packets.
The PS indicates no fowarding interfaces, then it drops the packet. On the other hand, the mfib table confirms that only one packet were fowarded (FS) as show in the next figure:
Then the source stops and the mfib at R3 is flagged with NS.
static igmp
Let’s now add a static igmp on R2 interface facing the receivers (such to signal that clients are present!)
At R3 the mroute shows a flagged T (indicating that SPT-bit is set; SPT stands for shortest path tree) route and correctly populated incoming and outgoing lists
The mfib table has changed also
Now the incoming interface is marked A for accept and the outgoing interface as F for forward. All packets were SW forwarded and no drops were registered.
The debug shows the packet are being forwarded because the forwarding interface is known now!
As conclusion
In this post we’ve checked the operation of our multicast routing network from the source (Server2) perspective by activating first the R3 (the router the nearst to Server2) and then R2. We showed how source trafic is being accepted and forwarded and then pruned because of lake of client.
We checked that in dense mode PIM signalling is not into much play (using the corresponding debug ip pim) from the source perspective.
