The PIM DR in a sparse mode environment is responsible for source and receiver registration with the RP. The DR receives IGMP query report notices from interested receivers and encapsulates those messages into unicast packets and forwards them to its configured RP. Since sources don't notify they simply start sending traffic, the DR when it receives an initial multicast packet for a *,G entry for its configure RP, it will encapsulate the packet and forward it to the RP for registration via unicast. This lab will focus on DR election and placement.
Concepts tested
- IP PIM-SM DR placement
- IP PIM RP
- IP PIM-SM configuration and troubleshooting
Topology
Lab Tasks
- Configure PIM sparse mode on all interfaces in the path between the source and receiver hosts
- Configure PIM sparse mode on R3's g0/0 interface
- Configure R1 and R2 so that the host RP becomes the RP.
- Do not configure source, receiver, or R3 as static RPs.
- Test your configuration by having receiver join its g0/0 interface to the 239.1.1.1 group then have source ping the group.
GNS3 configuration file, requires IOS v15 for the 7200 router: Link
Solution
Receiver(config)#ip multicast-routing
Receiver(config)#int g0/0
Receiver(config-if)#ip pim sparse-mode
R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 5.5.5.5
R1(config-if)#int g1/0
R1(config-if)#ip pim sparse-mode
Solution
Receiver(config)#ip multicast-routing
Receiver(config)#int g0/0
Receiver(config-if)#ip pim sparse-mode
R1(config)#ip multicast-routing
R1(config)#ip pim rp-address 5.5.5.5
R1(config)#int g0/0
R1(config-if)#ip pim sparse-modeR1(config-if)#int g1/0
R1(config-if)#ip pim sparse-mode
RP(config)#ip multicast-routing
RPconfig)#ip pim rp-address 5.5.5.5
RP(config)#int lo 0
RP(config-if)#ip pim sparse-mode
RP(config)#int g0/0
RP(config-if)#ip pim sparse-mode
RP(config-if)#int g1/0
RP(config-if)#ip pim sparse-mode
R2(config)#ip multicast-routing
R2(config)#ip pim rp-address 5.5.5.5
R2(config)#int g0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int g1/0
R2(config-if)#ip pim sparse-mode
R3(config)#ip multicast-routing
R3(config)#int g0/0
R3(config-if)#ip pim sparse-mode
Source(config)#ip multicast-routing
Source(config)#int g0/0
Source(config-if)#ip pim sparse-mode
Verification
Lets begin our verification by joining receiver to the group 239.1.1.1 and attempting to ping it.
Receiver(config)#int g0/0
Receiver(config-if)#ip igmp join-group 239.1.1.1
Source#ping 239.1.1.1 rep 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
...........
It failed, why? lets investigate.
Lets first make sure our PIM domain is properly configured between receiver and source. A quick way to check this is with mtrace at the reciever toward the source. This tool verifies SPT via RPF to the source. Keep in mind this doesn't necessarily verify the shared tree from receiver to RP and RP to source. In our case they are the same path.
Receiver#mtrace 120.0.45.1
Type escape sequence to abort.
Mtrace from 120.0.45.1 to 120.0.0.254 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 120.0.0.254
-1 120.0.0.254 None [120.0.45.0/24]
-2 120.0.0.1 None [120.0.45.0/24]
-3 120.0.12.5 None [120.0.45.0/24]
-4 120.0.13.2 PIM [120.0.45.0/24]
-5 120.0.45.1
Looks OK. Now lets look at our *,G and S,G tables.
R1#sh ip mroute 239.1.1.1
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:02:01/00:02:38, RP 5.5.5.5, flags: SP
Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.12.5
Outgoing interface list: Null
RP#sh ip mroute 239.1.1.1
Group 239.1.1.1 not found
R2#sh ip mroute 239.1.1.1
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:01:55/stopped, RP 5.5.5.5, flags: SP
Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.13.5
Outgoing interface list: Null
(120.0.45.1, 239.1.1.1), 00:01:55/00:01:03, flags: PT
Incoming interface: GigabitEthernet0/0, RPF nbr 120.0.45.1
Outgoing interface list: Null
So the obvious issue appears to be that the RP does not know about 239.1.1.1. So the RP has not been notified of the receiver or the source.
In this case based on our multicast design the next hop routes R1 and R2 should be notifying the RP but they are not.
For a receiver in a sparse mode environment the next hop PIM router is responsible for sending join/prune messages to the RP for registration. On a LAN that responsibility falls to the elected DR. lets see who are the DRs.
R1#sh ip pim int g0/0 det
GigabitEthernet0/0 is up, line protocol is up
Internet address is 120.0.0.1/24
Multicast switching: fast
Multicast packets in/out: 0/442
Multicast TTL threshold: 0
PIM: enabled
PIM version: 2, mode: sparse
PIM version: 2, mode: sparse
PIM DR: 120.0.0.254
PIM neighbor count: 1
PIM Hello/Query interval: 30 seconds
PIM Hello packets in/out: 721/741
PIM State-Refresh processing: enabled
PIM State-Refresh origination: disabled
PIM NBMA mode: disabled
PIM ATM multipoint signalling: disabled
PIM domain border: disabled
PIM neighbors rpf proxy capable: TRUE
Multicast Tagswitching: disabled
R2#sh ip pim int g0/0 det
GigabitEthernet0/0 is up, line protocol is up
Internet address is 120.0.45.2/24
Multicast switching: fast
Multicast packets in/out: 591/0
Multicast TTL threshold: 0
PIM: enabled
PIM version: 2, mode: sparse
PIM version: 2, mode: sparse
PIM DR: 120.0.45.254
PIM neighbor count: 2
PIM Hello/Query interval: 30 seconds
PIM Hello packets in/out: 1460/744
PIM State-Refresh processing: enabled
PIM State-Refresh origination: disabled
PIM NBMA mode: disabled
PIM ATM multipoint signalling: disabled
PIM domain border: disabled
PIM neighbors rpf proxy capable: TRUE
Multicast Tagswitching: disabled
The reciever and R3 our the DR's for their respective LANs. But they are not configures as RPs nor do they know about the DR.
Receiver#sh ip pim rp map
PIM Group-to-RP Mappings
R3#sh ip pim rp map
PIM Group-to-RP Mappings
So for the receiver LAN the host receiver is responsible for taking IGMP membership reports and turning them into PIM join/prune messages and forwarding them to the RP for the appropriate *,G entry. But it is not configured with an RP so it can't do this.
The same is essentially true for R3 accept sources don't notify they just send traffic. But the DR with a source on its local LAN is responsible for taking the mcast packets and encapsulating them and forwarding them on to the RP as unicast packets for registration, but again its not configured with an RP so it can't do this.
The solution is to either configure these devices with RP information or simply change the DR for each LAN. We will change the DR.
R1(config-if)#ip pim dr-priority 2
R1(config-if)#
*Nov 18 23:30:14.358: %PIM-5-DRCHG: DR change from neighbor 120.0.0.254 to 120.0.0.1 on interface GigabitEthernet0/0
R2(config-if)#ip pim dr-priority 2
R2(config-if)#
*Nov 18 23:30:52.618: %PIM-5-DRCHG: DR change from neighbor 120.0.45.254 to 120.0.45.2 on interface GigabitEthernet0/0
Now lets ping our group again and see what happens. It may be necessary to clear your mroute cache and re-join the group on the receiver to ensure everything gets registered properly.
Source#ping 239.1.1.1 rep 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 120.0.0.254, 220 ms
Reply to request 1 from 120.0.0.254, 128 ms
Reply to request 1 from 120.0.0.254, 196 ms
Reply to request 2 from 120.0.0.254, 72 ms
Reply to request 3 from 120.0.0.254, 112 ms
Sources:
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/multicast/configuration_guide/b_mc_3se_3850_cg/b_mc_3se_3850_cg_chapter_01101.html#GUID-8A53F572-FFF7-47B0-BBC9-67C2E3F15CF3
No comments:
Post a Comment