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

2 comments:

Isacco said...

;))))
Ciao futuro CCIE !!


6509-2#sh ip mroute vrf MGMT
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.192.1.10), 2d23h/stopped, RP 10.190.190.254, flags: S
Incoming interface: Tunnel1, RPF nbr 172.25.64.1, using vrf IpTv, RPF-MFD
Outgoing interface list:
GigabitEthernet8/48.3, Forward/Sparse, 2d23h/00:02:43, H

(10.254.199.15, 239.192.1.10), 00:02:44/00:00:45, flags: T
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet8/48.3, Forward/Sparse, 00:02:44/00:02:43

(*, 239.255.255.255), 2d23h/stopped, RP 10.190.190.254, flags: SJC
Incoming interface: Tunnel1, RPF nbr 172.25.64.1, using vrf IpTv, RPF-MFD
Outgoing interface list:
GigabitEthernet8/48.3, Forward/Sparse, 2d23h/00:02:57, H

(*, 239.255.255.250), 2d23h/stopped, RP 10.190.190.254, flags: S
Incoming interface: Tunnel1, RPF nbr 172.25.64.1, using vrf IpTv, RPF-MFD
Outgoing interface list:
GigabitEthernet8/48.3, Forward/Sparse, 2d23h/00:02:32, H

(172.25.18.80, 239.255.255.250), 13:12:53/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.17, 239.255.255.250), 2d07h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.54, 239.255.255.250), 2d12h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.86, 239.255.255.250), 2d13h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.43, 239.255.255.250), 2d21h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.246, 239.255.255.250), 2d23h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.247, 239.255.255.250), 2d23h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.234, 239.255.255.250), 2d23h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(172.25.18.242, 239.255.255.250), 2d23h/stopped, flags: PX
Incoming interface: GigabitEthernet8/48.3, RPF nbr 172.25.211.225, using vrf IpTv, RPF-MFD
Outgoing interface list: Null

(*, 224.2.127.254), 2d23h/stopped, RP 10.190.190.254, flags: SJC
Incoming interface: Tunnel1, RPF nbr 172.25.64.1, using vrf IpTv, RPF-MFD
Outgoing interface list:
GigabitEthernet8/48.3, Forward/Sparse, 2d23h/00:02:52, H

(*, 224.0.1.40), 2d23h/00:02:53, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet8/48.3, Forward/Sparse, 2d23h/00:02:53

Marco Rizzi said...

Ehehe mooolto futuro...

Immagino la vrf IpTv serva a inizio giugno....

:-)

Marco