Lesson 58 - Introduction to IPv6 - Migration

Now, being equipped with some fundamental IPv6 knowledge, we can try to configure RIPng protocol (RIP Next Generation), as well as try to connect two different IPv6 networks over IPv4 cloud. I'm going to use the same topology in the previous lesson.

Pic. 1 - IPv6-IPv4 Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Let's start off with enabling RIPng between R1 and R3 followed by some verification steps. RIPng is very similar to RIPv2 we used before. It uses similar mechanism such as split-horizon, maximum hop-count (16 hops), advertisements every 30 seconds, etc. It uses UDP port 521 (RIP uses UDP port 520).

  
Step 1
Configure IPv6 and IPv4 addresses and enable the interfaces. Check point-to-point reachability.

R1 Configuration:

!

interface Loopback0
 no ip address
 ipv6 address 2001:1:1:1::1/64
!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:13:13:13::1/64
!

interface Serial0/0
 ip address 10.1.1.1 255.255.255.252

!

R2 Configuration:

!

interface Loopback0
 no ip address
 ipv6 address 2001:2:2:2::2/64

!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:24:24:24::2/64
!

interface Serial0/0
 ip address 10.1.1.2 255.255.255.252

!

R3 Configuration:

!

interface Loopback0
 no ip address
 ipv6 address 2001:3:3:3::3/64
!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:13:13:13::3/64

!

R4 Configuration:

!

interface Loopback0
 no ip address
 ipv6 address 2001:4:4:4::4/64

!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:24:24:24::4/64

!

Verification:

Pic. 2 - IPv6 Ping Test on R1.

Pic. 2 - IPv6 Ping Test on R2.

Since, pinging by IPv6 address is a bit awkward, you can create name-to-ip mapping using the following commands (here: R1 as an example):

R1 Configuration:

!

R1(config)#ipv6 host R3 2001:13:13:13::3
R1(config)#end

!

Then, you can 'ping R3' (name is case insensitive) instead of using its address.

The routing table of R1 looks like this. You should recognize the addresses easily based on the previous post.

Pic. 4 - R1's IPv6 Routing Table.

Step 2
Enable RIPng to advertise loopbacks. Check the reachability.

In order to support IPv6 routing, you must enable support for it using:
'ipv6 unicast-routing'. Starting RIP process will require to configure a tag for the process (can be number or name). Then, you enable RIPng on the interfaces in question (note: there is no network statement to do that).

R1 Configuration:

!

ipv6 unicast-routing

!

ipv6 router rip TEST

!

interface Loopback0
 no ip address
 ipv6 address 2001:1:1:1::1/64
 ipv6 rip TEST enable

!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:13:13:13::1/64
 ipv6 rip TEST enable
!

R2 Configuration:

!

ipv6 unicast-routing

!

ipv6 router rip TEST

!

interface Loopback0
 no ip address
 ipv6 address 2001:2:2:2::2/64
 ipv6 rip TEST enable

!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:24:24:24::2/64
 ipv6 rip TEST enable

!

R3 Configuration:

!

ipv6 unicast-routing

!

ipv6 router rip TEST

!

interface Loopback0
 no ip address
 ipv6 address 2001:3:3:3::3/64
 ipv6 rip TEST enable
!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:13:13:13::3/64
 ipv6 rip TEST enable

!

R4 Configuration:

!

ipv6 unicast-routing

!

ipv6 router rip TEST

!

interface Loopback0
 no ip address
 ipv6 address 2001:4:4:4::4/64
 ipv6 rip TEST enable
!

interface FastEthernet1/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:24:24:24::4/64
 ipv6 rip TEST enable

!

Verification (here just on R1):

Pic. 5 - R1's RIPng Routing Table.

Note!
R3's Loopback has been advertised to R1. The next-hop-address is the R3's link-local address, NOT the globally unique IPv6 address.

Pic. 6 - Debugging RIPng.

Take time and effort in analyzing the output of the debug. Pay attention to the UDP port number used. It is 521 (RIPv1 and RIPv2 use 520). Also notice that the source IPv6 is the router's link-local address and not globally unique one. Also, the destination address is IPv6 multicast address reserved for RIPng: FF02::9.
Another, worth noting fact is that R3 advertises its loopback (2001:3:3:3::/64) and its locally connected network (2001:13:13:13::/64). 

