If...then...NAT

[lincolnwebber]

Ok guys,

I dont know if this has been something thats frequently required, but anyway here goes.

Lets say I have a DMVPN consisting of 2 HUBs at one location and a third HUB at another location. There are also a couple spokes scattered about. Now theres a particular application to which the clients behind the spokes connect at the Main HUB site (location with 2 hubs). The Backup site (location with 1 hub) is serving this application as well in the event of a failure at the main site.

However, the clients at the spoke are hardcoded with the IP address of the main site application server (changing this is not an option). In the event of a failure of the server at the main site, we require the client to be directed to the backup site server.

So in summary, the client will always transmit a packet destined to the IP address of the server at the main site, even when the server is not available for any reason.

So, the question:

Is there any combination of IP SLA, TRACKING, ROUTE MAPS and NAT that may be used to translate the destination of the packet from the client when the router recognises that the main site server is unreachable?

[Marwan ALshawi]

How do setup you dmvpn tunnel or tunnels

Do you have multiple tunnels and the backup tunnel used in case of main site down ?

If this is the case the let's say tunnel interface 2 is the backup tunnel

Then set up a static nat with a route map that match the exit interface in this case interface tunnel 2 as a condition for nat

For example

Route-map map1

Match interface tunnel 2

Ip nat inside source static 1.1.1.1 10.10.10.10 route-map map1

In the case that nat will occur only when the traffic is routed over tunnel 2

Hope this help

If helpful rate

[lincolnwebber]

Thanks Marwan,

However I just recognized a problem with mith my logic. Before I get into that though. Let me explain the conceptual setup.

The spokes would probably be load balancing traffic headed towards the main site via the 2 hubs. Both hubs at the main site would share an internal subnet, and would probably be in an HSRP group as well.

The Backup site would obviously be connected to a different internal subnet, which would have the backup application server on that subnet.

Now back to what i overlooked.

When the main site routers have completely failed, the spokes will lose their routes to the main site subnets. But the clients at the spoke sites still source a packet destined to the IP of the application server at the main site.

What will prevent that route map you gave me from being applied under normal circumstances, i.e. when the main site routers are reachable?

[Marwan ALshawi]

As I mentioned I am assuming your using different dmvpn tunnel for the main site

And a second tunnel used for the backup site as in the above example tunnel 2

Once sthe main site is Down the route will go over tunnel 2 as a exit interface and the nat will take effect

[Peter Paluch]

Lincoln, Marwan,

I am thinking of a slightly different approach but it's up to you guys to evaluate it.

I was thinking about announcing a /32 route specifically to the server's address from both the primary and backup hub location. This /32 route can be a static route installed to the routing table on both primary and backup hub and then redistributed into the DMVPN cloud. Moreover, these /32 routes would be controlled by an IP SLA to be present in the routing table (and hence redistributed) only if the server responds to pings. Then, trivial seed metric during the redistribution would make sure that the primary site is the preferred destination.

This would assume that the server indeed has the same IP address both on the primary and secondary site (not so difficult to accomplish). No NAT would be necessary.

Would this concept work for you, Lincoln?

Best regards,

Peter

[Marwan ALshawi]

Hi Peter

This is indeed another option can be considered if it can be deployed

But also we ca use same concept but the NAT can be done on the backup site router rather than on the branch router

In this case the second advertised host route will be used in the case of the main site is down and then the nat will beer formed on the backup site router with simple static NAT !

[lincolnwebber]

Peter,

You are spot on...up to having both servers on different sites with the same IP address. I dont know if this would be desired by the customer.

So Marwan's concept would come into play because duplicating the server's IP isn't an option.

But back to you Peter,

Please confirm if I have understood your concept:

Announce static host routes for the main site app server on all hubs.

Redistribute this route into the dynamic routing protocol

• On the spoke routing table, this route would point to the main site, but would still be in the eigrp topology (if its the protocol being used) via the backup site.
  

If the server is unreachable from the main site router, an IP SLA echo configuration would remove this route from the table, preventing it from being anounced into the dynamic routing protocol, hence leaving the spoke to promote the route pointing to the Backup site into the routing table

With the spoke router now sending packets destined to the server's IP to the backup site's router, a destination NAT would be required to translate the main site server IP to the backup site server IP.

What would the /32 route look like in the HUB routers? would we point it to NULL?

What would the IP SLA config look like? what about the tracking?

Give me some example syntax please.

[Marwan ALshawi]

You got the point of Peter

But he advised you to relay on routing protocol for path selection without the need to use ip sla

Also you mixed it with NAT on the destination hub is a good idea where you can add a static route point to null 0 in the hub to be redistributed and then nated

While in the main site you need to have to static route to point to the actual server or any next hope connected to that server

Not sure if Peter has different approach for this !

HTH

Plz rate the helpful posts

[lincolnwebber]

Thanks very much Marwan,

However, the IP SLA would be used just for the main site router to check the availability of the server. For instance if it is taken offline for maintenance. In this case, we would want to the spokes to send their traffic to the backup site, even though the main site DMVPN tunnels are up.

[Marwan ALshawi]

Yes you can do that and better for high availability

Just associate the ip sla track with main site host static route

Btw thanks for the nice rating

[lincolnwebber]

I am tryig to implement this now. I have the traffic reaching the secondary site router. How do I compose the NAT command so that the route to Null0 does not discard the packet? Should the tunnel interface be the outside nat interface?

[Marwan ALshawi]

Yes

Sent from Cisco Technical Support iPhone App

[lincolnwebber]

Is there a way that i can perform the destination NAT on the packet based on the source in that same packet.

I want traffic coming from only specific hosts to be desination NATed on entry to the outside interface.

This is because i want all other communication between the inside host to use its original address when initiating communication.