Archive

Archive for October, 2012

ASA version 9.0 released

October 30, 2012 5 comments

Version 9.0 of the Cisco ASA software has now been released. Here are some of the major features in the new release.

  • Filter ICMP by ICMP code
  • Clustering of multiple ASAs
  • OSPFv3 and EIGRP support
  • IPv6 support on outside interface for VPNs
  • NAT for IPv6 and NAT64
  • DHCPv6 relay
  • Unified ACLs for v4 and v6
  • Clientless SSL VPN – Support for new browsers and HTML5
  • Site to Site VPN in multiple context mode
  • Dynamic routing in multiple context mode
  • Mixed firewall support in multiple context mode

There seems to be some interesting features in here. If you are running v6
in your network this release seems much more useful. Also site to site VPNs
in multiple context mode is something that has been long overdue. It’s
also nice to see that you can run different firewall modes for each
context.

It was rumored that 9.0 was supposed to have BGP. I don’t see this mentioned
anywhere. I’m not sure if it got delayed or if they abandoned the idea but
some people like to run BGP on their firewalls. In my opinion it’s better
to keep a router for that but it wouldn’t hurt to have the option of running
BGP.

One thing that seems interesting is being able to cluster ASAs. I did not find
much information about this but it seems like the ASAs would be treated as
one logical unit. The difference to failover would be that you can use
the power of the multiple ASAs so if one ASA could inspect 100 Mbit/s you
should be able to inspect 200 Mbit/s with two of them. I’ll have to try
to find some more information on this feature.

Future of the blog

October 29, 2012 5 comments

Hi guys,

I’m interested to hear from you what you want to see from this blog in the future. As I have passed the CCIE lab it won’t be only CCIE related things. Would you like to see some troubleshooting labs? Technical articles? Posts on other certifications that I pursue? I’m probably doing the CCDP in the future but I don’t expect that to generate a lot of posts. Looking forward to hear from you.

Categories: Announcement Tags:

CCIE #37149 – My passing lab experience

October 24, 2012 34 comments

So by now you know that I passed my lab in Brussels yesterday. Here is my story.

I arrived at monday in Brussels around 13.30. I took a walk in the beautiful
weather to the lab location. By now I have no problems finding it but it’s
just kind of a routine. I spent the day doing some final reviews and then
visited the gym at NH hotel. It’s good to clear your head and to get sleep
in the evening if your body is tired. I did not sleep that great however.
I woke up at around 03.30 and then I went back to sleep and woke up at 5 AM
again. I got around 7h sleep so it wasn’t too bad anyway. It’s normal if
you don’t sleep that well. Don’t make too much of a deal of it.

I arrived just before 8 AM to the Cisco building and checked in at the reception
as usual. I was waiting for the proctor to come get us. The proctor goes through
the guidelines for the exam and you get assigned a rack number. It was now time
for the TS section.

I put my earplugs in and went to work. I think it is good to use earplugs for
zoning out from the environment around you. I always start by trying to solve tickets
that look easier. These are usually the ones that contain only a few devices.
The reasoning behind this is to build your confidence and to get the feeling
that time is not running out on you. For TS especially time management is
everything. As engineers we have a narrow mindset when troubleshooting and
we want to solve something before moving on. This can be your pitfall in the
TS. You MUST move on after spending 10 minutes on a ticket. Usually if you
think about something else for a while your mind starts thinking more
creatively and you can find a solution to what seemed impossible earlier.
For the TS it is very important to have a good understanding of the protocols.
You are expected to know what show output looks like so that you can gather
information from that. You need to user proper tools and don’t go hunting
with sh run. Sh run interface and sh run | section are useful though. I solved
all the tickets with about 50 min to go and then spent 15 minutes verifying
that they were still all working. Pay close attention to the restrictions
and don’t skip reading the guidelines in the beginning to save time!

It was now time for the configuration. I ate a banana to refuel some energy.
You are allowed to bring snacks to your desk if you like. I started looking
through the entire lab for dependencies and to see if any devices would need
to be reloaded. Always do this at the beginning! I started with the L2 section
and things were moving on smoothly. I used the L3 diagram to see what VLANs
I needed to configure where. You need to be comfortable with this, don’t expect
to have anything served, it’s all up to you! I did a lot more verification as
I moved along compared to my earlier attempts, don’t blindly trust your config!
I then moved on to the L3 section and that went well. I just finished the L3
section before lunch.

