PIM Sparse Mode - BSR

November 26th, 2007 neteng

Welcome back everyone. I hope you guys were smart enough to avoid following my lead this past weekend and not stuff yourself silly. I’m growing feathers from all the turkey I ate! But I digress…We’re back in action for awhile and I hope to have some good material coming your way.

Let’s begin where we left off and take a look at our common PIM network. We’ve seen static RP assignments and Auto-RP at work, so now we’ll take a look at BSR. It’s really not very complicated if you’re familiar with Auto-RP and you’ll see what I mean as we go through the configuration. The BSR router plays a similar role to the Auto-RP Mapping Agent, but it performs one major function differently. The Auto-RP MA elects an RP based on the announcements it receives from candidate-RPs (C-RP). The BSR router actually sends all mapping possibilities to every PIM router and allows them to elect an RP. They will elect the same RPs for each group though, as every PIM router uses the same hash algorithm.

First, we’ll configure R3 to be our C-RP:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip pim rp-candidate lo0

Now let’s verify:

R3#sh ip pim rp map
PIM Group-to-RP Mappings
This system is a candidate RP (v2)

Next, let’s configure R2 to be our BSR:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip pim bsr-candidate lo0

Let’s verify that everything is working as it should be now:

R2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 192.168.23.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:54, expires: 00:01:33

You can see that R3 has been selected as the RP for all multicast groups. Now we’ll ping from our R1 multicast source to R6 and see what happens:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 452 ms

You can see that R5 is using R3 as it’s RP. This was learned as the BSR sent the announcement to each PIM router (224.0.0.13), and each PIM router forwarded this announcement to it’s neighbors at the same address. Let’s take a look:

R5#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 150.1.2.2 (?),via bootstrap, priority 0, holdtime 150
Uptime: 00:06:41, expires: 00:02:01

Here’s our mroute table on R5:

R5#sh ip mroute
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

(*, 239.39.39.39), 01:29:37/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 01:29:37/00:02:31

(192.168.12.1, 239.39.39.39), 00:02:56/00:00:10, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:02:56/00:02:31

(*, 224.0.1.40), 01:30:15/00:02:27, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:30:15/00:02:27

As far as basic BSR setup, that’s all there is to it! If you have multiple BSRs, the one with the highest priority will be elected. If they all have the default Cisco priority of 0, then the BSR candidate with the highest IP address will be chosen. If you have multiple RP candidates seeking election, then the BSR will also elect the RP based on the same priority/IP address system.

I hope you’ve found this series of PIM labs useful. I haven’t quite decided what to tackle next, but have some ideas in mind. Suggestions are always welcome! In the meantime though, expect to see a review of CCNA/CCNP training materials provided by our friends at TrainSignal.

neteng

Bookmark It

Hide Sites

Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »

PIM Sparse Mode - Auto RP

November 21st, 2007 neteng

Ok, so I told a small fib in my last post…But this really is the last post for this week! I finished up this lab and decided to go ahead and post it today. We’re using our familiar topology but we’ll be moving away from static RP assignments and using Cisco’s Auto-RP:

We’ve designated R3 as our Rendezvous Point (RP) and R2 as our Mapping Agent (MA). As a quick refresher, the RP acts as the root of the shared distribution tree and the MA is in charge of mapping RPs to multicast groups and disseminating that information out to multicast-participating routers. The dynamic RP system makes for a much simpler setup when you need to make changes in the future. Instead of having to update each individual router with new RP information, you just need to touch a few pieces.

The first thing we’ll want to do is assign our RP-candidate. We’ll do that as follows:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip pim send-rp-announce lo0 scope 16

As you can see, we’re having R3 announce it’s loopback address (150.1.3.3) as a candidate for RP assignment. The scope requirement on this command sets the TTL on the announcement packets, in order to limit how far they can go. I just picked an arbitrary number of 16. This command tells the router to send an announcement to 224.0.1.39, which every mapping agent is listening on. Now let’s verify that this router is set to announce itself as an RP:

R3#sh ip pim rp map
PIM Group-to-RP Mapping
This system is an RP (Auto-RP)

Next, we’ll assign the mapping duties to R2:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int lo0
R2(config-if)#ip pim sparse-mode
R2(config-if)#exit
R2(config)#ip pim send-rp-discovery lo0 scope 16

We had to make sure to configure PIM on R2’s loopback interface so it could participate. Now let’s verify that R2 is configured correctly:

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:00:10, expires: 00:02:49

We now see that R2 is our mapping agent and has already picked up the RP announcement coming from R3. It will now announce the RP assignment to multicast group 224.0.1.40 on which the PIM-configured routers listen. For curiosity’s sake, let’s see what would happen if we also configured R5 to also announce itself as an RP:

R2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:05:50, expires: 00:02:08
RP 150.1.3.3 (?), v2v1
Info source: 150.1.3.3 (?), via Auto-RP
Uptime: 00:24:37, expires: 00:02:23

R5 is now the RP of choice as it won out over R3. This is because of the higher IP address on R5. If R5 were to die, R2 would assign the RP duties to R3 to keep things going.

Ok, let’s take R5 out of the RP game and put things back to where they were. Now we’ll ping from R1 to the 239.39.39.39 group again (of which R6 is a member). Here is what our mroute table will look like on R5:

R5#sh ip mroute
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

(*, 239.39.39.39), 00:01:29/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:01:29/00:02:23

(192.168.12.1, 239.39.39.39), 00:00:04/00:02:55, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:00:04/00:02:55

….unnecessary info omitted….

Results from our ping:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 468 ms

Hope this was informative! We’ll return with a vengeance next week and tackle BSR along with other exciting topics. Enjoy the long weekend…

neteng

Bookmark It

Hide Sites

Posted in HOWTO, Multicast, Networking, Routing | 2 Comments »

PIM Sparse Mode - Static RP

November 20th, 2007 neteng

Welcome back to the PIM show! I know you’re just chomping at the bit to continue our PIM routing escapades, so we’ve come back to another lab…this time featuring sparse mode routing. We’re going to use the same topology as our dense mode lab and tweak things a little bit. For this lab, we’re just going to implement a static RP device. After this lab, we’ll dive into Auto-RP & BSR. Here’s our sparse mode topology:

We’re going to use the loopback0 interface of R3 as the RP address. This address must be reachable via our IGP. The first thing we’ll want to do is enable PIM on the loopback interface:

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int lo0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
*Nov 20 09:19:23.503: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 150.1.3.3 on interface Loopback0

Next, we need to statically assign the RP to each router participating in PIM (R2, R3 and R5):

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip pim rp-address 150.1.3.3

It’s important that remember to configure this on our RP as well, because it will not accept it’s status as an RP and you’ll get a message such as this:

*Nov 20 10:38:15.419: %PIM-1-INVALID_RP_REG: Received Register from router 192.168.23.2 for group 239.39.39.39, 150.1.3.3 not willing to be RP

We can verify that the RP is now assigned with the following command:

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
RP: 150.1.4.4

As you can see, the default mapping for the RP assignment is for all IP multicast groups. If you wanted to, you could have multiple RPs for different multicast groups by using ACLs. It could look something along the lines of this:

access-list 1 permit 239.0.0.0 0.255.255.255
ip pim rp-address 150.1.3.3 1
ip pim rp-address 150.1.4.4

This is saying “I want to use R3 as my RP for all multicast traffic going to 239.x.x.x.”
Here is what our mappings would look like in conjunction with the first assignment:

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
RP: 150.1.4.4 (?)
Acl: 1, Static
RP: 150.1.3.3

Okay, now lets do a test ping from R1 to R6 (who is still joined to our 239.39.39.39 group from our previous dense-mode lab, via the ip igmp join-group command) and see how our mroute table looks from R5’s perspective:

R5#sh ip mroute
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

(*, 239.39.39.39), 00:05:01/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:05:01/00:02:58

(192.168.12.1, 239.39.39.39), 00:02:28/00:02:20, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:02:28/00:02:58

(*, 224.0.1.40), 00:05:05/00:02:58, RP 150.1.3.3, flags: SJPCL
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list: Null

As you can see, we have our (*, 239.39.39.39) group which is part of the shared tree initially created by PIM sparse mode. Once the source-based tree is built, multicast packets are no longer forwarded along the shared tree and therefore you see the stopped message in the shared tree entry. In our case, the topology is pretty limited so the shared tree and source-based tree are essentially the same.

