Object Tracking with Static Routes

Unanswered Question
Nov 20th, 2009
User Badges:

Hi Everyone,


Object tracking with static routes allows you to monitor a target with the ability to remove and then add a new route to the routing table, but in my scenario, when the target is unreachable (upstream device), I would like to stop advertising a route from this device.  It should then be learned from another Layer 3 device.


Main question: Is it possible to use object tracking to just remove a route, but not inject a new one?  I suppose I can always inject a useless route?


More detail is this:  Layer 3 device with a static route to the Internet is redistributed south to the local LAN.  This static route should be monitored and if a northbound devices becomes unreachable, it would be removed from the routing table, and thus not redistributed any more.  The local LAN then would learn a new default route from somewhere else that had been previously advertised from, but has a lower metric from the one redistributed from the Layer 3 device mentioned above so it's not used when all devices are working as expected.



Any thoughts?


Thanks,

Jason

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Fri, 11/20/2009 - 11:11
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

jason.edelman wrote:


Hi Everyone,


Object tracking with static routes allows you to monitor a target with the ability to remove and then add a new route to the routing table, but in my scenario, when the target is unreachable (upstream device), I would like to stop advertising a route from this device.  It should then be learned from another Layer 3 device.


Main question: Is it possible to use object tracking to just remove a route, but not inject a new one?  I suppose I can always inject a useless route?


More detail is this:  Layer 3 device with a static route to the Internet is redistributed south to the local LAN.  This static route should be monitored and if a northbound devices becomes unreachable, it would be removed from the routing table, and thus not redistributed any more.  The local LAN then would learn a new default route from somewhere else that had been previously advertised from, but has a lower metric from the one redistributed from the Layer 3 device mentioned above so it's not used when all devices are working as expected.



Any thoughts?


Thanks,

Jason


Jason


I saw a similiar question to this a while back and if i recall correctly the answer was to use EEM. The EEM expert is J. Clarke and he usually hangs out in the Network Management forum. Perhaps if you posted there you would get an answer.


Jon

jason.edelman Fri, 11/20/2009 - 11:19
User Badges:

Jon,


I'm actually using an ASA here.  Either way, I'd rather not get into scripting using EEM.


The simplest way to accomplish might be to monitor a device using object tracking and if that device is unreachable, remove the default route and insert a route such as 99.99.99.99/32 or something rogue and that way it would still learn a default from another device.  Thoughts on this?


Thanks,

Jason

Jon Marshall Fri, 11/20/2009 - 11:35
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Jason


jason.edelman wrote:


Jon,


I'm actually using an ASA here.  Either way, I'd rather not get into scripting using EEM.


The simplest way to accomplish might be to monitor a device using object tracking and if that device is unreachable, remove the default route and insert a route such as 99.99.99.99/32 or something rogue and that way it would still learn a default from another device.  Thoughts on this?


Thanks,

Jason


Worth a shot but would need testing. Alternatively could you not just insert a default-route pointing to the other device ie. the one you want to use.


Jon

Giuseppe Larosa Fri, 11/20/2009 - 11:26
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Jason,


>> Main question: Is it possible to use object tracking to just remove a route, but not inject a new one?  I suppose I can always inject a useless route?


I think it is enough to skip configuration of floating static route.


or in your case you should verify if you are redistributing the static route in a dynamic routing protocol in theory when the route is removed from IP routing table the redistribution detects this and should be able to remove the route from the dynamic routing protocol domain.


This is something you should test in a lab, you may expect some delay between object failure and effective removal of dynamic route as the redistribution process is executed from time to time so reaction is not immediate.


Edit:

I don't see a need for EEM here, redistribution imports in a dynamic routing protocol only routes that are present in the IP routing table, object tracking should able to remove the route from IP routing table when the test fails. subsecond convergence cannot be expected.


we can see this because for example IP ACLs used for controlled redistribution have their counters that increment over time.


Hope to help

Giuseppe

jason.edelman Fri, 11/20/2009 - 11:32
User Badges:

This scenario is actually the opposite of a floating static actually.  Static is peferred and should the next hop go down via object tracking it should learn a new route via a dynamic routing protocol.


The question still is can object tracking be configured without "inserting" a new route or is the best way to insert a new bogus route?


