4.11 Redistribution and Loop Prevention

Can someone explain why SW1 needs to lower distance on RIP?  I don't see any other boundary router between this RIP domain and the OSPF domain.  My lab session is fixing to end, so I may try to lab this up again and see how router going from RIP-> OSPF can go back to RIP on the same router that redistributed it.

Thanks, Jains

Comments

  • Hi

    If/when the link between R1 and BB3 flaps, SW1 will now know all the RIP prefixes (30.0.0.0/16 to 30.3.0.0/16 & 31.0.0.0/16 to 31.3.0.0/16) originated in BB3  from R3 as O E2 with the AD of 110.  This is due to mutual redistribution between EIGRP and OSPF on R1 and R2, which essentially kept these prefixes "alive" and looping between these routers and fed back to R3 and then SW1 when VLAN 73 link is down.  When this link is restored, SW1 will learn these RIP prefixes from BB3 again, but will not install in the routing table due to RIP's AD is 120 which is higher than OSPF's 110.  When you ping these prefixes, they will be unreachable.  When you do a trace, you will see, instead of going to BB3, it would loop between R3, and R1/R2.

    HTH,

  • Do we have to consider the flap to BB3 ? When did we do that in the other labs or where did IE asked it?

     

  • No, you don't have to consider BB3 flapping or was it part of any requirement. 

    I discovered this accidentally.  There was no longer full IP reachability after rebooting, so I tried to troubleshoot to fix the issue.  Then I was able to replicate the cause of the issue to test my understanding.

    This was very similar to Vol.3-Lab2 in a way.  If R2's s0/0 was to flap, there will be intermittent IP reachability to R1's L0 and VLAN 10.

  • This solution leaves something to be desired IMO.

    First, I get why we set the distance for RIP on SW1 to 109. When the routes from BB3 get redistributed into OSPF and sent to R3 and then R1&R2, the redistribution with EIGRP will cause R1 or R2 to install the routes as an EIGRP route (AD 170 vs. Our OSPF external AD of 171). These routes then get sent back to R3 which then sends them back to SW1 as OSPF E2 routes. SW1 sees the routes as having AD 110. This is lower than the RIP routes so SW1 installs the OSPF routes. Setting RIP AD to 109 prevents the route "feedback" from R3 from being installed.

    This still doesn't change the fact that R1 and R2 are redistributing into EIGRP and that R1 or R2 will be feeding those routes back to R3. Subiptimal routing is still occuring here. and so is a loop.

    I'm going to pick on 30.1.0.0 here.

    Let's look at the route on all 4 devices:

    SW1:

    Routing entry for 30.1.0.0/16
      Known via "rip", distance 109, metric 1
      Redistributing via ospf 1, rip
      Advertised by ospf 1 subnets
      Last update from 204.12.1.254 on Vlan73, 00:00:01 ago
      Routing Descriptor Blocks:
      * 204.12.1.254, from 204.12.1.254, 00:00:01 ago, via Vlan73
          Route metric is 1, traffic share count is 1

    Good here. Points to BB3

    R3:

    Routing entry for 30.1.0.0/16
      Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
      Last update from 152.1.37.7 on Ethernet0/0, 00:01:33 ago
      Routing Descriptor Blocks:
      * 152.1.37.7, from 150.1.7.7, 00:01:33 ago, via Ethernet0/0
          Route metric is 20, traffic share count is 1

    Good here points to SW1

    R1:

    Routing entry for 30.1.0.0/16
      Known via "ospf 1", distance 171, metric 20, type extern 2, forward metric 74
      Redistributing via eigrp 10
      Advertised by eigrp 10 metric 1 1 1 1 1
      Last update from 152.1.123.3 on Serial0/0.123, 00:02:34 ago
      Routing Descriptor Blocks:
      * 152.1.123.3, from 150.1.7.7, 00:02:34 ago, via Serial0/0.123
          Route metric is 20, traffic share count is 1

    OK. Looks good. Points to R3

    R2:

      Known via "eigrp 10", distance 170, metric 2560002816, type external
      Redistributing via eigrp 10, ospf 1
      Advertised by ospf 1 subnets
      Last update from 152.1.125.1 on FastEthernet0/0, 00:17:59 ago
      Routing Descriptor Blocks:
      * 152.1.125.1, from 152.1.125.1, 00:17:59 ago, via FastEthernet0/0
          Route metric is 2560002816, traffic share count is 1
          Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
          Reliability 1/255, minimum MTU 1 bytes
          Loading 1/255, Hops 1

    AHHH. Now we see that R2 is learning the route from R1 via EIGRP. So R2 uses R1 to get to 30.1.0.0. Certainly not optimal as it now includes an extra hop in th e path but we have full reachability so everything is good right?

    Personally, I wouldn't want to leave a network in this state (yeah, yeah, I know "the CCIE lab isn't real world" blah blah)

    Let's look at the ospf database on R3.

    30.1.0.0        150.1.2.2       1399        0x80000001 0x00E6FE 0
    30.1.0.0        150.1.7.7       1448        0x80000001 0x00A536 0

    Well we definitely have two LSAs for that route from SW1 and R2.

    The big question is - What causes R3 to choose to install the route from SW1 over the one from R2. They are both E2. Both with a metric of 20.

    The answer lies in the forward metric which is the routers cost to reach the ASBR. If a router receives two E2 routes to the same prefix it will install the route with the lower forward metric. If they are equal, then we have load balancing.

    So I tried something.

    I increased the cost on E0/0 on R3 as follows:

    Original:

    R3(config-if)#do show ip ospf int e0/0
    Ethernet0/0 is up, line protocol is up
      Internet Address 152.1.37.3/24, Area 37
      Process ID 1, Router ID 150.1.3.3, Network Type BROADCAST, Cost: 10

    New:

    R3(config-if)#do show ip ospf int e0/0
    Ethernet0/0 is up, line protocol is up
      Internet Address 152.1.37.3/24, Area 37
      Process ID 1, Router ID 150.1.3.3, Network Type BROADCAST, Cost: 10000

    Now let's look at the route to 30.1.0.0 on R3:

    R3(config-if)#do show ip route 30.1.0.0
    Routing entry for 30.1.0.0/16
      Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 781
      Last update from 152.1.123.2 on Serial1/0.123, 00:00:29 ago
      Routing Descriptor Blocks:
      * 152.1.123.2, from 150.1.2.2, 00:00:29 ago, via Serial1/0.123
          Route metric is 20, traffic share count is 1

    R3 now says that the route to 30.1.0.0 is through R2. Even after 10 minutes that route is still there

    R3(config-if)#do show ip route 30.1.0.0
    Routing entry for 30.1.0.0/16
      Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 781
      Last update from 152.1.123.2 on Serial1/0.123, 00:10:17 ago
      Routing Descriptor Blocks:
      * 152.1.123.2, from 150.1.2.2, 00:10:17 ago, via Serial1/0.123
          Route metric is 20, traffic share count is 1

    Now we still have a loop. R1 learns the original route from R3 which learned if from SW1. R1 redistributes into EIGRP. R2 receives the external EIGRP route from R1, redistributes into OSPF and sends to R3. Since R2 is now an ASBR for the route, R3 considers the OSPF forward cost from R2 which is lower than the one from SW1. So it installs the route from R2 and doesn't use the route from SW1. Then R3 sends that route with the new forward metric to R1 and the cycle continues, leaving no method of reaching 30.1.0.0 or any of the routes from BB3.

    Ugly is the first word that comes to mind. While setting the RIP AD on SW1 "seems" to solve the original problem there are still other issues here that manipulating AD does not solve.

     

  • Good analysis of the issue!  I agree, and this is something that you could definitely stub your toe on during a real exam.  I try to avoid these loops/race conditions whenever possible.  Because, as you've shown, this could be working, then get broken by something seemingly unrelated, leaving you scrambling to find a problem that was easy to solve in the first place.

    When redistributing into OSPF from RIP (on SW1), I tagged the routes, and then filtered redistribution on R2 (in both directions).  This prevented the route from getting redistributed back into OSPF, and prevented the race condition at the edge of the OSPF domain (is R2 going to route via R1, or vice versa?).  However, it still has the suboptimal routing, where all traffic destined for BB3 will traverse R1 (even traffic from R2).

    I thought this could also be solved using the "distance..." command in EIGRP on R1 and R2.  For example, on R1 specify all routes learned via R2, and set them to a distance of 175.  This would allow for optimal routing, with load sharing and redundancy.  I wasn't able to get this to work.  Is it not possible to change the AD of external EIGRP routes using this command?

     

    - Bobby

  • as we know, routing loop occurs when both R1 & R2 do mutual redistribution between eigrp and ospf.

    what if, to prevent looping between R1 and R2 we set higher AD for each advertisement receive from R1 to R2 or vice versa?.  I assume its not violate the scenario. since IE scenario only mention that we must only use AD to answer this section.


    R1
    --
    !
    router ospf 1
     redistribute eigrp 10 subnets
     network 150.1.1.1 0.0.0.0 area 0
     network 152.1.123.1 0.0.0.0 area 123
     distance 244 150.1.2.2 0.0.0.0 12
    !
    access-list 12 permit any
    !



    R2
    --
    !
    router ospf 1
     redistribute eigrp 10 subnets
     network 150.1.2.2 0.0.0.0 area 0
     network 152.1.123.2 0.0.0.0 area 123
     distance 244 150.1.1.1 0.0.0.0 21
    !
    access-list 21 permit any

    !




    any comment?







  • Bobby,

    "distance eigrp 89 169" under the EIGRP stanza changes the AD to 89 for internal and 169 for external.

    Mike

     

  • Can someone explain why SW1 needs to lower distance on RIP?  I don't see any other boundary router between this RIP domain and the OSPF domain.  My lab session is fixing to end, so I may try to lab this up again and see how router going from RIP-> OSPF can go back to RIP on the same router that redistributed it.

    Thanks, Jains


    Jains,

    Here's what I discovered:

    With OSPF External AD at 171

    If I left the AD at it's default, SW1 learned all of its routes from BB3 via OSPF.

    I power cycled R1 ( my next hop to the BB3 routes from R5's point of view) and everything was great. BB3 routes where learned from RIP on SW1.

    Once R1 came back up, then the BB3 RIP routing problems came back.

    The problem isn't that SW1 believes the OSPF routes that it generates over the RIP routes.

    After all the rules of redist state that all current routing table routes (prior to redist) under a routing protocol will be redistributed as well as any connected routes.

    The problem is that once R3 advertises an external route from the redistribution at R1 and R2 (EXT OSPF AD 171/EXT EIGRP AD 170), SW1 believes the 110 AD from OSPF routes feeding back over the EIGRP domain over 120 AD of RIP. The 109 AD in the SG prevents this from happening.

    Changing the AD at SW1 seems sloppy and tags are probably the best option, but that's how changing the AD at SW1 fixes the problem. Or least that's my theory!

    Mike

     

  • I almost forgot... Once those routes leave the RIP routing table and becomes OSPF routes, then there isn't anymore RIP -> OSPF redist for the 30 and 31 nets. Gone into an infinite loop between R1 and R2!

     

    Can someone explain why SW1 needs to lower distance on RIP?  I don't see any other boundary router between this RIP domain and the OSPF domain.  My lab session is fixing to end, so I may try to lab this up again and see how router going from RIP-> OSPF can go back to RIP on the same router that redistributed it.

    Thanks, Jains


     

    Jains,

    Here's what I discovered:

    With OSPF External AD at 171

    If I left the AD at it's default, SW1 learned all of its routes from BB3 via OSPF.

    I power cycled R1 ( my next hop to the BB3 routes from R5's point of view) and everything was great. BB3 routes where learned from RIP on SW1.

    Once R1 came back up, then the BB3 RIP routing problems came back.

    The problem isn't that SW1 believes the OSPF routes that it generates over the RIP routes.

    After all the rules of redist state that all current routing table routes (prior to redist) under a routing protocol will be redistributed as well as any connected routes.

    The problem is that once R3 advertises an external route from the redistribution at R1 and R2 (EXT OSPF AD 171/EXT EIGRP AD 170), SW1 believes the 110 AD from OSPF routes feeding back over the EIGRP domain over 120 AD of RIP. The 109 AD in the SG prevents this from happening.

    Changing the AD at SW1 seems sloppy and tags are probably the best option, but that's how changing the AD at SW1 fixes the problem. Or least that's my theory!

    Mike

     


  •  

    R2:

      Known via "eigrp 10", distance 170, metric 2560002816, type external
      Redistributing via eigrp 10, ospf 1
      Advertised by ospf 1 subnets
      Last update from 152.1.125.1 on FastEthernet0/0, 00:17:59 ago
      Routing Descriptor Blocks:
      * 152.1.125.1, from 152.1.125.1, 00:17:59 ago, via FastEthernet0/0
          Route metric is 2560002816, traffic share count is 1
          Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
          Reliability 1/255, minimum MTU 1 bytes
          Loading 1/255, Hops 1

     

    Hmm.. R2 points to R3 for that route, for me.

  • Wow, I'm screwed if there is anything like this on the lab...

  • Well you got your number :-)

    Key lesson - make time to reload are of your devices and check reachability.  You want all of your routing protocols to converge to a consistent state - although R1 and R2 this can't be guaranteed.

  • I almost forgot... Once those routes leave the RIP routing table and becomes OSPF routes, then there isn't anymore RIP -> OSPF redist for the 30 and 31 nets. Gone into an infinite loop between R1 and R2!

    There are couple of ways to avoid loops in redistribution scenarios. In this task either set RIP AD to be less then 110 to make RIP route always prefered else tag the RIP routes so that these routes are not feedback from R1 or R2 back to SW1.

  • The solution for this task is all wrong in the SG... It's shame that it's not getting updated for so long time. The simplest solution I can think of to avoid the loop between R1 and R2 for the BB3 routes after the redistribution is to increase teh AD only for the redistributed from EIGRP routes, not for all External OSPF routes as in the SG - redistribute eigrp 10 metric 175 subnets. It seems to be working fine, but does somebody see posible problem with it ?

  • Excellent point. The number is all that matters 

     

  • as we know, routing loop occurs when both R1 & R2 do mutual redistribution between eigrp and ospf.

    what if, to prevent looping between R1 and R2 we set higher AD for each advertisement receive from R1 to R2 or vice versa?.  I assume its not violate the scenario. since IE scenario only mention that we must only use AD to answer this section.


    R1
    --
    !
    router ospf 1
     redistribute eigrp 10 subnets
     network 150.1.1.1 0.0.0.0 area 0
     network 152.1.123.1 0.0.0.0 area 123
     distance 244 150.1.2.2 0.0.0.0 12
    !
    access-list 12 permit any
    !



    R2
    --
    !
    router ospf 1
     redistribute eigrp 10 subnets
     network 150.1.2.2 0.0.0.0 area 0
     network 152.1.123.2 0.0.0.0 area 123
     distance 244 150.1.1.1 0.0.0.0 21
    !
    access-list 21 permit any

    !


    any comment?

     

     

    Funny you mentioned that. I did come up with a similar, but more
    convoluted and perhaps unnecessary solution. The reason for that is the way I
    interpreted the question "Ensure that EIGRP external routes that are
    redistributed into OSPF on R1 and R2..." I thought it only wanted the EIGRP external routes and no internal routes should be involved. So what I did was to go to
    R1/R2 and check which routes were *only* EIGRP external routes.

    RSRack1R2#sh ip route eig | inc EX
    D EX    152.1.5.0/24
    D EX    152.1.4.0/24
    D EX    152.1.45.4/32
    D EX    152.1.45.0/24
    D EX    54.1.10.0 [170/2560002816] via 152.1.125.5, 00:04:58, FastEthernet0/0
    D EX 212.18.1.0/24 [170/2560002816] via 152.1.125.5, 00:04:58, FastEthernet0/0
    D EX 212.18.0.0/24 [170/2560002816] via 152.1.125.5, 00:04:58, FastEthernet0/0
    D EX 212.18.3.0/24 [170/2560002816] via 152.1.125.5, 00:04:58, FastEthernet0/0
    D EX 212.18.2.0/24 [170/2560002816] via 152.1.125.5, 00:04:58, FastEthernet0/0
    D EX    150.1.4.0 [170/2560002816] via 152.1.125.5, 00:04:58, FastEthernet0/0
    D EX    150.1.10.0 [170/2560002816] via 152.1.125.5, 00:04:58, FastEthernet0/0

    then based on this output I created a standard named ACL and used the distance command on R1 and R2.

    !
    ! r1,r2
    !
    conf t
    !
    ip access-list standard EIGRP_EX
     permit 152.1.4.0 0.0.0.255
     permit 152.1.5.0 0.0.0.255
     permit 152.1.45.0 0.0.0.255
     permit 54.1.10.0 0.0.0.255
     permit 212.18.0.0 0.0.3.255
     permit 150.1.4.0 0.0.0.255
     permit 150.1.10.0 0.0.0.255
    !
    router ospf 1
     distance 200 0.0.0.0 255.255.255.255 EIGRP_EX
    !
    end

    RSRack1R2#sh ip prot
    Routing Protocol is "eigrp 10"
      Outgoing update filter list for all interfaces is not set
      Incoming update filter list for all interfaces is not set
      Default networks flagged in outgoing updates
      Default networks accepted from incoming updates
      EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
      EIGRP maximum hopcount 100
      EIGRP maximum metric variance 1
      Redistributing: eigrp 10, ospf 1
      EIGRP NSF-aware route hold timer is 240s
      Automatic network summarization is not in effect
      Maximum path: 4
      Routing for Networks:
        152.1.125.2/32
      Routing Information Sources:
        Gateway         Distance      Last Update
        152.1.125.5           90      00:04:48
        152.1.125.1           90      00:04:48
      Distance: internal 90 external 170

    Routing Protocol is "ospf 1"
      Outgoing update filter list for all interfaces is not set
      Incoming update filter list for all interfaces is not set
      Router ID 150.1.2.2
      It is an area border and autonomous system boundary router
      Redistributing External Routes from,
        eigrp 10, includes subnets in redistribution
      Number of areas in this router is 2. 2 normal 0 stub 0 nssa
      Maximum path: 4
      Routing for Networks:
        150.1.2.2 0.0.0.0 area 0
        152.1.123.2 0.0.0.0 area 123
     Reference bandwidth unit is 100 mbps
      Routing Information Sources:
        Gateway         Distance      Last Update
        150.1.7.7            200      00:04:50
        150.1.9.9            200      00:05:44
        150.1.3.3            200      00:05:44
        150.1.1.1            200      00:05:44
      Distance: (default is 110)
        Address         Wild mask       Distance  List
        0.0.0.0         255.255.255.255      200  EIGRP_EX

    I can see hits on the access-list as normal

    RSRack1R2#sh ip access-li
    Standard IP access list EIGRP_EX
        10 permit 152.1.4.0, wildcard bits 0.0.0.255 (1 match)
        20 permit 152.1.5.0, wildcard bits 0.0.0.255 (1 match)
        30 permit 152.1.45.0, wildcard bits 0.0.0.255 (2 matches)
        40 permit 54.1.10.0, wildcard bits 0.0.0.255 (1 match)
        50 permit 212.18.0.0, wildcard bits 0.0.3.255 (4 matches)
        60 permit 150.1.4.0, wildcard bits 0.0.0.255 (1 match)
        70 permit 150.1.10.0, wildcard bits 0.0.0.255 (1 match)


    I
    have full reachability and as far as I can tell I haven't broken any
    requirements. However, based on the workbook and on what you guys are
    saying here this solution seems to add unnecessary burden.

     

  • i fixed the loop with tags 

     

    redistribute eigrp 10 route-map OSPF2EIGRP SUB
    redistribute ospf 1 route-map EIGRP2OSPF metric 10000 10000 255 1 1500 

     

    route-map OSPF2EIGRP deny 10
    match tag 90
    route-map OSPF2EIGRP  permit 20
    set tag 110
    exit

    route-map EIGRP2OSPF deny 10
    match tag 110
    route-map EIGRP2OSPF permit 20
    set tag 90
    exit

     

     

    Tag and don't allow tagged routes to come back, problem solved.

  • So the confusion for me is the wording of the actual task:

    It strictly focuses on EIGRP>OSPF and strictly mentions Admin Distance (I would have preferred to use tags too).

    As a result I was not looking for anything else to achieve this goal... Is this short sighted of me?

    10 minutes allocated for this task seemed way too much for the simple config,

    The SG provided the confusion - with the RIP distance and no explaination...

     

     

  • Though the SG's answer does work, it relies on a few things.

    If you were doing the tasks in sequence then you redistributed RIP prior to setting the AD lower to prevent feedback from SW->R3->R1/R2->R3-SW1. 

    This causes a loop in the topology.  Now you have either R1 or R2 (depending on which redistributed first for me it was R2) feeding an external EIGRP route back to ospf, learned from the other (R1) that it learned from R3, R3 in turn advertises it back to SW1 and since it has a lower AD than RIP, replaces it with the E2 OSPF route.  I think everyone gets up to this part.

    So when you lower the AD of RIP on SW1 to 109, SW1 now installs the RIP routes and sends E2 routes back to ABR R3

    R3 now sees 2 E2 routes for all the external routes from SW1 one from SW1 and one from either R1 or R2.  The deciding factor is supposed to be cost to the ASBR.  This Cost is Metric (from the ospf database) + the cost to get to the ASBR that you can just look and see on the show ip route for the loopbacks.

    With SW1 being connected via Ethernet and R1/R2 being connected via frame, SW1 should be the winner at all times.  I proved this by setting the ip ospf cost on R3 F0/0 to make the path to SW1 over, equal, and under the path to get to R2(or R1).  If you set it over you will force the loop, if you set it equal, you will actually see both routes on the R3 routing table, and if you set under then you will get a loop free topology. 

    Now this is all fine in theory, but when I did the lab, I was in the same mess everyone else was in, I couldn't get the old routes out.  And I wasted what seemed like hours.  What came to be was that for some reason my metric was set to 20 on SW1.  If the metric is not equal then route selection does not rely on cost.  Lower Metric will be selected.

    So check on R3 by doing a show ip ospf data ex 30.0.0.0, and you can see the metrics for yourself, if SW1 is not winning you'll get a loop, if it is same then check your cost to the loopbacks (ASBRS).  SW1 must win at R3 to avoid loops.

    My solution looks like this for part 4.10 and 11 on R1, R2, R3, and SW1

    R1 and R2

    router ospf router ospf 1

    redistribute eigrp 10 subnets metric 20

    distance ospf external 171

    !

    router eigrp 10

    redistribute ospf 1 metric 10000 1000 255 1 1500

     

    SW1

    router rip

    redistribute ospf 1 metric 1

    distance 109

    !

    router ospf 1

    redistribute rip subnets metric 10

    The other thing I did that helped me troubleshoot all of this was clear ip ospf proc on all the OSPF routers at about the same time, it helped get rid of any old LSAs.

    Here's an INE Blog Post (I found it when I was googling for help, hah!)

    http://blog.ine.com/2011/04/04/understanding-ospf-external-route-path-selection/

    And here's another person explaining why only one router between R1 and R2 will feedback.

    http://ieoc.com/forums/t/3477.aspx  <-- Look for mgeorge's reply.

     

    All feedback welcomed, I'd rather be flamed than ignorant

    Peace,

    MC

  • When I first did task 4.10 i implemented loop prevention by tagging (didn't read 4.11 first). So i wanted to try a different solution. I did increase the ospf external distance >170 (EIGRP's external) on r1 and r2 as the SG. However, rather than set Sw1 with a RIP AD <100, I set a higher AD on opsf external there as well. I actually just needed it to be greater than 120 in this case (RIP), but just stuck with the same 180 i used on R1 and R2.

     

    So it looks like this:

    R1:

    ----

    router ospf 1

      distance ospf external 180

     

    R2:

    ----

    router ospf 1

      distance ospf external 180

     

    Sw1:

    ----

    router ospf 1

      distance ospf external 180

     

    My TCL pings show full reachability, even after rebooting. I do still have the same sub-optimal routing as other because R1 will prefer eigrp externals from R2 over ospf externals from R3 or vica-versa (R2 prefers R1's advertised EIGRP external over the OSPF external from R3). This affects route that originated in RIP on Sw1.

    In my particular instance R2 "won."

    R2#sh ip route 30.0.0.0

    Routing entry for 30.0.0.0/16, 4 known subnets

      Redistributing via eigrp 10, eigrp 1

     

    O E2    30.2.0.0 [180/20] via 152.1.123.3, 00:01:47, Serial0/1/0.1

    O E2    30.3.0.0 [180/20] via 152.1.123.3, 00:01:47, Serial0/1/0.1

    O E2    30.0.0.0 [180/20] via 152.1.123.3, 00:01:47, Serial0/1/0.1

    O E2    30.1.0.0 [180/20] via 152.1.123.3, 00:01:47, Serial0/1/0.1

     

    R1#sh ip route 30.0.0.0

    Routing entry for 30.0.0.0/16, 4 known subnets

      Redistributing via eigrp 10

     

    D EX    30.2.0.0 [170/28416] via 152.1.125.2, 00:01:28, FastEthernet0/0

    D EX    30.3.0.0 [170/28416] via 152.1.125.2, 00:01:28, FastEthernet0/0

    D EX    30.0.0.0 [170/28416] via 152.1.125.2, 00:01:28, FastEthernet0/0

    D EX    30.1.0.0 [170/28416] via 152.1.125.2, 00:01:28, FastEthernet0/0



    R2 goes to R3- GOOD. R1 goes to R2 - SUBOPTIMAL BUT WORKS. This could be solved using the distance command inside of EIGRP with prefix-list matching those speicifc 30 and 31 networks (and 204.12.1.0.24).

    Anyhow, but to the solution of increasing ospf external on Sw1, I think its really the same net effect as lowering rip, just making sure that the we choose the original RIP routes over the ones we get def back from OSPF. Does anyone see any potential issues with this solution?


    Thanks!

     

    Mike

  • Hi Mike,

    After some moment of analysis of the design, I found your solution will not violate any rule since you need lower AD value for RIP than OSPF external to avoid suboptimal route.

    If i'm not wrong, we have to perform the AD manipulation on Sw1 because we should less prioritize the external prefixes coming from  Backbone 1. So, we need to enforce Sw1 to find best route via Backbone 2 that are coming from external network behind multiple backbones.

    In R1 and R2 you increased 180, which ensures loop prevention between EIGRP and OSPF domain because once the EIGRP external route comes into OSPF domain thorugh R1, R2 will get the prefix with AD 180 and it's compared with 170 D EX, thereby not allowing the prefix to be installed in OSPF routing table on R2 which completely prevents the loop.

    Good luck!

  • Yes it doesn't make difference whether you increase it for ospf or decrease it for RIP. Thanks Hari for the analysis and confirmation.

     

  • So.... just for clarification, suboptimal routing is ok as long as it meets the requirements of the task?

  • JoeMJoeM ✭✭✭

    So.... just for clarification, suboptimal routing is ok as long as it meets the requirements of the task?

    Hi EMelloul,

    Avoiding loops is the main concern, while fullfilling the requirements.  

    What are you referencing in regards to suboptimal routing?

     

Sign In or Register to comment.