One more command to check RIPng configuration.

Pic. 7 - IPv6 Protocols.

Step 3
Create tunnel between two IPv6 networks over IPv4 island.

Since CCNA official course does not teach how to create tunnels, I will use 6to4 tunneling method which encapsulates IPv6 packet in IPv4 headers to send them across IPv4 network. These posts do not aspire to help you pass the exam. They are designed as an extra, practical help to master the technologies at the CCNA level instead.

R1 Configuration:

!

interface Tunnel0
 no ip address
 ipv6 address 2001:12:12:12::1/64
 ipv6 rip TEST enable
 tunnel source 10.1.1.1
 tunnel destination 10.1.1.2
 tunnel mode ipv6ip

!

R2 Configuration:

!

interface Tunnel0
 no ip address
 ipv6 address 2001:12:12:12::2/64
 ipv6 rip TEST enable
 tunnel source 10.1.1.2
 tunnel destination 10.1.1.1
 tunnel mode ipv6ip

!

Verification:

Pic. 8 - R3's IPv6 Routing Table.

Pic. 9 - Ping Test from R3 to R4.

The Cisco documentation on how to implement IPv6 is available at:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/12_4/ipv6_12_4_book.html 

If you want to learn more on tunneling methods used during the migration look at:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel.html

Another method called NAT-PT (NAT Protocol Translation) can is explained at:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-nat_trnsln_ps6350_TSD_Products_Configuration_Guide_Chapter.html

In my next post, I will address the basics of WAN technologies including some legacy technologies such as Frame-Relay since they are still part of the exam game.

Lesson 54 - Network Address Translation Part 4

It's time to put our theory into practice. We're going to use a single topology and try out different scenarios. They are not related to one another but my intention is to show you the variety of different methods in use. Keep in mind that they are just the few fundamental types of translations but there are more options available and they can become a bit more complex than the ones presented here.

Pic. 1 - Network Topology.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

R2 is playing a role of ISP's router. For the purpose of this presentation I'm not going to use real IP public addresses. I'm going to use 172.x.x.x range and pretend they are public ones.

Addresses used in this lesson are going to be as follows:
Private (LAN) IP = 192.168.1.0/24 and 192.168.2.0/24
Public (Internet) IP = 172.16.1.0/30 (connection to ISP)
Public (Internet) IP = 172.30.1.1 (Internet host used to check NAT)

All these addresses are simulated using Loopback interfaces.

R1 Initial Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
!

ip http server

!

ip route 0.0.0.0 0.0.0.0 172.16.1.2

!

R2 Initial Configuration:

!

interface Loopback0
 ip address 172.30.1.1 255.255.255.0
!

interface FastEthernet1/0
 ip address 172.16.1.2 255.255.255.252

!

ip http server

!

ip route 172.20.1.0 255.255.255.252 172.16.1.1

!

Scenario 1 - Static NAT
In this scenario I'm going to configure a static (one-to-one) NAT. This type of configuration allows me to present my public services to the Internet clients. Let's pretend that our 192.168.1.1 address is a Web server and is connected to R1 (loopback1 simulates this server). Our ISP gave us two public IP addresses (we pretend they are public anyway).

Inside Global Address Pool:

• 172.20.1.1/30
• 172.20.1.2/30

Our web server (192.168.1.1) will be seen on the Internet as 172.20.1.1. Below is the configuration to accomplish that.

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside

!

ip nat inside source static 192.168.1.1 172.20.1.1

!

Note!
When you assign inside or outside role on the interface, the router is going to add 'ip virtual-reassembly' (dependant on the IOS version you use). At the CCNA level you can ignore the meaning of this command.

Verification:

Pic. 2 - NAT Table.

Note!
Static entry is created allowing transmission towards 192.168.1.1 which is seen as 172.20.1.1 on the Internet. Since we have not specified any layer 4 protocols (tcp/udp) and their ports, all ports are open in R1 allowing access to all ports on the web server. If you wanted to open only TCP port 80, you could use this command instead (more likely in real life scenarios):

!

ip nat inside source static tcp 192.168.1.1 80 172.20.1.1 80

!

Pic. 3 - Accessing Web Service.

Connection succeeds!

