Skip to main content

CCIE VERIFY RPF FAIL

One of the major issues with Multicast is finding the RPF and making sure that there is no Failure in it, as if we do have a fail we can patch it by adding ip mroute (like a static route but only to pass the RPF, not actually changing the path of the packet). So how we can find such fail we have several tools the first one is to find if we have rp mapping. R6#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:14:48, expires: 00:00:02 R6# we see here in that example that we do have RP Mapping so we defiantly passed the RPF. I have made an RPF fail and we now will try to trace it: R6#sh ip mroute count IP Multicast Statistics 3 routes using 1962 bytes of memory 3 groups, 0.00 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 we see that we are not receiving packets from our mapping agent when we listen on group 224.0.1.40 so some where along the path we have an RPF fail. R6#sh ip mrou IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 227.0.0.1), 00:02:19/00:02:47, RP 0.0.0.0, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:47 (*, 224.0.1.1), 00:02:19/00:02:53, RP 0.0.0.0, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:53 (*, 224.0.1.39), 00:01:12/stopped, RP 0.0.0.0, flags: DP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (150.1.5.5, 224.0.1.39), 00:01:12/00:01:47, flags: PT Incoming interface: FastEthernet0/0, RPF nbr 166.1.12.1 Outgoing interface list: Null (*, 224.0.1.40), 00:02:20/00:02:54, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:20/00:02:54 R6# we see above that we do get see the RP and we get it from 166.1.12.1 so lets got to R1 (166.1.12.1). R1#sh ip mroute count IP Multicast Statistics 5 routes using 2946 bytes of memory 4 groups, 0.25 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 1 RP-tree: Forwarding: 0/0/0/0, Other: 1/0/1 Group: 224.0.1.39, Source count: 1, Packets forwarded: 12, Packets received: 12 Source: 150.1.5.5/32, Forwarding: 12/1/48/0, Other: 12/0/0 Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 R1# we see here that we still do not recive any packet on the mapping group. R1#sh ip mrou IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 227.0.0.1), 00:01:24/00:02:10, RP 0.0.0.0, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (*, 224.0.1.1), 00:01:24/stopped, RP 0.0.0.0, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (166.1.12.4, 224.0.1.1), 00:00:20/00:03:09, flags: T Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, Forward/Sparse, 00:00:20/00:03:09 (166.1.12.6, 224.0.1.1), 00:00:20/00:03:09, flags: T Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, Forward/Sparse, 00:00:20/00:03:09 (*, 224.0.1.39), 00:01:26/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00 Serial1/0, Forward/Sparse, 00:01:26/00:00:00 (150.1.5.5, 224.0.1.39), 00:01:26/00:02:56, flags: T Incoming interface: Serial1/0, RPF nbr 166.1.0.5 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00 (*, 224.0.1.40), 00:01:27/00:02:04, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:27/00:00:00 Serial1/0, Forward/Sparse, 00:01:27/00:00:00 R1# now lets go again one step forward to R5 to see if R5 is also not receiving packets for group of the mapping agent. R5#sh ip pim rp ma PIM Group-to-RP Mappings This system is an RP (Auto-RP) Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:45, expires: 00:00:01 R5# and we can see that we do receive the mapping from 150.1.3.3 on R5 so we know that the RPF fail happen on R1 to R3 Now I will tell you that R5 R3 and R1 are connected over FR (Physical Interface only) R5 is the hub and R1 and R3 are the spokes. so first we need to make sure that we enabled R5(config-if)#ip pim nbma-mode that command will make sure that packets received on one VC of the FR can go out that same interface to another VC for Sparse Groups Only here bellow you can see the output of sparse group with the nbma-mode enable you can see it is going out of that same interface but to different IP (VC) (*, 227.0.0.1), 20:05:09/stopped, RP 150.1.5.5, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, 166.1.0.3, Forward/Sparse, 00:15:40/00:01:01 Serial1/0, 166.1.0.5, Forward/Sparse, 04:28:41/00:02:42 And on that same router R5 although I have enabled nbma-mode you can see that for dense mode group it is acting different. (*, 224.0.1.40), 17:24:56/stopped, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 17:24:56/00:00:00 Serial1/0, Forward/Sparse, 17:24:56/00:00:00 So now that we see that we traced where the RPF is we need to solve it, on R1 R1#sh ip route 150.1.3.3 Routing entry for 150.1.3.3/32 Known via "ospf 1", distance 110, metric 65, type intra area Redistributing via eigrp 1 Advertised by eigrp 1 metric 1536 1 255 1 1500 Last update from 166.1.0.3 on Serial1/0, 00:17:50 ago Routing Descriptor Blocks: * 166.1.0.3, from 150.1.3.3, 00:17:50 ago, via Serial1/0 Route metric is 65, traffic share count is 1 R1#sh ip route 166.1.0.3 Routing entry for 166.1.0.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 1 Advertised by eigrp 1 Routing Descriptor Blocks: * directly connected, via Serial1/0 Route metric is 0, traffic share count is 1 we know that 224.0.1.40 is Dense mode group and it cannot pass the RPF due to that as it will not be able to go out the same interface it came in. so what we can do is create a tunnel interface between R1 to R3. And set the RPF to check the path trough that tunnel. interface Tunnel0 ip unnumbered Loopback0 ip pim sparse-mode tunnel source Loopback0 tunnel destination 150.1.3.3 ! R1#sh run inc ip mrou ip mroute 150.1.3.3 255.255.255.255 Tunnel0 R1# ! interface Tunnel0 ip unnumbered Loopback0 ip pim sparse-mode tunnel source Loopback0 tunnel destination 150.1.1.1 end R3# we must make sure that the source and the destination match exactly on both side like showed here and both on the interface that we are sourcing and destination and the tunnel we enabling PIM. R1#sh ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 166.1.0.5 Serial1/0 20:52:24/00:01:20 v2 1 / DR S 166.1.12.4 FastEthernet0/0 17:20:06/00:01:24 v2 1 / S 166.1.12.6 FastEthernet0/0 20:51:54/00:01:21 v2 1 / DR S 150.1.3.3 Tunnel0 00:02:12/00:01:30 v2 1 / S R1# R1#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:10, expires: 00:00:02 R1# And now we can go back to R6 and see that we have also mapping on R6 so we solved RPF fail. R6#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:33, expires: 00:00:03 R6#
Post a Comment

Popular posts from this blog

Step By Step MPLS – Basic MPLS Setup

Initial configuration , very basic with no MPLS, connectivity only to directly connected interfaces.R1R2R3R4!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.31.1 255.255.255.0
duplex auto
speed auto
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.42.2 255.255.255.0
duplex auto
speed auto
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
no clns route-cache
!
interface FastEthernet0/0
ip address 10.0.31.3 255.255.255.0
duplex auto
speed auto
  no clns route-cache
!
interface Serial1/0
ip address 10.0.43.3 255.255.255.0
  serial restart-delay 0
no clns route-cache
!
!
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
no clns route-cache
!
interface FastEthernet0/0
ip address 10.0.42.4 255.255.255.0
duplex auto
speed auto
!
interface Serial1/0
ip address 10.0.43.4 255.255.255.0
  serial restart-delay 0
no clns route-cache
!
adding to the following configuration MPLS labels we will start wi…

VRF Maximum Routes

Maximum routes under customer vrf, if the service provider had unlimited resources he would not have needed that!
however normally resources are limited and expensive, and Service provider would like to make money from his available resources. maximum routes configured under VRF provide a mean of controlling PE local resource and abuse avoidance from the CE side.I have vrf called DC_EXTRANET, you can see that I have 16 routes, I have configured 10 maximum routes under that vrf however I did not want to be aggressive so I have set the warning only option. See that immediately I get a notice that I have more routes then the maximum, however no action is taken other then alerting and sending a syslog. ! PE_ashdod_otherisp.n(config-vrf)# maximum routes 10 warning-only % The current number of routes in the routing table is equal to, or exceeds the configured warning limit PE_ashdod_otherisp.n(config-vrf)# *Nov 26 20:39:41.175: %IPRT-3-ROUTELIMITWARNING: IP routing table limit warning - DC_…

ISIS Database Reading

ISIS is simple to operate normally while everything is working, most common deployments are flat network based on L2, however when there is a problem and we need to start troubleshooting then people start to get lost.So I would like to provide some tools on how to read ISIS database.notice to the “*” sign, that mean LSP was generated on the router you did the show command, you can see that host name from the show command match also host name on the LSPID,LSPID identified by hostname.xx-yy,  xx is normally 00 unless that LSP is pseudo node LSP generated by DIS , yy is representing the number of fragments for that LSP 00 – FF (max 255 fragments, plenty), most cases all the important information will be in 00 unless there are many fragments.LSP Holdtime is the amount of time an LSP will stay in database without any refresh.ATT/P/OL - 0/0/0, ATT bit or attached bit is used on L1/L2 connected to L1 node, if set to 1 L1 node will generate default route to the best L1/L2 node (best metric)AT…