From: Pavel Bykov (slidersv@gmail.com)
Date: Thu Feb 05 2009 - 07:19:33 ARST
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
> ip address 10.1.1.1 255.255.255.255
> !
> interface Loopback1
> ip address 11.11.11.11 255.255.255.255
> ip nat enable
> !
> interface Ethernet0/0
> ip address 192.168.0.1 255.255.255.0
> ip nat enable
> ip virtual-reassembly
> half-duplex
> !
> interface Ethernet0/1
> ip address 192.168.2.1 255.255.255.0
> ip virtual-reassembly
> half-duplex
> !
> interface Ethernet0/2
> no ip address
> shutdown
> half-duplex
> !
> interface Ethernet0/3
> no ip address
> shutdown
> half-duplex
> !
> router ospf 1
> router-id 0.0.0.1
> log-adjacency-changes
> network 10.1.1.1 0.0.0.0 area 0
> 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 IP-Address OK? Method Status Protocol
>> FastEthernet0/0 10.5.5.5 YES NVRAM up up
>> Serial0/0 183.1.45.5 YES NVRAM up up
>> Serial0/1.345 183.1.0.5 YES NVRAM up up
>> Loopback0 150.1.5.5 YES NVRAM up up
>> Loopback55 55.55.55.55 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:
>> Loopback0
>> Inside interfaces:
>> Loopback55
>> Hits: 9 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
>> Match clauses:
>> ip address (access-lists): 121
>> Set clauses:
>> interface Loopback0
>> 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
>> 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 Inside local Outside local Outside
>> global
>> icmp 150.1.5.5:4 55.55.55.55:4 150.1.4.4:4 150.1.4.4:4
>> Rack1R5#
>> *Feb 4 11:24:51.549: NAT: s=55.55.55.55->150.1.5.5, d=150.1.4.4 [17]
>> *Feb 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"). 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. 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. 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-----
>>>
>>>
>>>
>>>
>>>
>>>
>>> _____
>>>
>>> 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. 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? 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-----
>>>
>>>
>>>
>>>
>>>
>>>
>>> _____
>>>
>>> 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
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Pavel Bykov
>>> ----------------
>>> Don't forget to help stopping the braindumps, use of which reduces value
>>> of
>>> your certifications. Sign the petition at http://www.stopbraindumps.com/
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.0.233 / Virus Database: 270.10.16/1930 - Release Date:
>>> 02/02/09
>>> 07:51:00
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Pavel Bykov
>>> ----------------
>>> Don't forget to help stopping the braindumps, use of which reduces value
>>> of
>>> your certifications. Sign the petition at http://www.stopbraindumps.com/
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.0.233 / Virus Database: 270.10.16/1930 - Release Date:
>>> 02/02/09
>>> 07:51:00
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
-- Pavel Bykov ---------------- Don't forget to help stopping the braindumps, use of which reduces value of your certifications. Sign the petition at http://www.stopbraindumps.com/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