From: joe_astorino@comcast.net
Date: Thu Feb 05 2009 - 14:46:12 ARST
Hey guys,
The only equipment I have tested this on is my 3640 and 2610XM running
12.4(23) and had the same results.B However, I could of sworn it did work on
these same routers when I had an earlier version of 12.4 code (prior to the
frame-relay encapsulation failed nightmare / upgrade :) )
----- Original Message -----
From: "Pavel Bykov" <slidersv@gmail.com>
To: "Jason Morris" <mcnever@gmail.com>
Cc: "Edouard Zorrilla" <ezorrilla@tsf.com.pe>, "Joe Astorino"
<joe_astorino@comcast.net>, ccielab@groupstudy.com
Sent: Thursday, February 5, 2009 4:19:33 AM GMT -05:00 US/Canada Eastern
Subject: Re: Simple NAT Issue
Dynamips shouldn't play a role in this case, since 26xx/36xx are software
platforms.
Edouard, then I was mistaken and it is not a rule. This could be
platform-dependent issue then.
On Wed, Feb 4, 2009 at 6:10 PM, Jason Morris < mcnever@gmail.com > wrote:
working with dynamips it seems to work fine as long as ip have 'ip nat
outside' on e0/0 in the example below.... i can have lo1 as 'ip nat enable' or
'ip nat inside' and it works fine...
Joe did you say it worked fine with your 3640 and you just had problems with
the ISR you orginally tested with?
ROM: 3600 Software (C3640-JS-M), Version 12.4(10), RELEASE SOFTWARE (fc1)
!
!
!
interface Loopback0
B ip address 10.1.1.1 255.255.255.255
!
interface Loopback1
B ip address 11.11.11.11 255.255.255.255
B ip nat enable
!B B B B B B B B
interface Ethernet0/0
B ip address 192.168.0.1 255.255.255.0
B ip nat enable
B ip virtual-reassembly
B half-duplex
!
interface Ethernet0/1
B ip address 192.168.2.1 255.255.255.0
B ip virtual-reassembly
B half-duplex
!
interface Ethernet0/2
B no ip address
B shutdown
B half-duplex
!
interface Ethernet0/3
B no ip address
B shutdown
B half-duplex
!
router ospf 1
B router-id 0.0.0.1
B log-adjacency-changes
B network 10.1.1.1 0.0.0.0 area 0
B network 192.168.0.0 0.0.0.255 area 0
!
ip http server
!
!
ip nat inside source list 65 interface Loopback0 overload
!
access-list 1 permit 192.168.0.0 0.0.0.255
access-list 65 permit 11.11.11.11
no cdp run
!
!
On Wed, Feb 4, 2009 at 7:05 AM, Edouard Zorrilla < ezorrilla@tsf.com.pe >
wrote:
Joe / Pavel :
Excuse, maybe I am mistaken, but I see that the local traffic is being
translated, in my base I have Lo0 on my routing proccess of OSPF so RackR5 can
ping RackR4 doing a nat inside R5 itself:
My config:
Rack1R5#siib
Interface B B B B B B B B B IP-Address B B B OK? Method Status
Protocol
FastEthernet0/0 B B B B B B 10.5.5.5 B B B B YES NVRAM B up up
Serial0/0 B B B B B B B B B 183.1.45.5 B B B YES NVRAM B up up
Serial0/1.345 B B B B B B B 183.1.0.5 B B B YES NVRAM B up up
Loopback0 B B B B B B B B B 150.1.5.5 B B B YES NVRAM B up up
Loopback55 B B B B B B B B 55.55.55.55 B B YES manual up up
Rack1R5#
My inside Nat is Lo55 and my outside Nat is Lo0:
Rack1R5#sh ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
B Loopback0
Inside interfaces:
B Loopback55
Hits: 9 B Misses: 0
CEF Translated packets: 0, CEF Punted packets: 0
Expired translations: 2
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 121 interface Loopback0 refcount 0
Queued Packets: 0
Rack1R5#
Route-Map that defines that traffic that goes from Lo55 must go thru Lo0:
Rack1R5#sh route-map MAP-A
route-map MAP-A, permit, sequence 10
B Match clauses:
B ip address (access-lists): 121
B Set clauses:
B interface Loopback0
B Policy routing matches: 9 packets, 900 bytes
Rack1R5#sh ip acc
Rack1R5#sh ip acce
Rack1R5#sh ip access-lists 121
Extended IP access list 121
B 10 permit ip 55.55.55.0 0.0.0.255 any (12 matches)
Rack1R5#
I applied it localy inside R5 so that traffic is redirected on the router
itself:
Rack1R5# sh run | sec ip local
ip local policy route-map MAP-A
Rack1R5#
Now I perform a ping to R4 using Lo55 as a source address:
Rack1R5#ping 150.1.4.4 source loopback 55 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
Packet sent with a source address of 55.55.55.55
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/2/4 ms
Translations works, you could see that inside local Lo55 (55.55.55.55) is now
Lo0 (150.1.5.5)
Rack1R5#sh ip nat translations
Pro Inside global B B B Inside local B B B Outside local B B B Outside
global
icmp 150.1.5.5:4 B B B 55.55.55.55:4 B B B 150.1.4.4:4 B B B B
150.1.4.4:4
Rack1R5#
*Feb B 4 11:24:51.549: NAT: s=55.55.55.55->150.1.5.5, d=150.1.4.4 [17]
*Feb B 4 11:24:51.553: NAT: s=55.55.55.55->150.1.5.5, d=150.1.4.4 [18]
Rack1R5#
So it means that router doing the NATing will actually NAT packets that it
generates. In this case, source Lo55 nated to Lo0. Let me know If I am
mistaken.
Regards.
----- Original Message ----- From: "Joe Astorino" < joe_astorino@comcast.net >
To: "'Pavel Bykov'" < slidersv@gmail.com >
Cc: < ccielab@groupstudy.com >
Sent: Wednesday, February 04, 2009 2:52 AM
Subject: RE: Simple NAT Issue
Hmmmmm.... I was just doing some research on this, and it seems that this is
a symptom when on the newer ISR routers that utilize the Nat Virtual
Interface ("ip nat enable"). B However, I thought that it only used the NVI
if you used the "ip nat enable" commands and not the older style "ip nat
inside" "ip nat ouside" commands. B On my 3640 running 12.4.23 code even if I
do "ip nat inside" and "ip nat outside" it immediately brings up/up
interface NVI0. B I wonder if all the newer code will not translate locally
generated packets despite the command set you use?
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
mQGiBEY2qu8RBAD0E7Ydspmpn9/rRfd614pvDaqj4GKAUeWpc8NNJ3xNU9C5TAKg
Ta/52f2DvxgPlw6m7W66AJP0HZODw2ameQ9tNMrz3upKRA+ISFaqkJa99UOTdLGC
W/HtHWZNUJDopBHm3j/TBAAhI0EWvcNIudbHx5zYY4osfDNMaIXYaySwIwCg61Db
RuST/K0PlSUFK9o6AqTmrcsD/ReQLYK/OEzZBQsPBqMD68ADtdYyIA3VZ7nhWCzc
YODiBl36XIskcwyVAnU9YXs/Hf96MfI1R2fvYGW8jJ4WHb3wT1JxgiUG4rUbA2L3
doxNseggGrKC31njFynVuOpdd/TRfsqzV3Yv5MGFPkNG3w/AoiRtwoMZFUtAox3j
EWbBA/4mYkTKS/Rfgpv7QQHj4ajCHsTL/JNSN8LARwbBomUFdJ+0xdNdr7Ax1zC4
FEUfP0plRMLMypKPSNYzlIF8dKGwW2I8hUMfQpmIBA4BXBE0/mbv21lU2AzTkvb1
FssbIzhCkx3mMzESgYIwnnNkJBatTfFqKOxGm//G7s2y1eFPsrQnSm9lIEFzdG9y
aW5vIDxqb2VfYXN0b3Jpbm9AY29tY2FzdC5uZXQ+iGAEExECACAFAkY2qu8CGwMG
CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAb4dzwEzSi9chbAKCTz89zl4etDIdD
Hewo7LNEmfT8uQCgmbneQqTT5VyIEx75nG5KzJh2K2m5Ag0ERjaq7xAIALgM2fwR
tuhRNrwvkYFXTA5grAnnhGqFXPfLt5YlU86QLdu3Z9WJcAAHck1HMCUxdm0gZyNu
q5XQnmr76dbWjftQ+mxYAdhZGjjGV1OQyjfyUoLbxyR0jvaLUTFvMmtxFsHpJvEc
VLscWZUvjPbpcg/BH8EWbDUSCJc70EZMW6TpjyL+1Eq6+n4KB+IWDnn603U3vYFj
ExVfg2CqTIzC/mxAGQ/lg1ujKBnL/VemGpjZzL8jyYVLhAtASTWnwuaL1Sf2kCYh
fApP+06YxkQ39BrJmi7Dg6s5zeRu4le57kPLVAGK0ZYRbaq5asAi9Ni5j/ZLdh/b
F3oUgAOTPQtqbi8AAwUH/1n9jpOXRX7LsfsI5K4gVhHYPUYuy5WuRRxJZ6Y1JbOq
UfePLg+cutaxE8RAvEY1VZvNTvEt7UYPoA3qR3lb4IzLqJimbbKGhhVdHIOYLGnz
nxiwfo4S+my9GEYKLb3iHIR1DCfihhDryVlFYGAMCPNh0w2sNSSenP4cZBuD6V1J
QLitW9aZoURMvtFYU8aO/BlZ7hVlRVNU5juwwAM5t2n2gBeRhMthaAR7OApDypvB
1TM+BeSDchieEAFNkX4leSMbFgP3CJmAXMJXKj8MQmsR8gdccUHGplGFI6IzNklm
L/eWLdhAZsM+LsAo4MpoJzPoQyFIH7wmIPm4b/z7YZmISQQYEQIACQUCRjaq7wIb
DAAKCRAb4dzwEzSi9XiWAKCdDtdnTW9X/6rHxQL/obNiZsEtEwCgrlmYisNacJyf
74k/eLaYWYqu7YI=
=8HMA
-----END PGP PUBLIC KEY BLOCK-----
B _____
From: Pavel Bykov [mailto: slidersv@gmail.com ]
Sent: Wednesday, February 04, 2009 1:32 AM
To: Joe Astorino
Cc: ccielab@groupstudy.com
Subject: Re: Simple NAT Issue
Yeah, I'm pretty sure of that. Same as with access lists. Locally originated
traffic just skips a lot of facilities.
What it does not skip is QoS, but this is dependent on platform - if you
originate packets on 12000, then it will skip QoS as well.
On Wed, Feb 4, 2009 at 7:26 AM, Joe Astorino < joe_astorino@comcast.net >
wrote:
Thanks for the solution Pavel. B Do you know if it is indeed true that a
router doing the NATing will not actually NAT packets that it generates,
even if the source address is in the NAT translation list? B I seem to
remember this sort of thing working on older versions of IOS.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
mQGiBEY2qu8RBAD0E7Ydspmpn9/rRfd614pvDaqj4GKAUeWpc8NNJ3xNU9C5TAKg
Ta/52f2DvxgPlw6m7W66AJP0HZODw2ameQ9tNMrz3upKRA+ISFaqkJa99UOTdLGC
W/HtHWZNUJDopBHm3j/TBAAhI0EWvcNIudbHx5zYY4osfDNMaIXYaySwIwCg61Db
RuST/K0PlSUFK9o6AqTmrcsD/ReQLYK/OEzZBQsPBqMD68ADtdYyIA3VZ7nhWCzc
YODiBl36XIskcwyVAnU9YXs/Hf96MfI1R2fvYGW8jJ4WHb3wT1JxgiUG4rUbA2L3
doxNseggGrKC31njFynVuOpdd/TRfsqzV3Yv5MGFPkNG3w/AoiRtwoMZFUtAox3j
EWbBA/4mYkTKS/Rfgpv7QQHj4ajCHsTL/JNSN8LARwbBomUFdJ+0xdNdr7Ax1zC4
FEUfP0plRMLMypKPSNYzlIF8dKGwW2I8hUMfQpmIBA4BXBE0/mbv21lU2AzTkvb1
FssbIzhCkx3mMzESgYIwnnNkJBatTfFqKOxGm//G7s2y1eFPsrQnSm9lIEFzdG9y
aW5vIDxqb2VfYXN0b3Jpbm9AY29tY2FzdC5uZXQ+iGAEExECACAFAkY2qu8CGwMG
CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRAb4dzwEzSi9chbAKCTz89zl4etDIdD
Hewo7LNEmfT8uQCgmbneQqTT5VyIEx75nG5KzJh2K2m5Ag0ERjaq7xAIALgM2fwR
tuhRNrwvkYFXTA5grAnnhGqFXPfLt5YlU86QLdu3Z9WJcAAHck1HMCUxdm0gZyNu
q5XQnmr76dbWjftQ+mxYAdhZGjjGV1OQyjfyUoLbxyR0jvaLUTFvMmtxFsHpJvEc
VLscWZUvjPbpcg/BH8EWbDUSCJc70EZMW6TpjyL+1Eq6+n4KB+IWDnn603U3vYFj
ExVfg2CqTIzC/mxAGQ/lg1ujKBnL/VemGpjZzL8jyYVLhAtASTWnwuaL1Sf2kCYh
fApP+06YxkQ39BrJmi7Dg6s5zeRu4le57kPLVAGK0ZYRbaq5asAi9Ni5j/ZLdh/b
F3oUgAOTPQtqbi8AAwUH/1n9jpOXRX7LsfsI5K4gVhHYPUYuy5WuRRxJZ6Y1JbOq
UfePLg+cutaxE8RAvEY1VZvNTvEt7UYPoA3qR3lb4IzLqJimbbKGhhVdHIOYLGnz
nxiwfo4S+my9GEYKLb3iHIR1DCfihhDryVlFYGAMCPNh0w2sNSSenP4cZBuD6V1J
QLitW9aZoURMvtFYU8aO/BlZ7hVlRVNU5juwwAM5t2n2gBeRhMthaAR7OApDypvB
1TM+BeSDchieEAFNkX4leSMbFgP3CJmAXMJXKj8MQmsR8gdccUHGplGFI6IzNklm
L/eWLdhAZsM+LsAo4MpoJzPoQyFIH7wmIPm4b/z7YZmISQQYEQIACQUCRjaq7wIb
DAAKCRAb4dzwEzSi9XiWAKCdDtdnTW9X/6rHxQL/obNiZsEtEwCgrlmYisNacJyf
74k/eLaYWYqu7YI=
=8HMA
-----END PGP PUBLIC KEY BLOCK-----
B _____
From: Pavel Bykov [mailto: slidersv@gmail.com ]
Sent: Wednesday, February 04, 2009 1:22 AM
To: joe_astorino@comcast.net
Cc: ccielab@groupstudy.com
Subject: Re: Simple NAT Issue
One of the solutions how to accomplish your goal is to use PBR and local
policy.
e.g.:
route-map NAT
set interface lo55
!
ip local policy route-map NAT
On Wed, Feb 4, 2009 at 6:32 AM, < joe_astorino@comcast.net > wrote:
I am having a problem regarding NAT and was hoping somebody could help me
understand this. I have a router, R5 that I wish to do NAT translation so
that anything sourced from its Loopback55 address will be translated to its
Loopback1 interface. This way I can meet a requirement that I should be able
to source a ping from Loopback55 and have it reply successfully without
adding Loopback55 to any routing protocol.
If I set this up the way I have below, and try a ping sourced from Lo55 it
does not work...no translation occurs. I thought I remember hearing
something at one point that the router doing the NAT translation won't NAT
packets sourced from itself, only packets that pass through it, but I am not
sure on that. Any ideas guys?
Just to be sure, I have checked that I do have reachability to the address I
am trying to ping when sourced from lo1.
R5(config)#do sh ip int brie | i Loop
Loopback1 99.99.99.5 YES manual up up
Loopback55 55.55.55.55 YES manual up up
R5(config)#do sh access-list 55
Standard IP access list 55
10 permit 55.55.55.55
R5(config)#do sh run int e0/0 | i ip nat
ip nat outside
R5(config)#do sh run int s2/0 | i ip nat
ip nat outside
R5(config)#do sh run int s2/0.56| i ip nat
ip nat outside
R5(config)#do sh run int s2/1 | i ip nat
ip nat outside
R5(config)#do sh run int lo1 | i nat
ip nat outside
R5(config)#do sh run int lo55 | i nat
ip nat inside
ip nat inside source list 55 interface lo1 overload
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:10 ARST