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