Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

I think I found an IOS bug

I am testing redundant internet connection for my company. In my lab I have our internet router connect to ISP-A and ISP-B. Traffic going out e0 and e1 (to cable & DSL modems) is NATted to global pools assigned from ISP-A and ISP-B respectively. I found that if I use NAT with rout-map, my ICMP packets will sneak out without being NATed. Debug IP NAT will not even catch the ICMP packets. Packet captures on remote destination also shows the ICMP request packets are sourced from internal addresses.

However, when I put an "ip policy route-map" command on the Inside interface (to route my pulic web server's dual IP addresses), outgoing ICMP echo requests got NATted successfully.

Neither CCO NAT documentation nor the helpful CCIEs on this forum mention that you need to turn on IP policy routing in order to NAT ICMP packets. I followed their examples strictly and even wiped out the config.txt, but ICMP would always sneak out --until I accidentally stumble upon the policy routing command. Initially it was even an incorrectly configured IP policy command! But it worked!

If I use NAT with ACL, everything gets NATted, including ICMP.

Is this an implementation bug?

I am running 12.1(?) on a Cisco 4000 router.

daniel

8 REPLIES
VIP Purple

Re: I think I found an IOS bug

Hello.

I checked the software bug toolkit and couldn´t really find any relevant bugs. The logical explanation for your problem would be that the shortest path for the ICMP packet is another than through your Ethernet interface, although that doesn´t really make sense, since there is no other physical path to the destination. Can you do a traceroute with and without the ip policy route-map configured ? Is there a difference in the hops the traceroute shows ?

Regards,

Georg

New Member

Re: I think I found an IOS bug

Georg,

I used both Ping and traceroute with and without ip policy route-map configured. There is no difference in the hops traceroute shows, because CEF is turned on. Besides, I even down one ISP link and tracert with only one link out. Same result.

I will verify the exact IOS version and 4000 model when I get back to work Monday.

Thanks!

daniel

Bronze

Re: I think I found an IOS bug

Hi Daniel,

Can you post your config, or atleast the nat, route map and access-list part.

Aslam.

Gold

Re: I think I found an IOS bug

Are you pinging from the box itself? If so, this makes sense--the route map won't be applied to locally generated packets, as far as I know. You either have to use the local policy command, which forces the router to use the route map for locally generated packets, or you have to source the traffic from off the box.

The reason for this is that normally you don't want your routing and other protocol packets to be impacted by policy routing, which are all locally generated.

Russ.W

New Member

Re: I think I found an IOS bug

Sorry for replying so late. No, I am not ping from the router box. All my traffic is from the inside client out. After a couple more days messing with it, it became clear that "ip policy route-map" on the inside interface is not the only problem with NAT. Even when ICMP is getting NATted, if I clear the NAT translation table, all my subsequent outgoing ICMP packets will not be NATted. I have to reload the router to resume NAT for ICMP. TCP packets will still get NATted even after I clear the translation table, which is expected.

This whole things gets more perplexing now and I do not know where to start. Before I confuse everbody, here is the running-config for the Cisco 4000 that does the dual NAT for two ISP connections:

version 12.1

no service single-slot-reload-enable

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname INET4000

!

no logging buffered

!

ip subnet-zero

ip cef

!

interface Ethernet0

description Cable-ISP link

ip address 2.2.2.2 255.255.255.0

ip nat outside

media-type 10BaseT

!

interface Ethernet1

description DSL-ISP link

ip address 2.1.1.2 255.255.255.0

ip nat outside

media-type 10BaseT

!

interface Ethernet2

description Corporate Network

ip address 60.0.0.1 255.255.255.0

ip nat inside

ip policy route-map static-map

media-type 10BaseT

!

interface Ethernet3

no ip address

shutdown

media-type 10BaseT

!

ip nat pool cable-pool 2.2.2.100 2.2.2.200 prefix-length 24

ip nat pool dsl-pool 2.1.1.100 2.1.1.200 prefix-length 24

ip nat inside source route-map cable-map pool cable-pool

ip nat inside source route-map dsl-map pool dsl-pool

ip nat inside source static 60.0.0.20 2.1.1.20 <-- dual IPs for inside public web server

ip nat inside source static 60.0.0.10 2.2.2.10

ip classless

ip route 0.0.0.0 0.0.0.0 2.1.1.1

ip route 0.0.0.0 0.0.0.0 2.2.2.1

no ip http server

!

access-list 10 permit 60.0.0.10

access-list 20 permit 60.0.0.20

access-list 50 permit 60.0.0.32 0.0.0.31

route-map dsl-map permit 10

match ip address 50

match interface Ethernet1

!

route-map cable-map permit 10

match ip address 50

match interface Ethernet0

!

route-map static-map permit 10

match ip address 10

set interface Ethernet0 <-- route packets from 1st web server IP through Cable-ISP

!

route-map static-map permit 20

match ip address 20

set interface Ethernet1 <-- route packets from 2nd web server IP thru DSL-ISP (see static NAT entries)

Despite the ICMP NAT problem, I thought my outgoing TCP connections worked pretty well w/ CEF per destination and NAT/route-map, until I put an ACL on 2.2.2.1 (Cable-ISP router 2500) to block incoming traffic sourced from 2.1.1.0 (DSL-ISP), and an ACL on 2.1.1.1 (DSL-ISP router 2500) to block incoming traffic fsourced from 2.2.2.0, simulating the anti-spoofing mechanism on ISP routers.

Now with these two ACLs, my outgoing TCP connection becomes very slow. Outgoing ICMP packets sometimes will be successful but most of the time will time out. For example, if I reload the router, "ping -t 200.2.2.20" from 60.0.0.63 (internal) will be successful for a while and then start to time out continuously. "sh ip cef exact-route 60.0.0.63 200.2.2.20" shows that route is using e0, next hop 2.2.2.1 (Cable-ISP). "sh ip nat tr" shows 60.0.0.63 is NATted to 2.2.2.100.

In the meantime, if I "ping -t 2.2.2.100" from 200.2.2.20 (remote), packets will time out every other packet:

reply from 2.2.2.100

timed out

reply from 2.2.2.100

timed out

replay from 2.2.2.100

timed out

...

It seems CEF per destination is still not using a fixed route for a given source-destination pair during load sharing.

I try a bunch of combination of commands like ip cef, ip load-sharing per-packet, no ip cef, ip route-cache flow, no ip route-cache. Some of these combination let ICMP sneak out without NAT. None of them make TCP connections faster but do make me dazed :))