Scenario 2 - Dynamic NAT using IP Address Pool.
In this scenario we have the same pool of pretend-to-be-public IP addresses from scenario 1. This scenario will dynamically pick the first available IP address and use it for the host that wishes to send packets to the Internet. Since we only have two public IP addresses, only two hosts can send traffic at the time. Adding the 'overload' keyword will include the port translation and more hosts can reuse these two public addresses (172.20.1.1-2/30).

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside
!

!

! The below command defines public IP addresses in the pool.

!

ip nat pool ISP_POOL 172.20.1.1 172.20.1.2 prefix-length 30
!

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed.

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

! The translation of INSIDE Local IP (ACL1) 

! to the INSIDE Global IP (pool ISP_POOL)

!

ip nat inside source list 1 pool ISP_POOL

!

Verification:

Pic. 4 - NAT from 192.168.1.0/24 and 192.168.2.0/24 Subnets.

This type of translation is not used as often as the last one. In case you wanted to use it and have more than two hosts sending traffic towards the Internet, you would use the same configuration including the 'overload' keyword like presented in the scenario 3.

Scenario 3 - Dynamic NAT using IP Address Pool with Overload.
The same method like presented in scenario 2 but used when there is no sufficient public (Inside Global) addresses for the number of hosts used in our LAN (Inside Local addresses).

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside
!

!

! The below command defines public IP addresses in the pool.

!

ip nat pool ISP_POOL 172.20.1.1 172.20.1.2 prefix-length 30
!

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed. 

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

! The translation of INSIDE Local IP (ACL1) 

! to the INSIDE Global IP (pool ISP_POOL)

!

ip nat inside source list 1 pool ISP_POOL overload

!

