Task 4.12 - Loop Prevention

Hi Guys,

I'm struggling trying to understand how to complete this exercise without violating any of the rules.

Obviously it's easy to see where the loop is and why it's happening, however solving it seems a bit harder.

I notice in the Solution guide they have configured a distance of 59 for OSPF which makes sense, however the questions specifies "Do not use administriative distance to accomplish this task".

Thanks in advance.

Comments

  • I would say that this is a typo in the Lab task...  "Do not use administriative distance to accomplish this task". Which is frustrating when you consider how much time you spent trying to figure it out before looking at the solution guide.  Hopefully typos like this can be caught and corrected earlier on with the rollout of the Poly Labs.

    ~Best

    Brent

  • I'm almost sure it is a Typo, but faced the task as if it were ok so decided to solve it w/o Administrative distance help.

    From my point of view sometimes solutions are simpler than they seem to be that why i decided to applu distribute-list on interfaces fa0/0 in R5 and a prefix-list just permitir the authentic RIP routes. and i think thats it.

     

     

    Santiago E

  • I agree with you Santiago that facing the task helps to use a simpler solution, which is to create a prefix-list of the routes and onlu redistribute them into OSPf


    ip prefix-list RIP_ROUTES: 4 entries

       seq 5 permit 156.9.8.0/24

       seq 10 permit 156.9.48.0/24

       seq 15 permit 156.9.54.0/24

       seq 20 permit 150.9.8.0/24

     

    But the drawback the typo does not help and these labs are suppose to build speed and accuracy. it's knida hard to do that when the lab have a lot of mistakes wich in turn costs you time. I have done all the 9/10 Volume 3 labs and I have to admit that these labs have a lot of errors which need to be fixes in order to meet the goal of the Volme 3 workbook.

     

    Just my 2c.  

  • Guys,

    Routing in this taks is stable with redistribution. Or did I just do anything wrong?

    Just out of curiosity. Have you noticed that even without any loop preventin techniques there is no route feedback and routing is stable?

     

    Tom

     

  • After I've seen the "don't use AD thing" I immediately started with tag and filter. Topology looked stable (debug ip routing was just fine, no route flaps)...

    However the major problem comes with the ospf network type point-to-multipoint.

    R1/R2/R4/R5 are in the same subnet using partial mesh, and we are forced to use point-to-multipoint. Since this type of network in OSPF treat NBMA as a collection of point to point, R5 will see the /32 routes coming via RIP from R4. This disrupt network connectivity as R5 will see directly connected neighbors via RIP.

    To fix this I tagged and filtered as well as create a standard access-list classifying genuine RIP routes. I then applied this ACL in a distributed list inbound for RIP. It took a bit of time to figure this out, imagine my reaction when I saw the SG... :)

    I agree it's impossible to increase speed and accuracy with this WB, this needs a SERIOUS review from INE.

     

  • R1/R2/R4/R5 are in the same subnet using partial mesh, and we are forced to use point-to-multipoint. Since this type of network in OSPF treat NBMA as a collection of point to point, R5 will see the /32 routes coming via RIP from R4. This disrupt network connectivity as R5 will see directly connected neighbors via RIP.

    To fix this I tagged and filtered as well as create a standard access-list classifying genuine RIP routes. I then applied this ACL in a distributed list inbound for RIP. It took a bit of time to figure this out, imagine my reaction when I saw the SG... :)

    Thats a good alternative but as per the task, if there are no loops it does not matter from where these routes are learned either rip or ospf as long as its a loop free topology. I did just used tagging to filter the ospf route not to go back to ospf domain on R4 and R5.

     

  • I did just used tagging to filter the ospf route not to go back to ospf domain on R4 and R5.

     

    I managed to achieve the same result using tags. Below is the configuration I've used which has been updated to reflect task 4.13 (no default into RIP) Essentially anything going from RIP into OSPF is blocked from returning into RIP and vice versa.

     

    !
    ! r4,r5
    !
    conf t
    !
    access-list 1 permit 0.0.0.0 0.0.0.0
    !
    route-map RIP_INTO_OSPF deny 10
     match tag 110
    !
    route-map RIP_INTO_OSPF deny 20
     match ip add 1
    !
    route-map RIP_INTO_OSPF permit 30
     set tag 120
    !
    !
    route-map OSPF_INTO_RIP deny 10
     match tag 120
    !
    route-map RIP_INTO_OSPF deny 20
     match ip add 1
    !
    route-map OSPF_INTO_RIP permit 30
     set tag 110
    !
    end
    !
    !
    !
    router rip
     redistribute ospf 1 metric 1 route-map RIP_INTO_OSPF
    !
    router ospf 1
     redistribute rip subnets route-map OSPF_INTO_RIP
    !
    end

  • I notice in the Solution guide they have configured a distance of 59 for OSPF which makes sense, however the questions specifies "Do not use administriative distance to accomplish this task".

    I've submitted the feeback below directly to INE. Let's hope they listen to us and fix it next time around.

    Workbook Vol3 Lab 9 Task 4.12 states "Do not use administrative distance to accomplish this task." yet the solution guide uses distance 59 under the rip process. In addition this solution would also break task 4.2 which reads "The administrative distance of RIP should be half of the default administrative distance on R4 and R5."

  • I would say that this is a typo in the Lab task...  "Do not use administriative distance to accomplish this task". Which is frustrating when you consider how much time you spent trying to figure it out before looking at the solution guide.  Hopefully typos like this can be caught and corrected earlier on with the rollout of the Poly Labs.

    ~Best

    Brent

    I also think it is a typo because INE is using AD in the SG. But I think I got a more simpler solution: We just have to adjust the AD of RIP routes received from R4 and R5 above OSPF internal routes.

     

    R4:

    router rip

     distance 60

     distance 120 156.1.54.5 0.0.0.0

     

     

    R5:

    router rip

     distance 60

     distance 120 156.1.54.4 0.0.0.0

     

     

    What do you think about that solution? This solution is more flexible because it accounts for new prefixes perhaps later redistributed into IGP. Therfore no prefix list has to get adjusted afterwards.

  • best solution in my opinion is hfjardim's

    (w/o using AD change of course)

    Lukas.. with your solution how can you prevent a loop between rip->ospf->rip? (60->110->60)?

    if you set an AD to 120 for prefixes from 54.5 and 54.5 you will get something like 120->110->120 again.. so a loop

    despite I think I did my task correctly I still have an unstable routing table.. I see this with debug ip routing:

    RT: del 150.1.7.7/32 via 156.1.0.5, ospf metric [110/11176]
    RT: add 150.1.7.7/32 via 156.1.45.5, ospf metric [110/12112]
    RT: NET-RED 150.1.7.7/32
    RT: del 150.1.5.5/32 via 156.1.0.5, ospf metric [110/65]
    RT: add 150.1.5.5/32 via 156.1.45.5, ospf metric [110/1001]
    RT: NET-RED 150.1.5.5/32
    RT: del 150.1.1.1/32 via 156.1.0.5, ospf metric [110/129]
    RT: add 150.1.1.1/32 via 156.1.45.5, ospf metric [110/1065]
    RT: NET-RED 150.1.1.1/32
    RT: del 150.1.7.7/32 via 156.1.45.5, ospf metric [110/12112]
    RT: add 150.1.7.7/32 via 156.1.0.5, ospf metric [110/11176]
    RT: NET-RED 150.1.7.7/32
    RT: del 150.1.5.5/32 via 156.1.45.5, ospf metric [110/1001]

    I've setup an ospf cost of 1000 on int R4/R5 se0/1, but despite this seems that router del lower metric prefixes for preferring highers.

    why?

  • I would have to assume the question is a typo as well based on the SG, but i solved it the following way (before looking at the SG).

    I used inbound offset lists on R4 and R5 to prevent them from learning routes from one another via RIP. It was pretty simple as R4 does not need to learn any RIP routes from R5, and R5 only needs to learn Sw2's Loopback, VLAN 8, and VLAN48 via R4 in RIP. So i just jacked uo all incoming rip routes on fa0/0 of R4 to 16 (infiinite) and jacked up all incoming routes to 16 on Fa0/0 of R5 EXCEPT those 3 networks (denied int he acl). It is stable and optimzed - no race condition either. I am pretty sure you could do the exact same thing with a distribute list as well - I just chose to use the distance metric (you would have to invert the ACL - denies become permits and permits become denies).

     

    R4:

    ------

    !Effectively renders all RIP routes from R5 inaccessible

    ip access-list standard R5OFFSET

     permit any

    !

    router rip

     offset-list R5OFFSET in 16 FastEthernet0/0

    R5:

    -------

    !Effectively renders all RIP routes from R4 inaccessible except those denied by the ACL

    ip access-list standard R4OFFSET

     deny   156.1.8.0

     deny   150.1.8.0

     deny   156.1.48.0

     permit any


    router rip

     offset-list R4OFFSET in 16 FastEthernet0/0




    ----Verification----



    R4#sh ip route rip

         156.1.0.0/16 is variably subnetted, 11 subnets, 2 masks

    R       156.1.8.0/24 [60/1] via 156.1.48.8, 00:00:25, FastEthernet0/1

         150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks

    R       150.1.8.0/24 [60/1] via 156.1.48.8, 00:00:25, FastEthernet0/1

    R4#sh ip route ospf

         51.0.0.0/32 is subnetted, 1 subnets

    O E2    51.51.51.51 [110/20] via 156.1.0.5, 01:11:04, Serial0/1/0.1

         156.1.0.0/16 is variably subnetted, 11 subnets, 2 masks

    O       156.1.0.5/32 [110/65] via 156.1.0.5, 01:11:04, Serial0/1/0.1

    O       156.1.7.0/24 [110/1066] via 156.1.0.5, 01:02:20, Serial0/1/0.1

    O       156.1.0.1/32 [110/130] via 156.1.0.5, 01:11:04, Serial0/1/0.1

    O       156.1.0.2/32 [110/195] via 156.1.0.5, 01:11:04, Serial0/1/0.1

    O IA    156.1.57.0/24 [110/66] via 156.1.0.5, 01:02:20, Serial0/1/0.1

    O E2 192.10.1.0/24 [110/1] via 156.1.0.5, 01:11:04, Serial0/1/0.1

         150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks

    O       150.1.7.7/32 [110/1066] via 156.1.0.5, 01:02:20, Serial0/1/0.1

    O       150.1.5.5/32 [110/66] via 156.1.0.5, 01:02:20, Serial0/1/0.1

    O       150.1.2.2/32 [110/196] via 156.1.0.5, 01:02:20, Serial0/1/0.1

    O       150.1.1.1/32 [110/131] via 156.1.0.5, 01:02:20, Serial0/1/0.1

    O*E2 0.0.0.0/0 [110/1] via 156.1.0.5, 01:11:04, Serial0/1/0.1



    ----------------------



    R5#sh ip route rip

         156.1.0.0/16 is variably subnetted, 11 subnets, 2 masks

    R       156.1.8.0/24 [60/2] via 156.1.54.4, 00:00:17, FastEthernet0/0

    R       156.1.48.0/24 [60/1] via 156.1.54.4, 00:00:17, FastEthernet0/0

         150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks

    R       150.1.8.0/24 [60/2] via 156.1.54.4, 00:00:17, FastEthernet0/0

    R5#sh ip route ospf

         51.0.0.0/32 is subnetted, 1 subnets

    O E2    51.51.51.51 [110/20] via 156.1.0.1, 01:10:42, Serial0/1/0

         156.1.0.0/16 is variably subnetted, 11 subnets, 2 masks

    O       156.1.0.4/32 [110/65] via 156.1.0.4, 01:10:42, Serial0/1/0

    O       156.1.7.0/24 [110/1001] via 156.1.7.7, 01:10:42, Tunnel0

    O       156.1.0.1/32 [110/65] via 156.1.0.1, 01:10:42, Serial0/1/0

    O       156.1.0.2/32 [110/130] via 156.1.0.1, 01:10:42, Serial0/1/0

    O E2 192.10.1.0/24 [110/1] via 156.1.0.1, 01:10:42, Serial0/1/0

         150.1.0.0/16 is variably subnetted, 6 subnets, 2 masks

    O       150.1.7.7/32 [110/1001] via 156.1.7.7, 01:10:42, Tunnel0

    O       150.1.4.4/32 [110/66] via 156.1.0.4, 01:01:54, Serial0/1/0

    O       150.1.2.2/32 [110/131] via 156.1.0.1, 01:10:42, Serial0/1/0

    O       150.1.1.1/32 [110/66] via 156.1.0.1, 01:10:42, Serial0/1/0

    O*E2 0.0.0.0/0 [110/1] via 156.1.0.1, 01:10:42, Serial0/1/0



    Some of that routing is impacted by the other tasks, but I believe it reflects all of the IGP tasks (section 4) being compelted.


    Obviously in real life using AD is a better solution since it will allow RIP routes to be used if the OSPF routes go down - but we all know by now the lab isn't about whats best in real life - its about doing precisely whats asked of you.
Sign In or Register to comment.