Joe, Thanks for labbing this up and clarifying the RPF process. It is an odd case, I think I'll lab up a couple different scenarios (using different IGPs, peering with physical links instead of loopbacks, etc.)
Also, I definantly understand there is a method to you guys madness, I'm just trying to understand the technologies best I can and identify gaps (and you pointed one out regarding my understanding of RPF checks). Thanks for all the help! On Wed, Apr 14, 2010 at 7:58 AM, Joe Astorino <[email protected]>wrote: > I labbed up your scenario and I think I have an idea of what is going > on here. Here are my results: When I removed BGP completely from the > picture (no router bgp 78) and did a "show ip rpf" for 8.8.8.8 from R7 > I received an error that no route existed! This was pretty funny since > I could like you run "sho ip route" and see it in the unicast routing > table. > > AFTER REMOVING BGP > ---------------------------------------- > > R7(config-if)#do sh ip route ospf > 8.0.0.0/32 is subnetted, 1 subnets > O 8.8.8.8 [110/2] via 150.100.78.8, 00:00:04, FastEthernet0/0 > > R7(config-if)#do sh ip rpf 8.8.8.8 > RPF information for ? (8.8.8.8) failed, no route exists > > > It seems like the reason MBGP was being preferred in your case is > because the router simply didn't even CONSIDER the route in the > unicast routing table. After a reload I received the RPF information > very briefly...right up until OSPF on Fa0/0 came up and then back to > the same RPF failure. If I shut down Fa0/0 the RPF information comes > back up just fine. Very strange. It is almost as if the RPF check > will not consider anything that PIM is not enabled on. To test this, > I enabled PIM on Fa0/0 of JUST R7 and ... > > R7(config-if)#do sh ip rpf 8.8.8.8 > RPF information for ? (8.8.8.8) > RPF interface: FastEthernet0/0 > RPF neighbor: ? (150.100.78.8) > RPF route/mask: 8.8.8.8/32 > RPF type: unicast (ospf 1) > RPF recursion count: 0 > Doing distance-preferred lookups across tables > > > Now of course there is still no PIM neighbor, but the interface itself > is participating in multicast. NOW that we know that path is being > considered we will bring BGP back up... > > > R7#sh ip bgp ipv4 multicast > BGP table version is 3, local router ID is 7.7.7.7 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > *> 7.7.7.7/32 0.0.0.0 0 32768 i > *>i8.8.8.8/32 150.100.87.8 0 100 0 i > R7# > R7# > R7# > R7#sh ip rpf 8.8.8.8 > RPF information for ? (8.8.8.8) > RPF interface: FastEthernet0/0 > RPF neighbor: ? (150.100.78.8) > RPF route/mask: 8.8.8.8/32 > RPF type: unicast (ospf 1) > RPF recursion count: 0 > Doing distance-preferred lookups across tables > > > And there we have it...OSPF still preferred. Of course this means > that on the other end where we still don't have PIM enabled on Fa0/0 > we will face the original problem of the OSPF path not being > considered. The best I can tell you here Robert is that it is pretty > strange behavior...obviously if we could enable PIM on the > FastEthernet interfaces we wouldn't have to worry about the RPF to > begin with. I did want to show you though that there IS a method to > our madness and those things get put into the books for a reason. > > If anybody else has some light to shed on this little mystery I would > love to hear it. > > > > > > > > > > On Wed, Apr 14, 2010 at 2:44 AM, Joe Astorino <[email protected]> > wrote: > > That is correct -- But that is talking about BGP only. If you only > > had unicast routes in BGP and you had multicast routes in BGP then it > > seems like the multicast is preferred. At that point the AD is the > > same because they are both coming in via BGP. That fits in with rule > > #3 that I posted previously when the AD is the same. If you have > > unicast routes in some other IGP like OSPF in your case, and you have > > multicast information coming in from MP-BGP it seems that the lower AD > > is preferred first by the RPF process. > > > > Of course, that is not what you are seeing but as you can see that is > > what the documentation says. That is also what I have observed in the > > past. It may have to do with how your iBGP is setup there. Could you > > try peering on the s0/0 interface instead of the loopback and see what > > happens? > > > > > > > > > > > > On Wed, Apr 14, 2010 at 1:19 AM, Robert Simmons <[email protected]> > wrote: > >> Hey Joe, Thanks for the quick response. Am I mis-understanding this > link: > >> > http://www.cisco.com/en/US/docs/ios/12_4t/ip_route/configuration/guide/tbrbover.html > >> Under the "Multiprotocol BGP Extensions for IP Multicast" paragraph > >> A multicast routing protocol, such as PIM, uses both the multicast and > >> unicast BGP database to source the route, perform Reverse Path > Forwarding > >> (RPF) lookups for multicast-capable sources, and build a multicast > >> distribution tree (MDT). The multicast table is the primary source for > the > >> router, but if the route is not found in the multicast table then the > >> unicast table is searched. Although multicast can be performed with > unicast > >> BGP, multicast BGP routes allow an alternative topology to be used for > RPF. > >> Thanks > >> -Rob > >> On Apr 14, 2010, at 12:55 AM, Joe Astorino wrote: > >> > >> Also, notice how "sh ip rpf" talks about distance-preferred lookups. > >> Check out the following from this Cisco doc: > >> > http://cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094b55.shtml > >> > >> Cisco IOS® calculates the RPF interface in this way. Possible sources > >> of RPF information are Unicast Routing Table, MBGP routing table, > >> DVMRP routing table and Static Mroute table. When you calculate the > >> RPF interface, primarily administrative distance is used to determine > >> exactly which source of information the RPF calculation is based on. > >> The specific rules are: > >> > >> All preceding sources of RPF data are searched for a match on > >> the source IP address. When using Shared Trees, the RP address is used > >> instead of the source address. > >> > >> If more than one matching route is found, the route with the > >> lowest administrative distance is used. > >> > >> If the admin distances are equal, then this order of preference is > >> used: > >> 1. Static mroutes > >> 2. DVMRP routes > >> 3. MBGP routes > >> 4. Unicast routes > >> > >> If multiple entries for a route occur within the same route > >> table, the longest match route is used. > >> > >> > >> On Wed, Apr 14, 2010 at 12:49 AM, Joe Astorino <[email protected]> > >> wrote: > >> > >> Nice job on the testing. I think it may have to do with the fact that > >> > >> you changed the next-hop manually there with your route-map. I'd be > >> > >> interested to see what things look like without that change. In > >> > >> testing I have done in the past to get the results I explained I had a > >> > >> slightly different setup > >> > >> 1) My iBGP peers were not between loopback addresses but on the > >> > >> physical addresses of the PIM enabled link > >> > >> 2) I was not changing the next-hop of the multicast networks in BGP > >> > >> > >> > >> On Wed, Apr 14, 2010 at 12:06 AM, Robert Simmons <[email protected]> > wrote: > >> > >> Joe, > >> > >> I mocked up the following quick scenario: > >> > >> <-------------Non Pim Enabled FastE Link-------------> > >> > >> R7 > >> R8 > >> > >> <-----------------Pim Enabled Serial Link-------------> > >> > >> - OSPF enabled on both links and loopback 0 > >> > >> - FastE link is preferred > >> > >> - R8 is RP/BSR router > >> > >> - R7/R8 has igmp join on both loopback0 interfaces > >> > >> In this configuration the routers are unable to ping each others mcast > IP > >> addresses, which is correct behavior due to RPF issue > >> > >> Added the following: > >> > >> -MBGP (I) configuration between R7 & R8 > >> > >> -Set next-hop IP address for loopback to the Serial Link > >> > >> In this configuration the RPF has been corrected. I'm able to ping mcast > >> interfaces from both routers. > >> > >> Since this BGP configuration is iBGP and not eBGP this again leads me to > >> believe that the multicast BGP table is looked at first and then the > unicast > >> table. > >> > >> Configs are below: > >> > >> > >> ***********R7************** > >> > >> hostname R7 > >> > >> ! > >> > >> ip multicast-routing > >> > >> ! > >> > >> interface Loopback0 > >> > >> ip address 7.7.7.7 255.255.255.255 > >> > >> ip pim sparse-mode > >> > >> ip igmp join-group 225.0.0.7 > >> > >> ! > >> > >> interface Serial0/0 > >> > >> ip address 150.100.87.7 255.255.255.0 > >> > >> ip pim sparse-mode > >> > >> encapsulation ppp > >> > >> clock rate 2000000 > >> > >> ! > >> > >> ! > >> > >> interface FastEthernet2/0 > >> > >> ip address 150.100.78.7 255.255.255.0 > >> > >> speed 100 > >> > >> full-duplex > >> > >> ! > >> > >> router ospf 1 > >> > >> log-adjacency-changes > >> > >> network 7.7.7.7 0.0.0.0 area 0 > >> > >> network 150.100.78.7 0.0.0.0 area 0 > >> > >> network 150.100.87.7 0.0.0.0 area 0 > >> > >> ! > >> > >> router bgp 78 > >> > >> no bgp default ipv4-unicast > >> > >> bgp log-neighbor-changes > >> > >> neighbor 8.8.8.8 remote-as 78 > >> > >> neighbor 8.8.8.8 update-source Loopback0 > >> > >> ! > >> > >> address-family ipv4 multicast > >> > >> neighbor 8.8.8.8 activate > >> > >> neighbor 8.8.8.8 route-map MCAST in > >> > >> no auto-summary > >> > >> no synchronization > >> > >> network 7.7.7.7 mask 255.255.255.255 > >> > >> exit-address-family > >> > >> ! > >> > >> ! > >> > >> route-map MCAST permit 10 > >> > >> set ip next-hop 150.100.87.8 > >> > >> ! > >> > >> R7#show ip route > >> > >> 7.0.0.0/32 is subnetted, 1 subnets > >> > >> C 7.7.7.7 is directly connected, Loopback0 > >> > >> 8.0.0.0/32 is subnetted, 1 subnets > >> > >> O 8.8.8.8 [110/2] via 150.100.78.8, 00:46:22, FastEthernet2/0 > >> > >> 150.100.0.0/16 is variably subnetted, 7 subnets, 2 masks > >> > >> O 150.100.108.0/24 [110/2] via 150.100.78.8, 00:46:22, > FastEthernet2/0 > >> > >> C 150.100.87.0/24 is directly connected, Serial0/0 > >> > >> C 150.100.87.8/32 is directly connected, Serial0/0 > >> > >> C 150.100.78.0/24 is directly connected, FastEthernet2/0 > >> > >> ! > >> > >> R7#show ip bgp ipv4 multicast > >> > >> BGP table version is 3, local router ID is 7.7.7.7 > >> > >> Status codes: s suppressed, d damped, h history, * valid, > best, i - > >> internal, > >> > >> r RIB-failure, S Stale > >> > >> Origin codes: i - IGP, e - EGP, ? - incomplete > >> > >> Network Next Hop Metric LocPrf Weight Path > >> > >> *> 7.7.7.7/32 0.0.0.0 0 32768 i > >> > >> *>i8.8.8.8/32 150.100.87.8 0 100 0 i > >> > >> ! > >> > >> R7#show ip rpf 8.8.8.8 > >> > >> RPF information for ? (8.8.8.8) > >> > >> RPF interface: Serial0/0 > >> > >> RPF neighbor: ? (150.100.87.8) > >> > >> RPF route/mask: 8.8.8.8/32 > >> > >> RPF type: mbgp > >> > >> RPF recursion count: 0 > >> > >> Doing distance-preferred lookups across tables > >> > >> > >> > >> ***********R8************** > >> > >> ! > >> > >> hostname R8 > >> > >> ! > >> > >> ip multicast-routing > >> > >> ! > >> > >> ! > >> > >> interface Loopback0 > >> > >> ip address 8.8.8.8 255.255.255.255 > >> > >> ip pim sparse-mode > >> > >> ! > >> > >> interface FastEthernet0/0 > >> > >> ip address 150.100.78.8 255.255.255.0 > >> > >> speed 100 > >> > >> full-duplex > >> > >> ! > >> > >> interface Serial0/0 > >> > >> ip address 150.100.87.8 255.255.255.0 > >> > >> ip pim sparse-mode > >> > >> encapsulation ppp > >> > >> ip igmp join-group 225.0.0.8 > >> > >> clock rate 2000000 > >> > >> ! > >> > >> ! > >> > >> router ospf 1 > >> > >> log-adjacency-changes > >> > >> network 0.0.0.0 255.255.255.255 area 0 > >> > >> ! > >> > >> router bgp 78 > >> > >> no bgp default ipv4-unicast > >> > >> bgp log-neighbor-changes > >> > >> neighbor 7.7.7.7 remote-as 78 > >> > >> neighbor 7.7.7.7 update-source Loopback0 > >> > >> ! > >> > >> address-family ipv4 multicast > >> > >> neighbor 7.7.7.7 activate > >> > >> neighbor 7.7.7.7 route-map MCAST in > >> > >> no auto-summary > >> > >> no synchronization > >> > >> network 8.8.8.8 mask 255.255.255.255 > >> > >> exit-address-family > >> > >> ! > >> > >> ip pim bsr-candidate Loopback0 10 > >> > >> ip pim rp-candidate Loopback0 > >> > >> ! > >> > >> route-map MCAST permit 10 > >> > >> set ip next-hop 150.100.87.7 > >> > >> ! > >> > >> R8#show ip route > >> > >> 7.0.0.0/32 is subnetted, 1 subnets > >> > >> O 7.7.7.7 [110/2] via 150.100.78.7, 00:53:22, FastEthernet0/0 > >> > >> 8.0.0.0/32 is subnetted, 1 subnets > >> > >> C 8.8.8.8 is directly connected, Loopback0 > >> > >> 150.100.0.0/16 is variably subnetted, 4 subnets, 2 masks > >> > >> C 150.100.87.7/32 is directly connected, Serial0/0 > >> > >> C 150.100.87.0/24 is directly connected, Serial0/0 > >> > >> C 150.100.78.0/24 is directly connected, FastEthernet0/0 > >> > >> ! > >> > >> R8#show ip rpf 7.7.7.7 > >> > >> RPF information for ? (7.7.7.7) > >> > >> RPF interface: Serial0/0 > >> > >> RPF neighbor: ? (150.100.87.7) > >> > >> RPF route/mask: 7.7.7.7/32 > >> > >> RPF type: mbgp > >> > >> RPF recursion count: 0 > >> > >> Doing distance-preferred lookups across tables > >> > >> > >> > >> On Apr 13, 2010, at 10:58 PM, Joe Astorino wrote: > >> > >> If it is eBGP you are fine. If it is iBGP the rpf will still prefer the > >> unicast routing table. My suggestion is that you play with both while > >> running "sh ip rpf" > >> > >> > >> ------Original Message------ > >> > >> From: Robert Simmons > >> > >> Sender: [email protected] > >> > >> To: CCIE OSL > >> > >> Subject: [OSL | CCIE_RS] Lab 5 Volume 3 > >> > >> Sent: Apr 13, 2010 3:56 PM > >> > >> IPExperts, > >> > >> I was working on Troubleshooting Ticket No. 4 (Multicast in AS25) and I > was > >> able to make it work but, when I looked at the DSG I noticed that you > guys > >> added the "distance bgp 20 20 20" command to the multicast address > family. > >> The solution guide says this was done because RPF lookup is still > dependent > >> on AD but, I thought the way RPF worked was that it looked at the > multicast > >> BGP database first and then the unicast table. Since you are modifying > the > >> route's next-hop via MBGP route-map (pointing it to the sparse enabled > >> interface) my thoughts are you wouldn't need to lower the MBGP AD. > >> > >> Am I missing something here? > >> > >> Thanks > >> > >> -Rob > >> > >> _______________________________________________ > >> > >> For more information regarding industry leading CCIE Lab training, > please > >> visit www.ipexpert.com > >> > >> > >> Sent from my Verizon Wireless BlackBerry > >> > >> Regards, > >> > >> Joe Astorino - CCIE #24347 > >> > >> Sr. Technical Instructor - IPexpert > >> > >> Mailto: [email protected] > >> > >> Telephone: +1.810.326.1444 > >> > >> Live Assistance, Please visit: www.ipexpert.com/chat > >> > >> eFax: +1.810.454.0130 > >> > >> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, > >> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco > >> CCIE (R&S, Voice, Security & Service Provider) certification(s) with > >> training locations throughout the United States, Europe, South Asia and > >> Australia. Be sure to visit our online communities at > >> www.ipexpert.com/communities and our public website at www.ipexpert.com > >> > >> > >> > >> > >> > >> -- > >> > >> Regards, > >> > >> > >> > >> Joe Astorino - CCIE #24347 > >> > >> Sr. Technical Instructor - IPexpert > >> > >> Mailto: [email protected] > >> > >> Telephone: +1.810.326.1444 > >> > >> Live Assistance, Please visit: www.ipexpert.com/chat > >> > >> eFax: +1.810.454.0130 > >> > >> IPexpert is a premier provider of Self-Study Workbooks, Video on > >> > >> Demand, Audio Tools, Online Hardware Rental and Classroom Training for > >> > >> the Cisco CCIE (R&S, Voice, Security & Service Provider) > >> > >> certification(s) with training locations throughout the United States, > >> > >> Europe, South Asia and Australia. Be sure to visit our online > >> > >> communities at www.ipexpert.com/communities and our public website at > >> > >> www.ipexpert.com > >> > >> > >> > >> > >> -- > >> Regards, > >> > >> > >> > >> Joe Astorino - CCIE #24347 > >> Sr. Technical Instructor - IPexpert > >> Mailto: [email protected] > >> Telephone: +1.810.326.1444 > >> Live Assistance, Please visit: www.ipexpert.com/chat > >> eFax: +1.810.454.0130 > >> > >> IPexpert is a premier provider of Self-Study Workbooks, Video on > >> Demand, Audio Tools, Online Hardware Rental and Classroom Training for > >> the Cisco CCIE (R&S, Voice, Security & Service Provider) > >> certification(s) with training locations throughout the United States, > >> Europe, South Asia and Australia. Be sure to visit our online > >> communities at www.ipexpert.com/communities and our public website at > >> www.ipexpert.com > >> > >> > > > > > > > > -- > > Regards, > > > > > > > > Joe Astorino - CCIE #24347 > > Sr. Technical Instructor - IPexpert > > Mailto: [email protected] > > Telephone: +1.810.326.1444 > > Live Assistance, Please visit: www.ipexpert.com/chat > > eFax: +1.810.454.0130 > > > > IPexpert is a premier provider of Self-Study Workbooks, Video on > > Demand, Audio Tools, Online Hardware Rental and Classroom Training for > > the Cisco CCIE (R&S, Voice, Security & Service Provider) > > certification(s) with training locations throughout the United States, > > Europe, South Asia and Australia. Be sure to visit our online > > communities at www.ipexpert.com/communities and our public website at > > www.ipexpert.com > > > > > > -- > Regards, > > > > Joe Astorino - CCIE #24347 > Sr. Technical Instructor - IPexpert > Mailto: [email protected] > Telephone: +1.810.326.1444 > Live Assistance, Please visit: www.ipexpert.com/chat > eFax: +1.810.454.0130 > > IPexpert is a premier provider of Self-Study Workbooks, Video on > Demand, Audio Tools, Online Hardware Rental and Classroom Training for > the Cisco CCIE (R&S, Voice, Security & Service Provider) > certification(s) with training locations throughout the United States, > Europe, South Asia and Australia. Be sure to visit our online > communities at www.ipexpert.com/communities and our public website at > www.ipexpert.com >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
