Lesson 57 - Introduction to IPv6 - Address Configuration

It's time to put our hands to work now. Let's see how we can configure IPv6 addresses. I'm going to use the following topology diagram to present different options with regard to IPv6 address configuration on router's interfaces.

Pic. 1 - IPv6-IPv4 Topology Diagram.

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

I will use R1 and R3 to begin with. The whole 'Introduction to IPv6' series will end with connecting these two IPv6 networks over IPv4 cloud to show you one of many migration options available.

As you already know, each IPv6-enabled interface, be it a router or computer's interface, will use two distinct addresses:

• link-local (FE80::)
• global (2000::)

Currently there are two global prefixes in use (as of writing this post):

• 2001 - global addresses
• 2002 - 6to4 tunnel (without actually creating a tunnel interface).

Let's open R1's console and configure IPv6 address on F1/0 interface. First, I'll use EUI-64 method to derive the host bits based on the MAC address. Take a look:

Pic. 2 - IPv6 Address with EUI-64.

Note, that by just configuring IPv6 on the interface, IPv6 protocol stack gets turned on automatically. You can verify this like shown below:

Pic. 3. IPv6 Address Verification

There area two methods of turning on IPv6 support on an interface in IOS:

• By using 'ipv6 enable' command.
• By configuring global IPv6 address.

Both link-local and global addresses are now configured. The subnet is what I typed in, the host portion created based on the MAC address taken from F1/0 interface. Do we always have to use EUI-64? Of course not. Both link-local and global addresses can be created automatically. I have removed the previous configuration (pic. 3) and configured this instead:

Pic. 4 - IPv6 Manual Address Assignment

(link-local and global).

Both addresses (link-local and global) are configured manually. Verify this below now:

Pic. 5 - Verification.

Okay. Let's bring the R1's interface F1/0 up, and jump over to R3 for a moment to configure its F1/0 interface ... differently!

An alternative to the above methods (it is going to be used primarily on the computers rather than routers) is so called 'autoconfig' method. For this method to work you must configure two commands first (as of writing this post in most IOS versions I came across both of these must be turned on):

R1 Configuration: 

R1(config)#ipv6 unicast-routing

R3 Configuration: 

R3(config)#ipv6 unicast-routing

R3(config)#int f1/0

R3(config-if)#ipv6 enable

R3(config-if)#ipv6 address autoconfig

Let's verify configuration of IPv6 with this method!

Pic. 6 - Verification.

The moment I enabled 'ipv6 unicast-routing', the router begins to support this method. R3configured as 'autoconfig' will obtain the network portion of the global address (the most significant 64 bits) from the local router (here: R1) by sending a special message called: Router Solicitation(RS). R1, upon receiving this message is going to reply with Router Advertisement (RA). This way,R3 learns what the network portion of the global address is and using EUI-64 completes the host portion, thus creating full, globally unique address to operate.

In IPv6 world there are no broadcasts, so the neighbor discovery using ARP is no longer working. The neighbor discovery, layer 3 to layer 2 address mapping are done using ICMPv6 protocol. There are four ICMPv6 Neighbor Discovery messages you must be aware of. These are:

• NS - Neighbor Solicitation, asking for neighbor information.
• NA - Neighbor Advertisements, introducing yourself to the neighbors.
• RS - Router Solicitation, asking for info about local routers.
• RA - Router Advertisements, advertising yourself as an active router.

Let's enable few debugs (remember that these are dangerous commands on production equipment) and see few of these messages being exchanged.

Pic. 7 - Debugging ICMPv6 Communication.

ICMPv6-ND: DAD: FE80::CE02:6FF:FE1E:10 is unique.

The above messages is the Duplicate Address Detection (DAD; mechanism of checking if the link-local is unique).

ICMPv6-ND: Sending NA for FE80::CE02:6FF:FE1E:10 on FastEthernet1/0
IPV6: source FE80::CE02:6FF:FE1E:10 (local)
      dest FF02::1 (FastEthernet1/0)

After checking that R3's link-local address is unique, it introduces itself to all the neighbors on F1/0 interface (Neighbor Advertisement).

ICMPv6-ND: Sending RS on FastEthernet1/0
IPV6: source FE80::CE02:6FF:FE1E:10 (local)
      dest FF02::2 (FastEthernet1/0)

R3 is sending Route Solicitation trying to discover locally active routers in order to obtain the information about the network portion of the global address.

ICMPv6: Received ICMPv6 packet from FE80::1, type 134
ICMPv6-ND: Received RA from FE80::1 on FastEthernet1/0

