Cisco IOS NAT on a Stick Configuration Example

Lessons Discussion
21

Hey Rene and Laz,

It seems to work for me in a lab only when the NAT router is also the destination, but when my NAT router is in between the source and the destination then it will reply with its physical interface’s source IP rather than using the loopback’s IP.

22

Hello Nitay

What you describe is normal behaviour. If you have an arrangement where the NAT router is in between the source and destination, then the physical interface will indeed reply. This is because, in such a situation, you have two hops, whereas, in the lesson, the traceroute response is only a single hop.

What the lesson is asking for is that the loopback IP address respond for the router for traceroute instead of the physical address. The loopback address is on the same router, so it doesn’t count as another hop.

I hope this has been helpful!

Laz

23

Hey :slight_smile:
Is the policy route-map will overload the CPU?
Every packet to the outside have to go through the policy…

24

Hello Adi

Policy route maps will indeed use some CPU resources in order to function. Will they overload the CPU? Well, that depends on a lot of things, such as the CPU capacity, the platform being used, the amount of memory available, as well as the expected traffic, and the complexity and number of policy route maps being applied.

For the most part, routers are designed to be able to handle large amounts of data and to process them via route maps. As you design such route maps, just be aware of the possibility of overloading the CPU, so that if it does occur, you can be ready for it and act accordingly.

Ultimately, you’ll have to experiment with the implementation, keeping an eye on the CPU usage. CPU usage will go up well before there is any failure, so you can monitor it and avoid any catastrophic failures well before they occur.

I hope this has been helpful!

Laz

25

Thanks a lot laz :pray:t2:

Adi

1 Like
26

Hello Laz ,

about Scenario 1 : can ip Local Policy only one time be applied on Self-generated Packet ? why this Policy has not been applied for the second Time on The reply Packet that has been sent from L0 Interface " with set Interface L0 command in route Map " ?although the Traffic here has matched the Route Map in ip Local Policy.
Thanks a lot for your Info .

27

Hello Mohammad

I understand and I share your confusion about this particular implementation. It seems strange to me that PBR would cause a change in the source address of sent packets, but it does. Think about it this way:

Take a look at the diagram once again:
image

Remember that the local policy will only match locally sourced traffic that matches the ACL.

  • When the original echo request comes in from R1 to R2, it enters Fa0/0. This is not locally sourced, so no PBR takes place.
  • R2 then prepares an ICMP reply. Now that reply is locally sourced, and matches the ACL so PBR is engaged and this packet is sent to the L0 interface.
  • The L0 interface then sends the packet to the destination the original ICMP echo request was sent from, which is 192.168.12.0/24. Note here that PBR would be engaged, but PBR is smart enough to know that it should not send traffic back to the IP address it originated from. So a locally sourced packet with a source IP of 2.2.2.2 will not be sent back to 2.2.2.2 using PBR.

This is a somewhat unusual case because PBR is using a next hop address that is local on the device. This is generally not implemented but is done so here simply to fulfill the requirements of the specific CCIE lab challenge.

I hope this has been helpful!

Laz

28

Anyone tried this with NAT on a stick with inside range also using dhcp service from the local router? So the ip nat side interface is also gateway for dhcp services supplied by the Cisco router, and ip nat outside to a local loopback (we are trying hide all dhcp clients behind one local loopback, so the upstream device can perform 1 to 1 nat )

Not sure what the best way to explain my current setup, will report back with a diagram when I have time!

29

Hello Robert

Yes, the setup you described is possible, and it is commonly used. You can have your Cisco router act as both a DHCP server and a NAT device. Here’s a brief explanation:

The router’s interface connected to your local network (LAN) would be the DHCP server, providing IP addresses to all devices on the LAN. This would be your “ip nat inside” interface.

You would then configure NAT on the router, with the same interface acting as the “inside” interface for NAT.

The loopback interface would be your “ip nat outside” interface. You’d configure static NAT rules to map the loopback IP address to the IP addresses of your DHCP clients.

Here’s a basic example of how you might configure this:

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
interface Loopback0
 ip address 10.0.0.1 255.255.255.0
 ip nat outside
!
ip nat inside source list 1 interface Loopback0 overload
!
ip dhcp pool LAN
 network 192.168.1.0 255.255.255.0
 default-router 192.168.1.1 
!
access-list 1 permit 192.168.1.0 0.0.0.255

In this example, the router’s FastEthernet0/0 interface is the DHCP server and the “inside” NAT interface. The Loopback0 interface is the “outside” NAT interface. The “ip nat inside source” command tells the router to perform NAT for any traffic from IP addresses that match access-list 1 (i.e., all IP addresses in the 192.168.1.0/24 range), and to use the Loopback0 interface’s IP address as the “outside” IP address.

This is just a generic example. Please share a network diagram of your particular setup so that we can apply the concept specifically to your situation.

I hope this has been helpful!

Laz

30

Hi Laz,

Thank you for the detailed notes, will keep these handy. =)

I also came across a more platform specific item, as I’m working with a 68xx h/w;

A bit more on the design, we are actually running the NAT on a stick inside the same VRF, and there seems to be various support limitations depending on ios or iosxe (we are on ios).

NAT with VRF - IOS vs IOS-XE

Our ios doesn’t support ‘match-in=vrf’ keyword, not sure if its on the features road map, so I
might have to report back to the head designer and ask if we can move the NAT onto a different part of the network (but it will probably still be my problem!).

Thank you for the reply again,

Cheers,
Rob

31

Hello Robert

Thanks for keeping us up to date on your progress and for sharing the information and resources that you found helpful. This enriches the forum and makes it an even more useful resource for all users.

It can often be difficult when attempting to configure specific features, like NAT on a stick when involving other mechanisms such as VRFs. It’s not always readily perceivable how these mechanisms will interact and behave. And this interaction and behavior may differ from platform to platform, and from software version to software version.

In any case, if you have anything to add as you discover more, feel free to let us know!

I hope this has been helpful!

Laz

32

Hi Laz,

Not a problem re: enriching the forum/community. I guess one day I will knuckle down and get up to speed on all the fancy new topics I see popping up as apart of the ever changing CCIE EI blueprint topics!

Cheers, Rob

1 Like
33

Hello,

Thanks again for the lesson. Just one question:

Would scenario 1 work with the following configuration?

int lo0
ip nat inside

int Fa0/0
ip nat outside

ip nat inside source static 2.2.2.2 192.168.12.2

I don’t think it will work: I was thinking that, since NAT goes before routing on the outside, it indirectly translates the destination of the packet to 2.2.2.2, so then the reply will be initially sourced by 2.2.2.2; but then NAT will translate the source of the reply from 2.2.2.2 to 192.168.12.2 because of the rule, so it will not work.

Is that right or am I wrong or misunderstanding?

Thanks,
Jose