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 _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
