Warning: Declaration of Suffusion_MM_Walker::start_el(&$output, $item, $depth, $args) should be compatible with Walker_Nav_Menu::start_el(&$output, $item, $depth = 0, $args = Array, $id = 0) in /homepages/5/d692508392/htdocs/clickandbuilds/l3switching/wp-content/themes/suffusion/library/suffusion-walkers.php on line 39
Jul 092012
 

Using PIM in sparse mode is much more effective, because of the explicit requests. A multicast packet is only flooded from the sender to the first hop router. Only when a client requests data, the multicast packets are flooded out of the broadcast domain. The core control point of PIM-Sparse mode is the Rendezvous Point (RP). The RP tracks all the senders and receivers in the multicast domain.

In the figure below the loopback 0 of R1 is configured as the RP address. OSPF area 0 and PIM in sparse mode is enabled on all interfaces of all routers.

Let us check the scenario when a multicast receiver joins to a group. We assume now there are no senders.

  • Client sends an IGMP membership report out on the LAN.
  • IGMP join will then the converted to PIM join and sent upstream to the RP.
  • A (*,G) entry will be installed on all routers in the IGP path to RP

The debug ip igmp on R3 shows that it received IGMP report for the group 224.1.1.1

IGMP(0): Received v2 Report on Ethernet0/1 from 10.0.10.1 for 224.1.1.1
IGMP(0): Received Group record for group 224.1.1.1, mode 2 from 10.0.10.1 for 0 sources

Now the DR on the LAN, which is R3 checks if it has an RP configured for the group 224.1.1.1.  It then will send a PIM join to the upstream router towards RP. In our case it is R2. The debug ip pim output shows the join messages sent.

