Lab 3 Ticket 4 - *TOTAL* disaster?

Hi there,

I'm on this ticket for about three hours now. I completed half of this task, but the second half (ospf routers must choose path via rip domain) is more than insane.

After two hours of thinking about this I gave up and read SG.

Well, I think that INE wants us to do sth that is nearly impossible. Imagine ospf routes traversing rip domain, being injected to ospf again - and those routes must be used. This is against idea of redistribution, where we normally try to make sure, that routes are available from their native protocol.

I think that the solution that INE proposes *MUST* end with routing loops, if not filtered carefully path-by-path. This is not however configuration section but troubleshooting, we are suppose to fix an issue, not to reconfigure whole routing domain.

Anyway, after applying SG solution, external routes from R6 still ends with routing loop at R1-R3-SW2. And it's obvious it sould end with this loop with this configuration.

take a look:

Rack1R2#show ip route 212.0.0.0 255.0.0.0 long | b Gate
Gateway of last resort is not set

R    212.18.1.0/24 [109/2] via 204.12.1.6, 00:00:21, FastEthernet0/0
R    212.18.0.0/24 [109/2] via 204.12.1.6, 00:00:21, FastEthernet0/0
R    212.18.3.0/24 [109/2] via 204.12.1.6, 00:00:21, FastEthernet0/0
R    212.18.2.0/24 [109/2] via 204.12.1.6, 00:00:21, FastEthernet0/0

Okay, looks pretty good. Let's check on R1:

Rack1R1#show ip route 212.0.0.0 255.0.0.0 long | b Gate
Gateway of last resort is not set

R    212.18.1.0/24 [120/9] via 163.1.18.8, 00:00:03, FastEthernet0/0
R    212.18.0.0/24 [120/9] via 163.1.18.8, 00:00:03, FastEthernet0/0
R    212.18.3.0/24 [120/9] via 163.1.18.8, 00:00:03, FastEthernet0/0
R    212.18.2.0/24 [120/9] via 163.1.18.8, 00:00:03, FastEthernet0/0

Whoah (!). These routes are from ospf process and should be visible via ospf on R1. But R1 pass it to R3 via ospf and both routers pass this route to SW2 via RIP. Take a look at SW2:

Rack1SW2#show ip route 212.0.0.0 255.0.0.0 long | b Gateway
Gateway of last resort is not set

R    212.18.1.0/24 [120/8] via 163.1.38.3, 00:00:12, GigabitEthernet0/20
R    212.18.0.0/24 [120/8] via 163.1.38.3, 00:00:12, GigabitEthernet0/20
R    212.18.3.0/24 [120/8] via 163.1.38.3, 00:00:12, GigabitEthernet0/20
R    212.18.2.0/24 [120/8] via 163.1.38.3, 00:00:12, GigabitEthernet0/20

SW2 chooses path from R3, pass this route to R1, R1 thinks it's better than ospf (via AD) and passes this route back to R3:

Rack1R1#show ip route 212.0.0.0 255.0.0.0 long | b Gate
Gateway of last resort is not set

O E2 212.18.1.0/24 [121/20] via 163.1.12.2, 00:00:15, Serial0/0
O E2 212.18.0.0/24 [121/20] via 163.1.12.2, 00:00:15, Serial0/0
O E2 212.18.3.0/24 [121/20] via 163.1.12.2, 00:00:15, Serial0/0
O E2 212.18.2.0/24 [121/20] via 163.1.12.2, 00:00:15, Serial0/0

Oh, wait. Shouldn't the ospf cost be set on routes redistributed from rip to 1000? Sure. Let's take a look at R3's database:

Rack1R3#sh ip ospf database ex 212.18.1.0

            OSPF Router with ID (150.1.3.3) (Process ID 1)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1893
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 212.18.1.0 (External Network Number )
  Advertising Router: 150.1.2.2
  LS Seq Number: 80000001
  Checksum: 0xC755
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

  LS age: 59
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 212.18.1.0 (External Network Number )
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0x261D
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1000
        Forward Address: 0.0.0.0
        External Route Tag: 0

Now it makes much more sense. This task is a disaster or I will never pass CCIE exam. I'm giving up at this point. Bad news is that all other tickets depends on this one.

Any clue on this?

 

 

