> 
> Got it. I think i just read about a similar thing EIGRP does that for loop 
> prevention it inserts it's router-id with external routes. Makes sense.
> 
> So normally you would use the distance command with the ip address you are 
> getting the routes from (say a neighbor) and manipulate the distance (to 
> prevent routes getting into the routing table), but when working with 
> external routes you have to refer to the router-id.
> 
> Thanks Derek.
> On Jul 27, 2011, at 7:19 PM, Mills, Derek wrote:
> 
>> It's kind of deceiving on which IP you specify in the distance command using 
>> an ACL with OSPF. It is not based on the next-hop but rather what the ID of 
>> the router that injected that route into the area. So, on R5 distance is 
>> applied to R6 router-id, and vice versa on R6. If on R5 you issue show route 
>> 10.0.0.35 R6's ID should show up (not as next-hop but I forget exactly how 
>> it is listed). That is how I figure out what IP to use in these type of 
>> distance commands. 
>> 
>> So therefore, the fact that it is coming through R2 doesn't matter...it is 
>> all about which router is injecting the route into the area. 
>> 
>> As you stated, the whole thing could have been avoided by not redistributing 
>> on R5. I read somewhere that this is a major trap on CCIE lab. Purposefully 
>> designed to let the student create their own problems when it was not 
>> necessary, as per the task, to redistribute on both R5 and R6. 
>> 
>> Derek 
>> 
>> 
>> -----Original Message-----
>> From: Alef [mailto:[email protected]] 
>> Sent: Wednesday, July 27, 2011 1:03 PM
>> To: Mills, Derek
>> Subject: Re: [OSL | CCIE_RS] Vol2, Lab8, Task 3.9 - Conflicting LSAID and 
>> distance manipulation
>> 
>> Hey Derek,
>> No, you're right on target. Thanks, that explains it. 
>> I still don't understand why the distance is applied on R5 for R6 and vice 
>> versa. Also, should it not be applied to R2 on both R5 and R6 as well ?
>> 
>> Alef
>> On Jul 27, 2011, at 6:47 PM, Mills, Derek wrote:
>> 
>>> First of all I am not sure why the DSG shows redistribution from EIGRP on 
>>> both R6 and R5 since the task states "Redistribute as needed..." without a 
>>> requirement that if R5 or R6 goes down all IGP routes must still be 
>>> available. Perhaps such a requirement is stated somewhere else.
>>> 
>>> But, onto your question...
>>> 
>>> I assume the 10.0.0.35, 10.0.0.36, and 10.0.0.38 routes are redistributed 
>>> into EIGRP AS 1 somewhere south of R6 since they are AS 170 at R6. If you 
>>> follow the redistribution upstream taking the route R6 EIGRP --> R5 EIGRP 
>>> --> R2 OSPF these routes end back at R6 as -- yes E2 routes but more 
>>> importantly as AD 110. When R6 hears these routes advertised as OSPF AD 110 
>>> it removes the EIGRP routes with 170 from the routing table. Since those 
>>> routes are not in the routing table any more, R6 tells R5 to withdraw those 
>>> routes via EIGRP. So now R5 does not redistribute into OSPF. So now R6 no 
>>> longer gets an OSPF route for the 10.0.0.x routes and removes the OSPF 
>>> routes. As such, R6 notices that it has EIGRP routes with AD 170 in the 
>>> EIGRP topology table and adds them to the routing table. Wow, new EIGRP 
>>> routes in the routing table so R6 advertises them to R5 and the whole thing 
>>> starts over. 
>>> 
>>> The key takeaway here is that with EIGRP, unlike OSPF, if the route is not 
>>> in the routing table it will not be advertised to EIGRP neighbors. Same 
>>> with RIP. 
>>> 
>>> Maybe I was way off on your question but hopefully this helps. 
>>> 
>>> 
>>> Derek
>>> 
>>> 
>>> -----Original Message-----
>>> From: [email protected] 
>>> [mailto:[email protected]] On Behalf Of Alef
>>> Sent: Wednesday, July 27, 2011 7:07 AM
>>> To: [email protected] IE
>>> Subject: [OSL | CCIE_RS] Vol2, Lab8, Task 3.9 - Conflicting LSAID and 
>>> distance manipulation
>>> 
>>> 3.9 
>>> 
>>> I wondered if the following message from OSPF on Cat4 had anything to do 
>>> with the /31 mask on the link between R6 and R9 and if it was merely a 
>>> informational message or actually botched up something.
>>> 
>>> Jul 27 10:13:11.407: %OSPF-4-CONFLICTING_LSAID: LSA origination prevented 
>>> by existing LSA with same LSID but a different mask
>>> Existing Type 5 LSA: LSID 172.30.96.0/31
>>> New Destination: 172.30.96.0/32
>>> 
>>> But the biggest issue i have is that i don't understand why we have to 
>>> apply the distance command. When RIP routes are being redistributed into 
>>> OSPF on R2, they are OSPF E2 external. Fine. When OSPF from Area 124 is 
>>> being redistributed into EIGRP AS 1 they are being external routes 170. 
>>> Also fine. Then EIGRP is being redistributed into R6 again, making these 
>>> also OSPF E2 routes. Why do we need to manipulate anything, as the routes 
>>> clearly comes from different distribution points (i.e route sources). For 
>>> some reason they all are originated from R2. I can clearly see it works, i 
>>> just don't understand how.
>>> 
>>> Not working and without applied distance on R6:
>>> IPeR6(config-router)#do sh ip route | i 10.0.0.3[586]
>>> O E2    10.0.0.35/32 [110/20] via 172.30.100.2, 00:00:08, Serial0/1/0
>>> O E2    10.0.0.38/32 [110/20] via 172.30.100.2, 00:00:08, Serial0/1/0
>>> O E2    10.0.0.36/32 [110/20] via 172.30.100.2, 00:00:08, Serial0/1/0
>>> IPeR6(config-router)#distance 171 10.0.0.5 0.0.0.0 2   
>>> 
>>> Working and with applied distance 171 to neighbor R5:
>>> IPeR6(config-router)#do sh ip route | i 10.0.0.3[586]
>>> D EX    10.0.0.35/32 [170/3417088] via 172.30.96.1, 00:00:02, Multilink1
>>> D EX    10.0.0.38/32 [170/3417088] via 172.30.96.1, 00:00:02, Multilink1
>>> D EX    10.0.0.36/32 [170/3417088] via 172.30.96.1, 00:00:02, Multilink1
>>> 
>>> Any help would be greatly appreciated in making me understand this.
>>> Regards,
>>> Alef
>>> _______________________________________________
>>> For more information regarding industry leading CCIE Lab training, please 
>>> visit www.ipexpert.com
>>> 
>>> Are you a CCNP or CCIE and looking for a job? Check out 
>>> www.PlatinumPlacement.com
>> 
> 

_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Are you a CCNP or CCIE and looking for a job? Check out 
www.PlatinumPlacement.com

Reply via email to