Jason

Giuseppe Larosa Fri, 11/20/2009 - 11:57
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Jason,

if you just want to have the tracked route removed when the test fails I don't see any need for a bogus route.


if the bogus route is missing the primary route should disappear from IP routing table and then from dynamic routing protocol database and domain.


Hope to help

Giuseppe

usparaya Wed, 11/14/2012 - 19:18
User Badges:

Hi,

To conditionally advertise thedefault route in BGP based on track:


  • Create a track object to track the reachability of the static route
  • Embed this track to the static default route
  • Create one prefix-list to match the default route
  • Call this prefix-list inside a route-map
  • Use this route-map while advertising default route to BGP neighbors (OSPF also has conditional advertisement of default-route)


Config details from my Blog:http://mynotesonroutingprotocols.blogspot.in/2012/11/bgp-conditional-advertisement-of.html

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

BGP: Conditional advertisement of default-route based on track object:


  • Yesterday one of my friends asked me one interesting question on BGP default-route advertisement.

  • R1 has a static default route through its BGP neighbor R2
  • R1 is advertising BGP default route to R3 and R4.
  • But, R1 should withdraw this default route to R3 and R4, if it loses its connection to R2 and this has to be done by tracking the static route••J
  • Initially, I thought I can call track-object inside a route-map, but there is no such option.
  • I googled so much on this topic and some people says we need to use EEM, but I didn’t find any exact answer for this.
  • Then I tried many ways of configuring track, static route, how to call the track in a route-map and all and finally it worked.

Solution:

  • Create a track object to track the reachability of the static route
  • Embed this track to the static default route
  • Create one prefix-list to match the default route
  • Call this prefix-list inside a route-map
  • Use this route-map while advertising default route to R3 and R4
  • R1 – AS 100
  • R2 – AS 200
  • R3 – AS 300
  • R4 – AS 400


R1(config)#do show run | i track

track 1 ip route 0.0.0.0 0.0.0.0 reachability

ip route 0.0.0.0 0.0.0.0 10.1.12.2 track 1

R1(config)#


R1(config)#ip prefix-list TRACK permit 0.0.0.0/0

R1(config)#route-map TRACK

R1(config-route-map)#match ip address prefix-list TRACK

R1(config-route-map)#exit

R1(config)#


R1(config)#router bgp 100

R1(config-router)#neighbor 10.1.13.3 default-originate route-map TRACK

R1(config-router)#neighbor 10.1.14.4 default-originate route-map TRACK

R1(config-router)#


  • Now, let me see R3 and R4 if they got default route from R1:


R4(config-router)#do show ip bgp

BGP table version is 56, local router ID is 4.4.4.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

             r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


   Network         Next Hop           Metric LocPrf Weight Path

*> 0.0.0.0         10.1.14.1               0             0 100 i

*> 1.1.1.1/32       10.1.14.1               0             0 100 i

*> 2.2.2.2/32       10.1.14.1                              0 100 200 i

*> 3.3.3.3/32       10.1.14.1                             0 100 300 i

*> 4.4.4.4/32       0.0.0.0                 0         32768 i

R4(config-router)#


R3(config-router)#do show ip bgp

BGP table version is 54, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

             r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


   Network         Next Hop           Metric LocPrf Weight Path

*> 0.0.0.0         10.1.13.1               0             0 100 i

*> 1.1.1.1/32       10.1.13.1               0             0 100 i

*> 2.2.2.2/32       10.1.13.1                             0 100 200 i

*> 3.3.3.3/32       0.0.0.0                 0         32768 i

*> 4.4.4.4/32       10.1.13.1                             0 100 400 i

R3(config-router)#


Observation:

  • R3 and R4 received the default route from R1.

  • Now, Let me shut the R1’s ser1/0 interface to bring the Track1, so that R1 will withdraw default route towards R3 & R4



R1#debug ip bgp updates

BGP updates debugging is on for address family: IPv4 Unicast

R1#


R1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)#int ser1/0

R1(config-if)#shut

R1(config-if)#

*Mar 1 03:29:00.567: BGP(0): no valid path for 2.2.2.2/32

*Mar 1 03:29:00.567: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Down Interface flap

R1(config-if)#