Comments

  • Hey jdr, I will load the config shortly and see what's going on. But I know what you're talking about here - that lab gave me the headaches too :) The RIP/OSPF redistribution is kind of insane. Did you check the most recent solution guide, I think I was updating it like 2-3 weeks ago, specifically for this lab.

  • Thanks Petr,

    I belive I have lastest materials (I downloaded fresh copy two days ago).

     

  • Jdr,

    Yes, this was, indeed, an very complicated redistribution problem. I just made a complete redistribution diagram and there are two logical loops that must be maintained while providing connectivity. Neither in real word, nor in the exam I expect you to see that level of deliberate complication. First, the the issue you mentioned - loops toward the routes learned from BB1. As you can see, those are fed to R1 via RIP because R3 still receives them via OSPF flooding.. This is tricky, but could be fixed by using the following command on R1:

    router ospf 1
     distance 110 150.1.2.2 0.0.0.0

    Effectively telling to keep the native distance for routes learned from R2. This is the same logic used for adjsuting the distance for R4 and R5 originated routes on R3 as demonstrated in the solution.

    Don't feel bad about this though! :) Resolving redistribution problems never was easy as there are no "universal" solutions due to numerous interferences among the protocols. And  things get even worse when you use summarization and route filtering. In the case of the scenario, seeing the task being too hard should be a good signla for you to eliminate existing redistribution and revert to something simpler - e.g. originating default routes from R3/R1 into RIP and not performing any redistribution on R1/R3 at all.

  • Oh I forgot, reaching those prefixes behind R6 wasn't really necessary to complete other scenarios in this lab, so the distance fixup on R1 was omitted in the solution :)

  • Oh I forgot, reaching those prefixes behind R6 wasn't really necessary to complete other scenarios in this lab, so the distance fixup on R1 was omitted in the solution :)

    B-u-s-t-e-d! :)

     

    Thanks for your reply Petr,

    In the real lab enviroment (which I by the way just scheduled on may, 17) if cisco would asked me to do sth like this i would surely skip this task and just make sure that there are no routing loops and my pings works correctly. The chances of passing the exam are bigger when you skip redistribution and do all other tasks, not when you let distribution to consume your valuable time and prevent you from completing another ones. :-)

     

  • jchanjchan ✭✭

    I just finished this ticket, it took me more than 2 hours.  I managed to fix most of the routing loops except I didn't see a need to set distance 109 on r2(to perfer the native rip routes) and it created sub-optimize routing in b/w r3 and r1.  I couldn't fix it till I looked at the SG.

    In my mind, I thought r2 has only one link to go out and come in, so redistribution on a single point with a single link should not cause any routing loop problem, obviously, I was wrong.  These routes goes out as rip but come back as ospf and creates the the sub-optimize routing.

    Good catch jdr, thanks for the explanation Petr.  It was a hard ticket but it was a good one too, let hope we won't see it in real lab. :)

    In additon,I configured a route-map on r5 to advertise 0.0.0.0/0 to SW1 only. (so that r4 and bb2 won't receive it)

    Rack1R5#sh run | b route-map
     default-information originate route-map TO_SW1

    route-map TO_SW1 permit 10
     set interface FastEthernet0/1

  • OMG I've just finished this task without the SG!

    ...However it took me 1:50 hours which would have totally killed my CCIE lab.

    The funny thing is that it took me about 10 min to complete the first part and about 1:40 hrs to make the damn routes use RIP instead of OSPF without generating any loop.

    I used the tag and filter method as it is my favourite - I personally don't like the AD manipulation method as it requires lots of route digging. However tag and filter will more than likely generate suboptimal routing.

    At some stage I realized  there was no other way other than this to nail this one:

    ON R1:

    ip access-list sta OSPF_ROUTES_R2
    permit 204.12.2.0
    permit 54.2.7.0
    permit 54.2.7.254
    permit 212.18.1.0
    permit 212.18.0.0
    permit 212.18.3.0
    permit 212.18.2.0
    permit 150.2.6.0
    permit 150.2.2.0


    Rack2R1(config-router)#distance 90 0.0.0.0 255.255.255.255 OSPF_ROUTES_R2

    don't know why but the simple distance command didn't work - I had to specify an ACL to match R2 prefixes.This is not dynamic of course (if R2 starts to advertise another route it'll loop) but did the trick. Also, I used 90 as AD because to avoid suboptimal routing I configured RIP with better AD instead of worse the OSPF AD.

    Still - if stuff like this will show up during my exam I think I'm gonna cry :)

  • It wasn't clear if the OSPF area 0 that has SW1, 3, and 4 should be linked to the other area 0 to have a fully connected OSPF domain. Too time and energy consuming to be configured in the real lab. Skipping the task in the practice lab and would do the same in the real lab after ensuring that there are no routing loops and that there is full connectivity. Looks like one of those things I would consider practicing before the 2nd or 3rd lab attempt, if the real lab turns out to be that difficult. With limited time and energy available one has no choice but to prioritize in real life and the lab.

  • Damn....

    so glad I'm not the only one fustrated with this ticket..... what a nightmare

     

  • Hi Bro,

    Try my solution, I took about 15 minutes to solve this ticket, and it works like charm... it does not break any rules, and to me, I like to think out of the "BOX".

    One of the objective is the use the high-speed links (Ethernet) rather than use the serial links, which hints us to use RIP learnt routes between R3-SW2-R1 for all the traffic forwarding (including both RIP native routes and OSPF native routes), the question also DID NOT mention that the redundant path need to be available after primary link failure... so... what I did is, just do the mutual redistribution between RIP and OSPF on both R3 and R1 without any tagging or filtering between the redistribution process; however, in addition to that, I used the "ospf database-filter" feature on the serial interface level between R3 and R1, followed by clearing the OSPF process on both R3 and R1. 

    I have verified, and it is working. 

    Details as following:

    ====================================================

    R1

    int s1/1
     ip ospf network point-to-point
     ip ospf database-filter all out
    !
    do clear ip ospf process
    y
    !

    R3

    int s1/2
     ip ospf network point-to-point
     ip ospf database-filter all out
    !
    do clear ip ospf process
    y
    !
    ====================================================

    Checking the routing table:

    Rack1R3(config)#do sh ip route ospf
         163.1.0.0/16 is variably subnetted, 14 subnets, 3 masks
    O E2    163.1.0.128/25 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O E2    163.1.45.5/32 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O E2    163.1.45.0/24 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O IA    163.1.54.0/24 [110/128] via 163.1.35.5, 03:14:23, Serial1/0
    O E2    163.1.57.0/24 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O E2    163.1.3.0/24 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O E2    163.1.0.0/25 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O E2    163.1.7.0/24 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O IA    163.1.5.0/24 [110/65] via 163.1.35.5, 03:14:23, Serial1/0
    O E2 10.0.0.0/8 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O E2 192.10.1.0/24 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
         150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
    O E2    150.1.7.0/24 [110/20] via 163.1.35.5, 03:14:23, Serial1/0
    O IA    150.1.5.5/32 [110/65] via 163.1.35.5, 03:14:23, Serial1/0
    O IA    150.1.4.4/32 [110/129] via 163.1.35.5, 03:14:23, Serial1/0
    Rack1R3(config)#do sh ip route rip
    R    204.12.1.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
         54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    R       54.1.7.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R       54.1.7.254/32 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R    212.18.1.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
         163.1.0.0/16 is variably subnetted, 14 subnets, 3 masks
    R       163.1.12.0/24 [120/3] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R       163.1.18.0/24 [120/1] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R    212.18.0.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R    212.18.3.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R    212.18.2.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
         150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
    R       150.1.6.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R       150.1.2.0/24 [120/10] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R       150.1.1.0/24 [120/3] via 163.1.38.8, 00:00:16, FastEthernet0/0
    R       150.1.8.0/24 [120/1] via 163.1.38.8, 00:00:16, FastEthernet0/0

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

    Rack1R1#show ip route ospf
    O E2 204.12.1.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
         54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
    O E2    54.1.7.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
    O E2    54.1.7.254/32 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
    O E2 212.18.1.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
    O E2 212.18.0.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
    O E2 212.18.3.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
    O E2 212.18.2.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
         150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
    O E2    150.1.6.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
    O E2    150.1.2.0/24 [110/20] via 163.1.12.2, 03:09:24, Serial1/0
    Rack1R1#show ip route rip
         163.1.0.0/16 is variably subnetted, 14 subnets, 3 masks
    R       163.1.0.128/25 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.35.0/24 [120/2] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.38.0/24 [120/1] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.45.5/32 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.45.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.54.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.57.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.3.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.0.0/25 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.7.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       163.1.5.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R    10.0.0.0/8 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R    192.10.1.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
         150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
    R       150.1.7.0/24 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       150.1.3.0/24 [120/2] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       150.1.5.5/32 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       150.1.4.4/32 [120/9] via 163.1.18.8, 00:00:24, FastEthernet0/0
    R       150.1.8.0/24 [120/1] via 163.1.18.8, 00:00:24, FastEthernet0/0

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

    Now verifying the end-to-end reachability between R6 and SW3 crossing the all the IGP domains.

    Rack1SW3#ping 204.12.1.6

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 204.12.1.6, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 17/48/118 ms
    Rack1SW3#trace 204.12.1.6

    Type escape sequence to abort.
    Tracing the route to 204.12.1.6

      1 163.1.0.134 0 msec 8 msec 8 msec
      2 163.1.0.1 0 msec 9 msec 0 msec
      3 163.1.57.5 33 msec 34 msec 8 msec
      4 163.1.35.3 42 msec 34 msec 8 msec
      5 163.1.38.8 9 msec 9 msec 33 msec
      6 163.1.18.1 109 msec 34 msec 25 msec
      7 163.1.12.2 67 msec 34 msec 33 msec
      8 204.12.1.6 67 msec *  68 msec

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

    Rack1R6#ping 163.1.3.3

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 163.1.3.3, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 44/85/196 ms
    Rack1R6#trace 163.1.3.3

    Type escape sequence to abort.
    Tracing the route to 163.1.3.3

      1 204.12.1.2 40 msec 92 msec 24 msec
      2 163.1.12.1 80 msec 56 msec 32 msec
      3 163.1.18.8 48 msec 24 msec 24 msec
      4 163.1.38.3 60 msec 40 msec 56 msec
      5 163.1.35.5 80 msec 104 msec 52 msec
      6 163.1.57.7 48 msec 56 msec 88 msec
      7 163.1.0.4 100 msec 64 msec 40 msec
      8 163.1.0.133 36 msec *  64 msec

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

     

    [:D]

     

     

     

     

    OMG I've just finished this task without the SG!

    ...However it took me 1:50 hours which would have totally killed my CCIE lab.

    The funny thing is that it took me about 10 min to complete the first part and about 1:40 hrs to make the damn routes use RIP instead of OSPF without generating any loop.

    I used the tag and filter method as it is my favourite - I personally don't like the AD manipulation method as it requires lots of route digging. However tag and filter will more than likely generate suboptimal routing.

    At some stage I realized  there was no other way other than this to nail this one:

    ON R1:

    ip access-list sta OSPF_ROUTES_R2
    permit 204.12.2.0
    permit 54.2.7.0
    permit 54.2.7.254
    permit 212.18.1.0
    permit 212.18.0.0
    permit 212.18.3.0
    permit 212.18.2.0
    permit 150.2.6.0
    permit 150.2.2.0


    Rack2R1(config-router)#distance 90 0.0.0.0 255.255.255.255 OSPF_ROUTES_R2

    don't know why but the simple distance command didn't work - I had to specify an ACL to match R2 prefixes.This is not dynamic of course (if R2 starts to advertise another route it'll loop) but did the trick. Also, I used 90 as AD because to avoid suboptimal routing I configured RIP with better AD instead of worse the OSPF AD.

    Still - if stuff like this will show up during my exam I think I'm gonna cry :)

     

  • It's just another "NO COMMENTS" lab.

  • Hey man feel the pain! lol....it's one of those!!!

     

    [:D]

  • Can someone explain the loop between R2 -> R1 -> SW2 - R3. R2 redistributes RIP into OSPF and R1 receives those prefixes. R1 then sends those into OSPF and redistributes into RIP as well.

    R3 will receive the prefixes via both OSPF and RIP. Since OSPF is lower AD it should only install those routes. R3 then redistributes into RIP but why would R1 accept these when OSPF has better AD than RIP does?

    Same thing for R4 -> R5 - > R3 -> SW2 -> R1. Why will the prefixes loop back? Shouldn't R3 see them as OSPF, send them via OSPF to R1 and redistribute into RIP so that SW2 receives them. SW2 will announce RIP and R1 receives both OSPF and RIP. Since OSPF is lower AD it should prefer those and redistribute into RIP but why would R3 accept these and then announce it back into the OSPF domain where R5 is located?

  • I followed the solution guide but I am seeing a problem, I think one of those chicken/egg type scenarios where I have everything working fine, and then I shutdown R3's link to the RIP segment so the ospf route gets installed as the backup (as should be), but when I bring the link back up the ospf route stays in the routing table and the RIP one never preempts it even though it has a lower AD?

     

     

    Rack1R3(config-router)#do sh ip route 204.12.1.0
    Routing entry for 204.12.1.0/24
      Known via "rip", distance 120, metric 9
      Tag 11
      Redistributing via ospf 1, rip
      Advertised by ospf 1 metric 10000 subnets route-map R3_RIP->OSPF_TAG
      Last update from 163.1.38.8 on GigabitEthernet0/0, 00:00:12 ago
      Routing Descriptor Blocks:
      * 163.1.38.8, from 163.1.38.8, 00:00:12 ago, via GigabitEthernet0/0
          Route metric is 9, traffic share count is 1
          Route tag 11

     

    Rack1R3(config-router)#int gi0/0
    Rack1R3(config-if)#shut
    Rack1R3(config-if)#
    Jan 17 23:30:57.123: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
    Jan 17 23:30:58.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
    Rack1R3(config-if)#do sh ip route 204.12.1.0
    Routing entry for 204.12.1.0/24
      Known via "ospf 1", distance 121, metric 20, type extern 2, forward metric 128
      Redistributing via rip
      Advertised by rip metric 8 route-map R3_OSPF->RIP_TAG
      Last update from 163.1.13.1 on Serial0/0/0, 00:00:11 ago
      Routing Descriptor Blocks:
      * 163.1.13.1, from 150.1.2.2, 00:00:11 ago, via Serial0/0/0
          Route metric is 20, traffic share count is 1

    Rack1R3(config-if)#no shut
    Rack1R3(config-if)#
    Jan 17 23:31:24.867: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
    Jan 17 23:31:25.867: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
    Rack1R3(config-if)#
    Jan 17 23:31:31.736: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to down
    Jan 17 23:31:32.736: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
    Rack1R3(config-if)#
    Jan 17 23:31:41.748: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
    Jan 17 23:31:42.748: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up

     

    Rack1R3(config-if)#do sh ip route 204.12.1.0
    Routing entry for 204.12.1.0/24
      Known via "ospf 1", distance 121, metric 20, type extern 2, forward metric 128
      Redistributing via rip
      Advertised by rip metric 8 route-map R3_OSPF->RIP_TAG
      Last update from 163.1.13.1 on Serial0/0/0, 00:01:27 ago
      Routing Descriptor Blocks:
      * 163.1.13.1, from 150.1.2.2, 00:01:27 ago, via Serial0/0/0
          Route metric is 20, traffic share count is 1

     

    ... a few minutes later it is still there

     

    Rack1R3(config-if)#do sh ip route 204.12.1.0
    Routing entry for 204.12.1.0/24
      Known via "ospf 1", distance 121, metric 20, type extern 2, forward metric 128
      Redistributing via rip
      Advertised by rip metric 8 route-map R3_OSPF->RIP_TAG
      Last update from 163.1.13.1 on Serial0/0/0, 00:04:28 ago
      Routing Descriptor Blocks:
      * 163.1.13.1, from 150.1.2.2, 00:04:28 ago, via Serial0/0/0
          Route metric is 20, traffic share count is 1

     

     

    Can anyone explain what exactly is going on, and what the reason for this is? I just can't get my head around it.

     

    And what is the solution to stop this from happening?

     

    Thanks,

    Gavin

  • I simply did the following and all worked fine

    R1, R2, R3, R4, R5

    router ospf 1
    distance ospf external 121

    R1

    router rip
    distance 122 163.1.18.8 0.0.0.0

     

  • JoeMJoeM ✭✭✭

    Hi Bobby,

    If this is all you did for the full task, I can guarantee that  you have loops in your lab.  

    The big issues are at three points:

    • R4,R5
    • R3,SW2,R1
    • R2,BB1,R6

    I have done this lab at least four times. I did it again today.   Total time killer, but I find it gets easier to understand each time.  On my point chart, I give myself a 3 out of 4 (not perfect but good).  ;-)

    After the pain/headaches went away, I now think that this may be the most interesting redistribution lab I remember ever doing. A serious brain-twister -- especially doing it without tags/route-maps.

    I simply did the following and all worked fine

    R1, R2, R3, R4, R5

    router ospf 1
    distance ospf external 121

    R1

    router rip
    distance 122 163.1.18.8 0.0.0.0

     

     

     

Sign In or Register to comment.