Foundation LAB 2 - RIP redistribution into OSPF

Hi guys,

Regarding R9 I observed something after we did Redistribution between RIP and OSPF on R3, from R3 I can´t ping 9.9.9.9 anymore, because it´s been redistributed into OSPF and there is a routing loop.

After spending some time why BGP  neighboring was intertmittent between R3 and R9 for VPNV4 section I could see this issue.

 

Take a look:

 

R3#show ip ro 9.9.9.9

Routing entry for 9.9.9.9/32

  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 30

  Redistributing via rip

  Advertised by rip metric 1

  Last update from 156.1.35.5 on Ethernet0/1.35, 00:11:06 ago

  Routing Descriptor Blocks:

  * 156.1.35.5, from 4.4.4.4, 00:11:06 ago, via Ethernet0/1.35

      Route metric is 20, traffic share count is 1

R3#traceroute 9.9.9.9

Type escape sequence to abort.

Tracing the route to 9.9.9.9

VRF info: (vrf in name/id, vrf out name/id)

  1 156.1.35.5 6 msec 3 msec 1 msec

  2 156.1.56.6 6 msec 8 msec 7 msec

  3 156.1.46.4 7 msec 8 msec 7 msec


4 156.1.146.6 6 msec 2 msec 4 msec

  5 156.1.46.4 7 msec 7 msec 7 msec

  6 156.1.146.6 9 msec 2 msec 3 msec

  7 156.1.46.4 2 msec 6 msec 4 msec

  8 156.1.146.6 3 msec 2 msec 3 msec



R5#show ip ro 9.9.9.9

Routing entry for 9.9.9.9/32

  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20

  Last update from 156.1.56.6 on Ethernet0/1.56, 00:11:45 ago

  Routing Descriptor Blocks:

  * 156.1.56.6, from 4.4.4.4, 00:11:45 ago, via Ethernet0/1.56

      Route metric is 20, traffic share count is 1

R5#




R6#show ip route 9.9.9.9

Routing entry for 9.9.9.9/32

  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10

  Redistributing via ospf 2, eigrp 5

  Advertised by ospf 2 subnets route-map CONNECTED_INTO_OSPF2

                eigrp 5

  Last update from 156.1.46.4 on Ethernet0/1.46, 01:28:58 ago

  Routing Descriptor Blocks:

  * 156.1.46.4, from 4.4.4.4, 01:28:58 ago, via Ethernet0/1.46

      Route metric is 20, traffic share count is 1

R6#





R4#show ip ro 9.9.9.9

Routing entry for 9.9.9.9/32

  Known via "eigrp 5", distance 170, metric 1075200, type external

  Redistributing via ospf 1, eigrp 5

  Advertised by ospf 1 subnets

  Last update from 156.1.146.6 on Ethernet0/1.146, 01:29:04 ago

  Routing Descriptor Blocks:

  * 156.1.146.6, from 156.1.146.6, 01:29:04 ago, via Ethernet0/1.146

      Route metric is 1075200, traffic share count is 1

      Total delay is 1100 microseconds, minimum bandwidth is 10000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

R4#




Shouldn´t we block this prefix from been redistributed into some protocol also?


R6 is redistributing into EIGRP A5 and R4 is redistributing into OSPF.





