Reverse path forwarding is the loop prevention mechanism for PIM. PIM relies on the underlying IGP and local routing table to know how to forward packets. One check to ensure that it does not loop packets is to check the source address of an incoming multicast packet by looking up the source IP in the local routing table and confirm that its path back to the source address is the same path that the packet was received through. This is referred to as the reverse path forwarding check. If this check fails then the packet is dropped. RPF failures can happen for several reason usually related to multi-path environments where either PIM is not enabled on all or the correct paths from the source to the reciever or there is an underlying issue where the multicast packet's source IP doesn't not match the interface it arrived on.
Concepts tested
- IGP routing
- PIM RPF Verification
- Enabling PIM
Topology
Lab Tasks
- Enable PIM on the path between R1 to the client device on the Gigabit Ethernet interfaces only.
- Test the configuration by joining the group 239.0.0.1 via the Clients G0/0 interface
- Ping the 239.0.0.1 group sourcing it from R1's loopback 0 interface to confirm multicast packets reach the receiver.
- Resolve any issues using the simply method and with modify routing or the topology.
GNS3 configuration file, requires IOS v15 for the 7200 router: Link
Solution
To begin lets configure our PIM neighbors.
R1(config)#ip multicast-routing
R1(config)#interface gig0/0
R1(config-if)#ip pim dense-mode
R2(config)#ip multicast-routing
R2(config)#interface gigabitEthernet 0/0
R2(config-if)#ip pim dense-mode
R2(config)#interface gigabitEthernet 1/0
R2(config-if)#ip pim dense-mode
R3(config)#ip multicast-routing
R3(config)#int g0/0
R3(config-if)#ip pim dense-mode
R3(config)#interface g1/0
R3(config-if)#ip pim dense-mode
With our PIM DM configuration in place we should see our PIM neighbor come up.
*Nov 14 14:05:35.559: %PIM-5-DRCHG: DR change from neighbor 120.0.12.1 to 120.0.12.2 on interface GigabitEthernet0/0
*Nov 14 14:05:37.127: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 120.0.12.2 on interface GigabitEthernet0/0
*Nov 14 14:07:45.799: %PIM-5-DRCHG: DR change from neighbor 120.0.23.2 to 120.0.23.3 on interface GigabitEthernet1/0
*Nov 14 14:07:48.363: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 120.0.23.3 on interface GigabitEthernet0/0
*Nov 14 14:07:59.111: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 120.0.30.3 on interface GigabitEthernet1/0
Client(config)#ip multicast-routing
Client(config)#int g0/0
Client(config-if)#ip pim dense-mode
Client(config-if)#ip igmp join-group 239.0.0.1
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.......
Client#sh ip mroute 239.0.0.1
(*, 239.0.0.1), 00:02:19/00:02:41, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Dense, 00:02:19/00:00:00
We can't ping our receiver, notice the incoming interface on the client is Null. lets look upstream to see what else we notice.
R2#sh ip mroute 239.0.0.1
(*, 239.0.0.1), 00:00:34/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet1/0, Forward/Dense, 00:00:34/00:00:00
GigabitEthernet0/0, Forward/Dense, 00:00:34/00:00:00
(1.1.1.1, 239.0.0.1), 00:00:34/00:02:25, flags: PT
Incoming interface: GigabitEthernet1/0, RPF nbr 120.0.23.3
Outgoing interface list:
GigabitEthernet0/0, Prune/Dense, 00:00:33/00:02:26
R3#sh ip mroute 239.0.0.1
(*, 239.0.0.1), 00:15:46/00:02:13, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet1/0, Forward/Dense, 00:15:46/00:00:00
GigabitEthernet0/0, Forward/Dense, 00:15:46/00:00:00
R2#sh ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
RPF interface: GigabitEthernet1/0
RPF neighbor: ? (120.0.23.3)
RPF route/mask: 1.1.1.0/24
RPF type: unicast (eigrp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
R3#show ip rpf 1.1.1.1
failed, no route exists
lets debug on R3 to see what might be going on.
R3(config)#int g0/0
R3(config-if)#no ip mfib cef input
R3(config-if)#no ip mfib cef out
R3(config-if)#int tu 0
R3(config-if)#no ip mfib cef input
R3(config-if)#no ip mfib cef out
* you must turn off fast switching in order to see the debug output below.
R3#deb ip mfib pak
*Nov 14 14:41:36.343: MFIBv4(0x0): Pkt (1.1.1.1,239.0.0.1) from Tunnel0 (PS) Acceptance check failed - dropping
*Nov 14 14:41:37.399: MFIBv4(0x0): Pkt (120.0.23.2,224.0.0.10) from GigabitEthernet0/0 (PS) copying to an internal member from GigabitEthernet0/0
*Nov 14 14:41:37.403: MFIBv4(0x0): Pkt (120.0.23.2,224.0.0.10) from GigabitEthernet0/0 (PS) Acceptance check failed - dropping
*Nov 14 14:41:38.287: MFIBv4(0x0): Pkt (120.0.13.1,224.0.0.10) from Tunnel0 (PS) copying to an internal member from Tunnel0
*Nov 14 14:41:38.291: MFIBv4(0x0): Pkt (120.0.13.1,224.0.0.10) from Tunnel0 (PS) Acceptance check failed - dropping
*Nov 14 14:41:38.315: MFIBv4(0x0): Pkt (1.1.1.1,239.0.0.1) (TS) input interface cannot forward, punting
We are not passing RPF, lets look out our routing tables.
Known via "eigrp 1", distance 90, metric 27008000, type internal
Redistributing via eigrp 1
Last update from 120.0.13.1 on Tunnel0, 00:42:02 ago
Routing Descriptor Blocks:
* 120.0.13.1, from 120.0.13.1, 00:42:02 ago, via Tunnel0
Route metric is 27008000, traffic share count is 1
Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 1
R3#sh ip route multicast 1.1.1.1
Routing Table: multicast
Routing entry for 1.1.1.0/24
Known via "eigrp 1", distance 90, metric 27008000, type internal, replicated
Last update from 120.0.13.1 on Tunnel0, 00:42:10 ago
Routing Descriptor Blocks:
* 120.0.13.1 (default), from 120.0.13.1, 00:42:10 ago, via Tunnel0
Route metric is 27008000, traffic share count is 1
Total delay is 55000 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 1
R3(config)#int tunnel 0
R3(config-if)#ip pim dense-mode
R1(config-if)#ip pim dense-mode
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Reply to request 0 from 120.0.30.1, 152 ms
Reply to request 2 from 120.0.30.1, 88 ms
Reply to request 3 from 120.0.30.1, 108 ms
Reply to request 4 from 120.0.30.1, 108 ms
Reply to request 5 from 120.0.30.1, 140 ms
Reply to request 6 from 120.0.30.1, 120 ms
Now we can ping our receiver.
No comments:
Post a Comment