R3 receives information from R1 (R1's Router Advertisement)

ICMPv6-ND: Sending NS for 2001:13:13:13:CE02:6FF:FE1E:10 on FastEthernet1/0
IPV6: source :: (local)
      dest FF02::1:FF1E:10 (FastEthernet1/0)

R3 is sending the Neighbor Solicitation trying to discover the neighbors. I already knows the 2001:13:13:13::

ICMPv6-ND: Autoconfiguring 2001:13:13:13:CE02:6FF:FE1E:10 on FastEthernet1/0

R3's autoconfiguration is complete.

ICMPv6-ND: DAD: 2001:13:13:13:CE02:6FF:FE1E:10 is unique.

R3's 128-bit global address is unique (Duplicate Address Detection).

ICMPv6-ND: Sending NA for 2001:13:13:13:CE02:6FF:FE1E:10 on FastEthernet1/0
IPV6: source 2001:13:13:13:CE02:6FF:FE1E:10 (local)
      dest FF02::1 (FastEthernet1/0)
      traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating
IPv6: Sending on FastEthernet1/0
ICMPv6-ND: Address 2001:13:13:13:CE02:6FF:FE1E:10/64 is up on FastEthernet1/0

R3 is announcing its presence on F1/0 segment (Neighbor Advertisement) and fully configured to operate using IPv6 address.

Note, that the ND (ICMPv6 Neighbor Discovery) communication uses multicast (FF). Two addresses are used here:

FF02::1 - All local hosts on the link.
FF02::2 - All local routers on the link.

One last thought about EUI-64 and link-local address. Since, it is locally significant, this address will be used on ALL interfaces. The reason I mention this is that if you try to check connectivity between link-local interfaces, you must provide the router with the output interface. It uses this address on ALL of them after all. Also, you must type in the full interface name to send icmp echo message using link-local address. Check it out:

Pic. 9 - Ping Connectivity Test.

Let's check R3's neighbors (layer 3 to layer 2 mapping):

Pic. 10 - IPv6 Layer 3 to Layer 2 Mapping.

Yes, this would be your IPv6 equivalent of the 'show arp' command used in IPv4!

In my next post we will configure RIPng (RIP Next Generation) routing protocol. The 'Introduction to IPv6' will finish with a short discussion on IPv4 to IPv6 migration and a quick lab to see how we can route IPv6 packets over IPv4 networks.

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 44 - EIGRP Fundamentals Part 2 - Implementation

In the previous post (lesson 43) I have laid the foundations related to EIGRP terminology. Without understanding those keywords and their meaning it is hard to implement and analyze the behavior of this routing protocol.

The basic implementation steps, like in case of other routing protocols we have learned so far, requires two major steps:

1. Enable EIGRP process in the 'config' mode.
2. Instruct EIGRP which interfaces should participate in the EIGRP domain.

The second step is accomplished with the 'network' statement in the EIGRP routing context. This statement instructs EIGRP routing process which interfaces EIGRP will run on. The consequences of enabling EIGRP on the interface are similar to what we saw in OSPF configuration:

• EIGRP-enabled interface begins to send EIGRP 'hello' packets in order to discover the neighbors. The address used to advertise these 'hello' packets is well-known, reserved multicast address: 224.0.0.10.
• EIGRP-enabled interface allow the EIGRP process to read the address and network mask configured on this interface and advertise this network or subnet out other EIGRP-enabled interfaces where the neighbor(s) has/have been discovered and the relationship has been formed with them.

The 'network' statement can take a form of classful (as per IP class A, B, C; without a wildcard mask) or classless (using wildcard mask similar to OSPF) entry.

Also, worth noting here is that the command that starts the EIGRP process is followed by a number which is the Autonomous System number. Unlike OSPF which is the process ID and has local significance, AS number in EIGRP is important as it must match between the neighbors. Example of enabling EIGRP:

router eigrp 1

Number '1' is the Autonomus system number (between 1-65535) which must be the same on all EIGRP speaking routers in the domain.

The following list of parameters must match between EIGRP neighbors in order to successfully establish neighbor relationships: 

1. Autonomous System number.
2. K-Values (look at the previous lesson).
3. If authentication is used both: the key number, the password, and the date/time the password is valid must match.
4. The neighbors must be on common subnet (all IGPs follow this rule).

Since the 'network' keyword uses either a classful statement or it can take a wildcard mask (inversed mask) as its argument, consider the following four examples which accomplish the SAME goal: all interfaces of R3 are going to be EIGRP-enabled.

Pic. 1 - R3's 

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

Example 1

!

router eigrp 1

 network 172.31.0.0

!

Example 2 

!

router eigrp 1

 network 172.31.123.0 0.0.0.255

 network 172.31.3.0 0.0.0.15

 network 172.31.3.16 0.0.0.15

!

Example 3 

!

router eigrp 1

 network 172.31.123.0 0.0.0.255

 network 172.31.3.0 0.0.0.255

!

Example 4 

!

router eigrp 1

 network 172.31.123.3 0.0.0.0

 network 172.31.3.1 0.0.0.0

 network 172.31.3.17 0.0.0.0

!

They all achieve the same result: all interface become EIGRP-enabled.

EIGRP is partially a Distance Vector routing protocol. By default the automatic summarization to the class boundary takes place. The command that disables that behavior is: 'no auto-summary' used under EIGRP process.

EIGRP uses five different types of the packets to communicate. Three of them are reliable and must be acknowledged by the receiver. The EIGRP packets are as follows:

1. Hello (unreliable).
2. Updates (reliable).
3. Queries (reliable).
4. Replies (reliable).
5. Acknowledgement (unreliable.

The last point I'd like to make relates to the ability of EIGRP to authenticate its packets. EIGRP currently (as of the time of writing this post) uses only one protocol which is MD5.

If you decide to configure authentication of EIGRP packets there are two major steps you must configure:

1. Configure a key chain with the parameters such as the password(s) and the date/time they are valid.
2. Apply authentication method and the key chain on per-interface basis.

Example of key chain configuration on R3 in Autonomous System 1. 

!

! Key Chain Configuration

!

R3(config)#key chain EIGRP
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string S3cr3t!!!

!

! Enabling authentication on F1/0 interface - EIGRP AS 1 here

!

R3(config-if)#ip authentication mode eigrp 1 md5
R3(config-if)#ip authentication key-chain eigrp 1 EIGRP
R3(config-if)#
!

• 'EIGRP' - The name of the key chain in my configuration. It can be any name.
• 'key 1' - Number '1' must match be used on the neighbor's interface connected to R3's F1/0 interface.
• 'S3cr3t!!!' - is the password used as the key 1. Must match between neighbors.
• mode eigrp 1/ key-chain eigrp 1 - EIGRP AS number configured in the 'config' mode.

There are two other commands available under 'key 1' which I did not used:

1. Accept-lifetime - date/time in which EIGRP packets signed with the digest based on the key-string will be accepted by the receiving router.
2. Send-lifetime - date/time in which EIGRP packets will be signed using the key-string specified. The digest will be attached to all EIGRP packet types.

Since I did not use these two options (NTP time synchronization is needed), the key 1, using the password (here: S3cr3t!!!) is valid forever.


In the next post, I'm going to use this lesson's theory and put it into practice.

Lesson 43 - EIGRP Fundamentals Part 1 - Overview

EIGRP is a Cisco Proprietary Routing Protocol. It is classified as an Advanced Distance Vector solution. EIGRP is a fast, modern and robust routing protocol offering features we expect to find in the routing protocol these days (as of the time of writing this tutorial).

EIGRP Characteristics

• Advanced Distance Vector Protocol - EIGRP routers, similarly to RIP, create the database in which only distance (how far) and direction (next-hop) are given. As a result of that, routers do not know the exact topology of the network. However, like in link-state algorithm, EIGRP routers are going to discover their neighbors using EIGRP Hello packets, form adjacency and exchange the routing databases reliably with their neighbors.
• Flexible Design - EIGRP does not use the concept of areas found in OSPF. It is less demanding in terms of the design allowing less experienced engineers implement it quickly. It supports summarization of prefixes on per interface-basis (unlike OSPF which does it on ABRs/ASBRs only). 
• Incremental Updates - Routing updates are not advertised periodically. They are exchanged reliably once (must beacknowledged). In stable network, only hello packets are transmitted between neighbors to maintain the relationship. In case of the topology change, the updates are sent to the routers that should receive it. The routers take into consideration how long it takes to send the reliable packet and get the response from a neighbor. Based on that, they determine how long they should wait to re-send the upate in case they did not get the acknowledgement. 
• VLSM Support - Although EIGRP is primary Distance Vector Protocol, it is a classless protocol which supports variable length subnet masking. In order to turn it on, you must use the 'no auto-summary' keyword in the routing process 'config-router'.
• Rapid Convergence - In case the EIGRP domain is designed with redundant connections and certain criteria are met (Feasibility Condition) a router can keep information about so called Feasible Successor(s) which are the second best path towards the destination (sort of a backup route). The difference between OSPF/RIP backup paths (second best routes) and EIGRP's feasible successor is that in the latter protocol, the traffic is redirected immediately without recomputing the routing table.
• Multicast - EIGRP uses multicast and unicast transmissions. Multicast address reserved for EIGRP is 224.0.0.10.
• 100% Loop Free - The Diffusing Update Algorithm (DUAL) which EIGRP uses, guarantees there are not going to be any loops formed which Distance Vector algorithms are susceptible to (thanks to the Feasibility Condition).
• Equal and Unequal Cost Load Balancing - EIGRP routers can utilize different paths with different metric performing a load balance. The router calculates the appropriate ratio regarding how many packet should be sent out the interface based on the difference in the metric value between these multiple paths available.
• Support for multiple layer 3 protocols - EIGRP can natively support IP,  IPX and Apple-Talk protocols (altough in today's IP world this is no longer a major advantage).

Based on my experience with EIGRP (personal opinion), the two major disadvantages of EIGRP are:

• It is very chatty if the network is not properly designed. Explanation of the design is beyond the scope of this tutorial.
• It is a Cisco proprietary routing protocol which means it won't work on routers from different vendors.

Terminology

EIGRP Databases

EIGRP creates three databases, similarly to OSPF:

• Neighbor Table - Lists all neighbors discovered with which it formed adjacency and exchanged routing information.
• Topology Table - Lists all the paths to all destinations learned. However, it shows only metric and the next-hop router and does not illustrate the real topology like OSPF LSDB.
• Routing Table - The best metric routes are going to be used to send the traffic. 

EIGRP Composite Metric
EIGRP calculates the metric using pretty complex formula which is beyond the scope of the CCNA tutorial. It is referred to as composite metric. EIGRP uses five different components (so called K-values) to determine the value of the metric. Thus, the composite metric. One of them, MTU (Maximu Transmission Unit), is not factored in directly but changes the way the value is calculated.

By default EIGRP uses two parameters in this magical formula:

• Bandwidth
• Delay

All K-values can be seen using: 'show ip protocols' command if EIGRP has been configured. The K-values listed are as follows:

• K1 - Bandwidth
• K2 - Load
• K3 - Delay 
• K4 - Reliability
• K5 - MTU

They can be used for traffic engineering (overriding normal route selection process). This helps to address issues with unde/over utilized links. However, configuring additional K-values to accomplish that is not recommended unless an administrator is experienced with EIGRP and knows their network very well.

Topology Database
Terms to remember:

• Advertised Distance - The best metric a router receives from the neighbor (next-hop device) to a given destination network/subnet. In some documentations it is also referred to as the Reported Distance. Do not confuse this term with Administrative Distance which is the ranking of routing protocols.
• Feasible Distance -  The total metric value which is a sum of the Advertised Distance and the metric to reach the neighbor (next-hop router towards the destination).
• Feasibility Condition - The situation in which the Advertised Distance value provided by a alternate neighbor(s) (their best metric) is lower than the best Feasible Distance (metric) through the best router(s) to reach the destination (successor: look below).
• Feasible Successor - The second best route(s) to a given destination. The router(s) which is/are the second best next-hop router(s) to a given destination meeting the FD (Feasibility Condition).
• Successor - The best route to a given destination (the least cost metric)

In order to understand the above terms and EIGRP behavior better, let's analyze the process of advertising 192.168.1.0 by R5.

R5 advertises its directly connected network with the metric value of 1. R2, R3 and R4 will add their own cost to reach R5 (Pic. 1). The sum of 1 + COST_TO_R5 becomes their successor (best metric). Then we add the R1 to this topology and let's analyze what R1 receives from three neighbors. Take a look at the pic. 1.

Pic. 1 - EIGRP Terminology.

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

R1 receives the prefix 192.168.1.0/24 from three neighbors (R2, R3, R4). It calculates the metric value by adding the cost to reach the neighbor (in red) to the metric advertised by this neighbor (in blue aka the advertised distance). The metric (cost if you will, or composite metric to be accurate) that is the lowest becomes the successor route (the best route). If however, other neighbor(s) advertise metric (Advertised Distance) that is lower than the least cost path, this neighbor or these neighbors become the second best next-hop routers towards the destination 192.168.1.0/24 and they are called feasible successors according to the Feasibility Condition:

AD < FD

In such situation, if the best route is not available, the feasible successor (second best) is used immediately without any re-computation of the routing table.

In our Pic.1, R2 is the successor towards 192.168.1.0/24, but R3 becomes the feasible successor (second best gateway) since its advertised distance is 20. This number is lower than the best feasible distance which is 21.

In the next post I will present the basic implementation and verification steps regarding EIGRP.

Lesson 40 - OSPF Fundamentals Part3 - RouterID and DR/BDR

There are two more notions I need to touch upon before we implement OSPF in our topology. These are: OSPF Router ID and special roles of the routers which are appointed in Broadcast and NBMA(Non-Broadcast Multiple Access) networks called Designated Router (DR) and Backup Designated Router (BDR). I thought I would do the practical implementation here as well, but I want to keep the post as short as possible.

OSPF routers exchange LSAs by flooding them to all OSPF neighbors. This flooding results in creating the same Link-State Database (LSDB) on all routers in the area. LSDB is a topology database, (kind of a "road map"), shared by all routers in the area. Then, each router runs Dijkstra's SPF algorithm to choose the best path to each destination, placing itself as a the root (starting point). The product of SPF algorithm operation is the routing table. Recall that all OSPF packets are encapsulated in the OSPF header (loot at previous post). So, LSAs are signed with the Router ID when the router originates and floods them.

So what is this Router ID in the OSPF world?

Router ID
Router ID is going to be chosen automatically unless configured manually, using the 'router-idA.B.C.D' command in OSPF configuration context. The A.B.C.D are four bytes just like an IP address representing the router ID. It can be changed at a later stage but this may require the process clearing (once the router had its ID chosen, changing it always requires this command):

R1#clear ip ospf process

Clearing the OSPF process is disruptive since the router will need to re-establish adjacency with its neighbors.

Initially, a router tries to choose its ID based on the following order of operation:

1. Router chooses numerically the highest IP address off of the loopback interface.
2. In case there is no loopback interface configured, the router is going to choose numerically the highest IP address off of the physical interface. 

Neither of these interfaces have to be enabled for OSPF.


OSPF DR/BDR 
Another concept that requires some explanation is the election of Designated Router (DR) andBackup Designated Router (BDR) elected on Broadcast and NBMA networks (such as Frame-Relay, ATM, X.25). It is a role that is valid on per link basis (Broadcast and NBMA). This means that a router can be DR on F0/0 interface (segment of the network) but BDR or DRother on F0/1 interface.

As you recall, all routers need to establish adjacency (full state) with their neighbors. Only then, are their LSDBs synchronized. The process of sending updates to a great number of neighbors in Broadcast and NBMA networks would be very inefficient as their number can be significant. The routers would create the number of adjacencies according to the following (full mesh) formula:

Number_of_Adjacencies = n(n-1)/2

where the 'n' stands for the number of routers neighbored. In case an LSU (update) is sent, there would be a number of exchanges occurring between all neighbors according to the following formula:

Number_of_LSA_Exchanges = n raised to the power of 2.

Consider the following picture.

Pic. 1 - Broadcast Network with Four Routers.

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

The next picture shows in part the LSU propagation of the same failed network on R3. This is only a partial picture. This would have to be done 16 times.

Pic. 2 - Partial LSU Exchange with 4 Routers.

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

This situation would be very chaotic indeed. Instead, the system on Broadcast and NBMA networks elect one representative called Designated Router which is going to be responsible for propagation of all updates on this segment. In case of the failure of DR there is going to be a Backup Designated Router elected to assume the role of DR. These roles are initially based on the highest 'priority number' assigned on the interface. The default number is 1, so in case of a tie, the highest Router ID is becoming DR and the second highest becomes the BDR. If a router's interface is set to the priority value of 0, the router automatically becomes DRother and does not participate in the election process.

---

NOTICE!
DR is the only router authorized to pass the updates on to other routers on Broadcast and NBMA networks. It must have FULL reachability to other routers on the segment. 

---

This is the reason, there are two different addresses reserved for OSPF:

• 224.0.0.5 - All OSPF enabled routers listen to this address.
• 224.0.0.6 - DR/BDR router listen to this address.

Hello packets are sent to 224.0.0.5 (unless unicast is used i.e. NBMA networks)
Updates are sent 224.0.0.5 except Broadcast and NBMA network which use 224.0.0.6 address instead.

So, in our example (pic 1, and pic.2), if R3 loses its directly connected network, it sends the update towards 224.0.0.6 (to DR/BDR), and DR is sending this back to all other routers using 224.0.0.5 address. R3 is also going to receive it, but it will silently ignore it as it is the same update (sequence number). Consider the below picture.

Pic. 3 - DR/BDR Elected on Broadcast and NBMA Networks.

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

This post ends the theory aspects in relation to OSPF in one area as per CCNA requirements.

In the next post, I will finally put this OSPF knowledge into practice. Then, we will troubleshoot OSPF using the tools learned in the next one.