Search This Blog

Monday, September 6, 2010

Basic Dynamic Network Address Translation - NAT

Above is a basic lab to demonstrate the use of Dynamic Network Address Translation (NAT). NAT was originally created to help extend the lifespan of the IPv4 address space range but it has found other uses in the form security, networks now normally segregate their internal private networks from their public networks. And NAT is a perfectly good way to do that.

The first thing I want to make sure for the people who are just learning NAT to know is that it has a few different ways it can operate. In this article I will only be focusing on one method but I will follow up with more articles explaining the other ways to implement NAT.

So how does NAT work? Well in its simplest form it takes one IP address and turns it into another! Like magic right??

No not really, the magic is really the translation table or more commonly called the Xslate for short. To demonstrate how it works lets look at the diagram above, at the bottom you will see a loopback int 0 with ip address 10.1.1.1/24 assigned to it. If you do a source ping from that address to the loopback int on R3 the source ip will remain the same all the way until it reaches its destination. But at R1 I have configured NAT to identify that IP address and told R1 to translate it to an available address from the NAT outside Pool range of 10.20.1.1-10.20.1.254.

Let us take a look at how I accomplished that feat. Below is the config from R1.

hostname R1
!
interface FastEthernet0/0
 ip address 10.100.1.2 255.255.255.252
 ip nat outside <--- Tells the router where the outside boundary starts, this where the translated IP addresses are sent from out to there destination.
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.10.1.2 255.255.255.252
 ip nat inside <--- Tells the router where the inside boundary starts, this where the translated IP addresses are sourced from and where the translation will begin.
 ip virtual-reassembly
 duplex auto
 speed auto
!
router ospf 1 <---ospf is running on all routers to establish basic routing between routers.
 log-adjacency-changes
 no auto-cost
 network 10.10.1.2 0.0.0.0 area 0
 network 10.100.1.2 0.0.0.0 area 0
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
ip nat pool outside 10.20.1.1 10.20.1.254 prefix-length 24 <---here is where I created the pool of outside IP addresses that I want my internal addresses (10.1.1.0/24) to be translated to.
ip nat inside source list 1 pool outside <---Here is how I told the router which IP addresses I want translated, the list 1 statement is pointing to an access-list #1 which states the IP addresses I want to translate to the the outside pool of addresses.
!
access-list 1 permit 10.1.1.0 0.0.0.255 log <--- and finally the access-list 1 statement declaring the 10.1.1.0/24 network range that I want to be translated.
!
And that is that! The other 2 routers just need basic routing and IP address assignment!

To test this config all we need to do is ping from the R2 loopback interface to the R3 loopback interface and then go to the R1 router and run the 'sh ip nat trans' command at the exec level prompt and we will see the translation record for that ping sequence.

Example:
R1#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.20.1.1:4       10.1.1.1:4         10.200.1.1:4       10.200.1.1:4


The inside global refers to the outside address pool address range, the inside local shows the source IP of the ping, the outside local is the destination, and so is the outside global. The : and number you see after the IP is the sequence number the Xslate table uses to keep track of the session!



Hopefully this is has been helpful and be sure to check out my other articles on the different types of NAT, including static and dynamic overload!!

Thanks for reading and please leave any comments or questions you may have about this article.

Simple VRF LAB w/explanation



Our scenario: Router R2 is acting as the ISP for the other routers and it is using two Virtual Routing and Forwarding tables to keep both Cust1 (R1,R3) and Cust2 (R4, R5) separate from each others networks.

As you may have already noticed in the diagram above I have overlapping IP address assignments. There are 2 different logical networks but also 4 physical links! Without VRF's this IP address scheme would not work. If I pinged R1 10.1.1.2 from R3 10.1.1.6 how would the router know which 10.1.1.2 to send the packet to?


So as a networking professional you need a tool to that allows to jump over this hurdle. Enter the VRF!


VRF's at work - VRF was created as a tool for engineers to use to help separate networks from each other on the same router. This is achieved by creating a separate routing and forwarding table apart from the global routing table.

How to configure a VRF: Creating a VRF is absolutely easy stuff on a Cisco router/L3 Switch. In global configuration mode you can simply type 'ip vrf name-here'  example 'ip vrf blue' like how we have setup in this lab! Once you enter that command you will be put into the VRF sub-command mode. This is where you set the VRF attributes. The only thing you need to set for basic VRF functionality is the forwarding Route Distinguisher (RD) which is in the following format ASN:ID. For instance in our lab I have set the RD for the VRF blue to 200:2, where 200 is the ASN and the 2 is the identification of the VRF. You will normally use the ASN:ID format so you can match the ASN to whatever the routing protocol's AS number is, for instance if you have BGP AS1000 you would use something like 1000:2, you can also use just the IP address and ID #, something like 10.1.1.1:2 would work as well. I will create a new tutorial showing how to use VRF's in routing protocols in another posting!!

Once the VRF is created you must place interfaces into the VRF that you want to share the new routing and forwarding table with. In the diagram above R2's F0/0 and F0/1 interfaces are placed in VRF blue and S0/0 and S0/1 are placed in VRF red. The color assignment and naming is completely arbitrary, you may choose something more logical like CustomerA and CustomerB.You also have to remember that you can only place one interface in one VRF at a time!! So if S0/0 is in red then it can not be in blue, it would defeat the purpose of the whole idea to keep the networks separate!!

So let us jump in and see how the config look on the ISP router, I have edited the config so they only show the important VRF related commands.

