2013/11/28

WB1 8.3 PIM Sparse Mode

8.3 PIM Sparse Mode

• Remove the PIM Dense Mode configuration and replace it with Sparse
Mode on all interfaces between R6 and SW4.
• Do NOT run PIM on the Frame Relay link between R4 and R5.
• Remove the static default mroute from R5.
• Use R5’s Loopback 0 interface as the static Rendezvous Point address.
• Configure SW4’s VLAN 10 interface to join the group 224.10.10.10, and ensure that R6 can send multicast packets to this segment.
• Perform SPT switchover only when the traffic flow exceeds 128Kbps.


---------------------------------------------------------

R4:
ip multicast-routing
ip pim rp-address 150.1.5.5
!
interface FastEthernet 0/1
ip pim sparse-mode
!
interface Serial 0/1/0
ip pim sparse-mode
!
interface Serial 0/0/0.1
no ip pim dense-mode


R5:
no ip mroute 0.0.0.0 0.0.0.0 155.1.0.4
!
ip multicast-routing
ip pim rp-address 150.1.5.5
!
interface Serial 0/1/0
ip pim sparse-mode
!
interface Serial 0/0/0
no ip pim dense-mode
!
interface FastEthernet 0/0
ip pim sparse-mode
!
! Needed to fix RPF check for R5’s Loopback0
!

interface Loopback0
ip ospf network point-to-point


R6:
ip multicast-routing
ip pim rp-address 150.1.5.5
!
interface FastEthernet 0/0.146
ip pim sparse-mode


SW2:
ip multicast-routing distributed
ip pim rp-address 150.1.5.5
!
interface Vlan 58
ip pim sparse-mode
!
interface Port-Channel1
ip pim sparse-mode


SW4:
ip multicast-routing
ip pim rp-address 150.1.5.5
ip pim spt-threshold 128
!
interface Port-Channel1
ip pim sparse-mode
!
interface Vlan 10
ip igmp join-group 224.10.10.10
ip pim sparse-mode


---------------------------------------------------------

When you check the mroute states on SW2 and SW4 you will only see (*,G) entries. This is because the SPT switchover rate is set to 128Kbps and we haven’t exceeded it yet. Thus SW4 never initialized SPT-switchover toward the source.

In order to see the SPT switchover process, disable the threshold setting on SW4 and repeat the multicast testing again.
SW4:
no ip pim spt-threshold 128


Rack1R6#ping 224.10.10.10 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.10.10.10, timeout is 2
seconds:
Reply to request 0 from 155.1.108.10, 49 ms
Reply to request 1 from 155.1.108.10, 32 ms


Now you can see the SPT entry in the multicast routing table of SW2. In our case, the SPT and shared tree overlap (follow the same paths) but in other scenarios they may differ and this can result in RPF issues.

沒有留言:

張貼留言