Understanding the multicast routing table

I set-up the following network using IOU and will give the output of the multicast routing table when various PIM protocols are configured. I didn’t used dynamips as there is a host of issues that are well document in the dynagen/dynamips forums indicating that multicast simulation isn’t reliable.

R1 is the source of the multicast traffic and I’m generating this using the ping command:

ping ip 239.0.0.1 repeat 1000

R7 is the multicast destination is not running any PIM / routing. I use the the “ip igmp join” command on their interface to subscribe to the group.

Router R2 to R6 running OSPF on all their interfaces .

This is the standard blurb when you run a show ip mroute command on a cisco box

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

  • D – Dense Entry is operating in dense mode.
  • S – Sparse Entry is operating in sparse mode. 
  • C – Connected A member of the multicast group is present on the directly connected interface.
  • L – Local The router itself is a member of the multicast group.
  • P – Pruned Route has been pruned. The Cisco IOS software keeps this information in case a downstream member wants to join the source.
  • R – Rp-bit set Indicates that the (S,G) entry is pointing toward the rendezvous point (RP). The RP  is typically a prune state along the shared tree for a particular source.
  • F – Register flag Indicates that the software is registering for a multicast source.
  • T – SPT-bit set Indicates that packets have been received on the shortest path source tree.
  • J – Join SPT
  • H – Hardware switched Indicates the outgoing interface is hardware switched because IP multicast MLS is enabled.
  • uptime – How long in hours, minutes, and seconds the entry has been in the IP multicast routing table.
  • expires – How long in hours, minutes, and seconds until the entry will be removed from the IP multicast routing table on the outgoing interface. The word “stopped” indicates that timing out of this entry is not determined by this expire timer.
  • RP- Address of the rendezvous point (RP) router. For routers and access servers operating in sparse mode, this address is always 0.0.0.0. 
  • Incoming interface – Expected interface for a multicast packet from the source. If the packet is not received on this interface, it is discarded.
  • RPF neighbor – IP address of the upstream router to the source. This is the router closer to the source and is the one sending you the multicast packets. The word “Tunneling” indicates that this router is sending data to the RP encapsulated in Register packets. The hexadecimal number in parentheses indicates to which RP it is registering. Each bit indicates a different RP if multiple RPs per group are used.
  • Outgoing interface list – Interfaces through which packets will be forwarded. When the ip pim nbma-mode command is enabled on the interface, the IP address of the PIM neighbor is also displayed.

The entry (*, G) is a shared multicast tree entry.

The entry (S, G) is a source-specific multicast tree for a particular multicast group. There will generally be one such entry for each source and group.

PIM-DM

Configuration

ip multicast-routing
 int e0/0
ip pim dense-mode
int e0/1
ip pim dense-mode

As this is dense mode (which is indicated by the D flag) the (*,G) entry really has no meaning and can be skipped. In dense mode you have no RPs as such the value is 0.0.0.0

R2
(*, 239.0.0.1), 00:13:17/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/1, Forward/Dense, 00:13:17/00:00:00

(1.1.1.1, 239.0.0.1), 00:13:17/00:02:30, flags: T
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/1, Forward/Dense, 00:01:22/00:00:00

In the (S,G) route, when you have a RPF neighbor of 0.0.0.0 and a specific incoming interface you can assume that this router is first the from the source. The route on R3 is shown below and you can clearly see that the incoming interface ie e0/1 with a neighbor of 2.2.2.2.

R3
(1.1.1.1, 239.0.0.1), 00:13:56/00:02:55, flags: T
  Incoming interface: Ethernet0/1, RPF nbr 2.2.2.2
  Outgoing interface list:
    Ethernet0/0, Forward/Dense, 00:13:56/00:00:00

R6
(1.1.1.1, 239.0.0.1), 00:17:46/00:02:03, flags: T
  Incoming interface: Ethernet0/0, RPF nbr 5.5.5.5
  Outgoing interface list:
    Ethernet0/1, Forward/Dense, 00:17:46/00:00:00

If you remove the active listener then tree is pruned and route changes as shown below.

R6
(1.1.1.1, 239.0.0.1), 00:29:53/00:01:58, flags: PT
  Incoming interface: Ethernet0/0, RPF nbr 5.5.5.5
  Outgoing interface list: Null

In this case you can see that the route on R6 has been active for 29 minutes 53 seconds and a prune will expire in 1 minute 58 seconds.

 PIM-SM (Static RP)

The RP is set to R4’s loopback which has an ip address of 44.44.44.44. Note as we are using static-rp we don’t need to run sparse-dense mode. Only sparse mode will do fine.

Configuration
ip multicast-routing
ip pim rp-address 44.44.44.44

int e0/0
ip pim sparse-mode
int e0/1
ip pim sparse-mode