Comments

  • After rebooting everything it´s ok. Another stuck behavior on IOU/IOL

    Everything working perfectly as it would be.


    If this happened with someone using IOL, please let me know.




    I´m studying the LAB and I don´t reboot the routers in the morning, the computer hibernate and on the other day I would reboot the routers before start a new session, seems like some proccess in IOL is stuck when the computer hibernate.




    I think the best practice is to start all the routers when the computer hibernate, maybe?





    R3#show ip ro 9.9.9.9

    Routing entry for 9.9.9.9/32

      Known via "rip", distance 120, metric 1

      Redistributing via ospf 1, rip

      Advertised by ospf 1 metric-type 1 subnets

      Last update from 156.1.39.9 on Ethernet0/1.39, 00:00:12 ago

      Routing Descriptor Blocks:

      * 156.1.39.9, from 156.1.39.9, 00:00:12 ago, via Ethernet0/1.39

          Route metric is 1, traffic share count is 1

    R3#



    R3#show ip ospf database external | beg 9.9.9.9

      Link State ID: 9.9.9.9 (External Network Number )

      Advertising Router: 3.3.3.3

      LS Seq Number: 80000001

      Checksum: 0x6A86

      Length: 36

      Network Mask: /32

            Metric Type: 1 (Comparable directly to link state metric)

            MTID: 0

            Metric: 20

            Forward Address: 0.0.0.0

            External Route Tag: 0


      Routing Bit Set on this LSA in topology Base with MTID 0

      LS age: 263

      Options: (No TOS-capability, DC, Upward)

      LS Type: AS External Link

      Link State ID: 156.1.24.0 (External Network Number )

      Advertising Router: 6.6.6.6

      LS Seq Number: 80000001

      Checksum: 0x2AA8

      Length: 36

      Network Mask: /24

            Metric Type: 2 (Larger than any link state path)





    R6#show ip ro 9.9.9.9

    Routing entry for 9.9.9.9/32

      Known via "ospf 1", distance 110, metric 40, type extern 1

      Redistributing via eigrp 5, ospf 2

      Advertised by eigrp 5

                    ospf 2 subnets route-map CONNECTED_INTO_OSPF2

      Last update from 156.1.56.5 on Ethernet0/1.56, 00:05:48 ago

      Routing Descriptor Blocks:

      * 156.1.56.5, from 3.3.3.3, 00:05:48 ago, via Ethernet0/1.56

          Route metric is 40, traffic share count is 1

    R6#




    R5#show ip ro 9.9.9.9

    Routing entry for 9.9.9.9/32

      Known via "ospf 1", distance 110, metric 30, type extern 1

      Last update from 156.1.35.3 on Ethernet0/1.35, 00:06:15 ago

      Routing Descriptor Blocks:

      * 156.1.35.3, from 3.3.3.3, 00:06:15 ago, via Ethernet0/1.35

          Route metric is 30, traffic share count is 1

    R5#




  • JoeMJoeM ✭✭✭

    EDIT:  I looked at the output in your first post. 

    The problem was between R3 and R9 (no where else). We can see this, as soon as we see that R3 has the route coming from OSPF.

    ** R3 is the only redistribution point between RIP and OSPF.....and R3 knows this. There should be NO confusion about the correct direction (from R3's point of view).

    What it looks like to me, is that when your lab came back up, everything was not sync'd.  The OSPF routers had stale information. 

    RIP between R3 and R9  does not seem to be up yet.


    R3#show ip ro 9.9.9.9
    Routing entry for 9.9.9.9/32
      Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 30
      Redistributing via rip
      Advertised by rip metric 1


     

    The fix for this was to get RIP updated between R3 and R9.  Possible timer issue.
    Maybe just a couple of simple commands on R3 would have done the trick:

               clear ip route *  <--for RIP first and check RIP routes

               clear ip ospf process <--"ahh what the heck. let's refresh OSPF too."

     

    /end EDIT

     

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


    ...After rebooting everything it´s ok. Another stuck behavior on IOU/IOL


    Everything working perfectly as it would be.


    If this happened with someone using IOL, please let me know....


    ....

    I think the best practice is to start all the routers when the computer hibernate, maybe? ....




    Sorry for not getting to your earlier post. This one is a little more difficult to troubleshoot without having the lab up in front of me.


    Be careful about scapegoating IOU/GNS3 for any TS problems.  Besides the documented issues, I believe that (most of the time) this is just a crutch to learning the technologies (TS practice).  

    There be a problem with hibernation and the timers of all of the devices, but unless you are in a time-crunch, I would use the opportunity to find out where it is broken -- and fix/refresh that process.

    I cannot tell you how many times, that I wanted to blame gns3 or iou (hours lost trying to solve issues).  But by being stubborn in my troubleshooting, I would find most of the time that my cofig was the problem -- a bad config with maybe just a single little line or option missing.

     

    Let the problem be your friend.  Try and understand the puzzle, rather than just doing reboot. (windows solution?)

    Every time that there is a problem with a technology, try to track it down.  Understand how the protocol works.  Understand what neighbor connections are broken. Understand the logical puzzle. What is missing or not working?



    It may be a pain-in-the-badword, but the reward is gold on lab day.  Trust me, little mistakes in the lab can completely chew-up time. Panic and heart racing when things go wrong.



    NOTE:  the only time I would reload a router/switch in IOU, is if my direct conections were not working.  Especially the switches in IOU can be problematic if the memory is used up due to....(see documented issues).








  • JoeMJoeM ✭✭✭

    BTW, you are bringing up great questions.   If you put these under the sub-forum for this lab, it is valuable information for future candidates doing the lab. 

    The old lab (CCIEv4) has been more-or-less archived for the older workbooks.  It is up to us to rebuild the INE CCIEv5 library of lab topics.  ;-)

Sign In or Register to comment.