Scenario 4 - NAT Overload
This is by far the most often used translation. This method is used on all broadband connections. In this method we only need a single public IP address (the one we use on the router's interface facing the ISP).

Our Inside Local addresses are: 192.168.1.0/24 and 192.168.2.0/24, and the single Inside Global address is: 172.16.1.1. Check the configuration below:

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed. 

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

ip nat inside source list 1 interface FastEthernet1/0 overload

!

Verification:

Pic. 5 - NAT Overload.

In case things do not work, use the following steps to troubleshoot NAT:

1. Check the 'ip nat inside' and 'ip nat inside' statements on the interfaces.
2. Check if your ACL matches on the appropriate Inside Local addresses. If you send traffic from these, 'show access-list' should show you the hits against the ACL entries.
3. You could consider using extremeley dangerous command: 'debug ip nat'. This one however, will inevitably crash your production router. If the traffic is not heavy (no users using the Internet), you can try to use it the way I present below.

I will use the debug ip nat for the presentation purposes only. DO NOT USE THIS on the production equipment!

I will trace a specific Inside Local address (192.168.1.1) translation.

Step 1
Configure the ACL that matches on our single Inside Local address (192.168.1.1)

R1 Configuration: 

!

access-list 99 permit host 192.168.1.1

!

Step 2
Using ACL 99 configured in step 1, I will use debug to see the NAT translation work. The proper output is shown below:

Pic. 6 - NAT Troubleshooting.

Note!
Translation: 192.168.1.1->172.16.1.1 when the packet is sent out F1/0. The translation on the packet returning: 172.16.1.1->192.168.1.1.


Also, the ACL receives the hits. Loot at this below:

Pic. 7 - ACL Hits.

Note!
My ACL 1 which matches on Inside Local addresses has received a hit. It is configured correctly for NAT.

Lesson 53 - Network Address Translation Part 3

In my last post I tried to explain the main principles behind NAT. As an example I used static and dynamic approach in which a client receives multiple IP addresses from the ISP (Internet Service Provider). In most cases though, we receive only a single IP address which is used on the router's interface that faces the Internet.

In that case, how a single IP address can represent (be used by) multiple computers in order to allow them communication with the hosst on the Internet? The solution is to use NAT Overload.

NAT Overload
In this method, the major points described in previous lesson do not change. Still, the router will have configuration that allows is to distinguish the 'nat inside' and 'nat outside' interfaces.

Also, the router is going to replace an 'inside local' IP address with the 'inside global' (the one used on the interface connected to ISP). This time though, ALL inside local addresses (private ones; RFC 1918) will be represented by the same unique public IP address (e.g. 86.46.1.10). This will instigate the problem when the packets are sent back from the Internet. They all point to the SAME public IP. That is why, we need something else to distinguish between PC1 (e.g. 192.168.1.1) and PC2 (e.g. 192.168.1.2) that will be represented by the same address: 86.46.1.10.

What could be this distinguisher?

TCP/UDP ports of course! Recall, that each computer, while sending something out, picks a source port from the range above 1023, and the well-known destination port. These are enough to distinguish PC1 from PC2, since it is very unlikely they will pick the same source port. If that happens, the router will replace this source port in TCP or UDP header with something unique.

Here's what happens when PC1 sends packets towards www.ciscco.com.

Step 1

The packet from PC1 (src: 192.168.1.1) arrives at the 'nat inside' interface (f0/0). The router is instructed to read its source IP address as well as its source TCP port in the layer 4 header. Appropriate entry is created in the NAT table as per Pic. 1 (Inside Local). Note, that this time R1 makes a note of the source port: 192.168.1.1:2001

The IP source address is removed and replaced with the 86.46.1.10 (R1's 'nat outside' interface - S1/0). The entry in the NAT table is created under the 'Inside Global' column. Also, the 'Outside Local' and 'Outside Global' entries are populated as per Pic. 1. This record in the NAT database, will allow to translate the packet back when www.cisco.com is replying to the sender (PC1).

Notice!

The :2001 is the port number in the TCP header.

Pic. 1 - NAT Overload - PC1's Transmission.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Step 2
When www.cisco.com (72.163.4.161) replies, the packet is delivered back to R1. The router, upon receiving the packet on the 'nat outside' interface, must now find the appropriate record in the NAT table, allowing it to locate the original sender's IP address and its source port (here: 192.168.1.1:2001). If there is no such entry, the packet is going to be dropped. Since in our case, the entry exists, the router is translating the packet back as shown in the pic. 2:

Pic. 2 - NAT Overload - PC1 Receives the Reply from www.cisco.com.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Suppose during this transmission, (PC1-to-www.cisco.com), PC2 is also going to send something towards the Internet. In order to simplify our discussion, PC2 is going to send the packet towards www.cisco.com as well (but this could be any host on the Internet).

Step 3
R1 receives another packet on its 'nat inside' interface (f0/0). It is sourced by IP address 192.168.1.2, the source TCP port 1408 this time. This port has not been used yet (does not exist in NAT table under 'inside local' column), so it is unique and can be used to send the packet out. Another entry is going to be created as per pic 3 below. Watch carefully the second record in the NAT table.

Pic. 3 - NAT Overload - PC1's Transmission.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Step 4
The web server (www.cisco.com) is sending the reply back. Again, R1 will look for the appropriate entry in the NAT table ('inside global=86.46.1.10:1408), to find out which machine was the originator of the traffic flow. Translation back to the original values is performed (dst: 192.168.1.2:1408). PC2 receives the reply from the web server.

Pic. 2 - NAT Overload - PC2 Receives the Reply from www.cisco.com.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In case the source port has already been used by some computer (even though it is rare it can happen), the router is going to use a different port. Imagine that the PC2 has also chosen to use the port 2001. In such situation, the 'Inside Local' entry is going to look like this:
192.168.1.2:2001

But, then upon noticing the port is already in use, the router will pick some other port that has not been used yet. The corresponding entry in the 'Inside Global' will be be changed to this for instance:
86.46.1.10:2002

In such case, the cisco web server will be replying to two different destinations:
86.46.1.10:2001 translated back to: 192.168.1.1:2001
and
86.46.1.10:2002 translated back to:192.168.1.2:2001

I hope this will do for you. In my next post, I'm going to show you how to configure NAT using four different methods:

• Static NAT (one-to-one)
• Dynamic NAT using pool of addresses
• Dynamic NAT overload
• Dynamic NAT using pool of addresses with overload

Lesson 52 - Network Address Translation Part 2

NAT Principles in a Nutshell
Now, that you realize there are not enough addresses for all devices in the global network, we can proceed with the general principles behind NAT.

The idea is quite simple when you think about it. The role of the edge router (the one that connects our private network to ISP) is to replace the original, source address in the IP header (private) with the one that is globally unique.

When the packet comes back, the edge router must have enough information to replace the globally unique address used (which now is the destination address) with the same one that was used by the sender originally (private).

NAT Principles - Detailed Explanation
Using our proper terminology, when the IP packet enters the router's inside interface (connected to the LAN), and is sent out the outside interface (connected to the Internet), it removes the inside local address (private, e.g. 192.168.1.1), makes a note what it did in the so called NAT table, and inserts the inside global address (public) in the IP header instead.

So for instance, the original source 192.168.1.1 becomes 86.46.1.10 when the packet is sent towards the Internet (apologies if I use somebody's real IP address here) .

Then, when the destination host sends the reply back to the original sender, this 86.46.1.10 (former source) becomes the destination address. Our edge router receives it on its 'outside interface'. Since, the outbound interface is now our 'inside interface' the router will need to find the appropriate entry in the NAT table which will allow it to identify the original sender's address (our 192.168.1.1). Its address will be now inserted in the destination field of IP header so the packet will be sent to the appropriate host originating this transmission. Check the step-by-step procedure below to see that more clearly.

Step 1
PC (Src=192.168.1.1) is sending packet towards Cisco web server (Dst=72.163.4.161). Since, the destination is not on the same network, the packet is sent towards the default gateway (MAC address of the router's F0/0). If you have problems with this, try to look back at the lessons about TCP/IP traffic flow.

Step 2
The router R1 receives the frame, checks the MAC address and realizes it is the destination for this Layer 2 frame (its MAC address shows in the destination field of the Ethernet header). Layer 2 frame is stripped off and the IP header is read. The destination IP (72.163.4.161) is not listed in the routing table, but the router has a default route (0.0.0.0/0) which tells it to send it to the ISP's router (here:R2). The packet is moved to the outbound interface (S1/0).

Now comes the tricky part. Both interfaces have been assigned special roles in NAT configuration. The interface F0/0 is configured as 'nat inside' which tells the router that packets sourced here belong to the 'inside local' group of addresses (candidates for translation). And the S1/0 interface is configured as 'nat outside'. This interface cannot send packets out with their original 'inside local' numbers (private addresses defined in RFC 1918). The router must perform the translation (address replacement) as per Step 3.

Step 3
R1 is removing 192.168.1.1 address from the IP header (source), and inserts 'inside global' address given to us by our ISP (for example: 86.46.1.10). You're probably waving your hands right now in protest saying: but my ISP does not give me many addresses. Stick with me for now, I will address this issue in my next post. For now, let's just assume that our ISP is generous and gives us a whole bunch of public IP addresses.

After removing 192.168.1.1 and replacing it with 86.46.1.10, the packet is sent out towards its destination (72.163.4.161). R1 creates a special entry in the NAT Table which will allow it to replace it back to 192.168.1.1 when the packet is sent back from www.cisco.com (72.163.4.161). Look at this action below:

Pic. 1 - Inside Local Address Replaced with Inside Global.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Step 4
The Cisco web server (72.163.4.161) is replying back to the sender. So, the IP header has the following addresses:
Src = 72.163.4.161
Dst = 86.46.1.10

The routers on the Internet send it back to our ISP (don't ask how it's done), which in turn, sends this towards S1/0 interface. At this stage, tTake this action for granted. The packet arrives on the 'nat outside' interface of R1 (S1/0). This is where the router is going to look into the NAT table, that should have the proper entry created before, allowing it to remove 86.46.1.10 and inserting the previously used address (192.168.1.1). This action allows to send this packet out its 'nat inside' interface (F0/0) back to the host which originated this transmission and expects to receive the reply.

After translation, the header looks as follows:
Src = 72.163.4.161
Dst = 192.168.1.1

The PC receives the reply packet from 72.168.4.161 as expected.

Pic. 2 - Inside Global Replaced with Inside Local.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

If you have many public addresses (inside global) you can configure this type of translation using two methods:

• Static Translation - one-to-one translation (one inside local is represented by the same inside global address). This allows 24/7 access to that computer (e.g. www, ftp, smtp, etc.) since the entry never ages out.
• Dynamic Translation - computers can use the public addresses from the pool of available ones. Then, after the transmission ends and the entry ages out, this public (inside global) address is sent back to the pool and other computer can use it. There is not permanent one-to-one translation using this method.

The problem is that in 99.999% cases, ISP only gives you a one public address which is applied on the router's interface facing the Internet ('nat outside'). How does NAT handles this problem?

In such situations we use Port Address Translation (Cisco also calls this method NAT overload). This method I leave for my next post.

Lesson 51 - Network Address Translation Part 1

Why NAT?
In 90s we observed an exponential growth of users connecting to a global network called the Internet. As of today, there are billions of people in this global village. The problem is that the designers of TCP/IP protocol suite did not realize this would happen. With the 32 bit IP address that was used originally we could allocate more than 4 billions unique identifiers. Apparently, this is not enough today having billions of devices using public network.

In February 1996 RFC 1918 document has been published. In it, some IP address reservations have been made known as PRIVATE ADDRESS SPACE. The ranges have been reserved as follows:

• 10.0.0.0 - 10.255.255.255  (10/8 prefix)
• 172.16.0.0 - 172.31.255.255  (172.16/12 prefix)
• 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Private Address Space is used in our local networks (home, work etc.) and cannot be used as public IP address range. This scope is sometimes referred to as non-routable addresses. This does NOT mean the routers cannot use them to route the packets. It means, that these addresses should never appear as source or destination on the Internet (unless this is some form of attack or misconfiguration).

What is NAT?
Network Address Translation is a technique in which the EDGE router (the one that is connected to ISP (Internet Service Provider) and your LAN, removes the original SOURCE address in the IP header (private range - RFC 1918) and replaces with legitimate, unique, public one leased to us by ISP while sending packets towards the Internet. However it is smart enough to keep this information in the special database called: NAT table. When the reply comes back, the SOURCE and DESTINATION addresses are reversed in the IP header. Once the packet reaches our EDGE router, it uses the right entry in the NAT table to swap the destination IP PUBLIC address (that represented our computer) back to its PRIVATE address.

If it sounds a little vague right now, do not worry since in my next post I will show you this operation step by step using some graphics.

NAT Terminology
If you want to fully understand this technique, you must understand the terminology that is used by it first. The official terms can be found on Cisco web site:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094837.shtml

Look at the below picture I'm going to use in the NAT section of this tutorial.

Pic. 1 - NAT Topology

Icons designed by: Andrzej Szoblik - http://www.newo.pl

What you are looking at is two companies (ABC and XYZ) connected to the Internet represented byR3 here. In real life this cloud consists of many routers belonging to different ISPs.

Computers are connected to the LAN and in both cases (I did this on purpose), use the same range of Private Address (192.168.1.0/24). Of course they can use any of addresses listed in RFC 1918.

R1's Serial0/1 interface uses 1.1.13.1, and R2 uses 1.1.12.2 address. Both are NOT described as the PRIVATE so they are PUBLIC or legitimate ones (my apologies if I used somebody's real, public addresses here. They are only used for educational purposes).

Using NAT technique you must be able to properly name them as per Cisco article above. Let's assume that we work for ABC company and we look at all addresses from this standpoint (this is critical). Here's what they are as per Pic. 1:

ABC Company

• INSIDE LOCAL - address (inside your LAN, before translation). In our example this would be our 192.168.1.0 (ABC) address.
• INSIDE GLOBAL - address used on the router's interface facing the Internet. GLOBAL means that is is legitimate, globally unique address. These are provided by ISP or Network Information Center (RIPE in Europe, ARIN in the US, etc.). For instance, in the example this would be 1.1.13.1 address.
• OUTSIDE GLOBAL - address which is also globally unique (like inside global), but is leased to another company, not us (remember? We're ABC here). In this example this would be 1.1.12.2 for instance.
• OUTSIDE LOCAL - address of the outside host as it appears to our local hosts. Typically in the NAT table we see them as OUTSIDE GLOBAL addresses. Our R1 router will never see XYZ company's 192.168.1.0 scope since it will be translated into a public IP before they send packets towards the Internet.

If you want to read more in-depth description of the terminology please, read the Cisco article I included in this post.

This concludes the introduction to NAT. In my next post, we will inspect step-by-step the process of NAT on the router.

Lesson 50 - Extended ACL Examples

Try to think of this post as your opportunity to put the extended ACLs into practice. Do not look at the solutions which are presented at the end of this post. Try to accomplish the tasks using IOS help '?' If you have found this difficult, you can look at the solutions and watch my videos I posted on Youtube. ACL related video links can be found at the bottom of this post.

The last video shows the syntax and benefits of using Named ACLs. Once you get to know named ACLs, you will not want to use numbered ones.

Look at this simple topology below first. Then

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Extended ACL Lab

Assumptions
You are in charge of R1 and R2 routers. R3 belongs to your Service Provider network (SP) and simulates Internet in our examples. If you want to enable HTTP access on the router, type in the 'config' mode:
ip http server

Static routing has been configured between routers.

Task 1
Configure an access-list disabling anyone TELNET to R1 and all devices behind it (R2) if the traffic is originated from Internet (here: SP). All other traffic should be permitted.

Task 2
On R1 remove the previous ACL and configure a new one allowing only HTTP access to 172.16.102.0/24 if the traffic is originated from Internet (here: SP). All other traffic should be discarded.

Task 3
On R1 remove previously configured access-list. Instead, allow the returning traffic from HTTP (172.16.102.0/24) towards any destination. All other traffic from 172.16.102.0/24 should be discarded.

Task 4
Remove previously configured ACL. Configure an access-list that blocks the TELNET/SSH traffic toR1 if the traffic is originated by 10.1.13.3 address. Use a standard ACL.

Extended ACL Lab

Task 1

Configure an access-list disabling anyone TELNET to R1 and all devices behind it (R2) if the traffic is originated from Internet (here: SP). All other traffic should be permitted.

R1 Configuration:

!

R1(config)#access-list 100 deny tcp  any any eq telnet
R1(config)#access-list 100 permit ip any any
R1(config)#int s0/1
R1(config-if)#ip access-group 100 in
R1(config-if)#end
R1#

!

Verification:

Pic. 2 - Ping from R3.

Pic. 3 - Telnet Test from R3.

Pic. 4 - ACL Statistics.

Task 2

On R1 remove the previous ACL and configure a new one allowing only HTTP access to 172.16.102.0/24 if the traffic is originated from Internet (here: SP). All other traffic should be discarded.

R1 Configuration:

!

R1(config)#no access-list 100
R1(config)#int s0/1
R1(config-if)#no ip access-group 100 in
R1(config-if)#exit
R1(config)#
R1(config)#access-list 101 permit tcp any host 172.16.102.2 eq www
R1(config)#int s0/1
R1(config-if)#ip access-group 101 in
R1(config-if)#

!

Notice!
There is an 'implicit' deny all at the end of the ACL that is why I do not have to use: 'deny ip any any' statement.

Verification:

Pic. 5 - ACL Test.

Notice!
I got the connection to port 80 and terminated session using GET command. In order for the router to accept incoming connection to TCP 80 (WWW), you must type in the following command in the 'config' mode:
ip http server


Task 3

On R1 remove previously configured access-list. Instead, allow the returning traffic from HTTP (172.16.102.0/24) towards any destination. All other traffic from 172.16.102.0/24 should be discarded.

R1 Configuration (one way of accomplishing the goal): 

!

R1(config)#int s0/1
R1(config-if)#no ip access-group 101 in
R1(config-if)#exit
R1(config)#no access-list 101
R1(config)#
R1(config)#access-list 102 permit tcp 172.16.102.0 0.0.0.255 eq 80 any
R1(config)#int f1/0
R1(config-if)#ip access-group 102 in
R1(config-if)#

!

Task 4
Remove previously configured ACL. Configure an access-list that blocks the TELNET/SSH traffic toR1 if the traffic is originated by 10.1.13.3 address. Use a standard ACL.
R2 Configuration:

!

R1(config)#int f1/0
R1(config-if)#no ip access-group 102 in
R1(config-if)#exit
R1(config)#no access-list 102
R1(config)#
R1(config)#access-list 1 deny host 10.1.13.3
R1(config)#access-list 1 permit any        

R1(config)#
R1(config)#line vty 0 4
R1(config-line)#access-class 1 in
R1(config-line)#exit
R1(config)#

!

Notice!
Because I forgot to mention this little contraption in my Standard ACL post, here it is. A standard ACL can be used to block traffic to ports VTY (remote access). The ACL is applied using the:access-class statement.

Pic. 6 - Verification.

Notice! 
Changing the source of my TELNET (lo0=172.16.103.3) allows me to login.
In my next post, I'll attempt to explain Network Address Translation (NAT) which you must be familiar at CCNA level (as of the time of posting it).