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.
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.
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
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
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.
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.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...