route outbound traffic based on source ip with automatic switch to backup link

[netone.cisco]

Hello fellow "ciscoers"

We are an ISP with two internet uplinks, one submarine fiber and other Satelite. We want traffic from a group of customers (differentiated by IP addresses) to flow though one link and the other via satelite and one should be backup for the other.

We are already doing this for incoming traffic with BGP prefix-lists and prepending.

Any one can help me doing this for outgoing traffic? PBR is one way but the problem is we have to go and manually change configuration if one link fails.

Important: The link that may fail is not directly connected to us. In case any link fails the interface and BGP neighbour still remain up.

Thanks in advance

[Mahesh Gohil]

Hi,

This is always a challenge because bgp is very robust but still it is destination based protocol.

In PBR automated fallback is not possible (Or i have not seen anywhere) even if you put different condition with multiple route-map statement.

The best way is learning different routes from both provider apart from default route. Like you can learn full-bgp (or only provider own routes) from both provider and use attribute to load-share.

Like for example learn partial table from both provider and put route-map in out direction with matching regular expression..

> Match first provider originated route in first route-map with regular expression as ^ProviderA_As_No  and allow to pass from
  that peering
> Match second provider originated route in second route-map with regular expression as ^ProviderB_As_No  and allow to pass from
  that peering
> As a backup of this put additional route-map statement with default route with different local preference

well all this depends upon if you learn more than default from provider

Hope this helps

Regards

Mahesh

[Richard Burts · Accepted solution]

Mahesh

You should look into the implementation of PBR using the verify reachability parameters on the set statement. The verify reachability uses IP SLA to verify reachability and has been supported for quite a while. If verify reachability indicates that it has failed then the PBR set statement is not used.

Mario

As I suggested to Mahesh, I believe that the verify reachability capability of Policy Based Routing makes it a viable solution for you. I am very puzzled about how the link could go down and the BGP neighbor could still be up. If the link is down how is there communication to the BGP neighbor?

HTH

Rick

[Mahesh Gohil]

Thanks rick for filling me ..any document link if you can share

Regards

Mahesh

[Richard Burts]

Mahesh

Part of the link provided by Mohamed should give you a good starting place:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtpbrtrk.html#wp1056347

in particular look at step 15 with verify-availability

HTH

Rick

[Mohamed Sobair · Accepted solution]

Hi,

Based on Source IP Address, you only have an Option with PBR.

Here is the Solution for you according to your requirment, you need (PBR support for multiple tracking Options).

With this setup, the PBR tracks the bgp Neighbor not the directly connected interface by normal ICMP (Configurable), if the neighborship BGP fails , the PBR is not active and you dont have to manually change the configuration.

check this document , and let us know if this solves your problem;

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtpbrtrk.html

HTH

Mohamed

[netone.cisco]

Hello everyone,

Thanks for your replies. I believe reachability testing is exactly what we need. Commands on the link are a bit different but I can check the correct sintax for our platform.

Richard,

To understand how the peer is up when the link goes down, check my attachment. We get internet from a provider which gets it from other provider. Full internet table comes from the 2nd upstream provider. Our provider just provides transit.

So, from what i understood I need to

1. configure ip sla to reachability to our provider's provider first hop router (not the directly connected router)

2. configure a tracker

3. configure route-maps to match the different ip address ranges for source address and the set different next-hops

4. apply to the incoming traffic interface

Is that it?

Unfortunately we dont have a test network so to test we will have to do schedule for downtime.

[Richard Burts]

Mario

I may still be a bit confused. When you talk about a problem when a link goes down are you talking about the link from your provider to their upstream going down? If your provider has only a single upstream then yes that could create a problem for you. It would be desirable (and would solve this problem) if the provider had more than one upstream (and many providers do have redundant upstream connections).

The 4 steps you identify are correct. You have a good point that the syntax may vary depending on the platform (and sometimes varies by release level) so you need to find the correct syntax for your particular platform and release. And in the situation that you describe you probably would want to track something in the network of your provider's provider.

HTH

Rick

[netone.cisco]

Hi Rick,

Yes, the link that may go down is the one from our provider to their uplink. Our connection to our provider is an ethernet cable. We are using their datacenter co-location service and their router are in rooms less than 50m away from our racks. These ethernet links actually never been down.

The WAN links from our provider to the other countries are the ones who have less than 95% availability.

They do have many links and provide redundancy to other customers but the service we get from them we buy bandwidth from a specific type of WAN link (satellite / SAT3 submarine fiber) so that our company has control of the traffic, redundancy, etc.

Sorry if I'm not being very clear, maybe there is a term for this kind of topology but english is not my native language.

For information for anyone actually trying or going to use this, there is one important step missing which would actualy be step 0 and we already had to do to monitor link availability.

step 0: configure static router for the 1st level provider router (provider's provider)  with next hop to the appropriate 2nd level provider (our provider)

This is necessary because we get full internet routes from both links and if one goes down, both 1st level router will still be reachable from the other link. With static /32 routes the router will send traffic the way we want it to.

[Richard Burts]

Mario

I do appreciate the difficulty in communicating in a language that is not your native language and I think you are doing pretty well with English. I do understand your environment better. I would have hoped that if their upstream link went down that they would stop advertising a default route to you. But apparently they continue to advertise the default route. And in that case the option to track, and to track to their upstream provider should provide the functionality that you need.

I am glad that you caught the need to configure /32 static routes as part of the tracking. When you are learning redundant routes from both providers, then you do need to be careful that your tracking packets are going out the interface that you intended.

HTH

Rick