PIM(0): Check RP 1.1.1.1 into the (*, 224.1.1.1) entry
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 224.1.1.1
PIM(0): Insert (*,224.1.1.1) join in nbr 10.0.23.2's queue
PIM(0): Building Join/Prune packet for nbr 10.0.23.2
PIM(0): Adding v2 (1.1.1.1/32, 224.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 10.0.23.2 (Ethernet0/0)

R2 does the same, it checks if it has an RP configured for the group 224.1.1.1. Then it will send it to the upstream neighbor towards RP. In our case R2 could reach the RP via its directly attached link. But it prefers the path via R6 because of the better OSPF cost. Thus it generates another PIM join for R6.

PIM(0): Received v2 Join/Prune on Ethernet0/1 from 10.0.23.3, to us
PIM(0): Join-list: (*, 224.1.1.1), RPT-bit set, WC-bit set, S-bit set
PIM(0): Check RP 1.1.1.1 into the (*, 224.1.1.1) entry
PIM(0): Add Ethernet0/1/10.0.23.3 to (*, 224.1.1.1), Forward state, by PIM *G Join
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 224.1.1.1
PIM(0): Insert (*,224.1.1.1) join in nbr 10.0.26.6's queue
PIM(0): Building Join/Prune packet for nbr 10.0.26.6
PIM(0): Adding v2 (1.1.1.1/32, 224.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 10.0.26.6 (FastEthernet1/0)

R6 after checking the RP for group 224.1.1.1, it builds its own PIM join towards its upstream router R1

PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 10.0.26.2, to us
PIM(0): Join-list: (*, 224.1.1.1), RPT-bit set, WC-bit set, S-bit set
PIM(0): Check RP 1.1.1.1 into the (*, 224.1.1.1) entry
PIM(0): Add FastEthernet0/0/10.0.26.2 to (*, 224.1.1.1), Forward state, by PIM *G Join
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 224.1.1.1
PIM(0): Insert (*,224.1.1.1) join in nbr 10.0.16.1's queue
PIM(0): Building Join/Prune packet for nbr 10.0.16.1
PIM(0): Adding v2 (1.1.1.1/32, 224.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 10.0.16.1 (FastEthernet1/0)

All of these routers will now have a (*,G) entry. The incoming interface for this entry will the RFP interface towards RP and the outgoing interface will be the one where it received an IGMP report or a PIM join.

R3#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:20:34/00:02:07, RP 1.1.1.1, flags: SJC
  Incoming interface: Ethernet0/0, RPF nbr 10.0.23.2
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:20:34/00:02:07

R2#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:20:34/00:02:38, RP 1.1.1.1, flags: S
  Incoming interface: FastEthernet1/0, RPF nbr 10.0.26.6
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:20:34/00:02:38

R6#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:20:34/00:02:36, RP 1.1.1.1, flags: S
  Incoming interface: FastEthernet1/0, RPF nbr 10.0.16.1
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:20:34/00:02:36

R1#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:20:34/00:02:36, RP 1.1.1.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 00:20:34/00:02:36

As next, Let us check the scenario when a multicast sender sends to a group. We assume that there are no receivers.

  • Server floods the multicast feed out on the LAN.
  • First hop router will then send a unicast PIM Register message to the RP.
  • The RP then replies with a Register stop message.

When R4 receives the multicast packet for the group 224.1.1.1, it checks for any known RP. Then it will send a PIM Register message to the RP.

PIM(0): Check RP 1.1.1.1 into the (*, 224.1.1.1) entry
PIM(0): Send v2 Register to 1.1.1.1 for 10.0.20.1, group 224.1.1.1
PIM(0): Received v2 Register-Stop on Ethernet0/0 from 1.1.1.1
PIM(0): for source 10.0.20.1, group 224.1.1.1
PIM(0): Clear Registering flag to 1.1.1.1 for (10.0.20.1/32, 224.1.1.1)

This message is unicasted to the RP. The debug ip packet shows the source of the packets are 10.0.45.4 towards 1.1.1.1

IP: tableid=0, s=10.0.45.4 (local), d=1.1.1.1 (Ethernet0/0), routed via FIB
IP: s=10.0.45.4 (local), d=1.1.1.1 (Ethernet0/0), len 88, sending, proto=103
IP: tableid=0, s=1.1.1.1 (Ethernet0/0), d=10.0.45.4 (Ethernet0/0), routed via RIB
IP: s=1.1.1.1 (Ethernet0/0), d=10.0.45.4 (Ethernet0/0), len 38, rcvd 3, proto=103

As there are no receivers, the RP will respond with a register stop message. The register stop message is also unicasted to R4. After this point, R4 will not send anymore multicast packets out.

PIM(0): Received v2 Register on Ethernet0/0 from 10.0.45.4
     for 10.0.20.1, group 224.1.1.1
PIM(0): Check RP 1.1.1.1 into the (*, 224.1.1.1) entry
PIM(0): Send v2 Register-Stop to 10.0.45.4 for 10.0.20.1, group 224.1.1.1

A (S,G) and (*,G) entry will be created on R4 which is attached to the multicast source and also on the RP. The incoming interface for the (*,G) entry will always the RPF interface towards RP. As there are no PIM join messages received, there are no receivers and thus the outgoing interface will be NULL. The incoming interface for the (S,G) entry will be the interface where the multicast feed comes in.

R4#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:00:08/stopped, RP 1.1.1.1, flags: SPF
  Incoming interface: Ethernet0/0, RPF nbr 10.0.45.5
  Outgoing interface list: Null

(10.0.20.1, 224.1.1.1), 00:00:08/00:02:51, flags: PFT
  Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list: Null

R1#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:00:08/stopped, RP 1.1.1.1, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(10.0.20.1, 224.1.1.1), 00:00:08/00:02:51, flags: P
  Incoming interface: Ethernet0/0, RPF nbr 10.0.15.5
  Outgoing interface list: Null

Now let’s check the case where a sender and receiver exist.

There exist two share trees, one from the receiver to the RP, the other from sender to the RP. RP will merge both trees. In our example then the server sends out the feed, R4 will send a PIM register to R1. Then R1 will answer with a PIM register stop message. At this point R4 and R1 will know about the multicast source.

When the client sends an IGMP report on the LAN, R3 will then in turn send a PIM join message to its upstream neighbor towards the RP. Thus state information (*,224.1.1.1) is created on all the routers from receivers LAN until the RP.

The RP knows of a source which sends to group 224.1.1.1. It then will send a PIM join message downstream towards R5 for the source 10.0.20.1. This will cause all routers in the path from the RP towards the source to have a (S,G) and (*,G) entry.

PIM(0): Received v2 Join/Prune on FastEthernet1/0 from 10.0.16.6, to us
PIM(0): Join-list: (*, 224.1.1.1), RPT-bit set, WC-bit set, S-bit set
PIM(0): Add FastEthernet1/0/10.0.16.6 to (*, 224.1.1.1), Forward state, by PIM *G Join
PIM(0): Add FastEthernet1/0/10.0.16.6 to (10.0.20.1, 224.1.1.1), Forward state, by PIM *G Join
PIM(0): Insert (10.0.20.1,224.1.1.1) join in nbr 10.0.15.5's queue
PIM(0): Building Join/Prune packet for nbr 10.0.15.5
PIM(0): Adding v2 (10.0.20.1/32, 224.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 10.0.15.5 (Ethernet0/0)

R5, when it receives the PIM source specific join, it generates another PIM source specific join to its downstream neighbor R4 and sends it.

PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.0.15.1, to us
PIM(0): Join-list: (10.0.20.1/32, 224.1.1.1), S-bit set
PIM(0): Check RP 1.1.1.1 into the (*, 224.1.1.1) entry
PIM(0): Add Ethernet0/0/10.0.15.1 to (10.0.20.1, 224.1.1.1), Forward state, by PIM SG Join
PIM(0): Insert (10.0.20.1,224.1.1.1) join in nbr 10.0.45.4's queue
PIM(0): Building Join/Prune packet for nbr 10.0.45.4
PIM(0): Adding v2 (10.0.20.1/32, 224.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 10.0.45.4 (Ethernet0/1)

Finally R4 receives the source specific PIM join.

PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.0.45.5, to us
PIM(0): Join-list: (10.0.20.1/32, 224.1.1.1), S-bit set
PIM(0): Add Ethernet0/0/10.0.45.5 to (10.0.20.1, 224.1.1.1), Forward state, by PIM SG Join

Now the traffic flows from the source towards RP and from RP down to receiver. The traffic takes the path which is not optimal. Now R3 the router which is attached to the receiver, knows of a source which sends to group 224.1.1.1. Now it could send a PIM join directly to this source, which then finally makes packets to flow over an optimal path.

When R3 knows of the source 10.0.20.1, it sends a PIM join message towards the source. This join message is sent to its upstream neighbor R2.  R2 also sends a prune message towards RP, because of the sub optimal path.

PIM(0): Insert (10.0.20.1,224.1.1.1) join in nbr 10.0.23.2's queue
PIM(0): Building Join/Prune packet for nbr 10.0.23.2
PIM(0): Adding v2 (10.0.20.1/32, 224.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 10.0.23.2 (Ethernet0/0)

R2 then sends a PIM join to R5 because R5 is the RPF neighbor towards 10.0.20.1.

PIM(0): Received v2 Join/Prune on Ethernet0/1 from 10.0.23.3, to us
PIM(0): Join-list: (10.0.20.1/32, 224.1.1.1), S-bit set
PIM(0): Add Ethernet0/1/10.0.23.3 to (10.0.20.1, 224.1.1.1), Forward state, by PIM SG Join
PIM(0): Insert (10.0.20.1,224.1.1.1) join in nbr 10.0.25.5's queue
PIM(0): Building Join/Prune packet for nbr 10.0.25.5
PIM(0): Adding v2 (10.0.20.1/32, 224.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 10.0.25.5 (Ethernet0/2)

When R5 receives the source specific PIM join on its interface ethernet0/2, it places this interface in the outgoing interface list.

PIM(0): Received v2 Join/Prune on Ethernet0/2 from 10.0.25.2, to us
PIM(0): Join-list: (10.0.20.1/32, 224.1.1.1), S-bit set
PIM(0): Add Ethernet0/2/10.0.25.2 to (10.0.20.1, 224.1.1.1), Forward state, by PIM SG Join

Now finally the packets flow over the optimal path from source 10.0.20.1 to the receiver.
When R2 sends a source specific PIM join towards 10.0.20.1, it also at the same time sends a PIM prune message towards the RP. This prune message is sent to R6.

PIM(0): Insert (10.0.20.1,224.1.1.1) sgr prune in nbr 10.0.26.6's queue
PIM(0): Building Join/Prune packet for nbr 10.0.26.6
PIM(0): Adding v2 (10.0.20.1/32, 224.1.1.1), RPT-bit, S-bit Prune
PIM(0): Send v2 join/prune to 10.0.26.6 (FastEthernet1/0)

Upon R6 receiving this prune message, it removes the interfaces where the prune message is received from its outgoing interface list. It then sends the prune message to R1.

PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 10.0.26.2, to us
PIM(0): Prune-list: (10.0.20.1/32, 224.1.1.1) RPT-bit set
PIM(0): Insert (10.0.20.1,224.1.1.1) sgr prune in nbr 10.0.16.1's queue
PIM(0): Building Join/Prune packet for nbr 10.0.16.1
PIM(0): Adding v2 (10.0.20.1/32, 224.1.1.1), RPT-bit, S-bit Prune
PIM(0): Send v2 join/prune to 10.0.16.1 (FastEthernet1/0)

When R1 receives the prune message, it removes the interface where it received the prune packet from the outgoing interface list for the 10.0.20.1,224.1.1.1 entry. It then also sends the prune message out to R5.

PIM(0): Received v2 Join/Prune on FastEthernet1/0 from 10.0.16.6, to us
PIM(0): Prune-list: (10.0.20.1/32, 224.1.1.1) RPT-bit set
PIM(0): Prune FastEthernet1/0/224.1.1.1 from (10.0.20.1/32, 224.1.1.1)
PIM(0): Insert (10.0.20.1,224.1.1.1) prune in nbr 10.0.15.5's queue - deleted
PIM(0): Building Join/Prune packet for nbr 10.0.15.5
PIM(0): Adding v2 (10.0.20.1/32, 224.1.1.1), S-bit Prune
PIM(0): Send v2 join/prune to 10.0.15.5 (Ethernet0/0)

Finally when R5 receives the prune message for the 10.0.20.1,224.1.1.1 entry, it removes the interface where it received the prune from the outgoing interface list.

PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.0.15.1, to us
PIM(0): Prune-list: (10.0.20.1/32, 224.1.1.1)
PIM(0): Prune Ethernet0/0/224.1.1.1 from (10.0.20.1/32, 224.1.1.1) - deleted

Finally multicast packets flow from the server to R4 then to R5, to R2, to R3 and the receiver. The multicast routing table from all routers will show the packet flow. We can see the incomming interface on R2 is ethernet0/2 and not fastethernet1/0.

R3#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 01:26:37/stopped, RP 1.1.1.1, flags: SJC
  Incoming interface: Ethernet0/0, RPF nbr 10.0.23.2
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 01:26:37/00:02:28

(10.0.20.1, 224.1.1.1), 01:26:36/00:02:56, flags: JT
  Incoming interface: Ethernet0/0, RPF nbr 10.0.23.2
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 01:26:36/00:02:28

R2#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 01:26:37/00:02:32, RP 1.1.1.1, flags: S
  Incoming interface: FastEthernet1/0, RPF nbr 10.0.26.6
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 01:26:37/00:02:32

(10.0.20.1, 224.1.1.1), 01:26:36/00:03:19, flags: T
  Incoming interface: Ethernet0/2, RPF nbr 10.0.25.5
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 01:26:36/00:02:32

R6#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 01:26:37/00:03:28, RP 1.1.1.1, flags: S
  Incoming interface: FastEthernet1/0, RPF nbr 10.0.16.1
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 01:26:37/00:03:28

(10.0.20.1, 224.1.1.1), 01:26:36/00:02:58, flags: PR
  Incoming interface: FastEthernet1/0, RPF nbr 10.0.16.1
  Outgoing interface list: Null

R1#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 02:28:10/00:02:35, RP 1.1.1.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse, 01:26:37/00:02:35

(10.0.20.1, 224.1.1.1), 02:28:10/00:02:51, flags: PT
  Incoming interface: Ethernet0/0, RPF nbr 10.0.15.5
  Outgoing interface list: Null

R5#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 01:26:37/stopped, RP 1.1.1.1, flags: SP
  Incoming interface: Ethernet0/0, RPF nbr 10.0.15.1
  Outgoing interface list: Null

(10.0.20.1, 224.1.1.1), 01:26:37/00:03:29, flags: T
  Incoming interface: Ethernet0/1, RPF nbr 10.0.45.4
  Outgoing interface list:
    Ethernet0/2, Forward/Sparse, 01:26:36/00:03:27

R4#sh ip mroute 224.1.1.1 | begin Interface
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 02:28:10/stopped, RP 1.1.1.1, flags: SPF
  Incoming interface: Ethernet0/0, RPF nbr 10.0.45.5
  Outgoing interface list: Null

(10.0.20.1, 224.1.1.1), 02:28:10/00:03:21, flags: FT
  Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 01:26:37/00:02:36

If we do not want R3 to change over to source tree, to attain an optimal path, we could use the ip pim spt-threshold infinity command on it. But that does not make sence in this case to do so.

Download GNS Config files