On my way back home from San Jose. I want to thank those that follow this blog and especially IPexpert for all the help. Will right more soon :)
-CCIE# 23707
Tuesday, March 3, 2009
Wednesday, February 25, 2009
PIM NBMA, DR and RPF issues
Below is the topology. RIP is running everywhere, PIM-SM on all interfaces and everyone has R4 at 192.168.100.4 as the static RP.
R1 has the following config on its LAN interface:
R1#debug ip mpacket
IP multicast packets debugging is on
03:40:21: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=197, ttl=251, prot=1, len=114(100), not RPF interface
03:40:23: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=198, ttl=251, prot=1, len=114(100), not RPF interface
It is important to remember we have at least two ways to resolve this:
1) Make R1 the DR
R1(config)#int e0/0
R1(config-if)#ip pim dr-priority 3000
R6#ping 239.0.0.1 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Reply to request 0 from 192.168.100.1, 60 ms
R6#
R1(config-if)#^Z
03:41:47: IP(0): s=192.168.56.6 (Serial0/0) d=239.0.0.1 (Ethernet0/0) id=207, ttl=252, prot=1, len=100(100), mforward
2) Static mroute to R2 for 192.168.56.6
R1(config)#int e0/0
R1(config-if)#no ip pim dr-priority 3000
R1(config-if)#exit
R1(config)#ip mroute 192.168.56.0 255.255.255.0 192.168.0.2
Make sure to clear mroutes otherwise previous state may mislead you :)
R4#clear ip mroute *
R6#ping 239.0.0.1 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Reply to request 0 from 192.168.100.1, 56 ms
R6#
This is one of those labs where I had no idea where I was going and I ended up with a nice troubleshooting scenario. If multicast is one your weaknesses than I highly recommend digging in and making something happen. Debug ip mpacket works best with "no ip mroute-cache" on your interfaces. In this scenario, I started troubleshooting on R5, then worked my way around to resolve the issue :)
R1 has the following config on its LAN interface:
interface Ethernet0/0Let's ping from R6:
ip address 192.168.0.1 255.255.255.0
ip pim sparse-mode
ip igmp join-group 239.0.0.1
R6#ping 239.0.0.1 re 5Hmmm....what gives? Let's look at R4:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
.....
R6#
R4#sho ip pim neighborWell, it looks R2 is showing up in the OIL, but why isn't R1? It is a PIM neighbor afterall. The reason is because R2 has won the DR election and has the right to forward traffic. So it is the neighbor that sends PIM joins to R4. R1 receives the traffic, but it comes in on its LAN interface and thus fails the RPF check.
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.34.3 Ethernet0/0 03:29:50/00:01:39 v2 1 / S
192.168.100.2 Serial0/0 02:25:22/00:01:38 v2 1 / S
192.168.100.5 Serial0/0 02:25:22/00:01:39 v2 1 / DR S
192.168.100.1 Serial0/0 02:25:22/00:01:38 v2 1 / S
R4#sho ip mroute 239.0.0.1 | be \(
(*, 239.0.0.1), 00:24:31/00:02:33, RP 192.168.100.4, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/0, 192.168.100.2, Forward/Sparse, 00:24:31/00:02:33
(192.168.56.6, 239.0.0.1), 00:02:03/00:02:45, flags: T
Incoming interface: Serial0/0, RPF nbr 192.168.100.5
Outgoing interface list:
Serial0/0, 192.168.100.2, Forward/Sparse, 00:02:03/00:00:57
R4#
R1#debug ip mpacket
IP multicast packets debugging is on
03:40:21: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=197, ttl=251, prot=1, len=114(100), not RPF interface
03:40:23: IP(0): s=192.168.56.6 (Ethernet0/0) d=239.0.0.1 id=198, ttl=251, prot=1, len=114(100), not RPF interface
It is important to remember we have at least two ways to resolve this:
1) Make R1 the DR
R1(config)#int e0/0
R1(config-if)#ip pim dr-priority 3000
R6#ping 239.0.0.1 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Reply to request 0 from 192.168.100.1, 60 ms
R6#
R1(config-if)#^Z
03:41:47: IP(0): s=192.168.56.6 (Serial0/0) d=239.0.0.1 (Ethernet0/0) id=207, ttl=252, prot=1, len=100(100), mforward
2) Static mroute to R2 for 192.168.56.6
R1(config)#int e0/0
R1(config-if)#no ip pim dr-priority 3000
R1(config-if)#exit
R1(config)#ip mroute 192.168.56.0 255.255.255.0 192.168.0.2
Make sure to clear mroutes otherwise previous state may mislead you :)
R4#clear ip mroute *
R6#ping 239.0.0.1 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Reply to request 0 from 192.168.100.1, 56 ms
R6#
This is one of those labs where I had no idea where I was going and I ended up with a nice troubleshooting scenario. If multicast is one your weaknesses than I highly recommend digging in and making something happen. Debug ip mpacket works best with "no ip mroute-cache" on your interfaces. In this scenario, I started troubleshooting on R5, then worked my way around to resolve the issue :)
Labels:
multicast
Monday, February 23, 2009
PIM Forwarder and the Assert Mechanism
I know, it's a cool name for a band, huh? Ladies and gentlemen...PIM Forwarder and the Assert Mechanism! Anyways, I always get confused about PIM DR and PIM Forwarder so this is to clear up my confusion. Here we take a look at PIM Forwarder and how to verify the assert process is working.
Here is the topology:
Here is what I have enabled:
-RIP on all interfaces
-ip multicast-routing on all routers
-ip pim sparse-dense on all interfaces
-ip igmp join-group 239.0.0.1 on R5 ethernet
For debugging:
-no ip mroute-cache
-debug ip mpacket
-ping
Scenario 1: R2 is the PIM Forwarder based on highest IP
From R4 we ping twice:
R1#
*Mar 2 02:05:36.795: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=70, ttl=253, prot=1, len=100(100), mforward
*Mar 2 02:05:36.799: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=70, ttl=252, prot=1, len=114(100), not RPF interface
*Mar 2 02:05:38.787: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=71, ttl=252, prot=1, len=114(100), not RPF interface
R2#
*Mar 1 02:25:00.567: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=70, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:25:00.571: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=70, ttl=252, prot=1, len=114(100), not RPF interface
*Mar 1 02:25:02.559: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=71, ttl=253, prot=1, len=100(100), mforward
Notice that each router sent the first packet onto the LAN and R5 responded to both. We can tell because R4 got two replies. What also happened is that R1 and R2 each saw that very same packet on their LAN interfaces. Immediately the PIM Assert process took over. Because both routers have the same AD (90) and metric (2) to the source, R2 won the right to forward based on highest IP.
Next we see that the second packet only gets forwarded by R2. Here we see that R2 has the A (Assert Winner) flag in its mroute entry. R1 has pruned that same interface.
Now we change R1's AD for RIP below the default of 120:
Here is the topology:
Here is what I have enabled:
-RIP on all interfaces
-ip multicast-routing on all routers
-ip pim sparse-dense on all interfaces
-ip igmp join-group 239.0.0.1 on R5 ethernet
For debugging:
-no ip mroute-cache
-debug ip mpacket
-ping
Scenario 1: R2 is the PIM Forwarder based on highest IP
From R4 we ping twice:
R4#ping 239.0.0.1 re 2On R1 and R2 we see the following:
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Reply to request 0 from 192.168.0.5, 20 ms
Reply to request 0 from 192.168.0.5, 20 ms
Reply to request 1 from 192.168.0.5, 8 ms
R1#
*Mar 2 02:05:36.795: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=70, ttl=253, prot=1, len=100(100), mforward
*Mar 2 02:05:36.799: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=70, ttl=252, prot=1, len=114(100), not RPF interface
*Mar 2 02:05:38.787: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=71, ttl=252, prot=1, len=114(100), not RPF interface
R2#
*Mar 1 02:25:00.567: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=70, ttl=253, prot=1, len=100(100), mforward
*Mar 1 02:25:00.571: IP(0): s=192.168.34.4 (Ethernet0/0) d=239.0.0.1 id=70, ttl=252, prot=1, len=114(100), not RPF interface
*Mar 1 02:25:02.559: IP(0): s=192.168.34.4 (Serial0/1) d=239.0.0.1 (Ethernet0/0) id=71, ttl=253, prot=1, len=100(100), mforward
Notice that each router sent the first packet onto the LAN and R5 responded to both. We can tell because R4 got two replies. What also happened is that R1 and R2 each saw that very same packet on their LAN interfaces. Immediately the PIM Assert process took over. Because both routers have the same AD (90) and metric (2) to the source, R2 won the right to forward based on highest IP.
Next we see that the second packet only gets forwarded by R2. Here we see that R2 has the A (Assert Winner) flag in its mroute entry. R1 has pruned that same interface.
R2#sho ip mroute 239.0.0.1 192.168.34.4 | be \(Scenario 2: R1 is the PIM Forwarder based on lowest AD
(192.168.34.4, 239.0.0.1), 00:00:39/00:02:26, flags: T
Incoming interface: Serial0/1, RPF nbr 192.168.23.3
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 00:00:39/00:00:00, A
R1#sho ip mroute 239.0.0.1 192.168.34.4 | be \(
(192.168.34.4, 239.0.0.1), 00:01:27/00:01:34, flags: PT
Incoming interface: Serial0/1, RPF nbr 192.168.13.3
Outgoing interface list:
Ethernet0/0, Prune/Sparse-Dense, 00:01:27/00:01:32
Now we change R1's AD for RIP below the default of 120:
R1(config)#router ripWe see the same behavior from R4's perspective but now R1 has won the Assert process and is forwarding group 239.0.0.1 onto the LAN:
R1(config-router)#distance 89
R4#ping 239.0.0.1 re 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 239.0.0.1, timeout is 2 seconds:
Reply to request 0 from 192.168.0.5, 12 ms
Reply to request 0 from 192.168.0.5, 12 ms
Reply to request 1 from 192.168.0.5, 8 ms
R4#
R1#sho ip mroute 239.0.0.1 192.168.34.4 | be \(
(192.168.34.4, 239.0.0.1), 00:00:07/00:02:54, flags: T
Incoming interface: Serial0/1, RPF nbr 192.168.13.3
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense, 00:00:07/00:00:00, A
R1#
Labels:
multicast
Subscribe to:
Posts (Atom)