Previously I had only done the L2 before lunch so I knew
I was in a much better position this time. I kept doing all of the tasks
and didn’t run into any major issues. I finished with a lot of time to spare
and now comes the most important part, verification! You need some time at
the end to do extra verification, account for this! You WILL do some mistakes
just due to stress or mistyping. I went through every task and every single
bullet point and made 100% sure that I was meeting the requirement. This took
a while but it was worth it. I still had an hour to go after this so I asked
the proctor if it was possible to start the grading early but he told me that
the grading is not done by them. I decided to stay the full time and did
an extra round of verification. I actually found a small mistake in this round
of verification so my advice is to stick around even if you finish early to
make sure you have done everything that you possibly can.

It was time to head home and I had a good feeling but I did not want to think
too much about it because if you get too high then you come crashing down hard
if you fail. After I landed in Gothenburg I checked my phone and saw that I had
received an e-mail. I rushed through the air port to check my mail on the computer
and to login to the portal. To access the CCIE portal you need your CSCO number, written
date and passing score. I did not know this for my first attempt and you don’t want
to be stranded not being able to login to check your score 🙂

I had received the e-mail around 19.30 and I had a good feeling that I got the score
fast but I have heard both good and bad examples of receiving a fast score. I logged
in and I saw PASS. At first I thought it might be the written so I didn’t want to
take anything for granted but then I clicked it and there it was! My number!

You all know I’ve worked hard for a long time for this and I am grateful to everyone
that has helped me on the way. I am not abandoning the blog but it might not only
be CCIE focused from now. If you have things you want me to write about make a suggestion
and if it is interesting to me I might write about it. As I don’t have to focus on
studies only now I can explore more interesting technologies and write about them.
Thanks for following on this great journey!

CCIE #37149

October 24, 2012 30 comments

Hey guys!

I’m back from Brussels and I passed the lab! I am now CCIE #37149. I’ll write a longer post tomorrow 🙂

Categories: Announcement, CCIE Tags: , ,

Catalyst QoS – A deeper look at the egress queues

October 8, 2012 2 comments

I’ve done a post earlier on Catalyst QoS. That described how to
configure the QoS features on the Catalyst but I didn’t describe
in detail how the buffers work on the Catalyst platform. In this
post I will go into more detail about the buffers and thresholds
that are used.

By default, QoS is disabled. When we enable QoS all ports
will be assigned to queue-set 1. We can configure up to two
different queue-sets.

sh mls qos queue-set 
Queueset: 1
Queue     :       1       2       3       4
----------------------------------------------
buffers   :      25      25      25      25
threshold1:     100     200     100     100
threshold2:     100     200     100     100
reserved  :      50      50      50      50
maximum   :     400     400     400     400
Queueset: 2
Queue     :       1       2       3       4
----------------------------------------------
buffers   :      25      25      25      25
threshold1:     100     200     100     100
threshold2:     100     200     100     100
reserved  :      50      50      50      50
maximum   :     400     400     400     400

These are the default settings. Every port on the Catalyst has
4 egress queues (TX). When a port is experiencing congestion
it needs to place the packet into a buffer. If a packet gets
dropped it is because there were not enough buffers to store it.

So by default each queue gets 25% of the buffers. The value is
in percent to make it usable across different versions of the Catalyst
since they may have different size of buffers. The ASIC will have
buffers of some size, maybe a couple of megs but this size is not known
to us so we have to use the percentages.

Of the buffers we assign to a queue we can make the buffers reserved.
This means that no other queue can borrow from these buffers. If we
compare it to CBWFQ it would be the same as the bandwidth percent command
because that guarantees X percent of the bandwidth but it may use more
if there is bandwidth available. The buffers work the same way. There is
a common pool of buffers. The buffers that are not reserved go into the
common pool. By default 50% of the buffers are reserved and the rest go
into the common pool.

There is a maximum how much buffers the queue may use and by default this
is set to 400% This means that the queue may use up to 4x more buffers than
it has allocated (25%).

To differentiate between packets assigned to the same queue the thresholds
can be used. You can configure two thresholds and then there is an implicit
threshold that is not configurable (threshold3). It is always set to the maximum the queue
can support. If a threshold is set to 100% that means it can use 100% of
the buffers allocated to a queue. It is not recommended to put a low value
for the thresholds. IOS enforces a limit of at least 16 buffers assigned
to a queue. Every buffer is 256 bytes which means that 4096 bytes are
reserved.

	 Q1% Q1buffer Q2% Q2buffer Q3% Q3buffer Q4% Q4buffer
buffers  25           25           25           25
Thresh1  100 50       100 50       100 50       100 50
Thresh2  100 50       100 50       100 50       100 50
Reserved 50  25       50  25       50  25       50  25
maximum  400 200      400 200      400 200      400 200

This table explains how the buffers works. Lets say that this port
on the ASIC has been assigned 200 buffers. Every queue gets 25% of the
buffers which is 50 buffers. However out of these 50 buffers only 50%
are reserved which means 25 buffers. The rest of the buffers go to the
common pool. The thresholds are set to 100% which means they can use 100%
of the allocated buffers to the queue which was 50 buffers. For packets
that go to threshold3 400% of the buffers can be used which means 200 buffers.
This means that a single queue can use up all the non reserved buffers
if the other queues are not using them.

To see which queue packets are getting queued to we can use the show
platform port-asic stats enqueue command.

Switch#show platform port-asic stats enqueue gi1/0/25
Interface Gi1/0/25 TxQueue Enqueue Statistics
Queue 0
Weight 0 Frames 2
Weight 1 Frames 0
Weight 2 Frames 0
Queue 1
Weight 0 Frames 3729
Weight 1 Frames 91
Weight 2 Frames 1894
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 577

In this output we have the four queues with three thresholds. Note that queue 0
here is actually queue 1. Queue 1 is queue 2 and so on. Weight 0 is
threshold1, weight 1 is threshold2 and weight 3 is the maximum threshold.

We can also list which frames are being dropped. To do this we use the
show platform port-asic stats drop command.

Switch-38#show platform port-asic stats drop gi1/0/25
Interface Gi1/0/25 TxQueue Drop Statistics
Queue 0
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 1
Weight 0 Frames 5
Weight 1 Frames 0
Weight 2 Frames 0
Queue 2
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0
Queue 3
Weight 0 Frames 0
Weight 1 Frames 0
Weight 2 Frames 0

The queues are displayed in the same way here where queue 0 = queue 1.
This command can be good to find out if you are having packet loss for important
traffic like IPTV traffic or such that is dropping in a certain queue.

The documentation for Catalyst QoS can be a bit shady and by this post I
hope that you know have a better understanding how the egress queueing works.

Categories: Catalyst, CCIE, QoS Tags: , , ,

A look at NAT – inside, outside and NAT on a stick

October 3, 2012 10 comments

This post will describe how NAT works. The reason for doing a blog post on NAT
is twofold. There is a lack of good documents out there describing NAT and I
want to do some learning for myself as well.

When we are talking about NAT we have some terminology that is commonly used.
Since the address is changed along the way we need to describe which address
we are referencing when talking about the IP address. The terminology is this.

Inside local address – This is the address as seen on the LAN (inside) before
the translation occurs.

Inside global address – This is the address as seen by other hosts on the Internet.
This is the address after translation has occurred.

Outside local – This is the address on the LAN of the other side. Note that if other side
is not running NAT the outside local and global may be the same. In the diagram the other
side is running public IP addresses on the inside (a valid design).

Outside global – The IP address as seen by other hosts on the Internet, this may be the
same as the inside local depending on if NAT is used or not.

When using NAT we need to define inside and outside interfaces (except if NVI is used).
The LAN interface(s) are the inside interfaces and the WAN interface(s) are the outside
interfaces. Translation is done when traffic is going from an inside interface to an
outside interface or vice versa.

The most basic NAT we can do is a 1:1 static NAT where the inside local address is
translated to an inside global address. We can map to an IP directly or to the
outside interface. To NAT to an interface the syntax is:

ip nat inside source static INSIDE_LOCAL interface OUTSIDE_INTERFACE

ip nat inside source static 192.168.1.11 interface f0/1
sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 193.10.0.2         192.168.1.11       ---                ---

Traffic sourcing from the inside local address 192.168.1.11 will be translated
to 193.10.0.2. When we are doing static NAT there is a bidirectional translation
so when traffic is coming back in the outside interface the destination is
translated from inside global to inside local address. We can see this when we
debug ip nat detail.

NAT*: i: icmp (192.168.1.11, 6) -> (184.10.0.4, 6) [12]
NAT*: s=192.168.1.11->193.10.0.2, d=184.10.0.4 [12]
NAT*: o: icmp (184.10.0.4, 6) -> (193.10.0.2, 6) [12]
NAT*: s=184.10.0.4, d=193.10.0.2->192.168.1.11 [12]

First we see the ICMP packet coming in and the source gets translated and then
the return packet comes in and the destination address is translated. This is
how the translation table looks like.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 193.10.0.2:6      192.168.1.11:6     184.10.0.4:6       184.10.0.4:6
--- 193.10.0.2         192.168.1.11       ---                ---

We can also do a static NAT and choose what the inside global address should be. The syntax is this:

ip nat inside source static INSIDE_LOCAL INSIDE_GLOBAL

ip nat inside source static 192.168.1.11 193.10.0.254
R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 193.10.0.254       192.168.1.11       ---                ---

We now see that the source is translated to 193.10.0.254.

NAT*: i: icmp (192.168.1.11, 8) -> (184.10.0.4, 8) [14]
NAT*: s=192.168.1.11->193.10.0.254, d=184.10.0.4 [14]
NAT*: o: icmp (184.10.0.4, 8) -> (193.10.0.254, 8) [14]
NAT*: s=184.10.0.4, d=193.10.0.254->192.168.1.11 [14]

The translation table looks like this:

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 193.10.0.254:8    192.168.1.11:8     184.10.0.4:8       184.10.0.4:8
--- 193.10.0.254       192.168.1.11       ---                ---

When doing regular static NAT like this we can only map one inside
local to one inside global. What if we want to map several outside
addresses to the same inside address? To do that we need to create
extendable NAT translations. The syntax is the same but with the keyword
extendable at the end.

ip nat inside source static 192.168.1.11 193.10.0.254 extendable
ip nat inside source static 192.168.1.11 193.10.0.253 extendable

The translation table now looks like this:

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 193.10.0.254       192.168.1.11       ---                ---
--- 193.10.0.253       192.168.1.11       ---                ---

If we ping 193.10.0.253 from the other side we will see that being translated to
192.168.1.11.

NAT*: s=192.168.1.11->193.10.0.253, d=184.10.0.4 [3]
NAT*: o: icmp (184.10.0.4, 0) -> (193.10.0.253, 0) [4]
NAT*: s=184.10.0.4, d=193.10.0.253->192.168.1.11 [4]

The translation table is below.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 193.10.0.253:0    192.168.1.11:0     184.10.0.4:0       184.10.0.4:0
icmp 193.10.0.254:10   192.168.1.11:10    184.10.0.4:10      184.10.0.4:10
--- 193.10.0.254       192.168.1.11       ---                ---
--- 193.10.0.253       192.168.1.11       ---                ---

When we are doing static NAT translations we can also match on an access-list.
The good thing about matching on an ACL is that we can specify which hosts we
want to have translated and which we want to leave alone. We can create an ACL
so that traffic to 184.10.0.4 gets translated but traffic to 4.4.4.4 will arrive
with its original source address. The syntax is:

ip nat inside source list LIST_NAME interface INTERFACE_NAME

We can only translate to an interface or a pool of addresses when using a list
as the source.

R2(config)#ip access-list extended NAT
R2(config-ext-nacl)#deny ip host 192.168.1.11 host 4.4.4.4
R2(config-ext-nacl)#permit ip any any
R2(config-ext-nacl)#ip nat inside source list NAT interface f0/1

We will debug on the destination to see which address the ICMP packet coming in has.

ICMP: echo reply sent, src 4.4.4.4, dst 192.168.1.11
ICMP: echo reply sent, src 4.4.4.4, dst 192.168.1.11
ICMP: echo reply sent, src 184.10.0.4, dst 193.10.0.2
ICMP: echo reply sent, src 184.10.0.4, dst 193.10.0.2

Once again we look at the translation table.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 193.10.0.2:12     192.168.1.11:12    184.10.0.4:12      184.10.0.4:12

So we can see that when sending traffic to 4.4.4.4 it does not get
translated but traffic to 184.10.0.4 does. We can confirm by looking
at the ACL counters.

R2#sh ip access-lists NAT
Extended IP access list NAT
    10 deny ip host 192.168.1.11 host 4.4.4.4 (2 matches)
    20 permit ip any any (1 match)

We can also configure NAT to NAT 1:1 for an entire network. This means that
the inside local address 192.168.1.11 will be translated to 193.10.0.11. If
we were sourcing traffic from .20 then that would be translated to .20 so the
addressing consistency is kept. This can be useful if we have like a web server
that is reachable from 192.168.1.30 on the inside and when we want to access
it from the outside we now that it will have the IP 193.10.0.30. We should
rely on DNS for reaching web servers but knowing the IP can be good in case
of a DNS failure. Use the following syntax.

ip nat inside source static network INSIDE_LOCAL_NETWORK INSIDE_GLOBAL_NETWORK PREFIX_LENGTH_OR_MASK

R2(config)#ip nat inside source static network 192.168.1.0 193.10.0.0 /24

Now when we ping we should see the source getting translated to 193.10.0.11.

NAT*: s=192.168.1.11->193.10.0.11, d=184.10.0.4 [22]
NAT*: s=184.10.0.4, d=193.10.0.11->192.168.1.11 [22]

And the translation table.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 193.10.0.11:14    192.168.1.11:14    184.10.0.4:14      184.10.0.4:14
--- 193.10.0.11        192.168.1.11       ---                ---
--- 193.10.0.0         192.168.1.0        ---                ---

We can also do NAT for a pool of addresses. Say that we have been granted
a new pool of addresses from our ISP. The pool is 193.12.0.0/29. We create
a NAT pool matching this and then we enable NAT for the 192.168.1.11 address.
The syntax is:

ip nat inside source list ACL_NAME pool POOL_NAME

R2(config)#ip nat pool NAT_POOL 193.12.0.1 193.12.0.6 prefix-length 29
R2(config)#ip nat inside source list NAT pool NAT_POOL

We do a ping to look at the translation.

NAT*: s=192.168.1.11->193.12.0.1, d=184.10.0.4 [25]
NAT*: s=184.10.0.4, d=193.12.0.1->192.168.1.11 [25]

We can see that the source address got translated. As you can see
we can do NAT for networks that are not configured on the router.
This is the translation table.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 193.12.0.1:16     192.168.1.11:16    184.10.0.4:16      184.10.0.4:16
--- 193.12.0.1         192.168.1.11       ---                ---

When doing NAT pools we can also make the host portion of the address match
if we want to. We do that like this.

ip nat pool prefix-length type match-host

ip nat pool NAT_POOL 194.10.0.1 194.10.0.30 prefix-length 27 type match-host
ip nat inside source list NAT pool NAT_POOL

Now when we ping the IP should get translated to 194.10.0.11.

NAT*: s=192.168.1.11->194.10.0.11, d=184.10.0.4 [27]
NAT*: s=184.10.0.4, d=194.10.0.11->192.168.1.11 [27]

Which it did. So even with pools we can match the host part of the address.
This is the translation table.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 194.10.0.11:17    192.168.1.11:17    184.10.0.4:17      184.10.0.4:17
--- 194.10.0.11        192.168.1.11       ---                ---

With NAT pools we can also do rotary assignments if we want or overload
the pool if we want to do Port Address Translation (PAT).

Now we will also create a scenario where using a route-map. Using route-maps
we can create more advanced scenarios. For this scenario telnet traffic
going to 184.10.0.4 will get one source IP and HTTP traffic will get
another source address.

R2(config)#ip access-list extended ISP1
R2(config-ext-nacl)#permi tcp any host 184.10.0.4 eq telnet
R2(config-ext-nacl)#ip access-list extended ISP2
R2(config-ext-nacl)#permit tcp any host 184.10.0.4 eq www
R2(config-ext-nacl)#ip nat pool POOL_ISP1 11.11.11.1 11.11.11.1 prefix-length 24
R2(config)#ip nat pool POOL_ISP2 22.22.22.2 22.22.22.2 prefix-length 24
R2(config)#route-map RM_ISP1
R2(config-route-map)#match ip add ISP1
R2(config-route-map)#route-map RM_ISP2
R2(config-route-map)#match ip add ISP2
R2(config-route-map)#ip nat inside source route-map RM_ISP1 pool POOL_ISP1
R2(config)#ip nat inside source route-map RM_ISP2 pool POOL_ISP2

Now to verify the configuration, first we send telnet to 184.10.0.4.

NAT: map match RM_ISP1
NAT*: i: tcp (192.168.1.11, 29183) -> (184.10.0.4, 23) [42518]
NAT*: i: tcp (192.168.1.11, 29183) -> (184.10.0.4, 23) [42518]
NAT*: s=192.168.1.11->11.11.11.1, d=184.10.0.4 [42518]

Now we send to port 80 instead.

NAT: map match RM_ISP2
NAT*: i: tcp (192.168.1.11, 15942) -> (184.10.0.4, 80) [30734]
NAT*: i: tcp (192.168.1.11, 15942) -> (184.10.0.4, 80) [30734]
NAT*: s=192.168.1.11->22.22.22.2, d=184.10.0.4 [30734]

And the translation table.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
tcp 22.22.22.2:27143   192.168.1.11:27143 184.10.0.4:80      184.10.0.4:80
tcp 11.11.11.1:64511   192.168.1.11:64511 184.10.0.4:23      184.10.0.4:23

So using route-maps we can do more advanced scenarios. If we have multiple
inside interfaces we could even match on those.

NAT can also be used to do a form of basic load balancing. Several
inside local addresses will be mapped to one inside global address.
A pool of inside local addresses will be created and handed out in a
rotary fashion.

R2(config)#access-list 1 permit 222.2.2.2
R2(config)#ip nat pool ROTARY_POOL 10.0.0.1 10.0.0.3 prefix-length 24 type rotary
R2(config)#ip nat inside destination list 1 pool ROTARY_POOL

IP addresses 10.0.0.1, 10.0.0.2 and 10.0.0.3 will now be handed out in a rotary
fashion when someone tries to access the IP 222.2.2.2. We can see this when
debugging the NAT translation.

NAT*: s=184.10.0.4, d=222.2.2.2->10.0.0.2 [42645]
NAT*: s=184.10.0.4, d=222.2.2.2->10.0.0.3 [57551]
NAT*: s=184.10.0.4, d=222.2.2.2->10.0.0.1 [26254]

So this performs a basic form of load balancing. The only thing different here is
that we are using the ip nat inside destination command. This translates the
destination of the packet. Usually we translate the source of the packet but
since static NAT is bidirectional in the other direction the destination of
the packet will be translated. When doing this form of NAT we need to trigger
it by sending TCP packets. Just sending ICMP will not trigger the NAT translation.

We have been through a lot of scenarios so far. Almost all of the scenarios
describe how to translate the source IP of the packet going out from the local
network. What if we want to translate the source of the address coming in on
the outside interface instead? This can be useful in scenarios
where there are overlapping subnets, e.g. the same subnet is used on two different
companies and they need to connect through a VPN tunnel or such. Syntax is the
following.

ip nat outside source static OUTSIDE_GLOBAL OUTSIDE_LOCAL

NAT: s=184.10.0.4->4.4.4.4, d=10.0.0.1 [5]

Here we see that the source of the packet is translated when coming in
on the outside. And this is the translation table.

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- ---                ---                4.4.4.4            184.10.0.4
icmp 10.0.0.1:1        10.0.0.1:1         4.4.4.4:1          184.10.0.4:1

The final scenario I want to describe is NAT on a stick. It’s not a very
common scenario but the idea is this. Look at the topology below.

R3 has only one interface which leads to a problem because we need to define
one interface as inside and the other as outside. How can we solve this?
We will use what is called NAT on a stick. R3 will do policy routing and
send traffic to its loopback to trigger the NAT process. R1 and R2 need
to have default routes towards R3 which will be doing the NAT. When R1
pings with a source of its loopback (10.1.1.1) that should be translated
to 100.1.1.1. When R2 pings from its loopback (10.2.2.2) then it should
be translated to 200.2.2.2. We start by setting up the policy routing.
We create an access-list matching traffic from 10.1.1.1 to 200.2.2.2.
Then we create a route-map matching the ACL and set the interface to
loopback0. The loopback interface will be the NAT inside interface.

R3(config)#access-list 100 permit ip host 10.1.1.1 host 200.2.2.2
R3(config)#route-map PBR
R3(config-route-map)#match ip add 100
R3(config-route-map)#set interface lo0
R3(config-route-map)#exit
R3(config)#int f0/0
R3(config-if)#no ip redirects
R3(config-if)#ip policy route-map PBR
R3#sh ip policy
Interface      Route map
Fa0/0          PBR

We also disable ICMP redirects so that R1 does not bypass R3 when
sending traffic to R2. We need to add a few routes on R3 for the
scenario to work. The network 10.1.1.0 is routed to R1. Then
10.2.2.0 and 200.2.2.0 is routed to R2. Why do we need to route
the 200.2.2.0 network to R2? This is because the order of operations
in Cisco routers. On inside to outside policy routing is done first, then routing
and then NAT. On outside to inside NAT is done first, then policy routing
and after that routing. Before we add the rest of the configuration
lets think about the traffic flow.

R1 sends an ICMP packet with (S= 10.1.1.1 , D= 200.2.2.2). The packet comes
inbound on R3 on Fa0/0. The traffic coming in matches the policy and the packet
is looped through R3 lo0. Loopback0 has ip nat inside so this triggers the
NAT process. The source IP 10.1.1.1 is translated to 100.1.1.1 and the destination
is translated to 10.2.2.2, then the packet is sent out Fa0/0.
The packet reaches R2 with (S= 100.1.1.1, D= 10.2.2.2). R2 sends
an ICMP reply with (S= 10.2.2.2, D= 100.1.1.1). The packet comes in on R3
Fa0/0 which is the NAT outside interface. That triggers a translation of the
source from 10.2.2.2 to 200.2.2.2. The destination is also translated from
100.1.1.1 to 10.1.1.1. R3 then checks the routing table and
sends the packet back out Fa0/0 to R1. The packet reaches R1 with
(S= 200.2.2.2 , D=10.1.1.1). And that finishes the flow. Now to
configure it.

R3(config)#ip route 10.1.1.0 255.255.255.0 131.1.123.1
R3(config)#ip route 10.2.2.0 255.255.255.0 131.1.123.2
R3(config)#ip route 200.2.2.0 255.255.255.0 131.1.123.2
R3(config)#int lo0
R3(config-if)#ip nat inside
R3(config-if)#int fa0/0
R3(config-if)#ip nat outside

Take a look at the translation table.

R3#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- ---                ---                200.2.2.2          10.2.2.2
--- 100.1.1.1          10.1.1.1           ---                ---

Now to see if it works. We will debug NAT on R3 to see what is happening while
pinging from R1.

NAT: s=10.1.1.1->100.1.1.1, d=200.2.2.2 [21]
NAT: s=100.1.1.1, d=200.2.2.2->10.2.2.2 [21]
NAT*: s=10.2.2.2->200.2.2.2, d=100.1.1.1 [21]
NAT*: s=200.2.2.2, d=100.1.1.1->10.1.1.1 [21]

Finally here is a drawing that is describing the traffic flow.

This has been
a very big post and I wrote it to have as a reference for my studies. You
don’t have to read the whole post at once but I hope that you find some
useful scenarios that you can try out for yourself. One final piece of advice
is that if you run NAT in Dynamips you should assign that router 256MB of
memory or you will see some strange things happening like sh run not working.