Bidirectional PIM

Today we are going to discuss about the BIDIRECTIONAL PIM.

Note all the router preconfigured with the ipv4 address and OSPF is used as the routing protocol, all routers are in area 0. PIM sparse dense mode it running.

IP ADDRESS: Fast Ethernet 155.1.XY.X/24

                       Loopback         X.X.X.X/32

Where X & Y is the router host number.(X <Y)

Bi-Dir is kind of the opposite Source specific multicast, everything is a shared-tree, but traffic can flow bidirectional. That we will discuss later

What's the reason of using Bidirectional ??

The answer is think a massive network of multicast traffic, with many sources and many receivers (a many-to-many multicast application network). A network like this would quickly add hundreds, even thousands and tens of thousands of (S,G), multicast entries in the mroute table. One of the major applications for Multicast is financial services, stock markets etc, and in today's climate of HFT (High-Frequency-Trading), latency is a big no-no.

All those multicast entries in the mroute table will slow the switch down, and start to make the switch inefficient, thus, we have Bidirectional PIM, the idea is that if everything uses a shared tree, we can reduce the number of mroute table entries down to just those with (*,G), when using one multicast group address with multiple sources, this efficiency really starts making sense.

Bidirectional PIM can be assigned via static and BSR.

First we need to enable ip pim bidir-enable in all the routers

Rx(config)#ip pim bidir-enable

As we are going to use BSR. Here we choose R2 as our BSR and R3 as Candidate RP. First lets enable that

R2(config)#ip pim bsr-candidate loopback 0

R3(config)#ip pim rp-candidate loopback 0 bidir

R2#show ip pim rp mapping

PIM Group-to-RP Mappings

This system is the Bootstrap Router (v2)

Group(s) 224.0.0.0/4

  RP 3.3.3.3 (?), v2, bidir

    Info source: 155.1.23.3 (?), via bootstrap, priority 0, holdtime 150

         Uptime: 00:01:40, expires: 00:01:48

So as far now we are ok we found the RP via BSR. Let generate some multicast feed

R1#ping

Protocol [ip]:

Target IP address: 224.5.5.5

Repeat count [1]: 100000000

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Interface [All]: loopback0

Time to live [255]:

Source address: 1.1.1.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 100000000, 100-byte ICMP Echos to 224.5.5.5, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

.............................................

Lets check the path and mroute table

R2#show ip mroute 224.5.5.5 | be Int

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

(*, 224.5.5.5), 00:10:47/00:02:57, RP 3.3.3.3, flags: BP

  Bidir-Upstream: FastEthernet1/1, RPF nbr 155.1.23.3

  Outgoing interface list:

    FastEthernet1/1, Bidir-Upstream/Sparse, 00:10:47/00:00:00

See R2 receiving the multicast feed as unicast packet. Hence R2 learns that we have a group 224.5.5.5 and make an entry (*,224.5.5.5). This stream sent upside towards the RP via Fa1/1. Now check on RP R3

R3#show ip mroute 224.5.5.5 | be Int

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

(*, 224.5.5.5), 00:00:51/00:02:08, RP 3.3.3.3, flags: BP

  Bidir-Upstream: Null, RPF nbr 0.0.0.0

  Outgoing interface list: Null

Hence this is our RP as we don’t have any receiver its prune. Lets create the receiver

R6(config)#int lo0

R6(config-if)#ip igmp join-group 224.5.5.5

As soon as we had a receiver our ping getting the success

R1#

Reply to request 581 from 155.1.56.6, 656 ms

Reply to request 582 from 155.1.56.6, 788 ms

Reply to request 583 from 155.1.56.6, 576 ms

Reply to request 584 from 155.1.56.6, 564 ms