We have a single Internet feed (Receiving full BGP table) in a remote location servicing DSL clients.
This remote location is connected to our core network via a private link (Used for pushing a nightly netflow data file back to our netflow processing box) - I would like to allow our DSL clients to utilise this private link (And subsequently our core networks Internet feeds) in the event of failure.
Is a route-map the preffered method?
route-map DSL-Clients permit 10
match ip address 101
set ip next-hop primary_internet_gw
set ip next-hop redundant_internet_gw
Thanks in advance.
Couldn't you do this with straight routing? Where is this route map applpied?
Since you are receiving full internet routes at the remote, it seems to me that you could just feed a default along the DSL link, and if the primary internet connection fails, they would use the DSL link to reach the Internet. Of course, you'll also need to advertise the more specific rotues that are reachable at the main location.
route map is applied to the portchannel sub-interface of our inter-connection with the DSL provider.
We are not responsible for session management of the DSL connections - Our clients (And our remote router) are part of the same VRF (So each DSL client has a default route of our remote router) - This is performed by our DSL provider.
The remote router has only one upstream connection (Therefore the entire BGP table is not really necessary!), and we are advertising more definitive routes via that connection for IP's assigned to the DSL clients (Our aggregate advertisement occurs via our multiple upstreams at our core network - Therefore if remote routers Internet feed goes down, traffic destined for the networks advertised there would come in via our core networks upstreams).
So traffic destined for our DSL clients will function in the event of failure, but traffic originating from our DSL clients must go via an alternate gw in the event of primary failure.
Excellent - So by adding a distance metric that is relatively high, the alternate gw will only be used if primary gw is down(failed)?
Much simpler! Thanks.
Ok - Applying a Distance metric to the alternate default gw does not appear to work (Unless I am doing something incorrect!)
ip route 0.0.0.0 0.0.0.0 primary_def_gw
ip route 0.0.0.0 0.0.0.0 alternate_def_gw 250
ip route local_network 255.255.240.0 local_network
Primary_def_gw is currently not accessible, yet I cannot get anywhere apart from our local_net.
Would this be due to the router doing one-armed routing?(So all eth. sub-interfacess are in a state of "up")? - In other words, the primary default route would always be in the routing table?
#show ip route
Gateway of last resort is primary_def_gw to network 0.0.0.0
The primary route will only be removed from the routing table if there's no route to primary_def_gw; e.g., if the subinterface on which it is directly-connected changes state to "down".
This is where some type of ping-based routing would be nice but unfortunately there's no such feature right now. I suspect it's imminent, however, as policy-routing has very recently been given "failover to an alternate next-hop if the primary one stops responding to pings" capability, so static routes are a logical next step.
Ok - So what are my options here? (As the sub-interfaces will always be in a state of "up")
A route-map with ip next-hop? (As per my original message?)
What I suggest is using route-map with a "ip next-hop verify". This would work if both routers are cdp enabled. Once your primary fails, it should switch to the secondary when the cdp neighbour is down.
You can change the cdp timeout to a shorter period if a fast failover is required, default is 180secs.
Hope this helps.
I found something that might be interesting to you.
Check "Reliable Static Routing Backup Using Object Tracking". This feature was introduced in 12.3.2XE
Ah, nice find. The non-partner link is here: http://www.cisco.com/en/US/products/sw/iosswrel/ps5413/products_feature_guide09186a00801d862d.html
So this feature has been introduced into a special IOS release for the 800 and 1700 router series. Though it says that "DDR must be configured" in order for this to work, that appears not to be the case as one of the configuration examples given is with two Ethernet interfaces.
Hopefully this will get integrated into 12.3(5)T or whatever the next T-train release is. It's long overdue and will be a tremendous help in (very common) situations where static route failover is desired.