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