*Mar 1 03:29:00.571: BGP(0): nettable_walker 2.2.2.2/32 no best path

*Mar 1 03:29:01.567: BGP(0): 10.1.13.3 send unreachable 0.0.0.0/0

*Mar 1 03:29:01.567: BGP(0): 10.1.13.3 enqueued default-originate update

*Mar 1 03:29:01.567: BGP(0): 10.1.14.4 send unreachable 0.0.0.0/0

*Mar 1 03:29:01.567: BGP(0): 10.1.14.4 enqueued default-originate update

R1(config-if)#

*Mar 1 03:29:02.543: %LINK-5-CHANGED: Interface Serial1/0, changed state to administratively down

*Mar 1 03:29:03.543: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down

R1(config-if)#

*Mar 1 03:29:06.139: %TRACKING-5-STATE: 1 ip route 0.0.0.0/0 reachability Up->Down

R1(config-if)#

*Mar 1 03:29:09.575: BGP(0): 10.1.13.3 send unreachable 2.2.2.2/32

*Mar 1 03:29:09.575: BGP(0): 10.1.13.3 send UPDATE 2.2.2.2/32 -- unreachable

*Mar 1 03:29:09.675: BGP(0): updgrp 2 - 10.1.13.3 updates replicated for neighbors: 10.1.14.4

R1(config-if)#do u all

All possible debugging has been turned off

R1(config-if)#


R4(config-router)#do show ip bgp

BGP table version is 58, local router ID is 4.4.4.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

             r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


   Network         Next Hop           Metric LocPrf Weight Path

*> 1.1.1.1/32       10.1.14.1               0             0 100 i

*> 3.3.3.3/32       10.1.14.1                             0 100 300 i

*> 4.4.4.4/32       0.0.0.0                 0         32768 i

R4(config-router)#


R3(config-router)#do show ip bgp

BGP table version is 56, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

             r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


   Network         Next Hop           Metric LocPrf Weight Path

*> 1.1.1.1/32       10.1.13.1               0             0 100 i

*> 3.3.3.3/32       0.0.0.0                 0         32768 i

*> 4.4.4.4/32       10.1.13.1                             0 100 400 i

R3(config-router)#


Observation:

  • R1 has withdrawn the default route to R3 and R3
  • Now, let me bring the R1’s ser1/0 interface up


R1(config-if)#

R1(config-if)#no shut

R1(config-if)#

*Mar 1 03:34:56.939: %LINK-3-UPDOWN: Interface Serial1/0, changed state to up

*Mar 1 03:34:57.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up

R1(config-if)#

*Mar 1 03:34:57.955: BGP(0): 10.1.13.3 enqueued default-originate update

*Mar 1 03:34:57.955: BGP(0): 10.1.14.4 enqueued default-originate update

R1(config-if)#

*Mar 1 03:35:06.139: %TRACKING-5-STATE: 1 ip route 0.0.0.0/0 reachability Down->Up

R1(config-if)#


R4(config-router)#do show ip bgp

BGP table version is 60, local router ID is 4.4.4.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

             r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


   Network         Next Hop           Metric LocPrf Weight Path

*> 0.0.0.0         10.1.14.1               0             0 100 i

*> 1.1.1.1/32       10.1.14.1               0             0 100 i

*> 2.2.2.2/32       10.1.14.1                             0 100 200 i

*> 3.3.3.3/32       10.1.14.1                             0 100 300 i

*> 4.4.4.4/32       0.0.0.0                 0         32768 i

R4(config-router)#


R3(config-router)#do show ip bgp

BGP table version is 58, local router ID is 3.3.3.3

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

             r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete


   Network         Next Hop           Metric LocPrf Weight Path

*> 0.0.0.0         10.1.13.1               0             0 100 i

*> 1.1.1.1/32       10.1.13.1                0             0 100 i

*> 2.2.2.2/32       10.1.13.1                             0 100 200 i

*> 3.3.3.3/32       0.0.0.0                 0         32768 i

*> 4.4.4.4/32       10.1.13.1                             0 100 400 i

R3(config-router)#


Observation:

  • R1 has advertised default route now to R3 and R4


Hope this helps.


Regards,

Usha Rani P

http://mynotesonroutingprotocols.blogspot.in/

Actions

This Discussion

Related Content