Static Routes are easy to begin with right ?
They must have saved your tail many times in production network outage situations.
Though inherent problem from Design perspective with Static Routes is that they are not considered as scalable solution except for small networks. But of course they can be used as duct tape in many cases just like my another favorite duct tape solution known as GRE Tunnels.
Normally Cisco documentation keeps pointing that Static Routes are recursive in nature. But I haven't personally seen many good documents going deep to explain it further with example.
Let's give it a try today :)
Consider the following network as shown below:
Two routers network using static routing...Can't be more simpler right ? :)
Now below are my traffic flow requirements.
The path through Ethernet Switch should be used all the time unless there is a problem, in which case the traffic should follow Backup Path (Point To Point) link.
Now it's easy right ?
One Normal Static Route pointing towards next hop reachable via Ethernet path and one Additional Static Route pointing towards point to point link next hop with higher AD (Administrative Distance) should be enough like shown below.
Let's verify our routing table quickly:
That looks fine.... Cool :)
Now in our first scenario we are going to shutdown f0/0 of R2 to see if our Backup Route gets triggered.
Let's see if our backup route is triggered:
Seems like a problem as we are still pointing route towards 12.0.0.2 which is reachable via our ethernet segment.
But that is something we all must have encountered at some point in production. R1 is not removing the primary route since it's local interface is up and it is completely unaware about the next hop being not reachable.
Simple solution to this problem is using Enhanced Object Tracking feature which can be integrated easily with static route in which there will be an IP SLA instance running and constantly checking next hop reachability and as soon as this probe detects next hop being unavailable, it will remove Static Route from RIB.
I tried by replacing static route from ethernet segment with "exit interface" syntax instead of next hop but that didn't help either.
Let's Unshut the interface back and move on to our next failure case.
Let's fail f0/0 of R1 this time and see if backup route gets triggered:
Now what ?.... Router Gone Crazy or IOS Bug ?
Let's examine some more details:
Let's review RIB:
Now here is a fundamental problem I talked about with Static Routing or Route Recursion process associated with it.
Although my local interface is down pointing towards Next Hop 12.0.0.2, but since 12.0.0.2 is reachable via another path (In Real Life Could Be Intentionally or Unintentionally...Less Specific Network Command under IGP, Redistribute connected etc), our router is not removing primary static route.
So how do we fix it. Simple :)
With this format of Static Route command, we basically force to recurse for next hop only via given interface instead of any interface which is default.
Now static routes should really be simple :)
HTH...
Deepak Arora
Evil CCIE
They must have saved your tail many times in production network outage situations.
Though inherent problem from Design perspective with Static Routes is that they are not considered as scalable solution except for small networks. But of course they can be used as duct tape in many cases just like my another favorite duct tape solution known as GRE Tunnels.
Normally Cisco documentation keeps pointing that Static Routes are recursive in nature. But I haven't personally seen many good documents going deep to explain it further with example.
Let's give it a try today :)
Consider the following network as shown below:
Two routers network using static routing...Can't be more simpler right ? :)
Now below are my traffic flow requirements.
Now it's easy right ?
One Normal Static Route pointing towards next hop reachable via Ethernet path and one Additional Static Route pointing towards point to point link next hop with higher AD (Administrative Distance) should be enough like shown below.
Let's verify our routing table quickly:
That looks fine.... Cool :)
Now in our first scenario we are going to shutdown f0/0 of R2 to see if our Backup Route gets triggered.
Seems like a problem as we are still pointing route towards 12.0.0.2 which is reachable via our ethernet segment.
But that is something we all must have encountered at some point in production. R1 is not removing the primary route since it's local interface is up and it is completely unaware about the next hop being not reachable.
Simple solution to this problem is using Enhanced Object Tracking feature which can be integrated easily with static route in which there will be an IP SLA instance running and constantly checking next hop reachability and as soon as this probe detects next hop being unavailable, it will remove Static Route from RIB.
I tried by replacing static route from ethernet segment with "exit interface" syntax instead of next hop but that didn't help either.
Let's Unshut the interface back and move on to our next failure case.
Let's fail f0/0 of R1 this time and see if backup route gets triggered:
Now what ?.... Router Gone Crazy or IOS Bug ?
Let's examine some more details:
Let's review RIB:
Now here is a fundamental problem I talked about with Static Routing or Route Recursion process associated with it.
Although my local interface is down pointing towards Next Hop 12.0.0.2, but since 12.0.0.2 is reachable via another path (In Real Life Could Be Intentionally or Unintentionally...Less Specific Network Command under IGP, Redistribute connected etc), our router is not removing primary static route.
So how do we fix it. Simple :)
With this format of Static Route command, we basically force to recurse for next hop only via given interface instead of any interface which is default.
Now static routes should really be simple :)
HTH...
Deepak Arora
Evil CCIE
