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