WB1 8.26 Bidirectional PIM

8.26 Bidirectional PIM

• The group range 238.0.0.0/8 is used for network video-conferencing with many participants.
• Configure the network so that this group uses a single shared tree rooted on R5 for multicast traffic delivery.

------------------------------------------------------------------------------------------------------

Bidirectional PIM or PIM BiDir is a special extension to the PIM SM concept that
uses only the shared tree for multicast distribution. This mode of operation is
useful in situations where most receivers are also senders at the same time. For
example, this might be the case when you run videoconferencing. In this
situation, in addition to joining the shared tree rooted at the RP, every receiver
needs to join the shortest-path multicast distribution tree rooted at every other
participant. If the number of participants is significant, the amount of multicast
route states in the core of the network will grow at a quadric rate.

One special feature of PIM SM shared and shortest path trees are that they are
unidirectional – traffic passes down from the root to the leaves of the tree. PIM
BiDir uses a single distribution tree rooted at the RP for all sources and receivers
at the same time. If there are multiple RPs, there could be many BiDir trees.
Unlike the classic tree, traffic may flow up and down this tree. When a source
sends multicast packets, they first flow up to the root of the tree (toward the RP)
and then down to all receivers.

To build the bi-directional tree, PIM elects special designated forwarders (DFs)
on every link in the network. A DF is elected based on the rules similar to the
ones used in the PIM Assert procedure – i.e., the router on the link that has the
shortest metric to reach the RP is selected as the DF. Notice that a single router
might be the DF on one link and a non-DF on another. After the elections, DF
routers are the only routers that are allowed to forward traffic toward the RP – via
the bi-directional tree (this is considered the “upstream” portion of the BiDir tree).
Every router in the multicast domain creates a (*,G) state for each BiDir group,
with the OIL built based on PIM Join messages received from its neighbors. This
is the “downstream” portion of the BiDir tree. Any packet received on a valid RPF
interface is forwarded based on the OIL. At the same time, the DF will forward a
copy of these packets toward the RP - upstream through the shared tree -
provided that the packet is not received on the interface pointing to the RP.

Notice that PIM BiDir does not utilize the source registration procedure, via PIM
Register/Register-Stop messages. Every source connected to a PIM BiDir
capable router may start sending at any time, and the packets will flow upwards
to the RP. After reaching the RP, packets are either dropped, if there are no
receivers for this group (i.e. the OIL for this (*,G) state is empty) or forwarded
down the BiDir tree. There is no way for the RP to signal the source to stop
sending traffic even if there are no receivers. This means commands like “ip pim
accept-register” covered in lab 8.8 will not work with PIM BiDir, due to the fact
that they rely on these “register-stop” messages to work.

Configuring PIM BiDir is relatively simple. You just need to enable BiDir PIM on
all multicast routers by using the command ip pim bidir-enable and
designate particular RP/Group combinations as bi-directional. You can do this in
a number of ways.

1) Using a static RP configuration with the command ip pim rp-address <IP> <ACL> bidir.

2) Using BSR or Auto-RP for RP information dissemination you may flag
particular group/RP combinations as bi-directional using the following syntax:

Auto-RP:
ip pim send-rp-announce <interface> scope <TTL> group-list <ACL> bidir

BSR:
ip pim rp-candidate <interface> group-list <ACL> bidir

This is all you need to enable bi-directional PIM. However, remember to enable
bi-directional mode on all routers in your network, or you might end up with
routing loops.

------------------------------------------------------------------------------------------------------

R1, R3, R4, SW2, SW4:
ip pim bidir-enable

R5:
ip pim bidir-enable
!
ip access-list standard GROUP238
permit 238.0.0.0 0.255.255.255
!
ip pim rp-candidate Loopback 0
group-list GROUP238 bidir

------------------------------------------------------------------------------------------------------

To verify, join R1 and SW4 to the bi-directional group 238.1.1.1.

R1:
interface FastEthernet 0/0
ip igmp join-group 238.1.1.1

SW4:
interface Vlan 10
ip igmp join-group 238.1.1.1

------------------------------------------------------------------------------------------------------

To verify, join R1 and SW4 to the bi-directional group 238.1.1.1.

R1:
interface FastEthernet 0/0
ip igmp join-group 238.1.1.1

SW4:
interface Vlan 10
ip igmp join-group 238.1.1.1

and then ping this group from R5.

------------------------------------------------------------------------------------------------------

Rack1R5#ping 238.1.1.1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 238.1.1.1, timeout is 2 seconds:
Reply to request 0 from 155.1.108.10, 4 ms
Reply to request 0 from 155.1.0.1, 188 ms
Reply to request 0 from 155.1.0.1, 104 ms
Reply to request 0 from 155.1.108.10, 8 ms
Reply to request 1 from 155.1.108.10, 4 ms
Reply to request 1 from 155.1.0.1, 189 ms
Reply to request 1 from 155.1.0.1, 104 ms
Reply to request 1 from 155.1.108.10, 8 ms

Check the mroute states on all routers. Notice that some interfaces are marked
as Bidir-Upstream – these interfaces are used to send packets upwards to the
root of the tree. The root of the tree (the RP) will have no upstream interfaces

Rack1R1#show ip mroute 238.1.1.1
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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 238.1.1.1), 00:08:33/00:02:43, RP 150.1.5.5, flags: BPL
  Bidir-Upstream: Serial0/0.1, RPF nbr 155.1.0.5
  Outgoing interface list:
    Serial0/0.1, Bidir-Upstream/Sparse, 00:08:33/00:00:00
Rack1R1#

Rack1R5#show ip mroute 238.1.1.1
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,
       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
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 238.1.1.1), 00:08:42/00:03:27, RP 150.1.5.5, flags: B
  Bidir-Upstream: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0, 155.1.0.1, Forward/Sparse, 00:07:57/00:03:27
    FastEthernet0/0, Forward/Sparse, 00:08:42/00:02:39
Rack1R5#