Multicast Pim Sparse Mode

Download PNETLab Platform
PNETLAB Store
PNETLab.com
Multicast PIM Sparse Mode

Lab Topology:
The lab network topology is illustrated below:
Lab Objective:
The objective of this lab exercise is for you to learn and understand Multicast PIM Sparse Mode.
Task:
R1, R2 and R3 are our multicast routers that we will configure for PIM sparse mode. S4 will be the
source that sends multicast traffic. H5 is the receiver.
Solution
Basic Configuration:
Router R1 R2
Configuration interface Ethernet0/0 interface Loopback0
no shutdown no shutdown
ip address 10.1.12.1 255.255.255.0 ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0 ip ospf 1 area 0
! !
interface Ethernet0/1 interface Ethernet0/0
1
PNETLAB Store
PNETLab.com

! !
interface Ethernet0/2 interface Ethernet0/1
Router R3 S4
Configuration interface Ethernet0/0 interface Ethernet0/0
ip ospf 1 area 0 no ip route-cache
! !
interface Ethernet0/1 ip default-gateway 10.1.14.1
no shutdown no ip routing
ip address 10.1.23.3 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/2
no shutdown
ip address 10.1.35.3 255.255.255.0
ip ospf 1 area 0
Router H5
Configuration interface Ethernet0/0
no shutdown
ip address 10.1.35.5 255.255.255.0
no ip route-cache
!
ip default-gateway 10.1.35.3
no ip routing
Multicast routing is disabled by default on Cisco IOS routers so we have to enable it:
R1(config)#ip multicast-routing
2
PNETLAB Store
PNETLab.com
Now we can configure PIM. Let’s start with R1 and R2:
R1(config)#interface e0/0
R1(config-if)# ip pim sparse-mode
As soon as I enable PIM Sparse mode on the interface our router will start sending PIM hello
packets. The default is 105 seconds. R1 and R2 will become neighbors since they receive each
others PIM hello packets. If they keep receiving them before the holddown timer is expired then
they will keep seeing each other as PIM neighbors:
R1(config-if)#
*Sep 13 06:07:36.751: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 10.1.12.1 on
*Sep 13 06:07:39.341: %PIM-5-NBRCHG: neighbor 10.1.12.2 UP on interface Ethernet0/0
*Sep 13 06:07:39.344: %PIM-5-DRCHG: DR change from neighbor 10.1.12.1 to 10.1.12.2 on
Let’s enable all the other interfaces.:
R1(config-if)#interface e0/1
Let’s make sure all routers have become neighbors:
R1#show ip pim neighbor
3
PNETLAB Store
PNETLab.com
PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.1.12.2 Ethernet0/0 00:04:59/00:01:42 v2 1 / DR S P G
10.1.13.3 Ethernet0/1 00:00:32/00:01:41 v2 1 / DR S P G

PIM Neighbor Table
Address Prio/Mode
10.1.12.1 Ethernet0/0 00:05:20/00:01:19 v2 1 / S P G
10.1.23.3 Ethernet0/1 00:00:50/00:01:23 v2 1 / DR S P G

PIM Neighbor Table
Address Prio/Mode
10.1.13.1 Ethernet0/0 00:01:07/00:01:36 v2 1 / S P G
10.1.23.2 Ethernet0/1 00:01:03/00:01:39 v2 1 / S P G
Above we can see that all routers have become PIM neighbors. Let’s take a look at the multicast
routing tables:
R1#show ip mroute
(*, 224.0.1.40), 00:08:04/00:02:58, RP 0.0.0.0, flags: DPL

Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
R2#show ip mroute
(*, 224.0.1.40), 00:08:29/00:02:29, RP 0.0.0.0, flags: DCL

Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:08:27/00:02:29
R3#show ip mroute
4
PNETLAB Store
PNETLab.com
(*, 224.0.1.40), 00:04:14/00:02:30, RP 0.0.0.0, flags: DCL

Above we see the output. At this moment we are not transmitting/receiving any multicast traffic
but we still see something in the multicast routing tables. There’s an entry for 224.0.1.40. This
multicast group address is used for Auto RP discovery, a protocol that dynamically learns RPs on
the network.
Let’s disable it:
R1(config)#no ip pim autorp
R2 will be the RP in our network:
R1(config)# ip pim rp-address 2.2.2.2

