Lesson 49 - Packet Filtering with Extended ACLs

This post I start with presenting solution to the Task 2 I left unanswered in the lesson 49.

Task 2
Configure an IP standard ACL that denies packets coming from the host 172.31.123.3 going towards 192.168.5.0/24. Traffic from other sources should be allowed.

Again, we use the standard IP ACL here, which is going to be applied on R5. Here goes:

R5 Configuration:

!

! In the global config 

!

access-list 1 deny host 172.31.123.3

access-list 1 permit any

!

! Enter the the incoming interface and apply the access-list

!

interface serial0/2

 ip access-group 1 in

!

Notice!

• access-list 1 - ACL numbers 1-99 are IP standard ACLs (check source of the packets only.
• host 172.31.123.3 - this keyword is an alias for: 172.16.123.3 0.0.0.0. It is a source address of the packets being inspected.
• any - this keyword is an alias for: 0.0.0.0 255.255.255.255 - any source here.

I hope your answers were correct. Now is the time to learn Extended ACLs.

First, look at the syntax you see in Cisco documentation:

Pic. 1 - Extended ACL Syntax.

If you go like: 'OMG!' do not worry because you do not have to use all these keywords.

The options we are going to use can be presented as follows:

Pic. 2 - Extended ACL Common Syntax.

It looks a bit more convoluted but do not worry because in time you will feel quite confident with it. Your best friend is help '?' which is going to show you what options and arguments are required.

The best way to explain the syntax you need to get familiar with is to use an example and try to de-construct it. So, let's look at our topology one more time and create the following filter:

Task 1
Deny telnet sessions coming from 192.168.4.0/24 destined to 172.31.3.0/28 and 172.31.3.16/28. All other traffic should be allowed.

Pic. 3 - Topology.

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

Which ACL type should we use?
Since, we are very specific in terms of which protocols we want to deny, we must use Extended ACL. The standard ACL can only match on the source IP address, permitting or denying all protocols the packet is carrying.

Which router/interface should we apply the ACL on?
Our topology clearly shows that R3 has three different interfaces with three different addresses. So, we have two options here:

• We can configure an Extended ACL on R4 FastEthernet 1/0 interface in the inbound direction (close to the source as per ACL guideline)
• We can configure an Extended ACL on R4 Serial0/2 in the outbound direction.
• Alternatively, we can apply an Extended ACL on R3 FastEthernet1/0 (inbound).

I'm going to chose the option suggested by the ACL guide lines: as close to the source as possible.

Let's read the task again:


Task 1

Deny telnet sessions coming from 192.168.4.0/24 destined to 172.31.3.0/28 and 172.31.3.16/28. All other traffic should be allowed.

Here's one way to configure this:

R4 Configuration:

!

! In the global 'config' mode the statements are:

!

access-list 100 deny tcp 192.168.4.0 0.0.0.255 172.31.3.0 0.0.0.15 eq 23

access-list 100 deny tcp 192.168.4.0 0.0.0.255 172.31.3.16 0.0.0.15 eq 23

access-list 100 permit ip any any

!

! Apply the ACL on the interface

!

interface Serial0/2

  ip access-group 100 out

!

Three lines that 'deny' traffic are similar. Let's dissect its syntax:

access-list 100 deny tcp 192.168.4.0 0.0.0.255 172.31.3.0 0.0.0.15 eq 23

• access-list 100 - The extended ACL (numbers 100-199)
• deny - condition (either 'deny' or 'permit' are allowed)
• tcp - layer 3 or 4 protocol (such as: ip, icmp, tcp, udp, rip, eigrp etc.)
• 192.168.4.0 - source IP address
• 0.0.0.255 - source wildcard mask (inversed mask)
• 172.31.3.0 - destination IP address
• 0.0.0.15 - destination wildcard mask (inversed mask)
• eq - operator: eq (equal), lt (less than), gt (greater than), range
• 23 - destination port (telnet)

Notice!
After source wildcard there is no source port. This means that the source port is not inspected at all (disregarded).

In the next post I'm going to show you few examples of extended ACL which should reinforce your study (today I have a friend over from UK so no time to do it ;))

Lesson 48 - Standard ACL Examples

Pic. 1 - Topology.

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

Task 1

Configure an IP standard ACL that denies packets coming from 172.31.3.16/28 going towards 192.168.4.0/24. All other traffic should be allowed.

Task 2

Configure an IP standard ACL that denies packets coming from the host 172.31.123.3 going towards 192.168.5.0/24. Traffic from other sources should be allowed.

Let's get 'em tiger!

When it comes to configuring ACLs my work flow goes like this:

1. Which ACL is going to accomplish my goal: Standard or Extended?
2. Which router and interface should I apply the ACL on?
3. Which direction should I use: in or out?

Dig this! 

Since as of this moment we talk about standard ACL, the answer to the first question is obvious: standard ACL must be used. In real life examples, the goals you try to accomplish will impose the criteria. If you must filter out some specific TCP traffic (e.g. going towards port 80), an extended ACL must be used as the standard one cannot filter on TCP (source IP only).

The guidelines specify that standard ACL must be placed as close to the destination as possible. Think about it. If I applied the ACL in Task 1 on R3 F1/0 out, the packet with the source 172.31.3.32/28 could not go anywhere out that interface. We're supposed to filter this source going towards Branch 1 (R4) and not anywhere else. R4 is going to be the router I'm going to apply the ACL on.

As for the last question about the direction, I could use R4's S0/2 inbound or F1/0 outbound. Since there are only two interfaces, I can apply this on s0/2 inbound and it won't make much difference except that the packet will be rejected on the inbound interface. This way, R4 won't have to do layer 3 lookup and waste it resources. If there were more interfaces I would use it on F1/0 interface outbound since the traffic should not be sent to the specific network (192.168.4.0).

Task 1

Configure an IP standard ACL that denies packets coming from 172.31.3.16/28 going towards 192.168.4.0/24. All other traffic should be allowed.

Pic. 2 - Communication Before Applying ACL.

Notice!

I pinged from the subnet in question (172.31.3.16/28).

R4 Configuration:

!

! Step 1 - Create an ACL statement in the global config

R4(config)#access-list 1 deny 172.31.3.16 0.0.0.15
R4(config)#access-list 1 permit any              
R4(config)#

!

! Step 2 - Apply the ACL on the interface

R4(config)#int s0/2
R4(config-if)#ip access-group 1 in
R4(config-if)#

!

Verification:

Pic. 3 - Communication After Applying ACL.

Notice!

Only packets sourced from the 172.31.3.16/24 are being blocked on R4. The packets from 172.31.3.0/28 are getting through.

Pic. 4 - R4's ACL counters.

I owe you an explanation here.

!

R4(config)#access-list 1 deny 172.31.3.16 0.0.0.15

!

access-list 1 - the number 1 implies the standard ACL (1-99)

deny - the packets meeting the criterion that follows will be denied (dropped)

172.31.3.16 - the source IP criterion

0.0.0.15 - the wildcard mask which is the subnet's inversed network mask

The subnet's network mask is: 255.255.255.240. In the binary it looks like:

11111111.11111111.11111111.11110000

If we inverse this network mask we get:

00000000.00000000.00000000.00001111

That, converted to decimal is: 0.0.0.15

Easy right?

!

R4(config)#access-list 1 permit any

!

permit any - this permits all other source IP. The word 'any' is the alias for:

0.0.0.0 255.255.255.255

Try to write an ACL according to the Task 2 description on your own. I will show you the solution in the next post.

In my next post: solution to the Task 2 and extended ACLs. 

Stop by and see what magic they can do! Meanwhile, happy studying!

Lesson 47 - Packet Filtering with Standard ACL

NOTICE!
Access Control Lists can inspect the traffic based on different protocols and criteria. In this post I’m going to focus in on IP-based ACLs. Other types such as MAC-based ACLs, dynamic or reflective ACLs are beyond the scope of this tutorial.

Have you noticed how your hand luggage is being scanned at the airport? ACL is similar to such scanner only used on the router. It can look at the content of the packet traversing it and check the content of the packet up to the layer 4 (extended ACL). You, as an administrator, get to decide what the action is going to be if the packet matches your criteria. A few applications of ACLs are as follows:

• ACLs can filter the packets that traverse the router in order to drop the unwanted traffic.
• ACLs can deny SSH or Telnet traffic to vty lines (router/switch remote management).
• ACLs are used as to match an interesting traffic to trigger VPN tunnel establishment and encrypt data.
• ACLs are commonly used in Quality of Service to prioritize certain applications or traffic flows over others or provide different treatment to a certain stream of packets.
• ACLs are used to filter inbound or outbound dynamic protocol advertisements.
• Etc.

To summarize it: you cannot call yourself a network specialist without being able to use ACLs. In this tutorial, we focus in on IP based ACLs.

IP  Based ACLs
You can use two major IP-based ACLs (look at the guidelines above):

1. Standard ACLs (numbers: 1 through 99)
2. Extended ACLs (numbers: 100 through 199)
3. Named ACL (standard or extended). Named ACLs offer more flexibility in terms of modifying ACLs 'on the fly'

The major differences between them are the amount and type of criteria we can use to inspect the packets as well as the syntax used to create the statement.

In this post I present IP standard ACL only used as a filtering mechanism (permit or deny the traffic through the router), but get familiar with the general guidelines first as they apply to all types and applications of ACLs.

ACL Guidelines
Here are some important guidelines regarding ACLs:

• ACLs use the top-down processing. This means that statements are being processed from the one listed on the top of the list first. If the statement is a successful match (permit or deny), the remaining entries listed below this matching statement are NOT inspected anymore.
• Cisco IOS allows to apply only one ACL per interface, protocol and direction. This means that you can apply ACL1 on two different interfaces, or ACL1 and ACL2 on the same interface but in two different directions (in and out).
• The ACL number will determine whether it is IP standard ACL (numbers 1-99) or IP extended ACL (numbers 100-199).
• Standard ACL can only inspect the source IP of the packet.
• Extended ACL will inspect both source and destination IP. In addition to these it can match on layer 4 protocols (TCP, UDP, OSPF, EIGRP etc.) and even the layer 4 port numbers (either source or destination or both).
• The standard ACLs should be placed close to the destination, extended ACLs should be placed close to the source of the transmission.
• There is an IMPLICIT DENY ALL at the end of all the statements that you create. This means, that if your statements have been created to deny traffic, there must be at least a single permit statements. Otherwise all traffic crossing the interface where ACL has been configured will be denied (filtered out).

The process of configuring ACLs consist of two steps:

1. Configuring the ACL statements in the global configuration mode.
2. Applying the ACLs on the interfaces to inbound or outbound traffic.

Standard Access Lists
Standard ACL offers you only a single criterion to single packets out from the flows a router handles. It is a source IP address. Based on this criterion, a router determines if the packet should be forwarded or dropped. This type of ACL does not check if IP carries TCP, UDP, OSPF, EIGRP etc. Based on the source IP address the “whole” IP packet (irrespective of the layer 4-5 content) will be forwarded or dropped.

This time, I'm going to show you the syntax taken directly from the Cisco web site. The point is, that sooner or later you have to learn how to use the official Cisco Documentation. You must learn how to be self-reliant at your work because in many cases you will not have anyone around to take you by the hand and solve an issue.

The ultimate source of all Cisco related configurations can be found at (here IOS 12.4 version):

http://www.cisco.com/en/US/products/ps6350/tsd_products_support_series_home.html

Pic. 1 - IP Standard ACL Syntax.

Pic. 1 shows you the standard ACL syntax you type in the 'config' mode (global configuration mode.

• access-list - the ACL keyword that is followed by a number of argument
• access-list-number - IP standard ACLs use the numbers in the range 1-99
• permit|deny - what is in braces '{}' are possible options; here permit or deny
• host|source - again in braces '{}' are possible options; here either a host address or other source such as network or subnet.
• source-wildcard|any - this is the inversed network mask ('1' becomes '0' and vice versa).

Bold font is the keyword that you must use.
Italic font is the arguement that follows the keyword.
| - a pipe is the logical 'or' statement giving you multiple choices.
{} - in braces the possible options are listed.

The next step in configuring an ACL (standard or Extended) is to apply it on the interface in either inbound or outbound direction.

Pic. 2 - Applying ACL on the Interface.

interface - the keyword to enter the interface context (must be in the 'config mode')
<interface> - type/number of the interface (e.g. interface Fa0/0)
ip access-group - the keyword that applies an ACL on the interface
number - the number of access-list configured in the 'config' mode (standard ACL use range 1-99)

in|out - the direction inbound or outbound (how packets are going to be processed)

INBOUND ACLs
This type of ACL analyzes the packets coming towards the router (the interface where packet was received on). Based on the criteria defined in the ACL, the packet will further be processed (layer 3 lookup performed trying to find the outbound interface), or dropped.

OUTBOUND ACLs
If you apply the ACL as 'out' the incoming interface does NOT compare the packet content with the ACL statements. It performs a layer 3 lookup immediately. Once the outbound interface is found, and the ACL is applied there as 'out' it analyzes the ACL statement one by one (top-down). Once the match is found (permit or deny) the packet is or is not sent out that interface.

Remember, that IP standard ACLs check the source IP only!


In the next post, I show you a few examples of IP standard ACL with a detailed analysis how they work. This and the next post should get you going with IP standard ACLs.

Lesson 46 - EIGRP Fundamentals Part 4 - Troubleshooting

In this post I'd like to show you how problems in EIGRP can manifest themselves and how to find and fix problems that are less conspicuous. All in the scope of the CCNA level.

Pic. 1 - Topology Diagram.

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

Let's assume that this is a new system and your colleague who's not experienced enough tried to set it up but with no success. Some work was done and the task at hand is to connect successfully the branches with headquarter accomplishing full reachability.

The first thing I'm going to do is to learn the topology diagram to know the addresses and encapsulations which connect the branches with the HQ network.

I log in to R1 and here's my first finding. Check it out:

Pic. 2 - EIGRP First Error.

The above output sent to the console indicates that R1 receives hello packets on its local S0/2 interface from the wrong address (not on common subnet). The IP address of the sender is: 172.32.14.4. R1's interface S0/2 is configured as 172.31.14.1. Clearly wrong address is assigned on R4.

I jump over to R2 and correct the address on S0/2 and make sure it is EIGRP enabled by typing in a right 'network' statement.

R4 Configuration:

!

R4(config)#int s0/2
R4(config-if)#ip address 172.31.14.4 255.255.255.0
R4(config-if)#router eigrp 1
R4(config-router)#no network 172.32.0.0
R4(config-router)#network 172.31.0.0
R4(config-router)#

!

I perform a simple check: I want to make sure that R4's interface S0/2 is running EIGRP protocol. Here's the output:

Pic. 3 - R4's EIGRP Interfaces.

To my great surprise, the interface is EIGRP-enabled but there R1 is not listed as the neighbor (peer). The ping shows no problems reaching R1 (172.31.14.1).

In this situation I decide to use a 'debug' tool. Be careful using 'debug' commands as they may severely impact the operation of the router. More information on how to use debug in lesson 37.

I disable a timestamps so the output of the debug is clearer. As soon as the first information is sent to the screen, I disable debug using 'u all' command (in case you are in other mode than privileged '#' the 'do u all' is used. It is the alias for: 'undebug all'. Here's what the debug reports.

Pic. 4 - Debug EIGRP Packets.

The output reveals that the local router (R4) has problems with authentication of EIGRP packets. Opcode =  5 (authentication off or key-chain missing).

The 'show key chain' shows ... zilch! There's no key chain defined on R4. I need to do it. I'm going to do to errors while configuring key chain in order to show you how they show in the 'debug ip eigrp' statement.

Here's my first erroneous configuration:

R4 Configuration:

!

R4(config)#key chain EIGRP
R4(config-keychain)#key 2
R4(config-keychain-key)#key-string cisco
R4(config-keychain-key)#
R4(config-keychain-key)#int s0/2
R4(config-if)#ip authentication mode eigrp 1 md5
R4(config-if)#ip authentication key-chain eigrp 1 EIGRP
R4(config-if)#

!

You noticed that I used the key 2. Since, the neighbor adjacency has not been built, I reach for the 'debug eigrp packets' again. Here's the output now:

Pic. 5 - Another Debug EIGRP Packets.

In the ton of gibberish I fish out the above message: 'key not defined or not live'. This is the cause of  the 'invalid authentication'

I check R1 and see that it uses key 1 and not key 2. The mismatch in the key number prevents the R1 and R4 from establishing adjacency.

I'll make one more mistake so that you can see another error related to authentication. Look at my key chain authentication on R4:

Pic. 6 - Running Configuration - Key Chain.

At first glance, all seems okay. But is it?

Still R1 and R4 are not neighbors. Let's debug one more time.

Pic. 7 - Debug EIGRP Packets.

This time there is no complaints about key number, but authentication still fails. The problem is with the password used. It does NOT match with the other end. Now, displaying configuration on both R1 and R4 shows the password 'cisco'. But is it so? Check the below output on R4:

Pic. 8 - Show Key Chain.

A closer inspection shows that the password cisco is followed by a 'space' character which does not show in the 'show running-config'. This a cause of the problem.

One last error that shows without any debug. Check it out:

Pic. 9 - EIGRP Unsolicited Error Message.

The problem is with the K-values used by R5's neighbor (R2). They do not match on both ends. A quick look at R5 shows that default K-values are used.

Pic. 10 - Show IP Protocols on R5.

The same output on R2 reveals that it all K-values are used to calculate the metric. They do not match on both ends which results in lack of neighbor adjacencies between routers.

Pic. 11 - Show IP Protocols on R2.

A look at EIGRP configuration on R2:

Pic. 12 - EIGRP Configuration on R2.

 A quick fix on R2 and all is good!

R2 Configuration:

!

R2(config)#router eigrp 1
R2(config-router)#no metric weights
R2(config-router)#

!

Incidentally, EIGRP unsolicited error messages are sent to the screen every few seconds which makes it hard to do the diagnostics. You can temporarily disable logging to the console 0 by typing:

R2(config)#no logging console

To bring back the defaults:

R2(config)#logging console

In the next post, I'll look at the ACLs (Access Control Lists) and how they can serve different purposes in your network.

Lesson 45 - EIGRP Fundamentals Part 3 - The Lab

In this post I'll put the pieces together in the practice lab. Our topology will be as presented below:

Pic. 1 - Topology Diagram.

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

This post is going to collect bits and pieces from lessons 43 and 44 to show you the implementation on the command line interface with verification steps.

Task List

General requirements

• All routers must use Autonomous System 1.
• All networks/subnets must be advertised and reachable.
• EIGRP authentication should be enabled between R1 and R4.

1. Enable EIGRP between R1, R2 and R3. Make sure loopbacks are advertised. Use the most specific wildcard mask.
2. Enable EIGRP between R1 and R4. Make sure loopbacks are advertised. Use the most specific wildcard mask on R1. On R4 the network statement should be classful (no wildcard mask).
3. Enable EIGRP between R2 and R5. Make sure loopbacks are advertised. Use the most specific wildcard mask on R2. On R5 the network statement should be classful (no wildcard mask).
4. Enable EIGRP authentication between R1 and R4. Use the password 'cisco'.

Lab Solution

Step 1
Enable EIGRP between R1, R2 and R3. Make sure loopbacks are advertised. Use the most specific wildcard mask.

Note!
The 'no auto-summary' keyword is not necessary in my topology, but I include it to show you how to disable automatic summarization to the class boundary.
R1 Configuration:

!

R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 172.31.123.1 0.0.0.0
R1(config-router)#network 172.31.1.1 0.0.0.0

R1(config-router)#

!

R2 Configuration:

!

R2(config)#router eigrp 1
R2(config-router)#no auto-summary
R2(config-router)#network 172.31.2.1 0.0.0.0
R2(config-router)#network 172.31.123.2 0.0.0.0
R2(config-router)#

!

Pic. 2 - EIGRP Adjacency Between R1 and R3.

R3 Configuration:

!

R3(config)#router eigrp 1
R3(config-router)#no auto-summary
R3(config-router)#network 172.31.3.1 0.0.0.0
R3(config-router)#network 172.31.3.17 0.0.0.0
R3(config-router)#network 172.31.123.3 0.0.0.0
R3(config-router)#

!

Verification:

Pic. 3 - R3's EIGRP-enabled nterfaces.

Pic. 3 confirms the network statement was correct for each interface.

Pic. 4 - R3's EIGRP Neighbor Table.

Notice!

R3 heard EIGRP hello packets from two neighbors. But to be sure they have exchanged their topology tables, the 'Q Cnt' column must show '0' messages pending (not acknowledged).

Notice!
In the 'output explanation' I show only the most relevant pieces of information. Others are either self-explanatory or not necessary to understand at the CCNA level.

Output Explanation:

• H - Handle; shows order in which the neighbors were discovered and adjacency built between them.
• Address - The IP address of the neighbor.
• Interface - The  local interface where neighbors are discovered.
• Hold - Length of time in seconds how long the router is going to wait for hello packet before declaring the neighbor down.
• Uptime - Elapsed time since the local router first heard from the neighbor.
• SRRT - Smooth Round Trip Timer; amount of time in milliseconds the required to send the packet to the neighbor and receive the acknowledgement.
• RTO - Retransmit Time Out; amount of time in milliseconds the local router waits before retransmitting EIGRP packet if acknowledgement did not arrive.
• Q Cnt - The number of EIGRP packets (update, query, reply) that the router keeps in the queue to be sent. Typically, it implies that some EIGRP reliable packets have not been acknowledged.

Pic. 5 - R3's EIGRP Topology Table.

Output Explanation:

• P - Route is Passive which means that router is not actively looking for a path towards it. It is a required status in stable topology.
• FD - Feasible Distance (metric value towards the destination)
• (156160/128256) - The first number (156160) is FD, the second number (128256) is the Advertised Distance advertised by the neighbor (FD of the neighbor). Recall, the Feasibility Condition from the previous lessons.

Pic. 6 - R3's Routing Table.

Output Explanation:

• D - EIGRP learned prefix; 'show ip route' shows all prefixes including connected networks with explanation of codes.
• [90/156160] - The first number (90) is the Administrative Distance (trustworthiness) of the protocol, the second number (156160) is the metric based on best FD from the topology table.
• via 172.31.2.1 - next-hop router (neighbor that advertised it).
• 00:30:04 - how long ago the prefix was learned.
• FastEthernet1/0 - The outbound interface towards the destination.

Pic. 7 - R3's EIGRP Details.

Your homework:
look at pic. 7 and consult my previous posts about EIGRP and the topology diagram to understand the highlighted parts.

Step 2
Enable EIGRP between R1 and R4. Make sure loopbacks are advertised. Use the most specific wildcard mask on R1. On R4 the network statement should be classful (no wildcard mask).

R1 Configuration:

!

R1(config-router)#network 172.31.14.1 0.0.0.0
R1(config-router)#

!

R4 Configuration:

!

R4(config)#router eigrp 1
R4(config-router)#no auto-summary
R4(config-router)#network 172.31.0.0

R4(config-router)#network 192.168.4.0
R4(config-router)#

!

Verification should be performed after this step (look at step 1).

Step 3
Enable EIGRP between R2 and R5. Make sure loopbacks are advertised. Use the most specific wildcard mask on R2. On R5 the network statement should be classful (no wildcard mask).

R2 Configuration:

!

R2(config-router)#network 172.31.25.2 0.0.0.0
R2(config-router)#

!

R5 Configuration:

!

R5(config)#router eigrp 1
R5(config-router)#no auto-summary
R5(config-router)#network 192.168.5.0
R5(config-router)#network 172.31.0.0

R5(config-router)#

!

Verification should be performed after this step (look at step 1).

Step 4
Enable EIGRP authentication between R1 and R4. Use the password 'cisco'.

R1 Configuration:

!

R1(config)#key chain MY_EIGRP_KEY
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string cisco
R1(config-keychain-key)#
R1(config-keychain-key)#int s0/2
R1(config-if)#ip authentication key-chain eigrp 1 MY_EIGRP_KEY
R1(config-if)#ip authentication mode eigrp 1 md5

!

R4 Configuration (without prompts):

!

key chain MY_EIGRP_KEY
 key 1
   key-string cisco
!

interface Serial0/2
 ip address 172.31.14.4 255.255.255.0
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 MY_EIGRP_KEY

!

Verification:

Pic. 8 - R1's Neighbors.

R1 and R4 have re-established neighbor relationships.

In the next post, I'll present a few troubleshooting techniques based on the topology and configuration used in this lesson.

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.