Task 2.2 Route tagging on R3 and R5

What is the reason to use route tagging on R3 and R5?  I really don't see a routing loop in the topology, (I might be wrong), in addition, the sub-optimize routing is resolved by the distance command configured on R3 and R5. 

So, Is it a good practice or route tagging is needed for this task?  Comments?

Comments

  • I feel the same way here man. I don't see any loop either between R3 and R5; I guess we just say good practice to prevent any suprise in case a route enter the EIGRP domain as external.

     

    mainDor

  • Hi Guys! I dont know how you cant see it! the loop happens when the native OSPF routes get redistributed into EIGRP and come back to the OSPF domain by means of EIGRP-to-OSPF redistribution by the other router. Imagine the following scenario:

    a native OSPF route is redistributed by R3 to EIGRP and this route then is redistributed from EIGRP to OSPF at R5 before R5 gets the chance to learn it as native OSPF route, this will cause a loop as R5 will start advertising reachibility for this native OSPF route via the EIGRP domain.

    I dont see why route tagging is needed though, i just feel that AD manipulation for this task is enough, my configuration doesnt use tags and it works fine.

    It is a good practice anyway, it makes sure no loops can occur.

  • Native OSPF routes will be injected into EIGRP as external routes with AD 170 therefore they won't be redistributed back into OSPF because you can only redistribute what you use (and in this case you use the native OSPF).

    You will have this problem if R5 would have redistributed into a third protocol that will be injected into OSPF or, as you said, if R5 learns the EIGRP route before the OSPF one - however, as soon as R5 learns the OSPF route with AD110 it will stop using EIGRP external and redistribute the OSPF route into EIGRP.

    I would not start redistributing IGPs before the "to-be-redistributed" domains routing tables are not stable...

    In any case, IMHO route tagging is always a good practice because it does not make any sense to inject into a routing domain what you know for sure it was originated into that domain.

    For this particular task I only used AD manipulation as you did.

  • Spot on Soul! Thanks for your helpful comments, do you mind me asking you what is "IMHO" you are refering to? :)

     

  • It just means "In my humble opinion" :)

  • You will have this problem if R5 would have redistributed into a third protocol that will be injected into OSPF or, as you said, if R5 learns the EIGRP route before the OSPF one - however, as soon as R5 learns the OSPF route with AD110 it will stop using EIGRP external and redistribute the OSPF route into EIGRP.

    I did the same by changing the OSPF external AD to 171 on R3 and R5.  The reason it's needed is because R5 loopback is redistributed into EIGRP and would loopback via either R3 and R5 if the distance wasn't changed.

    There are no constraints on the task that prevents this being a valid solution.

     

     

     

  • There is a route-map over R5 and mapped with redistribution as following:

     

    route-map CONNECTED->OSPF permit 10
     match interface Loopback0
     set metric 20
     set metric-type type-2

     

    router ospf 1
     router-id 150.1.5.5
     log-adjacency-changes
     redistribute connected subnets route-map CONNECTED->OSPF

     

    My confusiton is that if we leave this map as it is it won't allow EIGRP redistributes routes to come in. So we need to match interface Serial1/0 FastEthernet0/0 FastEthernet0/1 to allow EIGRP into OSPF via R5.

     

    Please correct me if i am wrong ?

  • Guys don't match the interface serial 1/0 i had loops in my network [:P]

  • Most importantly, did you understand why loops created?

    Good luck with your studies!

  • Most importantly, did you understand why loops created?

    This is certainly a very open ended question - as there is more than one type of loop cause by redistribution.

    Let's keep this simple a routing loop is caused when -

    • mutual distribution between multiple routing protocols so that the original protocol learns native routes via another protocol.  In these situation metric information is lost - as each protocol uses a different metric.
    • On the redistributing router (or any router running multiple routing protocols) the protocol with the lowest AD is preferred.
    • Most routing protocols do not adequately differentiate between internal (or native) and external (or redistributed) routes using AD in their default configuration although EIGRP is an exception.
    • This can mean that the non native route can be preferred over the native route causing sub optimal routing, or a routing loop.

    There are some exceptions to this were you can see route oscillation where there is only one redistribution point between routing protocols but both protocols meet on another router as "ships in the night".  Of particular concern here is EIGRP and RIP and the requirement that a route must be in the routing table before it can be redistributed! Say the "ships in the night" router is running RIP/OSPF while the other router is redistributing between these protocols. Then the following will happen -

    1. A route in the RIP domain beyond the "ships in the night" router is redistributed into OSPF with an AD 110
    2. This route is learned by the "ships in the night" router which then installs this router via OSPF.  The AD is better for OSPF.
    3. The "ships in the night" router cannot advertise this route via RIP - as it's not in the routing table!
    4. This means that the route will be removed on the redistributing router
    5. So the route can't be redistributed into OSPF.
    6. This means that "ships in the night" router will remove the OSPF route allowing the RIP route to appear - after all the route would alway be in the RIP database.
    7. The whole process repeats again.

    This type of oscillation is prevalent in RIP and EIGRP which are effectively distance vector based routing protocols unlike OSPF which is link state based.

    You have to be aware of the above scenario even if you are redistributing on a single router within a domain. 

    The only way to solve this type of problem is by decreasing/increasing the default AD for the routing protocols to ensure that native routes are preferred over external ones.

     

     

  • Note:  This "loop" only reproduces based on order of operation/routing protocol coming up.  Mine broke when I did a mass-reload of all devices prior to finishing and running my ping scripts.  Otherwise, an item like this is quite hard to find.

    On the other hand, the AD modification for external routes alone is enough, because in this case, the mutually redistributed routes are always external ones.

  • Hi all,

    I got stuck on the issue that Mani asked about.

    There is preconfigured redistribution of R5's Loopback to OSPF by using route-map CONNECTED->OSPF.

    Iif we do as SG suggests:

    [code]<br />router ospf 1
     redistribute eigrp 10 subnets route-map EIGRP_TO_OSPF 
     distance 171 0.0.0.0 255.255.255.255 R3_R6_LOOPBACKS<br />[/code]<br /><br />

      the EIGRP prefixes 56.0/24 and 5.0/24 which are directly connected will NOT get redistributed.

    Personally I would modify CONNECTED->OSPF route-map to get this done.

    Any thoughts?

  • Martin,

    Not really sure what you would want to modify to achieve the same. Can you please be more specific?

    As other guys mentioned above, I think there is no chance of loop in this scenario since the OSPF AD for R6's loopback has been changed to 171 on R3 & R5. So, AD prevents the external routes from being looped between these two routing protocols. 

    Thanks,

  • Hi Hari,

     

    Thanks for your reply. My concern is not about loop, but reachability of VLAN56 and VLAN5 in the OSPF routing domain.

    Maybe I'm missing something, but IMHO the solution in the SG is incomplete.

    Initial configs include redistribution of R5's loopback into OSPF domain by means of 'redistribute connected route-map CONNECTED->OSPF' under R5's OSPF process.

    Now, according to task requirements, we must redistribute EIGRP to OSPF on R5, right? 

    But configuring 'redistribute eigrp' under R5's OSPF process isn't enough, because 'redistribute connected' provided by the initial configs will take precedence over 'redistribute eigrp' and VLAN56 / VLAN5 prefixes will not be redistributed. R6 loopback will be redistributed because it is not a connected interfece.

    To achieve what we need, we would need to modify CONNECTED->OSPF route-map on R5 and include Fa0/1 and Fa0/0 interfaces.

    Does this make sense now or should I try again? :)

     

Sign In or Register to comment.