NAT only to BGP routed destinations

[Chris Bennetts]

I want to NAT traffic to only destinations that are recieved as BGP routes (Any BGP routes will do, not just a particular neighbour).

RTR1 has 3 connections, LAN1 (10.3.0.1/24) and 2 WAN connections with BGP peering on WAN1 connection for some specific 10.0.0.0/8 addresses in the form of /16 and /24 subnets. RTR1 then has a 10.0.0.0/8 route via the WAN2 connection for traffic not matching the BGP sourced subnets.

RTR2 has an IP in LAN1 (10.3.0.2/24 fa0/1) and an IP in LAN2 (10.3.11.1/24 fa0/0). RTR2 has 10.0.0.0/8 routed to 10.3.0.1 and it also has BGP peering with RTR1 to get the specific routes that use WAN1.

so it looks like this:

LAN2-> RTR2 -> LAN1 -> RTR1 -> WAN1 (with BGP)

                                               -> WAN2 (static route)

Essentially I want to NAT traffic on RTR2 (coming from 10.3.11.0/24) going to the BGP sourced destinations. say for example 10.250.0.0/16 is via WAN1(BGP) and 10.100.0.0/16 is via WAN2 (static route)

Normally I would do this on RTR1, but due to other NAT setup on RTR1 it is not possible.

I peered RTR2 to RTR1 so it has the BGP peer list in the hope that I could match the traffic somehow to match an "ip nat inside" command.

My thought was do something like this:

ip nat inside route-map NAT2BGP interface interface FastEthernet0/1 overload

But I have not found a way in a route-map to match traffic from the BGP peer or even any BGP routes.

Does anyone have any suggestions?

Thanks

[Peter Paluch]

Hello Chris,

I assume that your BGP-learned routes have a common next-hop IP address (or only a couple of next-hop addresses), don't they? If so then you can use the match ip next-hop command in the route-map to perform the NAT only in the case that the next-hop of a packet under question matches the BGP peer.

Alternatively, I was thinking about tagging all BGP-received routes with some special tag, say, 12345, and then use the match tag in your route-map to NAT only those packets that are forwarded according to the tagged routing table entries but I am not sure if the match tag is supported for NAT usage. The match ip next-hop, however, should work as expected.

Let us know if this worked for you.

Best regards,

Peter

[Chris Bennetts]

Hi Peter,

Unfortunately I could not match the next hop as they were both the same (i.e. the next hop for both the static and bgp sourced locations was the LAN1 interface on RTR1.

I tried using the match as-path which didn't work, tagging the routes unfortunately also didn't work.

I've implemented a tunnel interface between the 2 routers for the static routes so they exit a different interface as a workaround.

Thanks for the help anyways.

- Chris

[milan.kulik]

Hi Chris,

if tagging the routes didn't work, what about changing the next-hop for BGP routes?

You could make it the RTR1's BGP neighbor address by

1) removing

neighbor RTR2 next-hop-self

from RTR1 BGP configuration, if you are running iBGP between RTR2 and RTR1.

2) configuring and incoming BGP route-map

with set next-hop RTR1's_neighbor_address

on RTR2.

RTR2 would have to make a recurring RIB lookup to route to a BGP site and you would need one additional static route on RTR2 (destination: RTR1's BGP neighbor address, netx-hop: RTR1's LAN1 address), but I don't suppose that to be a problem.

I hope your NAT2BGP route-map "match the next hop" command would be looking into RIB (and not CEF FIB) and would see a different next-hop for BGP destinations and static routes.

BR,

Milan

[Peter Paluch]

Milan,

That's an excellent idea - modifying the next-hop attribute of the BGP routes to a different, specific value that is recursively pointing towards RTR1! That next-hop IP may be arbitrary as long as it is unique, say ,192.0.2.1, as long as there is another route (static) set up on RTR2 that directs the 192.0.2.1 towards RTR1. Gee, how could I miss that? Hat off, this is an awesome trick!

I hope Chris will be able to test your solution and come back to tell us whether it worked.

Best regards,

Peter

[milan.kulik]

Hi Peter,

yeah, I had to use the trick of changing BGP next-hop by an incoming route-map a long time ago for some very specific problem.

I don't remember details anymore.

It can be quite dangerous though, I'm afraid  (I was even surprised it was available in IOS).

So I hope the light version - removing next-hop-self from an iBGP session - should work here.

BR,

Milan