07-26-2009 04:19 AM - edited 03-04-2019 05:33 AM
Hi Experts,
I am configuring NAT in stick configuration. I am not comfortable with the logic behind this. Also,I have completely gone thru the CISCO document describing the NAT in stick configuration. Still i donot understand
Below I am explaining the issue
Please find the attached Topology diagram and configuration. Please correct the what i am missing in the configuration.
1. I am not able to ping 61.1.192.65 (INTERNET Router) IP address from PC Router.
2. What is the need of PBR configuration here.
3. In what logic i have to make the interface as INSIDE or OUTSIDE. (Since in this case we are configuring public ip address and private ip address in the same eth 0/0 interface and creating loopback 0 interface)
I believe i have explained the need to your understanding. Please help
Thanks in advance
Sairam
Solved! Go to Solution.
07-28-2009 04:34 AM
Hi Sairam,
Thank you for your kind words.
While the Cisco does not explicitely state that the NVI can be used for the NAT-on-stick applications, it does not say neither that it can not be used. In the command reference for 12.4 IOS, it is stated that the "vrf" option in the "ip nat source" command is optional, thereby allowing its use also in the global routing table.
Regarding that the NVI is allegedly supposed to provide means for communication between different VRFs, this is a quotation from the article about the NVI posted earlier here:
NVI is not a new way of doing NAT; it's a new feature to resolve NAT restriction.
And this is what I also think about NVI. Not primarily VRF-specific stuff (even though it might in cases help solve some problem but I do not know enough about such applications) but rather a different approach to do NAT.
Best regards,
Peter
07-26-2009 07:00 AM
use the follwoing config and should work
yours was ok but you had extra entry in the ACL of route-map
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
ip address 218.248.17.2 255.255.255.0 secondary
ip address 192.168.1.254 255.255.255.0
ip nat outside
ip virtual-reassembly
ip policy route-map nat
duplex auto
speed auto
!
interface FastEthernet1/1
no ip address
shutdown
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 218.248.17.1
!
no ip http server
no ip http secure-server
!
ip nat pool pool1 218.248.17.11 218.248.17.12 netmask 255.255.255.0
ip nat inside source list 1 pool pool1
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
!
route-map nat permit 10
match ip address 100
set interface Loopback0
this a copy of the debug i did it in gns3 lab:
NAT: s=192.168.1.1->218.248.17.12, d=61.1.192.65 [22]
NAT*: o: icmp (61.1.192.65, 4) -> (218.248.17.12, 4) [20]
NAT*: s=61.1.192.65, d=218.248.17.12->192.168.1.1 [20]
NAT*: o: icmp (61.1.192.65, 4) -> (218.248.17.12, 4) [21]
NAT*: s=61.1.192.65, d=218.248.17.12->192.168.1.1 [21]
NAT: i: icmp (192.168.1.1, 4) -> (61.1.192.65, 4) [23]
good luck
HTH
07-26-2009 07:59 AM
Hi HTH,
Thanks for responding. I will try your suggestion. By the mean time can you please explain the logic behind using the PBR in this scenario. Let me put my question in simpler way
1. What happens when in the packet 192.168.1.1 (inside host) enters the router interface fa 1/0.
As per router inside to outside traffic flow logic first policy route-map will be checked and then routing table and finally NAT will be used.
2. when the return packet comes back to router first NAT translation will be checked and if translation is found then it will route the packet directly to fa 1/0.
Am i correct. If this is the case see the attachment of a file describing "NAT ON STICK ROUTER CONFIGURATION". In Example configuration on page 4 they have the below ACL used for route-map.
access-list 102 permit ip 10.0.0.0 0.0.0.255 any
If i remove this from configuration, the setup stopped working. It seems it is mandatory ACL for return traffic
Correlating the point 1 and 2 i explained above, i don't know why this ACL has to be included and what it does.
I know that i explained very lengthy which would have tested you patience. But i tried to give detailed info.
Please explain the logic
Sairam
07-26-2009 07:42 AM
Hi Its me again.
I tried an another way of achieving this. probably this may be the alternative solution.
I used a L2 switch connecting Internet, NAT Router, and PC Router. I configured sub interfaces on NAT Router as below
int fa 0/0.1
encap dot1q vlan 192
ip add 192.168.1.254
ip nat inside
int fa 0/0.2
encap dot1q vlan 128
ip add 218.248.17.2
ip nat outside
ip nat inside source list 1 pool NAT overload
access-list 1 permit 192.168.1.0 0.0.0.255
ip nat pool NAT 218.248.17.1 218.248.17.2 prefix 24
It is working perfectly. I am surprised why CISCO is not suggesting this as solution. Is there any downside found in this solution described now
sairam
07-26-2009 01:41 PM
this is not nat on stick
this is one using to logical interfaces
the logic how it works nat on stick
traffic coming to the interface, match the the acl of the route-map
then the route-map will make the input interface as the lo0
lo0 has nat enabled
then the packed wil be routed based on the router routing table and when go through the interface as egress interface will be nated using the nat pool
Hope this Help
07-26-2009 01:44 PM
Sairam,
What you have designed here with 802.1Q subinterfaces is a common solution if you have a 802.1Q-capable switch available. There are no notable downsides with this solution.
I do not know why Cisco is not suggesting this as a solution but it is basically a different scenario than you have originally suggested. You original problem was that you needed to designate a single interface both as inside and outside. What you have done here is basically a "cheating" but a smart one :) By creating two subinterfaces, you can designate one as inside, the second as outside.
The PBR solution is another smart trick whose primary disadvantage is that all NATted packets must be process-switched.
However, Cisco has actually come with a targeted solution exactly for this kind of problem - a NAT performed on a single interface. The solution is called the NAT Virtual Interface and is supported since IOS 12.3T. You may find further information here:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html
Best regards,
Peter
07-27-2009 02:23 AM
Hi Peter,
Thanks for your post. The link you provided is very useful
But i am worried whether VRF has to be configured if NAT Virtual interface is used?
What to do if I donot have any VRF in place and whether this solution is suitable for the scenario i have discussed in my first post
Thanks and looking for your expertised comments
Sairam
07-27-2009 02:41 AM
Hello Sairam,
I believe that you don't need those VRFs at all when using NVI.
Your configuration would be as follows:
interface Ethernet0/0
ip address 218.248.17.2 255.255.255.0 secondary
ip address 192.168.1.254 255.255.255.0
ip nat enable
exit
ip nat pool SAI 218.248.17.11 218.248.17.12 netmask 255.255.255.0
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
ip nat source list 101 pool SAI overload
Best regards,
Peter
07-27-2009 05:36 AM
Hi Peter,
I am very convinced with your reply. I will use NVI for upcoming projects.
But going back to NAT in Stick configuration, I need some more clarity which i expect you to help me
What is the logic of assigning OUTSIDE & INSIDE in the NAT in stick configuration. Because We are configuring both the outside and inside ip address in the same interface. (refer the diagram & configuration i attached previously.Then we are creating loopback 0 and making it IP NAT OUTSIDE interface.
But contradictly refering example 2 in the document i attached which is taken from CISCO there the Interface fa 0/0 is configured with IP NAT OUTSIDE and Loopback is configured with IP NAT INSIDE
can you take some of your time and make the concept clear for me.
sairam
07-27-2009 09:47 AM
Hi peter,
Have you tested the configuration.
I did using Dynamips. It failed. Moreover you configured 218.248.17.11 as secondary. If this is the case then I have to configure " ip route 192.168.1.0 255.255.255.0 218.248.17.2" in INTERNET Router, which will bypass the NAT(it will start working without NAT).
Moreover I understood that NVI is one of the method used for Inter VRF communication / routing.
Shall you help me on this?
Sairam
07-27-2009 10:12 AM
Hello Sairam,
Sorry for replying lately.
I have tested it right away - you were right, the configuration did not work as I originally posted it here. The solution is, fortunately, quite simple: add the command "no ip redirects" on the Ethernet interface and it should make things work.
My current configuration is as follows:
interface FastEthernet0/0
ip address 218.248.17.2 255.255.255.0 secondary
ip address 192.168.1.254 255.255.255.0
no ip redirects
ip nat enable
!
ip nat pool SAI 218.248.17.11 218.248.17.12 netmask 255.255.255.0
ip nat source list 101 pool SAI overload
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
A neighboring router on the same segment produces this output:
Internal#show ip route
*Mar 1 00:19:36.891: %SYS-5-CONFIG_I: Configured from console by console
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 192.168.1.254 to network 0.0.0.0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 192.168.1.254
Internal#ping 218.248.17.222 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 218.248.17.222, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
Internal#traceroute 218.248.17.222
Type escape sequence to abort.
Tracing the route to 218.248.17.222
1 192.168.1.254 4 msec 8 msec 36 msec
2 218.248.17.222 32 msec * 68 msec
Internal#
The router being pinged and tracerouted to is also on the same segment:
External#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 218.248.17.0/24 is directly connected, FastEthernet0/0
Sorry again for originally posting a non-working solution.
Best regards,
Peter
07-27-2009 11:12 AM
Hi Peter,
I am happy to see your reply. Indeed I am waiting for that. Thanks.
I will try this immediately. But please explain me the following:
1. How "no ip redirects" command makes the difference here. I know the use of this command. But what is the purpose of using this here and how it influenced the configuration
Thanks in advance. I will let you know the result after checking the configuration
Thanks in advance
Sairam
07-28-2009 01:02 AM
Hi Sairam,
You are heartily welcome.
I will try to explain the topics you've asked me but it will take some time.
About the "no ip redirect" - to be completely honest, I am also not quite sure what is going on. But I tried a few experiments and this is what I've found out.
First off, according to the wonderful document "When Are ICMP Redirects Sent?" at
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml
the redirects are sent when all these conditions are met:
1.) The interface on which the packet comes into the router is the same interface on which the packet gets routed out.
2.) The subnet or network of the source IP address is on the same subnet or network of the next-hop IP address of the routed packet.
3.) The datagram is not source-routed.
4.) The kernel is configured to send redirects.
Note that the sending of ICMP redirect messages does not apply in the case of our router with two IP addresses on its Ethernet interface because the condition 2 is not met (the packet goes from one IP subnet to another). In this case, the router reroutes the packet as usual.
Now, if we do not configure the NAT, things basically work - the router with the secondary address takes the packet and simply reroutes it on the same segment. However, as soon as we turned on the NAT, it apparently stopped working.
The problem was that the addresses in your NAT pool were from the same IP subnet as the secondary IP address in the Ethernet interface. I believe that the following sequence of steps has taken place (it is only my speculation as I have not found it documented anywhere - if there is a Cisco engineer nearby please correct me!):
1.) The packet came into the router through the NAT-enabled interface
2.) The NAT code first looked into the translation table for the Ethernet interface to see if there is already a translation entry. Let's assume that this is the first packet and the NAT table is empty.
3.) The NAT code therefore evaluated the access list 101 to see if that packet is eligible for translation. Because the packet passed the ACL check, the NAT created a new translation entry and rewrote the packet's source IP address to one of the NAT pool's public addresses.
4.) Now, the packet was about to be routed. However, the routing code with the IP Redirect feature turned on discovered that the (rewritten) source IP address of the packet is in the same network as the destination and that it is on the same interface through which the packet came in. Probably, the code now concluded that it is unnecessary to resend the packet out as both the source and the destination are on the same network and on the same interface, so it just dropped the packet without sending anything.
I suspect that turning off the IP Redirect feature removes that addition "sanity" check and the router simply and dutifully routes the packet according to its routing table after it was NATted. Therefore, it started working.
You can try this: make the NAT pool to contain addresses from a different network than the secondary IP address on the Ethernet interface is in. Then the NAT will work even with the IP Redirect turned on.
I don't know if this is comprehensible to you - I find it myself quite messy.
Best regards,
Peter
07-28-2009 02:47 AM
Hi Peter,
I am in sync with you. I am able to get your explanation cleary. No doubt in it. I admire you depth understanding on the concepts
But in none of the cisco doc and in any forums i am seeing that NVI is the alternate to NAT in stick configuration
It says that, NVI is used to make communication with different VRFs.
Do you have second opinion on this
Sairam
07-28-2009 04:34 AM
Hi Sairam,
Thank you for your kind words.
While the Cisco does not explicitely state that the NVI can be used for the NAT-on-stick applications, it does not say neither that it can not be used. In the command reference for 12.4 IOS, it is stated that the "vrf" option in the "ip nat source" command is optional, thereby allowing its use also in the global routing table.
Regarding that the NVI is allegedly supposed to provide means for communication between different VRFs, this is a quotation from the article about the NVI posted earlier here:
NVI is not a new way of doing NAT; it's a new feature to resolve NAT restriction.
And this is what I also think about NVI. Not primarily VRF-specific stuff (even though it might in cases help solve some problem but I do not know enough about such applications) but rather a different approach to do NAT.
Best regards,
Peter
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: