Cool, then looks like we have learned something new today : ) On Wed, Apr 14, 2010 at 12:24 PM, Rob Simmons <[email protected]> wrote: > Yes, that was my original concern. I was able to get the scenario working > and when I went back and looked at the DSG, I saw it referenced the > "distance" command, which I didn't use and I was trying to understand why. > > Sent from my iPhone > > On Apr 14, 2010, at 12:17 PM, Joe Astorino <[email protected]> wrote: > >> Based on our findings today I would agree with you. Did you try it? >> I would, but my rack is unavailable for that at the moment. I would >> also like to get Marko's input on this since he is the author of that >> particular question. Typically, things like that (changing the AD) >> get introduced into the lab because we found while writing it that it >> would not work otherwise, but I could be wrong. Marko is teaching a >> class this week, but I'll forward this to him and see if he has any >> memory of this specific issue. >> >> >> >> >> On Wed, Apr 14, 2010 at 12:10 PM, Rob <[email protected]> wrote: >>> >>> So, back to my original question. It looks like you would not need to add >>> the "distance bgp 20 20 20" command for this particular scenario since, >>> you >>> only have the one Pim enabled path? >>> >>> On Wed, Apr 14, 2010 at 12:04 PM, Joe Astorino <[email protected]> >>> wrote: >>>> >>>> That is pretty much the conclusion I came up with in testing -- since >>>> the RPF mechanism was never even considering the IGP learned route, >>>> there was never a decision to be made between anything. There was >>>> only 1 valid choice so that is what was used. Once there was more >>>> than one valid choice (upon enabling PIM) for RPF information, the AD >>>> was used as the first tie-breaker. If the AD is the same (like say >>>> you are JUST running BGP and have unicast BGP routes and multicast BGP >>>> routes) then it seems multicast BGP table is preferred (according to >>>> the rules I posted earlier) >>>> >>>> I hope that helps >>>> >>>> >>>> >>>> On Wed, Apr 14, 2010 at 11:52 AM, Rob <[email protected]> wrote: >>>>> >>>>> Joe, >>>>> >>>>> I really hate to keep beating this to the ground but.... >>>>> >>>>> Is it possible that the RPF multicast rules that you forwarded to me >>>>> only >>>>> apply to "Pim Enabled" interfaces. Meaning since the fastethernet link >>>>> is >>>>> not enabled, routes (unicast) sourcing from it are not evaluated? >>>>> >>>>> When I look at the show ip rpf command, one of the fields I notice is >>>>> the >>>>> RPF neighbor, which leads me to believe that you would need to have a >>>>> neighbor relationship (meaning you would need to have Pim enabled on >>>>> both >>>>> ends). >>>>> >>>>> Let me know, if I'm looking at this the wrong way >>>>> >>>>> Thanks >>>>> >>>>> On Wed, Apr 14, 2010 at 10:06 AM, Joe Astorino <[email protected]> >>>>> wrote: >>>>>> >>>>>> For sure Rob! One of the biggest parts of becoming a CCIE is this -- >>>>>> questioning everything, and being unwilling to accept an answer until >>>>>> you >>>>>> understand it. That is the right attitude and one we appreciate from >>>>>> students who are hungry : ) >>>>>> >>>>>> 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 >>>>>> >>>>>> ________________________________ >>>>>> From: Rob <[email protected]> >>>>>> Date: Wed, 14 Apr 2010 09:51:35 -0400 >>>>>> To: Joe Astorino<[email protected]> >>>>>> Cc: <[email protected]>; CCIE >>>>>> OSL<[email protected]> >>>>>> Subject: Re: [OSL | CCIE_RS] Lab 5 Volume 3 >>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> 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
