cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
419
Views
6
Helpful
6
Replies

Default static floating route

marechaujeremie
Level 1
Level 1

Hi guys,

I don't manage to create a default static floating route for my lab. It's made of real devices but I did a diagram of the topology (relevant part attached). I would like Core 1 and Core 2 switches to forward to the Internet via their directly connected router, but if this fails, use the route through the other Core and router. Issuing the following commands and disconnecting the router doesn't modify the routing table and the connexion fails rather than taking the longer path.

Core1:
ip route 0.0.0.0 0.0.0.0 10.1.1.253
ip route 0.0.0.0 0.0.0.0 10.1.1.250 2

Core2:
ip route 0.0.0.0 0.0.0.0 10.1.1.250
ip route 0.0.0.0 0.0.0.0 10.1.1.253 2

After researching a bit the limitation seems related to the Core switches' interfaces connected to the routers being L2.

Would anyone have an idea how to create my default static floating route without changing the whole config?

Many thanks!

image.png

1 Accepted Solution

Accepted Solutions

Jens Albrecht
Level 3
Level 3

Hi @marechaujeremie,

if e.g. R1 fails, the SVI on the core switches remains up so that the route to R1 does not get removed from the routing table.

You need to track the reachability of the routers on your core switches and there are different ways to achieve the desired result depending on the exact condition that should trigger the fail-over.

The easiest way is to track the link from each core switch to the directly connected router.
So on Core1 you create track 1 to monitor the line-protocol of int Gi1/0/22 and add this tracking object to your static route.

In case you want to fail-over if R1 is still running but lost its connection via Gi0/1 to the internet, then you need to create a tracking object that monitors an IP SLA sending pings to the IP address of R1's Gi0/1 and then add this tracking object to your static route.

Finally, instead of using floating static routes on your core switches, you could also create another HSRP process between your routers and then point the static routes from the core switches to this new HSRP process.

So there are different ways depending on what you want to achieve.
Let us know if you need help to create the tracks and/or IP SLAs. We can also explain the necessary config step-by-step if you tell us what condition you want to use for fail-over.

HTH!

View solution in original post

6 Replies 6

Jens Albrecht
Level 3
Level 3

Hi @marechaujeremie,

if e.g. R1 fails, the SVI on the core switches remains up so that the route to R1 does not get removed from the routing table.

You need to track the reachability of the routers on your core switches and there are different ways to achieve the desired result depending on the exact condition that should trigger the fail-over.

The easiest way is to track the link from each core switch to the directly connected router.
So on Core1 you create track 1 to monitor the line-protocol of int Gi1/0/22 and add this tracking object to your static route.

In case you want to fail-over if R1 is still running but lost its connection via Gi0/1 to the internet, then you need to create a tracking object that monitors an IP SLA sending pings to the IP address of R1's Gi0/1 and then add this tracking object to your static route.

Finally, instead of using floating static routes on your core switches, you could also create another HSRP process between your routers and then point the static routes from the core switches to this new HSRP process.

So there are different ways depending on what you want to achieve.
Let us know if you need help to create the tracks and/or IP SLAs. We can also explain the necessary config step-by-step if you tell us what condition you want to use for fail-over.

HTH!

shambhu.kumar
Spotlight
Spotlight

physical interface and VLAN interface is remain in up state and this is the reason fail over not happening.

for example,

track 2 ip route 0.0.0.0 0.0.0.0 reachability
!
interface vlan 10
ip address x.x.x.x y.y.y.y
standby 10 ip 10.1.1.254
standby 10 priority 255
standby 10 preempt

standby 10 track 2 decrement 160      ! keep another side priority less.

marechaujeremie
Level 1
Level 1

Hi @Jens Albrecht,

Many thanks for the enlightenment!
I passed CCNA recently and I'm trying to go further. I found some doc online and was able to implement the IP SLA feature. I'm delighted I learnt something today, very impressed by the community here!
Thanks also to @shambhu.kumar, I'll try this in the future.
Here's my config in case some newbies wonder the same as I did:

I ensured the routers outside interfaces get a static IP; 192.168.1.6 for R1 and 192.168.1.7 for R2.
I configured host routes to these on both core switches with the inside interface of the relevant router as next hop:

ip route 192.168.1.6 255.255.255.255 10.1.1.253
ip route 192.168.1.7 255.255.255.255 10.1.1.250

I configured IP SLA tracking as follows on Core1:

ip sla 1
    icmp-echo 192.168.1.6
        timeout 100
        frequency 1

ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability

Same  for Core 2 with icmp-echo 192.168.1.7

I finally configured the default routes tracking the primary one:

Core1
ip route 0.0.0.0 0.0.0.0 192.168.1.6 track 1
ip route 0.0.0.0 0.0.0.0 192.168.1.7 2

Core2
ip route 0.0.0.0 0.0.0.0 192.168.1.7 track 1
ip route 0.0.0.0 0.0.0.0 192.168.1.6 2

Thank you again!

Hi @marechaujeremie,

the config you posted looks good and I assume that you already tested failover successfully. Nice work!

Good luck on your journey towards CCNP and we are here to answer any further questions you may have.

Regards, Jens

Hi @Jens Albrecht,

Indeed, I didn’t precise but the failover works like a charm, and thanks a lot for the encouragements!

 

Jeremie

Joseph W. Doherty
Hall of Fame
Hall of Fame

Would anyone have an idea how to create my default static floating route without changing the whole config?

That's been "solved" (BTW, take special note of Jens' mention of using Internet side of Internet routers as SLA target although using DHCP address on them, adds a wrinkle) but there may be further alternatives that may be better for your service goals and/or possibly "better" practice.

For example, from each core perhaps you would benefit spliting Internet egress traffic, from each core, across both Internet paths.

Or, rather than using a Cisco dependent (?) SLA tracking methodology, you use classical L3 dynamic routing.

Insufficient information to say whether any other approach offers you any benefit, but conversely when you, sort of, reinvent dynamic routing, possibly it's reasonable to review your approach.

Similarly, if and while perhaps re-assessing your network, as you have two core devices running HSRP, possibly mHSRP, GLBP would be a better option.  Or, whether VLAN 1 should be used, etc.