Sunday, April 25, 2010

Multicast Basics Lab#3: PIM Sparse-mode with Static RP

Hi all,
here another small lab about multicast basics, just to refresh pim sparse-mode using the previous lab topology (see: Multicast Basics Lab #1: PIM-DM )

So the topology still the same (mmm next time I have to change it):


And the initial config still the same as the previous labs too.

Let's start recalling that every PIM sparse-mode router need to know a rendezvous-point, that is used to manage the active groups and the active sources.
Usually the Rendezvous-point (commonly abbreviated as RP) is choosed on a central location, to avoid suboptimal paths during the shared tree phase, in our topology a suitable RP will be R3, but we will try to use several RPs for our tests.

First step, enable pim sparse-mode on all interfaces:


## R1 sparse mode multicast
ip multicast-routing

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

## end R1 sparse mode multicast

## R2 sparse mode multicast
ip multicast-routing

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

## R3 sparse mode multicast
ip multicast-routing

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

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

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

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

## R4 sparse mode multicast
ip multicast-routing

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

## end R4 sparse mode multicast

## R5 sparse mode multicast
ip multicast-routing

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

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

## R6 sparse mode multicast
ip multicast-routing

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

## end R6 sparse mode multicast


Then we can try the different ways to inform your routers about the RP placement.

In this lab we will start with: STATIC RP MAPPING
This is the easyest way to setup a RP mapping, the only pro here is that the resul is always highly predictable (you configure the rp(s) statically...) the cons are obviously many, first this method is not very scalable, every router on your network must be manually configured on every change. The second con is that your RP might fail, breaking your multicast network functionality.

So let configure the static RP as R5s loopback0


!-- ON R5 enable sparse mode on Lo0
int lo 0
ip pim sparse-mode

!-- configure R5 to recognize itself as RP
ip pim rp-address 5.5.5.5

!--- Verify:
R5(config)#do sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
RP: 5.5.5.5 (?)


Ok, now on all the other routers we have to statically configure R5 as RP, we can see what changes when R1 Lo0 joins a group like 238.1.2.3

!-- on all other routers configure RP as R5 Lo0
ip pim rp-address 5.5.5.5

!-- Then try to join a group on R1
!-- First enable sparse-mode on R1 Lo0
int lo 0
ip pim sparse-mode
!-- then join the group
ip igmp join-group 238.1.2.3

On R1 mroute table after a little while we can see the joined group as an (*,G) entry, with the RP specified:

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

(*, 238.1.2.3), 00:03:45/00:02:29, RP 5.5.5.5, flags: SJCL
Incoming interface: Serial0/0/1, RPF nbr 10.0.13.3
Outgoing interface list:
Loopback0, Forward/Sparse, 00:03:45/00:02:29


Here we see the interesting informations for troubleshooting:
-the incoming and outgoing interfaces
-the RPF neighbor for the incoming interface
-the RP
-the flags with the useful legend

On R3 we can see something similar, obviously with different flags since R3 has no directly connected clients that joined the group:

R3(config)#do sh ip mroute 238.1.2.3
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

(*, 238.1.2.3), 00:15:26/00:02:49, RP 5.5.5.5, flags: S
Incoming interface: Serial0/0/0, RPF nbr 10.0.35.5
Outgoing interface list:
Serial0/1/0, Forward/Sparse, 00:15:26/00:02:49


All right, and the incoming interface on R3 is ser0/0/0 that's connected with R5, the RP.
Looking ok R5:

R5(config)#do sh ip mroute 238.1.2.3
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

(*, 238.1.2.3), 00:49:59/00:02:48, RP 5.5.5.5, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0/0, Forward/Sparse, 00:49:59/00:02:48


So, with a simple join, we have created a path from the RP to the client, but at the moment we don't have any source for this group.

Let's add R4 as source with ip sla:

ip sla 1
icmp-echo 238.1.2.3
frequency 5
timeout 2000
threshold 2000
ip sla schedule 1 start now life forever


As you may recall, a source will initially send a register message to the RP, then, when RP replyes with a register stop, will add the (S,G) entry in the mroute table:


R4#sh ip mroute 238.1.2.3 | beg \(
(*, 238.1.2.3), 00:02:44/stopped, RP 5.5.5.5, flags: SP
Incoming interface: Serial0/1/0, RPF nbr 10.0.45.5
Outgoing interface list: Null

(4.4.4.4, 238.1.2.3), 00:02:44/00:03:28, flags: T
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0, Forward/Sparse, 00:02:44/00:03:28


Then you can see on all other routers on the shared tree path the (S,G) entry, the traffic flow has the correct path created and the receivers that joined this group will start receiveing some traffic.

That's the basic and simplyfied operatin on PIM sparse mode, in the next labs we will try the different methods to dynamically select the RP, like autorp and bsr.

stay tuned!
Marco

Friday, April 9, 2010

birthday present

Hi all, well, today it's my birthday....


(that's me in dyna-metabolism)

...and what's the best present for a CCIE candidate?

maybe to be the 5th winner of the "CCIE Flyer Challenge" ?!?!?!

of course! (unbelivable!) :-)

I'm so happyyyyy!

Marco

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