Reroute traffic based upon source network?

[Jim Mueller]

I'm not sure if this is the best forum for this question, but I'll start here.

We moved a local web application to the cloud about 2 years ago. After it was moved, we were struggling with performance using the internet route so we ordered a 1G P2P circuit directly between out respective datacenters. After the equipment was upgraded at each datacenter, it was determined during testing that the P2P circuit performance was snappier than the public route. However, there were significantly fewer users testing the private circuit compared to the production web site.

In an effort to offer the best end user experience, management wants to know if we can define which offices/floors (each have their own subnet) use which route to the web application. They don't want to advertise both remote URLs and cause an influx of calls if one of the remote URLs is inaccessible. If either remote host went down, we'd want to make it as simple as possible to adjust the routing so that all clients temporarily used the remote host which was still up.

Local virtual host: private.contoso.com
Remote host 1: https://public.vendor.com, accessed via public internet
Remote host 2: https://private.vendor.com, accessed via private P2P circuit

Sample logic: Client browses to private.contoso.com. If the source IP of the client is within a predefined list of networks, then re-route to remote host 1, else re-route to remote host 2. If the default route is down, use the other host instead.

Any ideas on whether this is possible, and if yes, specifics on how it could be implemented, are appreciated.

Thanks for you help.

[Georg Pauwen]

Hello,

I cannot really tell from your diagram if the two URLs are accessible through two different links. Either way, I have come up with a rudimentary EEM script that would route hosts from a specific subnet (192.168.1.0/24 in this example) through one link by means of applying a route map on the outbound interface. If that link, which is tracked, is down, it would remove the route map and add a new default route.

It would look something like this:

4321#(config)#ip access-list extended 101
4321(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 any
4321(config)#route-map TO_PRIVATE_MAP
4321(config-route-map)#match ip address 101
4321(config-route-map)#set ip next-hop 1.1.1.1

ip route 0.0.0.0 0.0.0.0 1.1.1.1

ip sla 11
icmp-echo 1.1.1.1
threshold 4000
frequency 6
ip sla schedule 11 life forever start-time now

track 11 ip sla 11
default-state up

event manager applet TO_PRIVATE_UP
event track 11 state up
action 1 cli command "enable"
action 2 cli command "conf t"
action 3 cli command "interface GigabitEthernet0/1"
action 4 cli command "ip policy route-map TO_PRIVATE_MAP"
action 5 cli command "end"

event manager applet TO_PRIVATE_DOWN
event track 11 state down
action 1 cli command "enable"
action 2 cli command "conf t"
action 3 cli command "no ip route 0.0.0.0 0.0.0.0 1.1.1.1"
action 4 cli command "ip route 0.0.0.0 0.0.0.0 2.2.2.2"
action 5 cli command "interface GigabitEthernet0/1"
action 6 cli command "no ip policy route-map TO_PRIVATE_MAP"
action 7 cli command "end"

[Jim Mueller]

Hi Georg,

Thank you for the sample script. The public URL would be accessible through the cloud at the bottom of the diagram. The private circuit doesn't happen to be on that diagram, but the local side of the fiber circuit terminates on a Cisco 4431 on port Gi0/1, and the 4431 (Gi0/2) connects to our core switch stack (Gi2/0/48).

I'm not convinced management's request is feasible. Let me add more detail.

A client would browse to an internal URL of our choice and advertised to everyone to use. Based upon the clients source network, a mechanism would default to rerouting the request to the remote public IP/URL (https://www.domain.com/12345company/pages/login.aspx), or if the source network is in a specific list then it would reroute the request to the remote private IP/URL (https://company2.domain.com/12345company/pages/login.aspx). Ideally, it would fail over to the other remote IP/URL if one of them went down.

Even if we get the traffic to the correct remote IP/URL, what's going to rewrite the URL to the correct syntax? It's not going to help if they simply land on an IIS7 landing page instead of the login page. I think that is something that the vendor would need to address on their side?

[Georg Pauwen]

Jim, 

we would need to combine the EEM script with a TCL script to call the specific URLs. I'll see what I can come up with...

[Georg Pauwen]

Hello,

would it be possible to distribute a batch file to users (and create a desktop icon that users can click to execute the batch file) ? The batch file would ping both websites, if one is not available, it would open the other one. The policy routing would take care of the routing and the failover.

Before going into the details of the batch file, would that be a feasible solution ?

[Georg Pauwen]

Hello,

here is the batch file I am thinking of. Basically, the internal URL is pinged,if it responds, it is opened, if not, the external URL is opened. The ping response would be taken care of by the policy routing...

@echo off
ping -n 1 (10.10.10.1) >nul
IF ERRORLEVEL 0 GOTO INTERNAL
IF ERRORLEVEL 1 GOTO EXTERNAL

:INTERNAL
start chrome https://company2.domain.com/12345company/pages/login.aspx
GOTO end

:EXTERNAL
start chrome https://www.domain.com/12345company/pages/login.aspx
GOTO end

[Jim Mueller]

Hi Georg,

While that process is technically feasible, we'd rather have them use central URL hosted on our intranet to access the remote application.

[Ji-Won Park]

Hi,

What you are looking for is called Policy Based Routing, aka Source Based Routing.

The configuration can be different based on your software type and version.

Thanks

JP

[Ganesh Hariharan]

Hi , As Suggested by others ..You should think of PBR but  is the url ip address are static or it will change dynamically.

Check below is the sample PBR configuration based on source ip address..

The following example illustrates how to route traffic from different sources to different places (next hops). Packets arriving from source 1.1.1.1 are sent to the next hop at 3.3.3.3; packets arriving from source 2.2.2.2 are sent to the next hop at 3.3.3.5. 

access-list 1 permit ip 1.1.1.1
access-list 2 permit ip 2.2.2.2
!

interface fastethernet 3/1 
ip policy route-map Source 1
!
route-map Source 1 permit 10
match ip address 1
set ip next-hop 3.3.3.3
!
route-map Source 1 permit 20
match ip address 2
set ip next-hop 3.3.3.5

Hope it Helps..

-GI