Question on Task 4.8

I tackled this task by applying tag to routes being redistributed into OSPF (routemap RIP2OSPF) on R4, and I filtered out the tagged routes on R5 as I redistributed OSPF2RIP and I did the same on R5, tagged routes redistributed into OSPF on R5 and filtered it on R4 as I redistribute OSPF2RIP. I thought that this was the classic loop prevention mechanism but the issue I ran into was that R1 did not receive the OSPF routes redistriuted into RIP on R4 and consequently I did not enjoy full reachability.

Can some please point out to me the fundamental flaw with my approach. I am desperate to know.

Regards

Chris

Comments

  • Hi Chris,

    I also employed the tag/filter method and it worked for me.  Here's the config. that I used:

    R4
    router ospf 1
     redistribute rip subnets route-map T4.8-R2O
    !
    router rip
     redistribute ospf 1 metric 7 route-map T4.8-O2R
    !
    route-map T4.8-R2O permit 10
     set metric 400
     set tag 4120
    !
    route-map T4.8-O2R deny 10
     match tag 5120
    !
    route-map T4.8-O2R permit 20


    R5
    router ospf 1
     redistribute rip subnets route-map T4.8-R2O
    !
    router rip
     redistribute ospf 1 metric 7 route-map T4.8-O2R
    !
    route-map T4.8-R2O permit 10
     set metric 500
     set tag 5120
    !
    route-map T4.8-O2R deny 10
     match tag 4120
    !
    route-map T4.8-O2R permit 20

    This tag/filter method also happens to fulfill T4.9 as well.  In this particular scenario, if you opt to do redistribution without tag/filter, there is no loop due to the topology, but R1's loopback is not reachable on R4, depending what metric you use when redistributing OSPF into RIP on R5.  If you use anything less than 10 (that's the metric that R1 advertises to R4 per T4.6), R4 will prefer this and point to R5 for R1's loopback instead, and this just leads to lalala land ;-).

    HTH

  • Hello HTH,

    Many thanks for your response. I have since reapplied my config and it works. My previous config must have contained an error. With regards to the loop if you redistribute without tag/filter, I experienced this because I also use a metric of 8 when redistributing into RIP. I guess if you use a prefix of 11, then no loop.. I will lab it up to see.

     

    Regards

    Chris

    [Y]

  • I tried the tag + filter method... then I tried the solution from the answer guide.. and both ways R4 was still saying it was learning of R1's loopback via RIP from R5. I ended up adding an offset-list outbound from R5->R4 and that fixed the issues. I'm not sure why it wasn't working...

  • Also, Idle... do you always name your ACLs and RMs with the task number like that? That's not a bad idea really..

  • I must have oversimplified and/or overlooked something here because I didn't'
    use route-maps at all for this particular task, but what I did instead was to set the metric directly during
    redistribution. And for the loop issue on task 4.9 I've set the OSPF AD
    for external routes to be higher than 120.

     

    !
    ! r5
    !
    conf t
    !
    router rip
     redis ospf 1 metric 1
    !
    router ospf 1
     redis rip subnets metric 500
     distance ospf external 121
    !
    end


    !
    ! r4
    !
    conf t
    !
    router rip
     redis ospf 1 metric 1
    !
    router ospf 1
     redis rip subnets metric 400
     distance ospf external 121
    !
    end


    !
    ! sw2
    !
    conf t
    !
    router rip
     redis ospf 1 metric 1
    !
    router ospf 1
     redis rip subnets
     distance ospf external 121
    !
    end

     

    RSRack1R2#sh ip route | inc 400|500
    O E2    140.1.14.0/24 [110/400] via 140.1.245.4, 00:04:50, Serial0/0
    O E2    140.1.45.0/24 [110/400] via 140.1.245.4, 00:04:50, Serial0/0
    O E2    140.1.45.4/32 [110/500] via 140.1.245.5, 00:04:50, Serial0/0
    O E2    140.1.45.5/32 [110/400] via 140.1.245.4, 00:04:50, Serial0/0
    O E2    150.1.1.0 [110/400] via 140.1.245.4, 00:04:50, Serial0/0

    RSRack1R2#ping 150.1.1.1

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 84/87/89 ms

    RSRack1R2#trace 150.1.1.1

    Type escape sequence to abort.
    Tracing the route to 150.1.1.1

      1 140.1.245.5 32 msec 28 msec 28 msec
      2 140.1.45.4 44 msec 44 msec 48 msec
      3 140.1.14.1 44 msec *  44 msec

  • Hi I did the same.  I only created the route-map to include the connected subnets, but set the metric in the redistribute

    command itself.  And used the Distance value to prevent the loop.  Now for some reason, and I've seen this behavior with

    BGP and EIGRP, that if a route is prefered by a protocol because of the Administrative DIstance, changing the AD value only won't make it change unless you shutdown the interface and re-enable it (the one toward the next hop at the moment).

    I don't know why, and could be a bug or something but it happend to me in this particular lab and one time with BGP and EIGRP.

    We had two sites interconnected via a 100Mb link running EIGRP, then another company acquired ours and implemented 10 Mbps BGP connections on both sites. We advertised everything and forgot to include the internal routes as BACKDOORs. At the time nothing happend, even do eBGP routes AD were lower (20) than EIGRP. 

    A month later an internal failure triggered the condition were the routers now preferred the eBGP routes and causing sub-optimal routing and you can imagine.

Sign In or Register to comment.