I apologize for the lengthy message.

Appreciate it so much!

daniel

Gold

Re: I think I found an IOS bug

Okay--why are youusing the set interface in the route-map for the NAT pool? I'm not certain this will work--NAT is just going to use the route maps to admit packets into the respective pools, not to route them (?). I would think you would just select the NAT pool, and then use standard policy based routing to select the interface (?), or just let it route normally.

Another option, the one I would try first, would be to match on the outbound interface, rather than the ip address, when you're selecting the nat pool to use. The packet should come in, get routed, and then the nat pool will be chosen based on the interface the packets was routed through.

Or at least that should be the way it works.

Russ.W

New Member

Re: I think I found an IOS bug

Russ,

What you suggested is exactly what I tried to accomplish in the config file. I guess my message is so long that it's confusing.

The "set interface" command is actually in the static-map, which is used to route packets from the two internal IPs of our public web server. I set the interface so that it will match the static NAT translation for that particular internal address.

The route maps used for dynamic NAT pools are called cable-map and dsl-map. Neither has the set interface command.

access-list 10 permit 60.0.0.10 <-- web server 1st IP

access-list 20 permit 60.0.0.20 <-- web server 2nd IP

access-list 50 permit 60.0.0.32 0.0.0.31 <-- range of hosts permitted for dynamic NAT

route-map dsl-map permit 10

match ip address 50 <- match regular internal clients

match interface Ethernet1 <-- outgoing port matches e1, port to DSL ISP

!

route-map cable-map permit 10

match ip address 50 <-- match regular internal clients

match interface Ethernet0 <-- outgoing port matches e0, port to Cable ISP

So, DSL-map and cable-map are used to choose the right NAT pool, while static-map is used to Policy route packets from the interal public web server w/ static NAT translation.

I just can't see anything wrong in the config.

Thanks,

daniel

Gold

Re: I think I found an IOS bug

Yes, I agree, I don't see what's wrong with this, other than that possibly it just won't work in the way we are thinking it should. The only thing I can think of is to either set it up in the lab, or to ask one of the folks around here that knows a lot more about NAT than I do.

If you send me your configs off line, I'll try and figure one of those two out.

Russ.W

riw@cisco.com

120
Views
0
Helpful
8
Replies