[c-nsp] PBR with NAT/PAT - strange (non-deterministic) behaviour
Dale Shaw
dale.shaw+cisco-nsp at gmail.com
Fri Mar 7 02:24:39 EST 2008
Hi all,
I'm trying to configure two 2611XMs to do PBR and NAT. The relevant
config snippet is included below, but essentially one of the routers
is doing what I want, and the other isn't. I suspect I'm hitting an
IOS bug, or my config isn't quite right (hmmm, thanks captain
obvious.)
I have a PBR policy-map applied on each router's Fa0/0 interface
(ingress). The route-map references an ACL that matches traffic I want
to send in a direction the routing table would not otherwise have it
go (i.e. S0/1.x instead of S0/0.x). To ensure symmetric routing, I
want to source NAT (PAT) traffic leaving the interface to that
interface's IP. All pretty straight-forward.
Another requirement: if the interface specified by the 'set ip
next-hop' parameter in the PBR route-map is down (e.g. S0/1.x), I want
traffic to be routed as normal via S0/0.x (as I understand it should),
but I want to do the same source NAT/PAT on the other interface -- in
other words, if the traffic leaves S0/1.x, it should be source NATed
to S0/1.x's IP and if it leaves S0/0.x, it should leave with S0/0.x's
IP.
The results:
On one router, it works fine -- 'sh ip nat trans', 'sh ip cache flow'
and 'sh policy int out' all show me what I want to see.
On the other router (configured in exactly the same way aside from the
obvious interface IP/next-hop differences), PBR is working and the
traffic leaves the correct interface (S0/1.x), but it leaves the
interface with S0/0.x's IP as a source! Asymmetric routing ensues.
I think the two "ip nat inside source route-map .." commands are
clobbering each other, and it was probably just dumb luck that one
router is working as intended and the other isn't. Both lines appear
in the config, but perhaps only the last one entered actually works?
Is there something I can do, perhaps in the NAT route-maps, to nail
the config down and make it more deterministic?
Upgrading the IOS is only really an option if I can pin this behaviour
to a documented bug.
Here is the (annotated) config from the first router. The other router
is configured in exactly the same way, apart from interface IPs,
subint/DLCIs, and the 'set ip next-hop' value in the App01-PBR
route-map.
! IOS (tm) C2600 Software (C2600-IPBASE-M), Version 12.3(6c), RELEASE
SOFTWARE (fc1)
!
interface FastEthernet0/0
! -- this is the ingress interface
!
ip address 192.168.90.30 255.255.255.224
no ip redirects
no ip proxy-arp
ip nat inside
ip flow ingress
ip policy route-map App01-PBR
!
interface Serial0/0
bandwidth 256
no ip address
encapsulation frame-relay
load-interval 30
frame-relay lmi-type ansi
!
interface Serial0/0.740 point-to-point
! -- this is the way traffic would go under normal
! conditions (no PBR). if S0/1.742 is down, traffic
! should leave via this interface and be src
! NAT'd to 192.168.91.138.
!
bandwidth 128
ip address 192.168.91.138 255.255.255.252
no ip redirects
no ip proxy-arp
ip nat outside
ip flow ingress
frame-relay interface-dlci 740
!
interface Serial0/1
bandwidth 256
no ip address
encapsulation frame-relay
load-interval 30
frame-relay lmi-type ansi
!
interface Serial0/1.742 point-to-point
! -- this is where I want policy-routed traffic
! to go. Traffic should leave with a src
! IP of 192.168.91.142.
!
bandwidth 128
ip address 192.168.91.142 255.255.255.252
no ip redirects
no ip proxy-arp
ip nat outside
ip flow ingress
frame-relay interface-dlci 742
!
ip nat inside source route-map App01-NAT-FOO1 interface Serial0/1.742 overload
ip nat inside source route-map App01-NAT-FOO2 interface Serial0/0.740 overload
!
access-list 125 remark ** match HTTP to server 1 **
access-list 125 permit tcp any host 192.168.91.67 eq www
access-list 125 remark ** match HTTP to server 2 **
access-list 125 permit tcp any host 192.168.91.3 eq www
!
route-map App01-PBR permit 10
match ip address 125
set ip next-hop 192.168.91.141
!
! -- even though the following route-maps are essentially the same,
! I found I needed to use two, otherwise only one "ip nat inside source .."
! command was supported (each one needs/wants its own route-map?).
!
route-map App01-NAT-FOO1 permit 10
match ip address 125
!
route-map App01-NAT-FOO2 permit 10
match ip address 125
!
! -- I tried using "match ip next-hop .." in the NAT route-maps above but
! I couldn't make it work. I thought this might be a way to 'nail down'
! the config a bit.
!
end
More information about the cisco-nsp
mailing list