Sunday, June 5, 2011

Lab 145 - PIM RPF Failure

Prerequisites: CCNP level skills.

Note!
All routers are running EIGRP protocol as well as multicast routing.

Topology

Pic. 1 - Topology Diagram.
Icons designed by: Andrzej Szoblik - http://www.newo.pl

Task 1
Configure multicast domain using the topology diagram. The multicast clients on subnet 10.1.234.0/24 will join 224.4.4.4 group. Ensure that multicast traffic is distributed to the clients which join the group explicitly. Do not enable multicast on 10.1.51.0/24 subnet. R5 should become RP in the multicast domain.

Task 2
Configure R4's Et0/0 to join the group 224.4.4.4. On R6 use ping to verify if R4 receives the multicast traffic.

Solution

Task 1
Configure multicast domain using the topology diagram. The multicast clients on subnet 10.1.234.0/24 will join 224.4.4.4 group. Ensure that multicast traffic is distributed to the clients which join the group explicitly. Do not enable multicast on 10.1.51.0/24 subnet. R5 should become the RP in the multicast domain.

R1 Configuration:
!
ip multicast-routing 
!
ip pim rp-address 172.16.105.5
!
interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 no ip split-horizon eigrp 100
 serial restart-delay 0
 frame-relay map ip 10.1.123.2 102 broadcast
 frame-relay map ip 10.1.123.3 103 broadcast
 no frame-relay inverse-arp
!
interface Serial1/1
 ip address 10.1.15.1 255.255.255.0
 ip pim sparse-mode
 serial restart-delay 0
!

R2 Configuration:
!
ip multicast-routing
!
ip pim rp-address 172.16.105.5
!
interface Ethernet0/0
 ip address 10.1.234.2 255.255.255.0
 ip pim dr-priority 20
 ip pim sparse-mode
!
interface Serial1/0
 ip address 10.1.123.2 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 10.1.123.1 201 broadcast
 frame-relay map ip 10.1.123.3 201
 no frame-relay inverse-arp
!

Note!
The 'ip pim dr-priority 20' is configured so R2 sends the pim join message on behalf of 10.1.234.0/24 subnet. R4 becomes multicast DR by default. I have found that if R4 joins the group, it does not want to send the register message at the same time. That's why I make R2 the DR for this subnet.

R3 Configuration:
!
ip multicast-routing
!
ip pim rp-address 172.16.105.5
!
interface Ethernet0/0
 ip address 10.1.234.3 255.255.255.0
 ip pim sparse-mode
!
interface Serial1/0
 ip address 10.1.123.3 255.255.255.0
 ip pim sparse-mode
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay map ip 10.1.123.1 301 broadcast
 frame-relay map ip 10.1.123.2 301
 no frame-relay inverse-arp
!

R4 Configuration:
!
ip multicast-routing
!
ip pim rp-address 172.16.105.5
!
interface Ethernet0/0
 ip address 10.1.234.4 255.255.255.0
 ip pim sparse-mode
!

R5 Configuration:
!
ip multicast-routing
!
ip pim rp-address 172.16.105.5
!
interface Ethernet0/0
 ip address 10.1.56.5 255.255.255.0
 ip pim sparse-mode
!
interface Serial1/0
 ip address 10.1.15.5 255.255.255.0
 ip pim sparse-mode
 serial restart-delay 0
!

R6 Configuration:
!
ip multicast-routing
!
ip pim rp-address 172.16.105.5
!
interface Ethernet0/0
 ip address 10.1.56.6 255.255.255.0
 ip pim sparse-mode
!

Verification:
The 'show ip pim interface' and 'show ip pim neighbor' commands show proper output.

Task 2
Configure R4's Et0/0 to join the group 224.4.4.4. On R6 use ping to verify if R4 receives the multicast traffic.

R4 Configuration:
!
interface Ethernet0/0
 ip address 10.1.234.4 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 224.4.4.4
!

Note!
The problem here, is that for R1 to reach the RP (172.16.105.5) the best path is through Ethernet (10.1.51.0/24). These interfaces are not enabled for PIM. As a result of this, the PIM join message will not reach the RP and the group is not going to be registered.

Verification:
Pic. 2 - R2 (DR) Multicast Routing Table.

Pic. 3 - R5 (RP) Does Not Register 224.4.4.4


The reason for not sending the group register message is that R1's routing table points towards RP out its Et0/0 rather than Se1/1. But Eth0/0 is not enabled for multicast.

In order to solve the problem, I must force R1's multicast protocol into believing that connection towards 172.16.105.5 out its s1/1 interface is better than given by the EIGRP protocol.

R1 Configuration:
!
ip mroute 172.16.105.5 255.255.255.255 10.1.15.5
!

Pic. 4 - R5 (RP) Registers 224.4.4.4 Group.

Pic. 5 - Ping Test.