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.
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
Hey 
Is the policy route-map will overload the CPU?
Every packet to the outside have to go through the policy…
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
Thanks a lot laz 
Adi
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 .
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:
Remember that the local policy will only match locally sourced traffic that matches the ACL.
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
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!
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
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
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
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