3.10- Default Routing

Hi,

I have to shutdown the R2 interface S 0/0.23 to see the lost default route in R5. After I shutdown both the interfaces in R3.

Rack1R3#sh ip route 164.1.23.0
Routing entry for 164.1.23.0/24
  Known via "ospf 1", distance 110, metric 20
  Tag 890, type extern 2, forward metric 67
  Redistributing via eigrp 100
  Last update from 164.1.34.4 on Serial1/0.34, 00:03:00 ago
  Routing Descriptor Blocks:
  * 164.1.34.4, from 150.1.8.8, 00:03:00 ago, via Serial1/0.34
      Route metric is 20, traffic share count is 1
      Route tag 890

Rack1R1>sh ip route 164.1.23.0
Routing entry for 164.1.23.0/24
  Known via "eigrp 100", distance 90, metric 15641600, type internal
  Redistributing via eigrp 100
  Last update from 164.1.12.2 on Serial0/0, 00:01:46 ago
  Routing Descriptor Blocks:
  * 164.1.12.2, from 164.1.12.2, 00:01:46 ago, via Serial0/0
      Route metric is 15641600, traffic share count is 1
      Total delay is 220380 microseconds, minimum bandwidth is 256 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

 

Comments

  • Hey, it happened to me also, I don't understand what is wrong, someone?

     

     

  • mmm almost configure FREEK frame relay end to end keep alive.

    but my rack finishes before I apply my theory.

    As I see there's missing keepalive command at S1/1.23 and S1/2 at R3  and their respective interfaces at R2 and R1 respectivelly, so interface will be down at every side because FREEK controls it.

    However I I don't understand why if at R3 both interfaces are down the conditional default still works.

     

    :-(

  • I think you are right with FR EEK fix. We have to enable that for R3-R2 PVC. Without that R2 is directly attached 164.1.23.0 and does not know that the other end (R3) is down as it still keeps receiving LMIs. As a result of that R1 can reach 164.1.23.0 via R2 and SW2 can reach 164.1.23.0 via R1. As we redistributed EIGRP into OSPF on SW2, R3 will know about 164.1.23.0 from SW2. Even if we shut down both S1/1.23 and s1/2 (using dynamips numbering) one of our routes still does exists! Hence default route is propagated into OSPF as per route-map definition.

    Just going to prove it with EEK :)

  • I noticed the same issue as well. For instance, when I shutdown both s1/2 and s1/1.23 on R3, the default route would still exist. One thing I found interesting is when I did a 'show int s1/1' the link was still UP but the line protocol was DOWN.

    If you shutdown both physical interfaces on R3 (s1/1 and s1/2) you will notice it works and the default route will be gone. When you just shutdown the sub-interface, it just takes the line protocol down as the physical interface's link (s1/1) on R3 is still UP.

     

  • it happened with me as well...seems FR SW doesnt work end to end..strange but in SG they didnt talk about it..anyway FREEk Should do it...didnt try to check it

  • Hi Gents,

    I believe a feasible solution here is to track both neighbor by rtr and do a boolean on the event.

     


    ip sla monitor 1

     type echo protocol ipIcmpEcho 164.1.23.2 

    ip sla monitor schedule 1 start-time now

    ip sla monitor 2

     type echo protocol ipIcmpEcho 164.1.13.1

    ip sla monitor schedule 2 start-time now

     

    track 1 rtr 1

    !

    track 2 rtr 2

    !

    track 3 list boolean or

     object 1

     object 2

     

    ip route 0.0.0.0 0.0.0.0 Null0 track 3

     

    router ospf 10

     default-information originate 

     

     

     

Sign In or Register to comment.