That’s all there is to it. I hope this was useful for you. As always, comments are welcome!

neteng

Bookmark It

Hide Sites

Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »

PIM Dense Mode

November 19th, 2007 neteng

Our first PIM lab will deal with dense mode PIM. If you need a refresher, please refer back to my previous post for a brief overview on dense mode. It also wouldn’t hurt to review some other documentation before you dive in.

Let’s take a look at our topology:

We have OSPF as our IGP providing full connectivity throughout the domain. Our first step is to get multicast routing up and running on all routers (except R4) with the following command:

ip multicast-routing

We can verify this with the show ip multicast command:

R1#sh ip multicast
Multicast Routing: enabled
Multicast Multipath: disabled
Multicast Route limit: No limit
Multicast Triggered RPF check: enabled
Multicast Fallback group mode: Sparse
Multicast DVMRP Interoperability: disabled

The next step is to enable dense mode PIM on the appropriate interfaces. We use the following command at the interface configuration level in our Cisco routers:

ip pim dense-mode

We can verify that we have PIM connectivity through the show ip pim neighbors command. If we run into trouble, we can also make sure that we have PIM enabled on the correct interfaces via show ip pim interface

R2#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.23.3 FastEthernet1/0 00:54:07/00:01:19 v2 1 / DR S

R2#sh ip pim interface

Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.12.2 FastEthernet0/0 v2/D 0 30 1 192.168.12.2
192.168.23.2 FastEthernet1/0 v2/D 1 30 1 192.168.23.3

Now that we’ve got our multicast routing in place, it’s time to have R6 use IGMP to join the 239.39.39.39 multicast group. We’ll use the following interface configuration command on the link from R6 to R5:

ip igmp join-group 239.39.39.39

Once we’ve done this, we can now ping 239.39.39.39 from R1. We see the following on R1:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 332 ms

We also see that an mroute has been built for this source,group (S,G) pair along the PIM-enabled path:

R3#sh ip mroute
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

(*, 239.39.39.39), 00:02:19/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Dense, 00:02:19/00:00:00
FastEthernet0/0, Forward/Dense, 00:02:19/00:00:00

(192.168.12.1, 239.39.39.39), 00:02:19/00:00:43, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 192.168.23.2
Outgoing interface list:
FastEthernet1/0, Forward/Dense, 00:02:19/00:00:00

(*, 224.0.1.40), 00:21:50/00:02:49, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Dense, 00:21:22/00:00:00
FastEthernet0/0, Forward/Dense, 00:21:50/00:00:00

Success! Now let’s make this a little more interesting. As of right now, here is how R5’s routing entry for the 192.168.12.0 network looks:

R5#sh ip route 192.168.12.0
Routing entry for 192.168.12.0/24
Known via “ospf 1″, distance 110, metric 3, type intra area
Last update from 192.168.45.4 on FastEthernet1/0, 01:25:30 ago
Routing Descriptor Blocks:
192.168.45.4, from 150.1.2.2, 01:25:30 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1
* 192.168.35.3, from 150.1.2.2, 01:25:30 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1

As you can see, R5 has a route through both R3 & R4 back to our multicast source. Let’s suspend reality for a minute and assume that the real bandwidth of the link between R5 & R3 is 10Mbps. Lets go ahead and decrease the stated bandwidth on the link between R5 & R3 so that R5 will prefer the route through R4. Here is the current bandwidth:

R5#sh int fa0/0
FastEthernet0/0 is up, line protocol is up
Hardware is DEC21140, address is ca04.0570.0000 (bia ca04.0570.0000)
Internet address is 192.168.35.5/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

Now let’s change that:

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#int fa0/0
R5(config-if)#bandwidth 10000

Now we look at the interface again:

FastEthernet0/0 is up, line protocol is up
Hardware is DEC21140, address is ca04.0570.0000 (bia ca04.0570.0000)
Internet address is 192.168.35.5/24
MTU 1500 bytes, BW 10000 Kbit, DLY 100 usec,

Let’s see how our route looks now:

R5#sh ip route 192.168.12.0
Routing entry for 192.168.12.0/24
Known via “ospf 1″, distance 110, metric 3, type intra area
Last update from 192.168.45.4 on FastEthernet1/0, 00:04:47 ago
Routing Descriptor Blocks:
* 192.168.45.4, from 150.1.2.2, 00:04:47 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1

Okay, now lets try to ping from our source again:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:
.

Nothing…Now if you recall, we do not have multicast configured on R4. When R5 runs a Reverse Path Forwarding (RPF) check on the multicast packet, it will drop the packet. This is because it is coming through a different interface then what the unicast routing table has as the outgoing interface for the source network (towards R4). Let’s run the following command on R5 to see how the router displays this:

R5#sh ip mroute count
IP Multicast Statistics
3 routes using 2038 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.39.39.39, Source count: 1, Packets forwarded: 0, Packets received: 1
Source: 192.168.12.1/32, Forwarding: 0/0/0/0, Other: 1/1/0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0

As you can see, we have an RPF failure here. We can fix this in a couple of ways. One, we can manipulate our unicast routing protocol so it will favor the PIM-enabled path. Another way would be to enter a static mroute on R5 to the source device using R3 as its next hop. This would allow multicast packets to be forwarded out a non-RPF interface. Let’s go ahead and try this second method out:

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#ip mroute 192.168.12.1 255.255.255.255 192.168.35.3

This creates our static mroute as seen here:

R5#sh ip mroute
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

(*, 239.39.39.39), 00:03:26/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/1, Forward/Dense, 00:03:26/00:00:00
FastEthernet0/0, Forward/Dense, 00:03:26/00:00:00

(192.168.12.1, 239.39.39.39), 00:01:40/00:02:24, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3, Mroute
Outgoing interface list:
FastEthernet1/1, Forward/Dense, 00:01:40/00:00:00

(*, 224.0.1.40), 00:04:12/00:02:38, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:04:12/00:00:00

Now let’s try to ping 239.39.39.39 from R1 again:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 208 ms

Voila!

I hope this little lab was useful for you. As always, comments are appreciated via the comments section or via email.

neteng

Bookmark It

Hide Sites

Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »

Multicast Routing - PIM

November 16th, 2007 neteng

Today, we’re going to take a look at multicast routing, specifically the PIM protocol. This article assumes you already have a grasp of multicast basics such as addressing and IGMP. If not, I recommend reading Cisco’s IP Multicast doumentation before going on. I’m just going to provide a general overview of PIM and it’s various modes and parts. Later on, we’ll do some lab-type scenarios where we’ll dive into things a little bit deeper. I also want to keep this as general as possible too, because there is so much good documentation already on the web for PIM and I’ve linked to some of these at the bottom of this article.

The name, Protocol Independent Multicast (PIM), gives you a pretty good idea of how it operates. There are a few other routing protocols for multicast traffic besides PIM, such as DVMRP and MOSPF. The key difference between PIM and DVMRP is that PIM doesn’t need to generate it’s own routing table. It relies on the unicast routing table to perform it’s packet forwarding. DVMRP builds a separate routing table which can take up precious memory and processing power. When it comes to MOSPF, the major difference is that MOSPF relies on OSPF as the unicast routing protocol. MOSPF is built on top of OSPF v2 through extensions. PIM doesn’t care what you’re running underneath it. It can use static routes, IS-IS, BGP, RIP, etc.

Before we go any further, I want to take a moment to discuss a key concept in multicast routing: the Reverse Path Forwarding (RPF) check. The RPF check is how multicast routing protocols prevent loops and inferior paths from ruining your day. When a router receives a multicast packet on an interface, it needs to decide whether or not to forward it or drop it. This decision is based on whether or not the packet came into an interface from which the unicast routing table has designated as the way out for the device sourcing the multicasts. Let’s look at this concept through an example:

Host 192.168.1.3 is sending multicast packets to destination 239.1.1.1. A PC is listening for multicasts to this destination and sits on a segment off of R3. R3 has a single path in its unicast routing table back to 192.168.1.0/24, which is out Serial0/0 and towards R2. Therefore, when a multicast packet is sourced from 192.1681.3 and forwarded from both R1 & R2, R3 drops the packet from R1 as it fails the RPF check. It forwards the packet from R2 though, as it passes the RPF check.

With that said, lets take a look at the various ways in which PIM can operate:

Dense Mode - Dense mode is considered to employ a push implementation of multicast routing. It floods multicast packets on the assumption that all other routers want to receive the traffic. If a router does not, it simply sends a prune message back towards the source. Dense mode produces a source-based tree system, meaning that the source is the root of the multicast packet distribution. It is rarely used in production networks these days, because of the fact that these floods can temporarily hog resources in large networks. A lot of financial companies utilize multicast (notably trading floors) and therefore any crippling spike in resource usage could literally cost folks money. Here’s a diagram of dense mode behavior:

Sparse Mode - Sparse mode is more widely used in today’s multicast networks. It uses a pull based system, assuming that other routers will explicitly request multicast packets. Initially, a shared-tree is built from a router designated as the Rendezvous Point (RP). All paths to and from the multicast source must first come through here until a source-based tree is built. If the direct unicast path from a multicast router to the multicast source has a better metric then the shared-tree path, a source-based tree will be built directly to the source. The gotcha with sparse-dense mode is that, if for whatever reason your RP fails or is not reachable, PIM will default to dense mode and flood packets accordingly. This can be avoided by configuring a sink RP which is a static-RP statement that will essentially take over. Another option is to add the no ip pim dm-fallback command to prevent dense-mode fallback. Here’s a diagram of sparse mode behavior:

Sparse-Dense Mode - This is essentially sparse mode with two multicast groups that operate in dense mode (groups 224.0.1.39 and 224.0.1.40). This is used to accommodate the Auto-RP protocol which we’ll define shortly.  The same dense-mode fallback pitfalls we saw with pure sparse-mode apply to sparse-dense as well. Again, we’ll dive into this a bit more further down the article.

Bidirectional Mode - Bidirectional PIM was created with the idea of efficient scaling when dealing with many multicast sources. Typically, multicast is a one-to-many operation. But when you have a many-to-many setup, bidirectional PIM is useful. It operates similarly to sparse mode in that a shared-tree is created, but instead of being unidirectional, the tree is bidirectional. That is to say, traffic flows not just from the source to the destination through the shared tree, but from the destination to the source as well. It does not allow for creation of source-based trees and therefore helps to limit heavy traffic flows to only one path.

Okay, so we’ve covered the various modes employed by PIM to achieve harmony in our multicast routing domain! Now, being the wise network guru that you are, you’ve obviously chosen to implement sparse mode in your network. We know that we’ll need an RP. There are 3 ways choose an RP:

Static RP - Self-explanatory. Pick your RP and configure every multicast-enabled router to point towards it.

Auto-RP - A Cisco-proprietary protocol that elects an RP. It can be used to lessen manual configuration and provide backup RPs in case of primary RP failure. Components of AutoRP include candidate-RPs (C-RP) and mapping agents (MA). C-RPs attempt to become an RP by having the MA elect them. The MA then floods the RP-to-group mappings to all multicast-routers, providing them with an RP to use. Now there are two ways you can configure PIM to work with Auto-RP. One way is to configure sparse-dense mode throughout your network in order to send multicast requests for RP election and assignment. This is because these requests are sent via multicast packets to 224.0.1.39 and 224.0.1.40. Without an RP already configured, these packets cannot be sent via a shared-tree to the RP! A second way is to configure your network to use pure sparse mode and configure the ip pim auto-rp listener command on each router. This forces the router to use dense mode for only the 224.0.1.39 and 224.0.1.40 groups.

Bootstrap Router (BSR) - BSR is an open protocol that functions similarly to Auto-RP. The BSR acts in a way similar to the Auto-RP MA, mapping RPs to multicast groups. There are two big differences between Auto-RP and BSR. First is the fact that BSR does not need dense mode to communicate. All communication is done through a combination of unicast messages and a special hop-by-hop All-PIM-Routers multicast address (224.0.0.13). Secondly, BSR does not perform the actual RP election. If there are multiple candidate-RPs, it sends all RP mappings to all PIM routers and they make the decision. But, this decision is bound to be the same across all PIM routers as they run the same hash function to determine a winner.

Once again, thank you for taking the time to read through this. I hope it’s been helpful and I appreciate all feedback and questions. We’ll do some lab work soon to show how things look from a router’s perspective!

neteng

Interesting reading available here:

PIM Sparse Mode RFC
PIM Dense Mode RFC
Financial Services Design for High Availability
IP Multicast and PIM Rendezvous Points

Bookmark It

Hide Sites

Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »