EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

Configuration & Working PIM Dense Mode

Configuration & Working PIM Dense Mode

Posted on Jan 24, 2020 (0)

Configuration & Working PIM Dense Mode

For Multicast routing PIM is widely used. The PIM has following version.

  • PIM-DM (PIM-Dense Mode based on Source Based tree)
  • PIM-SM (PIM-Sparse Mode based shared tree or CBT)

PIM Dense Mode:

PIM-DM is the Protocol Independent Multicast dense mode has following characteristics:

  • It is the protocol independent (can use eigrp, ospf, bgp static) unicast route table for RFP check
  • No separate multicast routing protocol like DVMRP
  • It uses Flood and prune method to migrates broadcast tree to SPT
  • It work easily on classless method as long as unicast routing protocol is classless.

PIM-DM Working:

PIM dense mode works with following steps:

  • PIM Neighbour Discovery
  • PIM-DM Source Distribution trees
  • PIM-DM Multicast forwarding along with various enhancement

PIM Neighbour Discovery:

When PIM runs on interfaces of router, it send the PIM Hello message every 30 seconds to establish PIM neighbour adjacencies. PIM router multicasts PIM Hello Message to all PIM routers 224.0.0.13 on each multicast enabled interfaces.

PIM hello Message also contain the HOLD time which tells the neighbour that if by that time PIM Hello is not received, PIM Neighborship will be down. By default HOLD Down timer is 90 sec.

When PIM hello message are used to form PIM adjacencies, This Hello message are also used to elect the designated router (DR) in multi-access medium. The Highest IP address in Hello message will be the DR of network.

In PIM-Dense mode DR has very little use, however it is much widely used in PIM-SP mode. Also if you are using IGMPv1, this DR acts as Querier to generate the IGMPv1 query message because IGMPv1 does not have its own Query router election mechanism.

There is also some advancement done in PIM message, now PIMv2 message is being used and in this you can configure Priority on router which can be used to elect the DR, because PIMv2 message has now priority filed enabled and it can carry routers priority.

In case the Priority are equal then highest IP address are used to elect the DR.

To know PIM adjacency and DR elected use show ip pim neighbor command:

In above example router Router-1 has several neighbours on interface FastEthernet0. Notice that neighbour 192.16.0.91 is the DR on this Fast Ethernet segment and has been up for 2 weeks and 6 days by 2w6d in the Uptime column. Also the adjacency with this neighbour expires in 1 minute and 1 second if router Router-1 doesn't receive any further PIM Hellos from this neighbour

PIM-DM Source Distribution trees

When PIM-DM is used, source distribution or shortest path first (SPT) are used to forward the multicast traffic.

PIM-DN uses its neighbour information to initially create the Source Distribution tree with incoming interface is in direction of Source and all other PIM-DM neighbour being downstream for this source. This initial form of tree is looks as Broadcast tree because a multicast traffic is sent to all neighbour weather they have any active host or not.

Later with PIM-DM prune method, this broadcast tree is converted to SPT. We will learn how pruning happens later in this section.

PIM-DM Multicast forwarding along with various enhancement

In order to flow multicast traffic using PIM-DM, PIM-Dense mode must be configured. Following are the method to configure PIM-DM.

Router-1)#ip multicast-routing

Enable PIM-DM on every interface in every router in the network, using the following interface command:

Router-1)#int fa0/0
Router-1(config-int)#ip pim dense-mode

Now before understanding how Multicast Traffic flow in PIM-DM lets understand how Control plane of PIM-DM is build and what PIM-DM state rule says:

 PIM-DM State Rules:

PIM dense mode create the (*, G) entry first whenever (S, G). And all (S, G) entries of PIM are linked to a parent (*, G) entry. With this, it leads to create the First PIM General Rule:

PIM-DM (*, G) state rule:

Whenever it is necessary to create an (S, G) entry and a corresponding parent (*, G) entry does not exist, a new (*, G) entry is automatically created first.

However in PIM-DM (*, G) entries are not used for multicast forwarding. In Dense mode this (*, G) entry is created because it contain all the neighbour information in its OIL (Outgoing interface list) or we can say that contains the interfaces where other PIM neighbours or directly connected members of the group exist. This information is used to initially populate the outgoing interface list (OIL) of any newly created (S, G) entries for the group or tree to say broadcast tree. This leads to the first dense mode rule.

The outgoing interface list of a dense mode (*, G) entry reflects the interfaces where

  • Other PIM-DM neighbors exist
  • Directly connected members of the group exist.

PIM-DM (S, G) state rule:

 As soon as Multicast traffic is arrived, (S, G) entries are created.

Incoming interface entry: The incoming interface for (S, G) entry is computed by calculating the RPF check for source S.

General Rule 2

The RPF interface is computed as the interface with the lowest cost to the IP address of the source (or in the case of a sparse mode (*, G) entry, the RP). If multiple interfaces have the same cost, the interface with the highest IP address is chosen.

Outgoing interface entry of(S, G): When the (S, G) entry is created, its outgoing interface list is initially populated with a copy of the outgoing interface list from its parent (*, G) entry. The outgoing interface list of the parent, dense mode (*, G) contains a list of all PIM neighbours or directly connected members, this list is initially used for traffic forwarding in a flood-and-prune manner via the newly created (S, G) entry. This leads to General Rule 3

General Rule 3

When a new (S, G) entry is created, its outgoing interface list is initially populated with a copy of the outgoing interface list from its parent (*, G) entry.

It may be that the incoming interface of an (S, G) entry may be the copy of the outgoing interface list of the parent (*, G) entry so in this case the incoming interface will also appear in the outgoing interface list for this (S, G) entry. This would lead to a multicast routing loop. To prevent this every time the RPF interface for an (S, G) entry is calculated, it is determined that RPF interface is removed from the outgoing interface list. This results the next general rule.

General Rule 4

The incoming interface (RPF interface) of a multicast forwarding entry must never appear in its outgoing interface list.

PIM-DM state maintenance Rule:

 General Rule 5: In this the RPF interface of every multicast state entry is recalculated in every 5 seconds, this is done because it may be possibility that unicast routing change may occur if any network events occur. Once it is done and in case of RPF change, the outgoing interface list is adjusted appropriately as per general rule4.

When (S,G) entry is created , in interface in OIL has status marked forward/dense so that the initial packets can be flooded to all neighbour, and once pruning is done then the pruned interface is not removed from OIL instead it is marked as prune/dense and simultaneously prune timer of 3 min starts. When prune timer expires the interface is returned back to forward/dense and starts flooding traffic again.

General Rule 6:  This rule states that if any addition or deletion to OIL list of (*, G) entry is done, these entries are replicated as per general rule 4 to all associated (S, G) entries of the group.

PIM-DM flags States:

 Following are the flags that are visible in different scenarios when you run “sh ip mroute” command.

Consider the following topology:

PIM-DM States Example as per sh ip mroute command:

Now let’s understand the line one by one:

(*, 224.2.2.2), 00:00:10/00:00:00, RP 0.0.0.0, flags: D

  • (*, 224.2.2.2) Indicates that this is the (*, G) entry for multicast group 224.2.2.2
  • 00:00:10/00:00:00 Uptime/expire timer counters. The uptime timer shows that this entry has been up for 10 seconds, but that the expire timer is not running. (This situation is normal for (*, G) dense mode entries that have associated (S, G) entries. When all the (S, G) entries are deleted, this timer will start. Expire timers usually count down from 3 minutes. When the expiration time is reached, the state entry is deleted.
  • RP 0.0.0.0 indicates the IP address of the RP. Because this is a dense mode group, there is no RP and, therefore, 0.0.0.0 is displayed.
  • Flags: D indicates that this group is a dense mode group. (Note: The S (Sparse) and D flags are shown only on the (*, G) entries.)

Incoming interface: Null, RPF nbr 0.0.0.0

  • Incoming interface: Null indicates that this entry is a dense mode (*, G) entry, and this information is not used. Dense mode forwards using (S, G) entries instead of (*, G) entries. Therefore, the incoming interface is shown as Null.
  • RPF nbr 0.0.0.0 Indicates the IP address of the upstream (RPF) neighbour for this multicast traffic. Again, because you don't forward on dense mode (*, G) entries, this information is always 0.0.0.0.

Outgoing interface list:

Serial0, Forward/Dense, 00:00:10/00:00:00

Serial1, Forward/Dense, 00:00:10/00:00:00

Serial2, Forward/Dense, 00:00:10/00:00:00

  • The outgoing interface list of dense mode (*, G) entries reflects any interfaces having a PIM neighbour or a directly connected member of the group. This information is used to initially populate the outgoing interface list of any (S, G) entries for Group G
  • Forward/dense Indicates the forwarding state and mode of the interface. Because this entry is in the outgoing interface list of a dense mode (*, G) entry, it always reflects forward and dense mode.

(192.168.1.2/32, 224.2.2.2), 00:00:10/00:02:50, flags: T

  • (192.168.1.2/32, 224.2.2.2) Indicates that this is the (S, G) entry for IP multicast source 192.168.1.2 sending to multicast group 224.2.2.2
  • Flags: T (SPT) Indicates that multicast traffic for this source/group is being forwarded using this entry. (In other words, the (S, G) traffic is being forwarded on the shortest path tree.)

Incoming interface: Serial0, RPF nbr 198.92.1.129

  • Incoming interface: Serial0 Indicates that Serial0 is the incoming (RPF) interface for this (S, G) traffic.
  • RPF nbr 198.92.1.239 indicates the IP address of the upstream (RPF) neighbour in the direction of the source is 198.92.1.239.

Outgoing interface list:

Serial1, Forward/Dense, 00:00:10/00:00:00

Serial2, Prune/Dense, 00:00:10/00:02:50

  • Serial1 indicates the outgoing interface.
  • Prune/Dense Indicates the forwarding state and mode of the interface. Dense mode (S, G) outgoing interface list entries reflect either Forward/Dense or Prune/Dense depending on whether the interface has been pruned or not.

PIM Forwarding

When Proper mroute table is created any multicast traffic related to appropriate group can be forwarded.

  • When a multicast packet is received , longest match with Source “ S” and Group “ G” is found which can be first match by any related (S,G) entry and if no matching is done , (*,G) entry will be used.
  • Dense mode only used (S, G) entry for source tree and forwards the traffic based on that tree.
  • When a match is found, RPF check is performed on incoming packet, it can be derived by comparing the incoming interface in the matching mroute table entry with the packet's actual incoming interface. If the packet didn't arrive via the incoming interface, the packet is dropped.
  • And if RPF interface is matched correctly, packet is forwarded out to all unpruned interface mentioned in OIL.

PIM-DM Flooding:

In below figure, we will see how flooding is done in PIM-DM. Let’s assume no multicast traffic is going at this point.

Let’s say R1 starts receiving the multicast traffic on s0 from Source 192.16.1.2 for group 224.2.2.2. As this is PIM-DM the packet is initially flooded to all PIM neighbours, to make this happen Router will create the (S,G) entry and its parent (*,G) entry based on General Rule 1.

The entry can be verified by sh ip mroute command:

  • R1 has automatically created the parent (*, G) entry, (*, 224.2.2.2), and populates its outgoing interface list with interfaces Serial0, Serial1, and Serial2 (based on Rule 1).
  • These are the interfaces on R1 that have PIM neighbours. Note that the PIM neighbour connected to R1's Serial0 interface is not shown. The (S, G) entry, (192.168.1.2/32, 224.2.2.2), shown has its incoming interface computed as Serial0, with an RPF neighbour set to 192.168.1.1 (this neighbour is not shown using the RPF calculation stated in General Rule 2.
  • The (S, G) entry has also had its outgoing interface list initially populated from a copy of the interfaces in the (*, G) outgoing interface list (based Rule 1). Finally, Serial0 (the incoming interface) was removed from the outgoing interface list (based on General Rule 4) so that the incoming interface does not appear in the outgoing interface list and cause a route loop.

PIM-DM Pruning:

 Using same example, R2 do not have any host active for this 224.2.2.2 group. This can be verified on R2 mroute table.

The arrival of the first (S, G) multicast packet caused Router B to create the (S, G) and (* G) entries (based on General Rule 1). Notice that the Flags field of the (*, G) entry indicates that this is a dense mode group, and because the (*, G) entry is not used to forward multicast traffic in dense mode, the entry reflects a Null incoming interface. In addition, the outgoing interface list of the (*, G) contains a single entry, Serial0, which is the interface that connects to its PIM neighbour, R1.

The incoming interface of the (S, G) entry has been computed as Serial0 (based on General Rule 2) with an RPF neighbor of 192.16.2.1, which is the IP address of Serial2 on R1. The outgoing interface list was initially populated with interfaces from the (* G) outgoing interface list, that is, Serial0. However, applying General Rule 4 and removing the incoming interface from the outgoing interface list leaves a Null outgoing interface list in the (S, G) entry as shown in the output of the initial state in R2 above.

Because the outgoing interface list is Null, R2 sets the P flag in the (S, G) entry and sends an (S, G) Prune upstream to R1 to shut off the flow of unnecessary (S, G) multicast traffic. When R1 receives the Prune, the router responds by pruning interface Serial2 and this Serial2 was immediately pruned by R1

Interface Serial2 in the outgoing interface list of the (S, G) entry is now in Prune/Dense state and that the interface timers are now reflecting Prune information. The Prune timeout information of 00:01:29/00:01:31 indicates that in  down to zero, the interface will be placed in Forward/Dense state, which will result in (S, G) traffic again being flooded out Serial2 to R2. This cycle will continually repeat itself every 3 minutes while source S is still sending Group G traffic, thereby causing R2 to send a Prune to R1 again.

PM-DM Grafting:

Let's assume that R2 has a directly connected host Join Group G Now, R2 needs to get the flow of (S, G) traffic started as quickly as possible to deliver it to its host

If R2 just simply waits until the upstream Prune state on R1 times out, the result could be a worst-case delay of 3 minutes before traffic is received. Fortunately,because R2 still has (S, G) state, it is aware that this source is active and can respond by sending a Graft message to its upstream neighbour to quickly restart the flow of multicast traffic. (The upstream neighbour is indicated in the RPF nbr field of the (S, G) entry.)

The multicast entry after Graft message on R2 is as shown.

C flag has been set in the (S, G) entry, which indicates that R2 has a directly connected member for this traffic. Also, the (S, G) outgoing interface is no longer Null as it now includes fa0/0.

State-Refresh Msg:

  • This mgs is used to prevent the interface from being flip-flop from forwards/dense to prune/dense or vice versa as soon as prune timer expires.
  • By this method, R2 monitors the time since it sent the last prune to R1, just before prune timer expires, R3 decides to send the state refresh message to R1 to keep its int status Pruned.

 


Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.