R2
(*, 239.0.0.1), 00:07:18/stopped, RP 44.44.44.44, flags: SPF
  Incoming interface: Ethernet0/1, RPF nbr 2.2.2.3
  Outgoing interface list: Null

(1.1.1.1, 239.0.0.1), 00:07:18/00:03:06, flags: FT
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:07:04/00:03:17

The (S,G) output is similar to the PIM-DM route for R2.

In the (*,G) entry the RP is set correctly to 44.44.44.44 rather than 0.0.0.0 in dense mode. The most interesting thing is that the RFP neighbor points to the router closer to the RP  (ie R3) and NOT the source.

R3
(*, 239.0.0.1), 00:00:08/stopped, RP 44.44.44.44, flags: SP
  Incoming interface: Ethernet0/0, RPF nbr 3.3.3.4
  Outgoing interface list: Null

(1.1.1.1, 239.0.0.1), 00:00:08/00:03:21, flags: T
  Incoming interface: Ethernet0/1, RPF nbr 2.2.2.2
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:00:08/00:03:23

The (*,G) and (S,G) entries are the same as R2. The (*,G) points towards R4 where as the (S,G) entry points towards R2.

R5
(*, 239.0.0.1), 00:50:10/00:02:31, RP 44.44.44.44, flags: S
  Incoming interface: Ethernet0/1, RPF nbr 4.4.4.4
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:50:10/00:02:31

(1.1.1.1, 239.0.0.1), 00:07:46/00:02:35, flags: T
  Incoming interface: Ethernet0/1, RPF nbr 4.4.4.4
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:07:46/00:02:37

These route entries have the same features as R3. This is to be expected because the PIM protocol joins the shortest path tree immediately after the first packet arrives from a new source. If we set the global config command “ip pim spt-threshold infinity” on R6 and repeat this for a new group (239.0.0.10) we see the following:


R2
(*, 239.0.0.10), 00:03:34/stopped, RP 44.44.44.44, flags: SPF
  Incoming interface: Ethernet0/1, RPF nbr 2.2.2.3
  Outgoing interface list: Null

(1.1.1.1, 239.0.0.10), 00:03:34/00:02:41, flags: FT
  Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0/1, Forward/Sparse, 00:03:29/00:02:57


R5
(*, 239.0.0.10), 00:04:04/00:03:21, RP 44.44.44.44, flags: S
  Incoming interface: Ethernet0/1, RPF nbr 4.4.4.4
  Outgoing interface list:
    Ethernet0/0, Forward/Sparse, 00:04:04/00:03:21



The R2 routes are the same since the traffic will always follow the (S,G) entry. The (*,G) entry will be there but unused. However on R5 we only have the (*, G) route which indicates that all our traffic is being received from the RP. 

In summary, when the spt threshold is set to infinity: all routers from the source, leading up to the RP will send traffic according to the (S,G) route and all routers after the RP will send traffic based on the (*,G) entry.

If we remove the command “ip pim spt-threshold infinity” and set it back to the default of 1, on R6 and R5 the routing table learns the (S,G) route and stars forwarding packets using this.

In this case we start with (S,G) -> for router from the source to the RP, and (*,G) -> for router from the RP to the destination. But after only 1 packet is transmitted we have (S,G) –> for router from the source to the destination.

 PIM-SM (AutoRP & AnycastRP)

These two protocols only decide how the RPs are defined in the network. They do not affect the multicast routing table. Regardless of which protocol you use: Static, AutoRP or AnycastRP the multicast routing table and how packets are forwarded will remain the same.



L3 IOU

This is the first testing I’ve done with IOU and  its really worth the effort to learn the new setup. Here is the NETMAP file I used:

101:0 102:0
102:16 103:16
103:0 104:0
104:16 105:16
105:0 106:0
106:16 107:16

The process assignments were as follows:

R1: 101
R2: 102
R3: 103
R4: 104
R5: 105
R6: 106
R7: 107

I started each router follows:

./wrapper-linux -m /usr/home/iou/l3iou/i86bi_linux-adventerprisek9-ms -p 2101 — 101 &
./wrapper-linux -m /usr/home/iou/l3iou/i86bi_linux-adventerprisek9-ms -p 2102 — 102 &
./wrapper-linux -m /usr/home/iou/l3iou/i86bi_linux-adventerprisek9-ms -p 2103 — 103 &
./wrapper-linux -m /usr/home/iou/l3iou/i86bi_linux-adventerprisek9-ms -p 2104 — 104 &
./wrapper-linux -m /usr/home/iou/l3iou/i86bi_linux-adventerprisek9-ms -p 2105 — 105 &
./wrapper-linux -m /usr/home/iou/l3iou/i86bi_linux-adventerprisek9-ms -p 2106 — 106 &
./wrapper-linux -m /usr/home/iou/l3iou/i86bi_linux-adventerprisek9-ms -p 2107 — 107 &

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s