Once you have configured the RP you might notice some messages on your consoles:
R1(config)#
*Sep 13 06:35:55.989: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed
state to up
R2(config)#
state to up
state to up
R3(config)#
state to up
5
PNETLAB Store
PNETLab.com
R1, R2 and R3 each create a tunnel0 interface. R2 also creates a tunnel1 interface.
The first tunnel interface is used to encapsulate the first multicast packet in a PIM register message
and forward it to the RP. The RP has one additional tunnel interface which is used for
decapsulation of the PIM register packet.
These tunnel interfaces won’t show up in your configuration but we can take a look at them with
the following command:
R1#show ip pim tunnel

Tunnel0
Type : PIM Encap
RP : 2.2.2.2
Source: 10.1.12.1

Tunnel0
Type : PIM Encap
RP : 2.2.2.2*
Source: 10.1.12.2
Tunnel1
Type : PIM Decap
RP : 2.2.2.2*
Source: -

Tunnel0
Type : PIM Encap
RP : 2.2.2.2
Source: 10.1.23.3
Let’s enable a debug and generate some traffic:
R1#debug ip pim
R2#debug ip pim
R3#debug ip pim
S4#ping 239.1.1.1 repeat 1000

Here’s what R1 will tell us:
R1#
*Sep 13 06:48:20.022: PIM(0): Check RP 2.2.2.2 into the (*, 239.1.1.1) entry
6
PNETLAB Store
PNETLab.com
*Sep 13 06:48:20.022: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
*Sep 13 06:48:20.022: PIM(0): Adding register encap tunnel (Tunnel0) as forwarding interface
of (10.1.14.4, 239.1.1.1).
*Sep 13 06:48:20.023: PIM(0): Received v2 Register-Stop on Ethernet0/0 from 2.2.2.2
*Sep 13 06:48:20.023: PIM(0): for source 10.1.14.4, group 239.1.1.1
*Sep 13 06:48:20.023: PIM(0): Removing register encap tunnel (Tunnel0) as forwarding
interface of (10.1.14.4, 239.1.1.1).
*Sep 13 06:48:20.023: PIM(0): Clear Registering flag to 2.2.2.2 for (10.1.14.4/32, 239.1.1.1)
R1 encapsulates the first multicast packet that it receives from our source and forwards it with a
PIM register message towards the RP. A bit later, it receives a PIM register stop from the RP who
asks R1 to stop forwarding anything.
Here’s what it looks like from R2’s perspective:
R2#
*Sep 13 06:48:20.022: PIM(0): Received v2 Register on Ethernet0/0 from 10.1.12.1
*Sep 13 06:48:20.022: for 10.1.14.4, group 239.1.1.1
*Sep 13 06:48:20.023: PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of
(*, 239.1.1.1).
(10.1.14.4, 239.1.1.1).
*Sep 13 06:48:20.023: PIM(0): Send v2 Register-Stop to 10.1.12.1 for 10.1.14.4, group
239.1.1.1
Above you can see that R2 receives the PIM register and replies with the PIM register stop.
When R1’s suppression timer is almost expired, it will send a PIM register null packet to check if
the RP is still not interested:
R1#
*Sep 13 06:52:26.952: PIM(0): Send v2 Data-header Register to 2.2.2.2 for 10.1.14.4, group
239.1.1.1
*Sep 13 06:52:26.954: PIM(0): Received v2 Register-Stop on Ethernet0/0 from 2.2.2.2
*Sep 13 06:52:26.954: PIM(0): for source 10.1.14.4, group 239.1.1.1
*Sep 13 06:52:26.954: PIM(0): Clear Registering flag to 2.2.2.2 for (10.1.14.4/32, 239.1.1.1)
R2 quickly replies, telling R1 to shut up. Here’s the debug from R2:
R2#
*Sep 13 06:52:26.953: (Data-header) for 10.1.14.4, group 239.1.1.1
7
PNETLAB Store
PNETLab.com

239.1.1.1
R1#
*Sep 12 14:08:53.719: PIM(0): Join-list: (10.1.14.4/32, 239.1.1.1)
*Sep 12 14:08:53.719: PIM(0): Add Ethernet0/1/0.0.0.0 to (10.1.14.4, 239.1.1.1), Forward
state, by PIM Graft
*Sep 12 14:08:53.719: PIM(0): Send v2 Graft-Ack on Ethernet0/1 to 10.1.13.3
Joining the RPT (Root Path Tree)
Let’s H5 join that group.
H5(config)#interface e0/0
H5(config-if)#ip igmp join-group 239.5.5.5
R3 will now join the RPT for 239.5.5.5 since it receives the IGMP membership report from H5.
Here’s what it looks like:
R3#
239.5.5.5
239.5.5.5
*Sep 13 06:59:24.205: PIM(0): Upstream mode for (*, 239.5.5.5) changed from 0 to 1
*Sep 13 06:59:24.205: PIM(0): Insert (*,239.5.5.5) join in nbr 10.1.23.2's queue
*Sep 13 06:59:24.205: PIM(0): Building Join/Prune packet for nbr 10.1.23.2
*Sep 13 06:59:24.205: PIM(0): Adding v2 (2.2.2.2/32, 239.5.5.5), WC-bit, RPT-bit, S-bit Join
*Sep 13 06:59:24.205: PIM(0): Send v2 join/prune to 10.1.23.2 (Ethernet0/1)
Above you can see the (*,G) entry which tells us we are joining the SPT. The * is a wildcard that
indicates “any source”. The G is the group, in our case 239.5.5.5.
Here’s what happens when our RP receives the PIM join
R2#
*Sep 13 06:59:24.205: PIM(0): Received v2 Join/Prune on Ethernet0/1 from 10.1.23.3, to us
*Sep 13 06:59:24.205: PIM(0): Join-list: (*, 239.5.5.5), RPT-bit set, WC-bit set, S-bit set
(*, 239.5.5.5).
8
PNETLAB Store
PNETLab.com
*Sep 13 06:59:24.205: PIM(0): Add Ethernet0/1/10.1.23.3 to (*, 239.5.5.5), Forward state, by

PIM *G Join
Above you can see that R2 accepts the PIM join and puts its Ethernet0/1 interface in forwarding
mode.
Let’s see what the multicast routing tables look like now:
R2#show ip mroute 239.5.5.5
(*, 239.5.5.5), 00:02:06/00:03:22, RP 2.2.2.2, flags: S

The output above is interesting. We have a RPT entry for (*, 239.5.5.5) and the RP is 2.2.2.2. The
“S” flag means we are using PIM sparse mode. Nobody is sending traffic to this group at the
moment so the incoming interface is null. The outgoing interface is in forwarding mode.
Let’s check R3:
(*, 239.5.5.5), 00:07:25/00:02:25, RP 2.2.2.2, flags: SJC

Incoming interface: Ethernet0/1, RPF nbr 10.1.23.2
R3 also has an entry for the RPT. There are three flags:
• S: we are using sparse mode.
• J: this is the SPT-bit. When possible, R3 will try to join the SPT for this multicast group.
We’ll see this in a minute…
• C: this means we have a member of this multicast group that is directly connected to us.
First, we will shut down interface Ethernet0/1 of R1
R1(config-if)#shutdown
Let’s see what happens when we send traffic to this multicast group
S4#ping 239.5.5.5 repeat 1000
9
PNETLAB Store
PNETLab.com
Our receiver is replying. Here’s what the debugs tell us:
R1#
*Sep 13 07:32:50.288: PIM(0): Adding register encap tunnel (Tunnel0) as forwarding interface
of (10.1.14.4, 239.5.5.5).
*Sep 13 07:32:50.289: PIM(0): Join-list: (10.1.14.4/32, 239.5.5.5), S-bit set
*Sep 13 07:32:50.289: PIM(0): Add Ethernet0/0/10.1.12.2 to (10.1.14.4, 239.5.5.5), Forward
state, by PIM SG Join
R1 receives a PIM join from the RP and decides to put its Ethernet0/0 interface into forwarding
mode. Here’s what we see on the RP:
R2#
*Sep 13 07:32:50.289: for 10.1.14.4, group 239.5.5.5
(10.1.14.4, 239.5.5.5).
*Sep 13 07:32:50.289: PIM(0): Insert (10.1.14.4,239.5.5.5) join in nbr 10.1.12.1's queue
*Sep 13 07:32:50.289: PIM(0): Adding v2 (10.1.14.4/32, 239.5.5.5), S-bit Join
R2>
*Sep 13 07:32:50.309: PIM(0): Update Ethernet0/1/10.1.23.3 to (10.1.14.4, 239.5.5.5), Forward
R2>
*Sep 13 07:32:56.874: PIM(0): Update Ethernet0/1/10.1.23.3 to (*, 239.5.5.5), Forward state,
by PIM *G Join
state, by PIM *G Join
*Sep 13 07:33:01.280: for 10.1.14.4, group 239.5.5.5
*Sep 13 07:33:01.280: PIM(0): Removing register decap tunnel (Tunnel1) as accepting interface
of (10.1.14.4, 239.5.5.5).
*Sep 13 07:33:01.280: PIM(0): Installing Ethernet0/0 as accepting interface for (10.1.14.4,
239.5.5.5).
10
PNETLAB Store
PNETLab.com
R2>
*Sep 13 07:33:21.306: for 10.1.14.4, group 239.5.5.5
239.5.5.5
*Sep 13 07:33:44.842: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
239.5.5.5
*Sep 13 07:33:54.148: PIM(0): Send RP-reachability for 239.5.5.5 on Ethernet0/1
*Sep 13 07:33:55.969: PIM(0): Update Ethernet0/1/10.1.23.3 to (*, 239.5.5.5), Forward state,
by PIM *G Join
state, by PIM *G Join
R2>
*Sep 13 07:34:44.746: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
239.5.5.5
We can see that R2 receives a PIM register with an encapsulated multicast packet that it accepts.
It now learns the source (10.1.14.4) of the multicast group so the router will join the SPT.
We can also see that it has received a PIM join from R3 and that its Ethernet0/1 interface goes
into forwarding mode.
Here’s the output of R3:
R3#
11
PNETLAB Store
PNETLab.com
R3 already joined the RPT for 239.5.5.5 but since it now has learned the source, it will join the SPT
(note the S-bit Join).
Let’s check the multicast routing tables:
R1>show ip mroute 239.5.5.5
(*, 239.5.5.5), 00:26:10/stopped, RP 2.2.2.2, flags: SPF

(10.1.14.4, 239.5.5.5), 00:07:44/00:02:16, flags: FT

Above we can see that R1 is receiving traffic from 10.1.14.4 which is forwarded on its Ethernet0/2
interface. The P-bit for the RPT (*, 239.5.5.5) entry indicates that it has been pruned. The T-bit for
the SPT (10.1.14.4, 239.5.5.5) entry tells us that it has joined the SPT for this group.
Let’s check the RP:
(*, 239.5.5.5), 00:41:31/00:03:23, RP 2.2.2.2, flags: S

(10.1.14.4, 239.5.5.5), 00:08:05/00:03:17, flags: T

Above we see that the RP has joined the SPT and that it is forwarding on its Ethernet0/1 interface.
Last but not least, let’s check R3:
(*, 239.5.5.5), 00:41:46/stopped, RP 2.2.2.2, flags: SJC

(10.1.14.4, 239.5.5.5), 00:08:20/00:02:29, flags: JT

12
PNETLAB Store
PNETLab.com

R3 is forwarding on its Ethernet0/2 interface.
Now let’s turn on interface e0/1 of R1 in order to see difference between the SPT and RPT
R1(config-if)#no shutdown
Now take a look at its multicast routing table:
(*, 239.5.5.5), 00:33:22/stopped, RP 2.2.2.2, flags: SPF

(10.1.14.4, 239.5.5.5), 00:14:56/00:03:03, flags: FT

(*, 239.5.5.5), 00:48:30/00:03:06, RP 2.2.2.2, flags: S

(10.1.14.4, 239.5.5.5), 00:15:04/00:02:26, flags: PT

(*, 239.5.5.5), 00:48:39/stopped, RP 2.2.2.2, flags: SJC

(10.1.14.4, 239.5.5.5), 00:15:12/00:01:43, flags: JT

13
PNETLAB Store
PNETLab.com

Above you can see that R3 has joined the RPT for 239.5.5.5 but it has joined the SPT for traffic that
is sourced from 10.1.14.4 and destined to 239.5.5.5.
Notice that R2 has pruned traffic from 10.1.14.4 to 239.5.5.5. This traffic is no longer required
since R3 has switched to SPT and is no longer using the RP.
When R3 made the switch from RPT to SPT, it has sent a PIM prune message to the RP.
14

Multicast Pim Sparse Mode

Uploaded by

Copyright:

Available Formats

Multicast Pim Sparse Mode

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Multicast Pim Sparse Mode

Uploaded by

Copyright:

Available Formats

Download PNETLab Platform

Multicast PIM Sparse Mode

ip ospf 1 area 0 ip ospf 1 area 0

Let’s make sure all routers have become neighbors:

R1#show ip pim neighbor

PIM Neighbor Table

R2#show ip pim neighbor

R3#show ip pim neighbor

(*, 224.0.1.40), 00:08:04/00:02:58, RP 0.0.0.0, flags: DPL

(*, 224.0.1.40), 00:08:29/00:02:29, RP 0.0.0.0, flags: DCL

(*, 224.0.1.40), 00:04:14/00:02:30, RP 0.0.0.0, flags: DCL

Let’s disable it:

R1(config)#no ip pim autorp

R2(config)#no ip pim autorp

R3(config)#no ip pim autorp

R2 will be the RP in our network:

R1(config)# ip pim rp-address 2.2.2.2

R2(config)# ip pim rp-address 2.2.2.2

R3(config)# ip pim rp-address 2.2.2.2

R1#show ip pim tunnel

R2#show ip pim tunnel

R3#show ip pim tunnel

S4#ping 239.1.1.1 repeat 1000

Here’s what it looks like from R2’s perspective:

*Sep 13 06:52:26.953: PIM(0): Send v2 Register-Stop to 10.1.12.1 for 10.1.14.4, group

Joining the RPT (Root Path Tree)

Let’s H5 join that group.

Here’s what happens when our RP receives the PIM join

*Sep 13 06:59:24.205: PIM(0): Add Ethernet0/1/10.1.23.3 to (*, 239.5.5.5), Forward state, by

R2#show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:02:06/00:03:22, RP 2.2.2.2, flags: S

Let’s check R3:

R3#show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:07:25/00:02:25, RP 2.2.2.2, flags: SJC

• S: we are using sparse mode.

First, we will shut down interface Ethernet0/1 of R1

S4#ping 239.5.5.5 repeat 1000

Our receiver is replying. Here’s what the debugs tell us:

Here’s the output of R3:

Let’s check the multicast routing tables:

R1>show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:26:10/stopped, RP 2.2.2.2, flags: SPF

(10.1.14.4, 239.5.5.5), 00:07:44/00:02:16, flags: FT

Let’s check the RP:

R2#show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:41:31/00:03:23, RP 2.2.2.2, flags: S

(10.1.14.4, 239.5.5.5), 00:08:05/00:03:17, flags: T

R3#show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:41:46/stopped, RP 2.2.2.2, flags: SJC

(10.1.14.4, 239.5.5.5), 00:08:20/00:02:29, flags: JT

Incoming interface: Ethernet0/1, RPF nbr 10.1.23.2

R1#show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:33:22/stopped, RP 2.2.2.2, flags: SPF

(10.1.14.4, 239.5.5.5), 00:14:56/00:03:03, flags: FT

R2#show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:48:30/00:03:06, RP 2.2.2.2, flags: S

(10.1.14.4, 239.5.5.5), 00:15:04/00:02:26, flags: PT

R3#show ip mroute 239.5.5.5

(*, 239.5.5.5), 00:48:39/stopped, RP 2.2.2.2, flags: SJC

(10.1.14.4, 239.5.5.5), 00:15:12/00:01:43, flags: JT

Sep 13 06:59:24.205: PIM(0): Add Ethernet0/1/10.1.23.3 to (, 239.5.5.5), Forward state, by