[c-nsp] IOS NAT, translating source into IP not included in routing table

[Wink]

Dale:

Your solution is really not all that bad.  We are moving to the static 
route solution, just as you have it below with the name tag.  We also 
considered just creating some /32 loopbacks with interface descriptions, 
but decided as a team that the static routes were the way to go.

So we have a bunch of /32s inside the customer networks we manage that 
represent NAT addresses.  The null route is really just an anchor. 

Sometimes being really functional also means being really ugly.




Dale Shaw wrote:
> I changed the "ip route .." commands to..
>
> ip route 192.168.20.5 255.255.255.255 Null0 name NAT
>
> .. and it continues to work as expected. This is cleaner, but I'm
> still interested in more elegant solutions. I've seen the "add-route"
> parameter, but it doesn't appear to support /32s, and only seems to be
> available for "ip nat outside .."
>
> cheers,
> Dale
>
>
> On Nov 22, 2007 2:10 PM, a. rahman isnaini r. sutan
> <risnaini at speed.net.id> wrote:
>   
>> New to me... never been working by translating internal IP to 'external IP
>> which is not directly connected to the router...'
>> If this work pretty well, it'd be good and some ideas might come up later...
>>
>> rgs
>> a. rahman isnaini r.sutan
>>
>> ----- Original Message -----
>> From: "Dale Shaw" <dale.shaw+cisco-nsp at gmail.com>
>> To: <cisco-nsp at puck.nether.net>
>> Sent: Thursday, November 22, 2007 5:39 AM
>> Subject: [c-nsp] IOS NAT,translating source into IP not included in routing
>> table
>>
>>
>>     
>>> Hi,
>>>
>>> My Google-fu is failing me..
>>>
>>> Scenario:
>>>
>>> FastEthernet0 (NAT inside), IP 10.20.20.1/24
>>> Tunnel1 (NAT outside), IP 172.16.0.1/24
>>> DMVPN environment with EIGRP
>>> Performing static source address translation from hosts in
>>> 10.20.20.0/24 to 192.168.20.x
>>>
>>>       
> [...]
>   
>>> The router will happily translate 10.20.20.50 etc. into any arbitrary
>>> IP, as per the "ip nat inside .." command, but return traffic is
>>> unrouteable because there is no routing table entry for 192.168.20.5
>>> in other routers in the AS.
>>>
>>> At present, I'm adding and redistributing a static host route like so:
>>>
>>> ip route 192.168.20.5 255.255.255.255 FastEthernet0 10.20.20.2
>>>
>>> ..And as expected, 192.168.20.5/32 appears in the routing table and
>>> packets know how to come back to this router.
>>>
>>> It's a bit ugly/counter-intuitive though, don't you think? Is there a
>>> more elegant way? (perhaps specifying Null0 in the static route would
>>> be nicer)
>>> I have a mix of 12.3 and 12.4 IOS in the environment so while I'm
>>> happy to hear about any better methods, ideally I'm looking for
>>> something that will work on all versions.
>>>
>>> cheers,
>>> Dale
>>>       
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>