Wednesday, April 7, 2010

Multicast Basics Lab #2: PIM sparse-dense-mode

Hi all,
This is my second lab about multicast, here we will play with pim sparse-dense-mode on the previous lab topology (see: Multicast Basics Lab #1: PIM-DM )

So the topology still:


And the initial config still the same too, but this time we will configure the serial interfaces to use pim sparse-dense-mode.

We have to say that pim sparse-dense-mode is a sort of hybrid mode, that uses first sparse mode, looking for a RP of a particular multicast group, and acting as dense if an RP cannot be found in the multicast routing table.

Let's start configuring interfaces and without a RP:


## R1 sparse-dense mode multicast
ip multicast-routing

int ser 0/0/1
ip pim sparse-dense-mode

## end R1 sparse-dense mode multicast

## R2 sparse-dense mode multicast
ip multicast-routing

int ser 0/1/0
ip pim sparse-dense-mode
## end R2 sparse-dense mode multicast

## R3 sparse-dense mode multicast
ip multicast-routing

int ser 0/0/0
ip pim sparse-dense-mode

int ser 0/0/0.1
ip pim sparse-dense-mode

int ser 0/1/0
ip pim sparse-dense-mode

int ser 0/1/1
ip pim sparse-dense-mode
## end R3 sparse-dense mode multicast

## R4 sparse-dense mode multicast
ip multicast-routing

int ser 0/1/0
ip pim sparse-dense-mode

## end R4 sparse-dense mode multicast

## R5 sparse-dense mode multicast
ip multicast-routing

int ser 0/0/0
ip pim sparse-dense-mode

int ser 0/1/0
ip pim sparse-dense-mode
## end R5 sparse-dense mode multicast

## R6 sparse-dense mode multicast
ip multicast-routing

int ser 0/0/0
ip pim sparse-dense-mode

## end R6 sparse-dense mode multicast


as expected, if we don't configure any RP, our network is acting like the previous dense mode, we can verify this looking the multicast routing table entries:

R3(config)#do sh ip mroute 239.1.1.2
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,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.2), 00:47:03/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0/0, Forward/Sparse-Dense, 00:46:31/00:00:00
Serial0/1/1, Forward/Sparse-Dense, 00:46:36/00:00:00
Serial0/1/0, Forward/Sparse-Dense, 00:46:36/00:00:00
Serial0/0/0.1, Forward/Sparse-Dense, 00:46:58/00:00:00

(4.4.4.4, 239.1.1.2), 00:47:04/00:02:56, flags: T
Incoming interface: Serial0/0/0, RPF nbr 10.0.35.5
Outgoing interface list:
Serial0/1/1, Forward/Sparse-Dense, 00:46:37/00:00:00
Serial0/1/0, Forward/Sparse-Dense, 00:46:37/00:00:00
Serial0/0/0.1, Prune/Sparse-Dense, 00:02:15/00:00:52



It looks exactly like in the previous dense-mode lab, with the (*,G) entry unused and with the "D" (dense) flag.

if we add a static RP on all routers, it will revert to sparse mode:


# on R1 R2 R3 R4 R5 R6
ip pim rp-address 3.3.3.3

# then look at the mroute table:
R3(config)#ip pim rp-address 3.3.3.3
R3(config)#do sh ip mroute 239.1.1.2
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,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.2), 01:06:16/00:03:01, RP 3.3.3.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0, Forward/Sparse-Dense, 00:00:28/00:03:01
Serial0/1/1, Forward/Sparse-Dense, 00:00:35/00:02:54

(4.4.4.4, 239.1.1.2), 00:00:43/00:03:24, flags: T
Incoming interface: Serial0/0/0, RPF nbr 10.0.35.5
Outgoing interface list:
Serial0/1/0, Forward/Sparse-Dense, 00:00:29/00:03:00
Serial0/1/1, Forward/Sparse-Dense, 00:00:36/00:02:53


After this change, the multicast traffic destined to group 239.1.1.2 is therated as sparse mode, with his own (*,G) entry flagged with "S" (sparse) and with an RP specified.
Note the incoming and outgouing interface for the (S,G) entry.

One interesting things with sparse-dense mode is the particular behavior of auto-rp groups (224.0.1.39 for announce, 224.0.1.40 for discovery).
These two groups are threated as dense mode, and the traffic is flooded through the interfaces without the needs of the "ip pim autorp listener".
So all the routers with sparse dense mode enabled on your network will learn and forward the informations about the RP without further configuration.
Let's check it announcing R6 as auto-rp, with sparse-dense-mode even R4 will know that R6 is the RP:

# on R1 / R2 / R3 / R4 / R5 / R6
no ip pim rp-address 3.3.3.3

#on R6
int lo 0
ip pim sparse-dense-mode
exit

ip pim send-rp-announce Loopback0 scope 4
ip pim send-rp-discovery Loopback0 scope 4


Wait a little, and you will see all the other routers with the RP mapped as R6 Lo0 address, this because the RP-discovery group is forwarded in dense mode and all have received the RP mapping agent discovery message.
We can verify it with:

R5(config)# do sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 6.6.6.6 (?), v2v1
Info source: 6.6.6.6 (?), elected via Auto-RP
Uptime: 00:03:31, expires: 00:02:21

R5(config)#do sh ip mroute summ
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,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.2), 00:01:09/00:01:50, RP 6.6.6.6, OIF count: 0, flags: SP

(*, 224.0.1.39), 00:14:13/stopped, RP 0.0.0.0, OIF count: 2, flags: D
(6.6.6.6, 224.0.1.39), 00:02:14/00:00:46, OIF count: 1, flags: PT

(*, 224.0.1.40), 00:37:55/stopped, RP 0.0.0.0, OIF count: 2, flags: DCL
(6.6.6.6, 224.0.1.40), 00:13:14/00:02:46, OIF count: 1, flags: LT

R5(config)#

As you can see, R5 recognizes the RP as 6.6.6.6, and receives traffic from R6 for the groups 224.0.1.39 and 224.0.1.40.

But why we don't need the "ip pim autorp listener" here?
According to the documentation the "ip pim autorp listener" is used when the interfaces are operating in sparse-mode, and tells the router to threat the 224.0.1.39 and 224.0.1.40 groups as dense. So here isn't needed since the interfaces are already operating in dense mode for those groups.

Next lab will cover sparse-mode and the different RP configurations, so static RP, auto-rp and bsr.

stay tuned
Marco

No comments: