Static NAT Cheat-sheet

Static NAT - Port Translation

1)  Define inside NAT interface
2)  Define outside NAT interface
3)  Define NAT using static keyword and assign port only

Example:

R2#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int ser 0/0
R2(config-if)#ip nat outside
R2(config-if)#int fa 0/0
R2(config-if)#ip nat inside

R2(config)#ip nat inside source static tcp 10.2.1.10 80 192.168.2.2  80


Verify:

R2#sho ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.2.2:80     10.2.1.10:80       ---                ---

R2#debug ip nat
IP NAT debugging is on
*Mar  1 00:39:46.131: ipnat_add_static_cfg: id 3, flag 6
*Mar  1 00:39:46.135: id 3, flags 0, domain 0, lookup 0, from_addr A02010A, from_mask FFFFFFFF, from_port 50, to_addr C0A80202, to_port 50 to_mask FFFFFFFF, proto 6
*Mar  1 00:40:20.575: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39818]
*Mar  1 00:40:20.623: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar  1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39819]
*Mar  1 00:40:20.627: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39820]
*Mar  1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20303]
*Mar  1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20304]
*Mar  1 00:40:20.655: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20305]
*Mar  1 00:40:20.655: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39821]
*Mar  1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20306]
*Mar  1 00:40:20.691: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20307]
*Mar  1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39822]
*Mar  1 00:40:20.691: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13399]
*Mar  1 00:40:20.703: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39823]
*Mar  1 00:40:20.723: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [0]
*Mar  1 00:40:20.723: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [39824]
*Mar  1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13400]
*Mar  1 00:40:20.735: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13401]
*Mar  1 00:40:20.743: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [20308]
*Mar  1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50985]
*Mar  1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50986]
*Mar  1 00:40:20.763: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50987]
*Mar  1 00:40:20.771: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13402]
*Mar  1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50988]
*Mar  1 00:40:20.791: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50989]
*Mar  1 00:40:20.791: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13403]
*Mar  1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50990]
*Mar  1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50991]
*Mar  1 00:40:20.803: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50992]
*Mar  1 00:40:20.803: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13404]
*Mar  1 00:40:20.815: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13405]
*Mar  1 00:40:20.823: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13406]
*Mar  1 00:40:20.835: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13407]
*Mar  1 00:40:20.843: NAT*: s=192.168.2.200, d=192.168.2.2->10.2.1.10 [13408]
*Mar  1 00:40:20.851: NAT*: s=10.2.1.10->192.168.2.2, d=192.168.2.200 [50993]
exit
R2#no debug all
All possible debugging has been turned off
R2#

Dynamic NAT cheat-sheet

Dynamic NAT - translate one subnet to a pool of addresses, often used when combining two networks with overlapping subnets.

1)  Define inside NAT interface
2)  Define outside NAT interface
3)  Create pool of addresses to use for NAT
4)  Create standard ACL for inside subnet
5)  NAT statement using ACL and pool as source and destination

Example:

R1(config)#int fa 0/0
R1(config-if)#ip nat inside
R1(config-if)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#exit

R1(config)#ip nat pool POOL2 192.168.2.200 192.168.2.225 prefix-length 24

R1(config)#access-list 1 permit 10.1.1.0 0.0.0.255

R1(config)#ip nat inside source list 1 pool POOL2
R1(config)#end


Verify:

R1#debug ip nat
IP NAT debugging is on
R1#
*Mar  1 00:16:55.147: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar  1 00:16:55.163: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar  1 00:16:55.647: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52471]
*Mar  1 00:16:55.667: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52471]
*Mar  1 00:16:56.155: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar  1 00:16:56.167: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar  1 00:16:56.655: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52472]
*Mar  1 00:16:56.679: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52472]
*Mar  1 00:16:57.131: NAT*: s=10.1.1.10->192.168.2.200, d=192.168.2.2 [0]
*Mar  1 00:16:57.159: NAT*: s=192.168.2.2, d=192.168.2.200->10.1.1.10 [0]
*Mar  1 00:16:57.699: NAT*: s=10.1.1.100->192.168.2.201, d=192.168.2.2 [52473]
*Mar  1 00:16:57.699: NAT*: s=192.168.2.2, d=192.168.2.201->10.1.1.100 [52473]


sho ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.2.200:6659 10.1.1.10:6659    192.168.2.2:6659   192.168.2.2:6659
--- 192.168.2.200      10.1.1.10          ---                ---
icmp 192.168.2.201:63436 10.1.1.100:63436 192.168.2.2:63436  192.168.2.2:63436
icmp 192.168.2.201:63692 10.1.1.100:63692 192.168.2.2:63692  192.168.2.2:63692
icmp 192.168.2.201:63948 10.1.1.100:63948 192.168.2.2:63948  192.168.2.2:63948
icmp 192.168.2.201:64204 10.1.1.100:64204 192.168.2.2:64204  192.168.2.2:64204
icmp 192.168.2.201:64460 10.1.1.100:64460 192.168.2.2:64460  192.168.2.2:64460
--- 192.168.2.201      10.1.1.100         ---                ---

NAT Overload cheat-sheet

NAT Overload:
1)  Define inside NAT interface
2)  Define outside NAT interface
3)  Create standard ACL to permit inside (LAN) subnet
4)  NAT statement with overload keyword

Example:

R1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int ser 0/1
R1(config-if)#ip nat outside
R1(config-if)#int f
*Mar  1 00:02:51.727: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to upa 0/0
R1(config-if)#ip nat inside
R1(config-if)#exit
R1(config)#ip access
R1(config)#ip access-list standard INSIDE_VLAN1
R1(config-std-nacl)#permit 10.1.1.0 0.0.0.255
R1(config-std-nacl)#exit
R1(config)#ip nat inside source list INSIDE_VLAN1 int ser 0/1 overload

Verify:
R1#debug ip nat
IP NAT debugging is on
R1#
*Mar  1 00:05:47.823: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar  1 00:05:47.835: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]
*Mar  1 00:05:48.807: NAT*: s=10.1.1.10->192.168.2.1, d=192.168.2.2 [0]
*Mar  1 00:05:48.819: NAT*: s=192.168.2.2, d=192.168.2.1->10.1.1.10 [0]

Multicast addresses

Because a quick reference is always good for review:

224.0.0.2 - all routers on this subnet
224.0.0.5 - OSPF all routers
224.0.0.6 - OSPF DR/BDR
224.0.0.9 - RIPv2 all routers
224.0.0.10 - EIGRP all routers

Spanning-tree Review

Spanning Tree was standardized in IEEE 802.1d as a layer-2 protocol designed to eliminate switching loops - or rather "bridging" loops since bridges were the prominent device at the time of adoption of the standard.

Root Bridge

The root bridge is the "master" bridge for maintaining all STP information within a network.  When a switch boots up, it immediately believes it is the root bridge and broadcasts a Bridge Protocol Data Unit (or BPDU) to all other switches on the network, at which time an election takes place.  The switch with the lowest bridge ID becomes the root.

The bridge ID is composed of two factors.  First is the root priority, which is a number between 0 and 61440, randomly assignable in increments of 4096 on the switch.  The default priority is 32768 (in hex, 8000), which all Cisco switches are initially configured with.  The second component of the bridge ID is the MAC address.  In the case of an election, the switch with the lowest root ID becomes the root.  First the priority is considered, then the MAC.

It is therefor advisable to configure the priority on a robust core switch when working in a highly complex or robust network to ensure that the switch controlling the STP is capable to handle the workload as well as in a central location.

BPDUs are multicast every two seconds by the root bridge following the initial election.  Contained in this packet is the bridge ID of the root bridge, and as long as that number is lower than the ID of the switch receiving the BPDU no election will be forced.  If a BPDU arrives with a lower ID than is configured on the switch, an election takes place and the STP topology will reconverge.

Root ports

After election of a root bridge, each nonroot switch forms an association back to the root.  The path with the lowest cumulative cost is placed into a forwarding state, and all other paths to the root are placed in a blocking state.  This information is contained in the BPDU, along with the root bridge ID and the sending switch's bridge ID. The cost  is the inverse of the bandwidth on the link between it and the root, so the lowest cost is the fastest path back to the root.  Costs are:

10 Gb:  Cost 2
1 Gb:  Cost 4
100 Mb:  Cost 19
10 Mb:  Cost 100

Each switch that receives a BPDU from the root will have a cost of 0.  It adds the cost of the interface on which it was received to that value and forwards that information to other switches with the new cost.  Each switch in turn performs the same action to determine what is the most efficient path to the root.

When equal cost paths are available, the system determines which port becomes the root port by first looking at the bridge ID and will select the lowest ID as the root.  If both links are to the same switch, it will use the lowest port priority, which is 128 by default but can be administratively set to chooose one link over another.  If port priority is equal, the switch will choose the lowest port number to determine the root port.

Designated Ports

 Designated ports connect to another switch and are a path back to the root bridge.  They are the "input" to the "output" of the root port and are selected based on the same path cost criteria as the root port.

Blocked Ports

When there are two paths from a switch back to the root port, STP will block client traffic from leaving the port with the highest path cost back to the root.  The port will still listen for BPDUs so that the switch can react to topology changes and notifications, but it simply doesn't send any data.

Port State Transitions

STP ports will go through a process of transitioning from a blocked state to a forwarding state.  Those states are:

Blocking - no client data is sent, but still listens for BPDU
Listening - no client data sent, but listens for topolgy updates
Learning - no client data sent, but learning MAC addresses on connected ports
Forwarding - now passing data as well as listening for BPDUs

The timers associated with those states:

Blocking - 20 seconds (max age timeout, or 10 BPDUs missed)
Listening - 15 seconds
Learning - 15 seconds

When a link goes down, a topology change notification BPDU (TCN BPDU) is sent from the switch reporting a link failure.  This is one of the only times a BPDU doesn't originate from the root bridge.   The root will eventually receive the TCN and notify the switches in its topology to start aging out MAC addresses 8 times more quickly than its default of 300 seconds.  The switches then begin rebuilding the topology by assigning ports to either designated, root or blocking states based on the updated condition of the network.

Because of these default timers, a network could take up to 50 seconds to converge and start sending data again.  To modify the default timers, only the root bridge needs to be adjusted and the timer changes will propagate through the topology.

Back in the saddle

Well, here I am, back again.

I read this post that the CCNA 640-802 will be retired as of September 30, 2013.  It was inevitable, but now I really do have to get my act in gear.

I am about to embark on passing this exam by the end of June, 2013.  My general plan for the rest of this week is to:

Routing and routing protocol review
Subnetting, subnetting, subnetting
Cram guide I compiled for the last time I passed the CCNA 640-802

I'm working in the cities this week, so I have long commutes.  I have recorded versions of my cram guide with Baroque music in the background that I'll be listening to as I drive since I'll have a bit of time on my hands.

Mainly, it's time to get back to work.  I've been stretched a bit thin recently with projects at work, passing my EMCISA and taking an intro to Fortinet course, as well as coming up to speed on VMWare implementations.  Since October when I made my change from Managed IT at Marco to Field Service, I've been learning one technology after another and it's taken a lot of work to be able to install and implement solutions using these technologies, and I'm now embarking on Cisco Voice installations.

There is no shortage of cool and exciting technologies to learn.  But for the next 30-45 days I need to focus and get this CCNA out of the way.  I'll be blogging my review notes here as I go along because that seemed helpful.

Time to rock and roll!

RE-taking the CCNA

Well, like a fool I let my CCNA expire and now I nave to re-take the exam.  I've moved from a role in our Managed IT support division out into the field and find that there is a much different set of skills when you are installing and configuring networks than when you are supporting already configured and networks that were (hopefully) working at one time.

So, my little note to self today is the "secret" Cisco escape sequence for traceroute or ping. I can never seem to recall it, so I'm putting it here where I can find it readily.

Ctrl+Shift+6 (twice)

It shouldn't be that hard to remember, but much more necessary today than last year in my old position. I'm hoping to post more as I re-take the exam, as I remember and re-learn things I once knew. I'm actually excited to go back to the beginning here. A good foundation is required for building a good structure...so lest my skills be built on sand, I dedicate myself to this endeavor fully. Target test date: March 15