Look down the config at my notes so you can see what I have configured and why and how it is working.

hostname ISP

ip cef  <--- Using Cisco express forwarding is recommend for improved forwarding on all the interfaces. I entered the command in the global config mode on the router.
!
ip vrf blue <--- Our first VRF with a route distinguisher of ASN 200 and ID 2
 rd 200:2
!
ip vrf red <--- Our second VRF with a route distinguisher of ASN 100 and ID 1
 rd 100:1
!
interface FastEthernet0/0
 ip vrf forwarding blue <--- Int F0/0 was placed into VRF blue and is now using the blue routing table
 ip address 10.1.1.1 255.255.255.252
 duplex auto
 speed auto
!
interface Serial0/0
 ip vrf forwarding red <--- Int S0/0 was placed into VRF red and is now using the blue routing table
 ip address 10.1.1.1 255.255.255.252
 clock rate 2000000
!
interface FastEthernet0/1 <--- Int F0/1 was placed into VRF blue and is now using the blue routing table
ip vrf forwarding blue
 ip address 10.1.1.5 255.255.255.252
 duplex auto
 speed auto
!
interface Serial0/1
 ip vrf forwarding red <--- Int S0/1 was placed into VRF red and is now using the blue routing table
 ip address 10.1.1.5 255.255.255.252
 clock rate 2000000
!
end

As you can probably tell this is a simple configuration but it works!!

The only thing left to do is to configure the interfaces with IP addresses on the remaining routers in our topology and viola! VRF in action!!!


The customer end points of R1, R3, R4, R5 have no VRF configuration necessary, only basic ip addressing and perhaps a default route or routing protocol to connect the 2 networks together for each Customer!


Once you build this lab you can test it by tracing packets from one end to another between R1 and R3 or R4 and R5.

Well that wasn't hard was it?

I would suggest at this point that you noodle around with this configuration in your lab and try adding on new VRF's and customer endpoints, or if you want to get hardcore start by adding some more ISP's with more complex routing scenarios!!

I hope this article was worth while and please comment and or leave suggestions for future articles!!

Thank you for reading my blog :)

Redundant Gateway Routing Protocol - HSRP

In the above diagram we have 2 Layer 3 switches and 1 Layer 2 switch and 1 PC. The goal of this exercise is to provide the PC a redundant path out of it's own network. The network is 10.1.1.0/24 and is located in Vlan 2. The link connecting ASW1 to the PC is a basic access link and the port has been placed into Vlan 2. The 2 links connecting ASW1 to CSW1 and 2 are 802.1q trunk links. The link between CSW1 and 2 is a layer link, the network connecting them is 10.100.1.0/30.

PC's IP is 10.1.1.100/24 with a gateway of 10.1.1.1. In a standard situation without HSRP only one of the CSW switches could act as the gateway for PC.

But what if CSW1 was chosen to do so and that device failed?

Well that is where HSRP comes into play! Hot Standby Routing Protocol is a Cisco proprietary technology that allows a Network professional to provide redundancy in their network for hosts.

HSRP creates a virtual layer 2 and layer 3 address so that a host (PC) can reach outside its network even though its active gateway is down.

In the HSRP config I have created for this example I have placed CSW1 as the active gateway and CSW2 as the standby gateway.

On CSW1 I created a SVI (Switches Virtual Interface) interface called Vlan 2 and gave it an IP address of 10.1.1.2/24, I have done the same on CSW2 but I used an address of 10.1.1.3/24. The IP addresses must be unique. Example: from global config mode type 'int vlan 2' this will create the switched virtual interface for vlan 2. You will still have to config the actual vlan and any VTP you may want to use on your network as well.

Now to start HSRP we will go in to both Interface Vlan 2's on CSW1 and CSW2 and type the following commands.

CSW1
standby 2 ip 10.1.1.1 <---this sets the VIP (Virtual IP for group 2)
standby 2 pri 1 <--- this sets a priority number for the interface, the lowest number will become the active gateway interface, CSW1 is being told to become the active)
standby 2 pre <--- the preempt command is used for when a failure occurs. If CSW1 was the active gateway and it went down CSW2 would take over as the active gateway. The preemption command tells this gateway to not become the active gateway when it comes back online. You would want this so another convergence on the network does not take place which by default can take about 5 seconds.

CSW2
standby 2 ip 10.1.1.1 <---this sets the VIP (Virtual IP for group 2)
standby 2 pri 2 <--- this sets a priority number for the interface, the lowest number will become the active gateway interface, CSW2 is being told here to become the standby)
standby 2 pre <--- the preempt command is used for when a failure occurs as stated int he CSW1 config, if CSW2 becomes the active and stays active and then has a failure the role of active would switch back over to CSW1, and when CSW2 comes back online it will stay in standby.

As for PC, well all it needs is its basic IP address config including the gateway address of 10.1.1.1. The host PC has no idea that HSRP is running on the network. PC communicates with the VIP and VMAC!

That is it for the HSRP config for Vlan 2. You can create more SVI's for your other Vlans and create standby groups by following the same example above just remember to change the group #!! It is really easy to implement a redundant gateway protocol and can mean the difference between a user being down for the count when disaster strikes on your gateway devices or unknowing skirting the disaster all together!!

I plan to follow this blog about HSRP up with 2 more for HSRP in your DMZ network and how to balance Vlans across your redundant gateway devices using PVST+.

As always thank you for reading and please feel free to leave comments and or suggestions.