09-02-2008 07:21 AM - edited 03-03-2019 11:22 PM
Hi there,
I am having a problem implementing the route-map argument with the static nat statement:
ip access-list extended COSMIC-MATCH
permit ip 10.0.0.0 0.255.255.255 18.0.0.0 0.255.255.255
route-map COSMIC permit 10 match ip address COSMIC-MATCH
ip nat inside source static network 10.0.0.0 53.0.0.0 /8 route-map COSMIC
Basically, what I want to accomplish is a static subnet nat translation from between 10.0.0.0 and 53.0.0.0
But I only want some specific conversations to be NATted, so I added a ACL in combination with a route-map, to specifiy the traffic to be NATted.
When I test the conversations specified in the ACL, the NAT process does add the translation, but only as fasr as the classufll bits count, 10.0.0.0 in this case. Show ip nat translations shows us the following:
R019#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 53.x.x.1:1024 10.0.0.0:1024 18.0.0.2:1024 18.0.0.2:1024
--- 53.0.0.0 10.0.0.0 --- ---
Apparently it translates 53.61.35.1 to 10.0.0.0 instead of 10.61.35.1
When I leave the route-map out of the ip nat inside statement, all works just fine:
R019#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 53.61.35.1:1024 10.61.35.1:1024 18.0.0.2:1024 18.0.0.2:1024
--- 53.0.0.0 10.0.0.0 --- ---
But now, all traffic gets NATted. Using ip nat pools is also no solutions, because the conversation must be able to be initiated from both sides, not dynamically.
Does anyone have any experience in using route-maps with static subnet translations?
Thanks!
09-08-2008 04:08 PM
ur config generally looks good
except the ACL ithink ur problem with the ACL
ip access-list extended COSMIC-MATCH
permit ip 10.0.0.0 0.255.255.255 18.0.0.0 0.255.255.255
make it more spisific like
10.61.35.0 0.0.0.255
good luck
if helpful Rate
09-08-2008 11:19 PM
thanks for your reply.
I have investigated this a bit more in the past few days, and It appears to me, that this specific static nat with route-maps feature, is behaving differently in some IOS releases.
The last succesfull test i did, was with the use of the "extendable" keyword in the NAT statement:
ip nat inside source static network 10.0.0.0 53.0.0.0 /8 route-map COSMIC-NAT extendable
after implementing this in my config, the specific ip connections, did get NATted the correct way, and not just the first 8 bits. All this sounds not clear to me, and I think they have to further investigate this issue.
09-09-2008 04:06 AM
hi Dion
u have done it right and this is 5 points :)
and this is the answer for the config u have done:
Typically, the ip nat inside source static command is used to translate a small number of entries between your network and two other networks. However, this command provides one interesting parameter: extendable. This parameter causes the Cisco IOS to create an extended translation entry in the translation table instead of a simple entry
example, internal has two Internet connections for redundancy. ISP1 has assigned an IP address space of 192.1.1.0/24. ISP2, which does not support ISP1's address space, has assigned 193.1.1.0/24 to this network. This poses a problem because you need to set up a static translation for the internal web server. Normally, a static statement allows only one translation. In this example, you must choose between 192.1.1.1 translated to 10.0.0.1, or 193.1.1.1 translated to 10.0.0.1 for the web server translation.
Using the extendable parameter, however, you can associate more than one global address with a local address
if helpful Rate
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide