Very quick post. For whatever reason this formula does not stick in my head although it should be fairly straightforward to second guess.
CIR = Bc/Tc
Tc can never be smaller than 10ms!
Tuesday, 18 August 2009
Sunday, 28 June 2009
Enhanced Interior Gateway Routing Protocol (EIGRP)
Here is the next installment of my CCIE studies, the Cisco proprietary EIGRP. I know a fair bit about EIGRP but there are still bits I tend to forget so here goes at trying to condense EIGRP into a single blog posting!
For detailed information please refer to the Cisco documentation on EIGRP here
Key Points
Uses IP protocol 88
Uses Reliable Transport Protocol (RTP) for reliable exchanging of data (does not use UDP or TCP)
Default metric is bandwidth and delay
Normally multicasts hellos and updates to 224.0.0.10
Uses Diffusing Update Algorithm (DUAL) in order to find best routes
Best routes are called Successors
Supports Feasible Successors which are back-up routes to a Successor route
Sends full updates with new neighbours and partial updates thereafter
Supports MD5 authentication only
Auto-summarisation on by default
Supports VLSM by turning off auto-summarisation
Manual summarisation supported anywhere in the EIGRP network
Routes redistributed into EIGRP can be tagged
Different next-hop router can be defined
Multiprotocol - it can support IPX and AppleTalk by use of PDMs
Timers
Hello Timer - The Hello interval is the rate at which EIGRP sends hello packets. The command ip hello-interval eigrp can be used to set the Hello interval time manually. The Hello interval defaults to 5 seconds for high-speed networks and 60 seconds for low-speed networks (i.e. less than 1.544Mbps).
Hold Timer - This is the amount of time that a router will consider a neighbor alive without receiving hello packets. The hold time is typically three times the hello interval. You can adjust the hold time with the ip hold-time eigrp command.
Unlike OSPF changing the hello timer does not automatically adjust the hold down timer.
Active Timer - This timer controls the time the router waits after sending a query before declaring the route stuck in active (SIA) and resetting the neighbor relationship. To avoid this neighbor resetting you can temporary increase the active timer until you solve the problem by eliminating the cause. The timers active-time [time-in-minutes] command under the EIGRP process can be used to adjust the active timer or be completely disabled by issuing the timers active-time disabled command. The default is 3 minutes.
There are some interesting points to be aware of with EIGRP timers:
1. The Hello mechanism works independently in each direction. Hellos from router R1 to router R2 do not necessarily have to use the same parameters as Hellos from R2 to R1.
2. The Hold timer is transmitted to the neighbor in the hello packet. R2 does not use its locally configured hold-time, but uses the value that R1 tells it to use.
This second point warrants an explanation. Let's say R1 has a Hello timer of 3 seconds and Hold timer of 10 seconds and R2 has a Hello timer of 20 seconds and a Hold Timer of 90 seconds (these figures are completely arbitrary and in no way would I recommend you use these figures).
Instinct would tell us that R1 may see R2 up initially but as R2's Hellos are longer than R1's Hold timer (20 seconds versus 10 seconds), R1 would believe that R2 is down. However, what point 2 says is that R1 will ignore its locally configured timers and use those advertised by R2 for the neighbour relationship with R2. Hence, R2 would only appear down to R1 if R1 does not receive a Hello from R2 within 90 seconds.
This leads us nicely on to how EIGRP neighbours are formed.
Forming a neighbour relationship
There are 4 things that potential EIGRP neighbours must agree on before they can be confirmed as neighbours:
1. Authentication password must match assuming authentication is used
2. The autonomous system (AS) number must match
3. K values must match
4. Source IP address of a received Hello must be in the same subnet as the primary IP address configured on the interface that received the Hello.
Note that timers do not need to match like other protocols!
Point 4 may need explaining but it is pretty straightforward. What is says is that EIGRP neighbours will not form on secondary IP addresses. Let's take a look at an example:
R1 and R2 are connected on their fa0/0 interfaces. R1 has the following configuration on its fa0/0 interface:
#R1
int fa0/0
ip address 192.168.1.1 255.255.255.0
R1 will expect the source address of a received Hello on fa0/0 to be in the 192.168.1.0/24 subnet. Let's say R2 is figured like this:
#R2
int fa0/0
ip address 192.168.2.1 255.255.255.0
ip address 192.168.1.2 255.255.255.0 secondary
The neighbour relationship will not form as R2 will source its Hellos from its primary IP address and that is not in the same subnet as R1's primary subnet on fa0/0.
Another thing to bear in mind is that the subnet masks do not have to match in order for the neighbour relationship to be formed. Taking the same example as above with R1 and R2 let's configure them with different subnet masks:
#R1
int fa0/0
ip address 192.168.1.1 255.255.255.0
#R2
int fa0/0
ip address 192.168.1.2 255.255.255.128
R1 will be expecting a received Hello to be sourced from an IP address in its primary subnet configured on fa0/0. Therefore it will expect an address in the range of 192.168.1.2 to 192.168.1.254. On R2 the IP address is indeed within that range and hence the neighbour relationship forms.
The other 3 factors that must pass in order for a neighbour relationship to be formed are covered in more detail in other sections within this post.
Metrics - K values
EIGRP uses a composite metric in order to calculate the cost to reach a subnet. By default it uses Path Bandwidth Value and Cumulative Interface Delay to give it its fancy name. They are more generally referred to as Bandwidth and Delay. There are five options in all with the other three being Reliability, Load, and Maximum Transmission Unit (MTU).
To set the EIGRP metrics you issue the metric weights tos k1 k2 k3 k4 k5 command under the EIGRP process. It's worth noting what each K value refers to:
k1 = Bandwidth (measured in kbps. Smallest/slowest bandwidth between the source and destination)
k2 = Load
k3 = Delay (Cumulative. Measured in 10s of microseconds AND DON'T YOU FORGET IT!)
k4 = Reliability
k5 = MTU
Each value is either switched on (binary 1) or off (binary 0). Therefore the K values usually look like 10100. How I remember this is by saying that 10100 has a value of 20 in binary.
Let's say I just want to use bandwidth as my metric. I would have to issue the following (assuming EIGRP uses AS 100).
router eigrp 100
metric weights 0 1 0 0 0 0
Assuming we go back to the default settings of using bandwidth and delay the calculation of a metric is achieved by using the following formula:
Metric = 256(107/bandwidth) + 256(delay)
Let's use an example to show how this works by assuming routers R1 and R2 are connected together using a T1 connection. R1 also has a LAN connection at 100Mbps.
R1:
LAN interface delay = 100. As this is in 10s of microseconds a delay of 100 is 1000 microseconds which is 1 millisecond (1ms).
LAN interface bandwidth = 10000. Bandwidth is in kbps so 100Mbps is 10000kbps
Putting those values in the above formula gives us a metric of 281600.
256(107/10000) + 256(100)
R2 will therefore receive this metric. R2 now has to calculate its metric based on the received metric. R2 receives the metric on its T1 interface hence the bandwidth used in the calculation will be 1544kbps. Now comes the bit that most people tend to miss. remember that fancy name given to Delay? That's right, Cumulative Interface Delay. Let's say R2 has a delay of 1000 (i.e. 10ms). The Delay used in R2s metric calculation will be the 1000 local delay PLUS the delay upstream which in this case is the delay of 100 on R1. Hence, the delay on R2 will be 1100.
The metric on R2 would therefore be:
256(107/1544) + 256(1100) = 1939631
The word "cumulative" in Cumulative Interface Delay just refers to the addition of the upstream delay to the local delay.
EIGRP Packets
Hello - Identifies neighbours, exchanges parameters, and is sent periodically as akeepalive function (every 5 seconds on interfaces above 1544kbps, every 60 seconds for speeds of 1544kbps and below). Sent to multicast address 224.0.0.10.
Update - Sent as a multicast initially. If no acknowledgement received from specific neighbour then sent as unicast to that neighbour. Initially, full updates are sent, including all routes except those omitted due to split horizon. Once all routes have been exchanged, updates cease. Future partial updates occur when one or more routes change. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.
Ack - Acknowledges Update, Query, and Response packets.
Query - Asks neighbouring routers to verify their route to a particular subnet. Reliable multicast.
Reply - Sent by neighbours in reply to a Query packet. Reliable unicast.
Goodbye - Used by a router to notify its neighbours when the router is gracefully shutting down due to removal of EIGRP process or the removal of a network statement under the routing process (e.g. no network 10.0.0.0). This is actually sent in a Hello packet with all K values set to 255.
EIGRP Updates
Once routers are adjacent, they can exchange routes using EIGRP Update messages. The process follows this general sequence:
1. Initially, full updates are sent, including all routes except those omitted due to split horizon.
2. Once all routes have been exchanged, updates cease.
3. Future partial updates occur when one or more routes change.
4. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.
EIGRP uses the Reliable Transport Protocol (RTP - not to be confused with Real Time Protocol) to send the multicast EIGRP updates. EIGRP sends updates, waiting on a unicast ACK message from each recipient. RTP allows the Update packet to be sent as a multicast. If any neighbours fail to acknowledge receipt of the Update packet, RTP sends a unicast Update to those neighbours.
Let's look at an example where R1 sends an update and R2 fails to respond:
1. R1 starts a Retransmission Timout (RTO) timer for each neighbour when it sends a reliable messgae like an Update packet. Cisco IOS actually calculates a Smoothed Round-Trip Time (SRTT) to each neighbour from which the RTO is derived. These values can vary over time.
2. R1 sends a multicast Update packet
3. R1 notes which neighbour it receives an ACK packet from
4. RTO expires before R2 responds with an ACK packet
5. R1 resends the Update packet, this time as a unicast, to R2.
EIGRP and RTP use a simple acknowledgement process with a window size of one message. Each Update packet has a sequence number, with the returned ACK packet confirming receipt of the Update by listing the same sequence number.
RTO, SRTT, and Sequence Number can all be viewed using the show ip eigrp neighbor command.
Basic Configuration
EIGRP uses a concept of an autonomous system (AS) which defines an area covered by a routing protocol and if you want to form a neighbour relationship with another router you have to be in the same AS. Back in the days of yore you had to advertise the classful network so if you wanted to advertise 10.1.2.0 you only needed to specify 10.0.0.0 in the network command.
conf t
router eigrp 100
network 10.0.0.0
no auto-summary <--turn off automatic summarisation (I do this as a matter of course)
What does the network command tell the router to do? In EIGRP it tells the router to do two things:
1. Advertise all networks that form part of the subnet specified
2. It tells the router to try and form an EIGRP neighbour relationship on the interfaces with IP addresses in that configured subnet.
What happens if we only want one interface in the 10.0.0.0 network to try and form a relationship? We could certainly use the passive-interface command (covered in more detail later) but even better we can now specify a wildcard mask in our network statement to match particular interfaces. Let's say I have two interfaces in the 10.0.0.0/8 network and only want to form a neighbour relationship on fa0/0:
int fa0/0
ip address 10.1.0.1 255.255.255.0
int fa0/1
ip address 10.1.1.1 255.255.255.0
With the original behaviour of EIGRP we would have to do the following:
router eigrp 100
network 10.0.0.0
passive-interface fa0/1
Instead, just like OSPF, we can specify a wildcard mask:
router eigrp 100
network 10.1.0.0 0.0.0.255
Or if we really want to just exactly that interface's IP address only:
router eigrp 100
network 10.1.0.1 0.0.0.0
Choosing the best route
There are a few terms that one should know when it comes to calculating the best route to a particular subnet.
Reported Distance (RD) - The metric received from a neighbour about a particular subnet
Advertised Distance (AD) - The metric advertised by a router about a particular subnet
Feasible Distance (FD) - The metric used by a router to reach a particular subnet
Successor Route - The route with the lowest FD to a particular subnet. This is promoted to the routing table.
Feasible Successor Route - A backup route to a Successor Route. For a route to considered a Feasible Successor it must have an AD less than the FD.
Let's say R1 has a Successor Route to 192.168.1.0/24 with an FD of 100 via R2 (assume R2 has an AD of 85 and our RD to R2 is 15). R3 also tells R1 that it can get to 192.168.1.0/24 with an AD of 150 and R4 can also get to 192.168.1.0/24 with an AD of 90. Do we have a Feasible Successor route? The answer is Yes. R4s AD is less than the FD of the Successor Route (i.e. 100) so it will be considered a Feasible Successor route. Note that R3's AD is 150 which is greater than the FD of 100 so it will not be considered a Feasible Successor route.
If, for example, R2 was to fail, R1 can simply promote the Feasible Successor route via R4 to the routing table thereby drastically reducing any network convergence time.
How do we view feasible successors? We simply use the show ip eigrp topology to view EIGRP's Topology table (this will show Successor and Feasible Successor routes only. If you want to view all routes use the show ip eigrp topology all-links command). I will now show a snippet of an entry to show how we identify a Feasible Successor.
R1# show ip eigrp topology
[output omitted]
P 172.31.24.0/30, 1 successors, FD is 768
via 172.31.11.2 (768/512), FastEthernet0/0
via 172.31.14.2 (1024/512), Serial0/0.4
That snippet shows that the route to 172.31.24.0/30 has one successor route which is always the first route underneath (in this case via FastEthernet0/0). Note the second entry via Serial0/0.4 and the contents of the brackets (1024/512). The 1024 denotes this router's Feasible Distance to reach the 172.31.24.0/30 subnet via Serial0/0.4. The Feasible Distance via FastEthernet0/0 is 768 which makes it better than 1024 and hence become the successor route. The second figure in the brackets is 512 which is the Reported Distance to the 172.31.24.0/30 subnet on Serial0/0.4. If this figure is less than the Feasible Distance of the Successor Route then it can be considered a Feasible Successor. In this case 512 is less than 768 so it can be considered a Feasible Successor. Let's bolden the text in the snippet above to help illustrate that point:
R1# show ip eigrp topology
[output omitted]
P 172.31.24.0/30, 1 successors, FD is 768 - FEASIBLE DISTANCE OF SUCCESSOR ROUTE
via 172.31.11.2 (768/512), FastEthernet0/0
via 172.31.14.2 (1024/512 - MUST BE LESS THAN FD OF SUCCESSOR ROUTE), Serial0/0.4
EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). This simply means that R1 could have 16 Successor Routes to a destination and would load balance across all 16 routes.
Load Balancing and Unequal Cost Load Balancing
I've already alluded to the fact that EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). Remember that this simply means that R1 could have 16 Successor Routes to a destination and would be able to load balance across all 16 routes.
You can configure this using the maximum-paths command under the EIGRP process. For example:
router eigrp 100
maximum-paths 6 <--sets the maximum number of Successor Routes to 6
A neat feature of EIGRP is to be able to load balance across paths that have different costs. In fact I was asked to configure this just the other day. It uses the concept of a multiplier called variance. This multiplies the FD of a route by the configured figure (let's call this value FDnew). Any Feasible Successor routes that have a value less than FDnew are considered to be equal to the original Successor Route and are promoted to the routing table.
To configure the variance we simply use the variance command under the EIGRP process:
router eigrp 100
variance 2 <--would multiply the FD of all Successor Routes by 2
Let's look at an example. R1 has a Successor Route to 192.168.1.0/24 via R2 with a FD of 100. R1 also has a Feasible Successor route via R3 with an AD of 90 and a total FD of 190. R1 also has a Feasible Successor route via R4 with an AD of 95 and a total FD of 205. R1 has variance 2 configured under its EIGRP process. The FD of the Successor Route is now 100 * 2 = 200. We now look at the FD of each Feasible Successor to see if it is less than 200. In the case of R3 this is true, and with R4 it is false. Therefore the routing table would contain two routes to 192.168.1.0/24 - the original route via R2 and the route via R3.
You can configure how EIGRP shares traffic across links. By default it will balance evenly across routes, ignoring EIGRP metrics. The folliwng can be configured under the EIGRP process:
traffic-share balanced - The router balances across the routes, giving more packets to lower-metric routes
traffic-share min - Although multiple routes are installed in the routing table, the router sends traffic using only the lowest-metric route
traffic-share balanced across-interfaces - If more routes exist than are allowed with the maximum-paths setting, the router chooses routes with different outgoing interfaces, for better balancing.
Going active on a route
There will inevitably be occasions when a route to a particular subnet goes down for some reason. If there is no feasible successor for that route the router will go active on that route. Conversely, if the route is up it is said to be passive.
So what does going active actually mean? Basically the router will query (remember that EIGRP Query packets are sent as a reliable multicast and will expect an Ack to be sent back) all of its neighbours asking them if they know of a route to the subnet in question. The router will then expect all of its neighbours to reply, using a reliable unicast EIGRP Reply packet, before calculating a new route and sending an Ack back.
Neighbours that are queried can do one of three things:
1. Send a Reply packet back stating that they do not have a route
2. Send a Reply packet back with details of their route
3. Go Active themselves if 1 or 2 are not satisfied and withholds its response until it has received all of its replies from the neighbours it is querying.
Hopefully you can see a pitfall here. If R1 went active on a route causing R2 to go active, it may mean R3 goes active too, etc. If a router stays active on a route for too long (default is 3 minutes) it is said to be stuck-in-active on that route and brings down the neighbour relationship to the router it has not received a reply from as it thinks that that router is having some problems. However, that router may be fine and it is downstream where the issue lies. This is clearly an undesirable state.
You can turn off the active timer by issuing the timers active-timer disabled command under the EIGRP process in order to combat a route from being stuck-in-active, however, there are more elegant solutions which revolve around limiting the query scope which we will discuss in the next section.
Limiting the Query Scope
Two methods can be used to limit the query scope in an EIGRP network. The first method that can be used is summarisation. When a Query reaches a router that has a summarised route, but not the specific route in the Query, the router immediately replies that it does not have that route. Put simply, if my router had a summarised route of 192.168.1.0/24 and it received a Query about network 192.168.1.16/28, it will send a Reply saying that it doesn't have a route to 192.168.1.16/28.
The second method for limiting the query scope involves the use of stub routers. Stub routers should not be used as transit routers and non-stub routers do not query stub routers. An ideal candidate for being configured as a stub router is a spoke site router in a hub-and-spoke topology. EIGRP stub routers are very easy to configure:
router eigrp 100
eigrp stub <-- makes this an EIGRP stub router
By default, the eigrp stub command will cause the router that it is issued on to advertise connected and summary routes only and indeed when you issue a show run you will see the following:
router eigrp 100
eigrp stub connected summary
There are other options that can be specified, some of which are not compatible with others. The following describes these options:
eigrp stub connected - Advertise connected routes, but only for interfaces matched with a network command.
eigrp stub summary - Advertise auto-summarised or statically configured summary routes.
eigrp stub static - Advertise static routes, assuming the redistribute static command is configured.
eigrp stub redistributed - Advertise redistributed routes, assuming redistribution is configured.
eigrp stub receive-only - Does not advertise any routes. This option cannot be used with any other option.
Authentication
As I mentioned earlier in this piece, EIGRP can have authentication configured so that EIGRP communication can be secured. Unlike other routing protocols EIGRP supports MD5 authentication only. If authentication is configured a pair of routers must be able to pass the authentication procedure if they are to successfully become neighbours. As you would expect, the passwords on both sides must match in order for the EIGRP neighbour relationship and subsequent updates to be successful.
You configure the passwords in global configuration mode using key-chains which are made up of keys which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen here):
key-chain MyKeyChain
key 1
key MyPassword
To turn EIGRP authentication on you must configure it under the interface which will be sending the updates:
int fa0/0
ip authentication mode eigrp autonomous-system-number md5
ip authentication key-chain eigrp autonomous-system-number key-chain-name
So if I was to use AS 100 my configuration would look like:
int fa0/0
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 MyKeyChain
EIGRP Summarisation
EIGRP supports classless routing but is classful in nature by default. What this means in very simple terms is that EIGRP can be configured to send subnet masks supports Variable Length Subnet Masks. If a router running EIGRP has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen if you issue the no auto-summary command under the EIGRP routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to discontiguous networks which is a fancy name for a class of network that has another class of network in between, for example:
(Class A)R1(Class B)-->(Class B)R2(Class B)-->(Class B)R3(Class A)
Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.
EIGRP also supports summarisation anywhere in the network by configuring a summary address on an interface:
int fa0/0
ip summary-address eigrp as-number ip-address mask [admin-distance] [leak-map name]
The ip summary-address eigrp command is used to configure interface-level address summarization. EIGRP summary routes are given an administrative distance value of 5. The administrative distance metric is used to advertise a summary without installing it in the routing table.
By default, EIGRP summarizes subnet routes to the network level. The no auto-summary command can be entered to configure subnet level summarization.
EIGRP Support for Leaking Routes - Configuring the leak-map keyword allows the advertisement of a component route that would otherwise be suppressed by the manual summary. Any component subset of the summary can be leaked. A route map and access list must be defined to source the leaked route.
The following is default behavior if an incomplete configuration is entered:
If the leak-map keyword is configured to reference a nonexistent route map, the configuration of this keyword has no effect. The summary address is advertised but all component routes are suppressed.
If the leak-map keyword is configured but the access-list does not exist or the route map does not reference the access list, the summary address and all component routes are sent.
Let's have a look at some examples:
The following example configures an administrative distance of 95 on interface FastEthernet0/0 for the 192.168.0.0/16 summary address:
router eigrp 100
no auto-summary
interface fa0/0
ip summary-address eigrp 100 192.168.0.0 255.255.0.0 95
The following example configures the 10.1.1.0/24 subnet to be leaked through the 10.0.0.0 summary address:
router eigrp 100
access-list 1 permit 10.1.1.0 0.0.0.255
route-map LEAK-10-1-1 permit 10
match ip address 1
interface fa0/0
ip summary-address eigrp 1 10.0.0.0 255.0.0.0 leak-map LEAK-10-1-1
Split Horizon
Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 an EIGRP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the no ip split-horizon eigrp autonomous-system-number command under an interface:
interface FastEthernet0/0
no ip split-horizon eigrp 100
Passive Interface
Unlike RIP where the passive-interface command tells a router's interface to stop sending updates out of that interface, that same command under the EIGRP process actually prevents a neighbour relationship from forming.
router eigrp 100
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops EIGRP forming neighbour relationship on fa0/0
Be aware that you can make all interfaces passive by issuing the passive-interface default command. This might be desirable when you want all interfaces except one from forming a neighbour relationship. For example, you may only want a router connected to fa0/0 to form a neighbour relationship with your router so you make every interface passive by default and then issue the no passive-interface [interface] command:
router eigrp 100
network 10.0.0.0
no auto-summary
passive-interface default <--stops EIGRP forming neighbour relationships on all interfaces
no passive-interface FastEthernet0/0 <--allows EIGRP to form a neighbour relationship on fa0/0
Route Filtering
In order to prevent updates about certain networks from being received or sent you should use something called a distribute-list. A distribute-list filters out routes from entering the routing table or being sent by referencing a pre-configured access-list or prefix-list.
For example, let's create an access-list:
access-list 1 permit 192.168.1.0 0.0.0.255
The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:
distribute-list [access-list-number_or_access-list-name] [in | out] [interface]
If there is a match in the access-list then that route is filtered out of the routing update. If you look at my access-list you will see that I am filtering out the 192.168.1.0/24 network.
In the following example I will use a distribute-list to stop updates being received on fa0/0 about 192.168.1.0/24
access-list 1 permit 192.168.1.0 0.0.0.255
router eigrp 100
network 192.168.1.0
no auto-summary
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
The next example shows you how to stop routes being advertised by changing the direction in the distribute-list command.
access-list 1 permit 192.168.1.0 0.0.0.255
router eigrp 100
network 192.168.1.0
no auto-summary
distribute-list 1 out FastEthernet0/0 <--prevents updates out of fa0/0 as specified by ACL 1
Using Offset Lists to change EIGRP's metric for a particular route
You change the metric received or advertised in EIGRP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:
offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]
Let's look at an example:
R1 has a route for 192.168.1.0/24 with a metric of 1544. We want to advertise that route to R2 with a metric of 1600. Let's configure our offset-list:
access-list 1 permit 192.168.1.0 0.0.0.255
router eigrp 100
offset-list 1 out 56 FastEthernet0/0
Here offset-list 1 specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by out. We add 56 to the metric of all routes matched by our access-list as specified by the 1 after the out keyword. Finally we specify the interface out of which our offset-list is applied.
Offset lists are more applicable to RIPv1 and RIPv2 than EIGRP has RIP has such a limited metric range. With EIGRPs complex metric it is very doubtful that you would want to change the metric in this way.
Clearing EIGRP routes from the routing table
The clear ip route * command from privileged mode will not affect EIGRP routes as the routers are in the topology table and will simply go straight back in to the routing table. In the case of EIGRP you have to tear down the neighbour adjacency:
clear ip eigrp neighbor - clears all neighbour adjacencies
clear ip eigrp neighbor ip-address - clears specified neighbour adjacency
clear ip eigrp neighbor interface - clears neighbour adjacencies on specified interface
Conclusion
If you're at ICND2 and above you need to know the majority of what I've written but as with my RIP posting I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on EIGRP. I hope I've got enough detail in here for you to understand the basic operation of EIGRP and some of the extras that can be configured.
As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.
Good luck with your studies!
For detailed information please refer to the Cisco documentation on EIGRP here
Key Points
Uses IP protocol 88
Uses Reliable Transport Protocol (RTP) for reliable exchanging of data (does not use UDP or TCP)
Default metric is bandwidth and delay
Normally multicasts hellos and updates to 224.0.0.10
Uses Diffusing Update Algorithm (DUAL) in order to find best routes
Best routes are called Successors
Supports Feasible Successors which are back-up routes to a Successor route
Sends full updates with new neighbours and partial updates thereafter
Supports MD5 authentication only
Auto-summarisation on by default
Supports VLSM by turning off auto-summarisation
Manual summarisation supported anywhere in the EIGRP network
Routes redistributed into EIGRP can be tagged
Different next-hop router can be defined
Multiprotocol - it can support IPX and AppleTalk by use of PDMs
Timers
Hello Timer - The Hello interval is the rate at which EIGRP sends hello packets. The command ip hello-interval eigrp can be used to set the Hello interval time manually. The Hello interval defaults to 5 seconds for high-speed networks and 60 seconds for low-speed networks (i.e. less than 1.544Mbps).
Hold Timer - This is the amount of time that a router will consider a neighbor alive without receiving hello packets. The hold time is typically three times the hello interval. You can adjust the hold time with the ip hold-time eigrp command.
Unlike OSPF changing the hello timer does not automatically adjust the hold down timer.
Active Timer - This timer controls the time the router waits after sending a query before declaring the route stuck in active (SIA) and resetting the neighbor relationship. To avoid this neighbor resetting you can temporary increase the active timer until you solve the problem by eliminating the cause. The timers active-time [time-in-minutes] command under the EIGRP process can be used to adjust the active timer or be completely disabled by issuing the timers active-time disabled command. The default is 3 minutes.
There are some interesting points to be aware of with EIGRP timers:
1. The Hello mechanism works independently in each direction. Hellos from router R1 to router R2 do not necessarily have to use the same parameters as Hellos from R2 to R1.
2. The Hold timer is transmitted to the neighbor in the hello packet. R2 does not use its locally configured hold-time, but uses the value that R1 tells it to use.
This second point warrants an explanation. Let's say R1 has a Hello timer of 3 seconds and Hold timer of 10 seconds and R2 has a Hello timer of 20 seconds and a Hold Timer of 90 seconds (these figures are completely arbitrary and in no way would I recommend you use these figures).
Instinct would tell us that R1 may see R2 up initially but as R2's Hellos are longer than R1's Hold timer (20 seconds versus 10 seconds), R1 would believe that R2 is down. However, what point 2 says is that R1 will ignore its locally configured timers and use those advertised by R2 for the neighbour relationship with R2. Hence, R2 would only appear down to R1 if R1 does not receive a Hello from R2 within 90 seconds.
This leads us nicely on to how EIGRP neighbours are formed.
Forming a neighbour relationship
There are 4 things that potential EIGRP neighbours must agree on before they can be confirmed as neighbours:
1. Authentication password must match assuming authentication is used
2. The autonomous system (AS) number must match
3. K values must match
4. Source IP address of a received Hello must be in the same subnet as the primary IP address configured on the interface that received the Hello.
Note that timers do not need to match like other protocols!
Point 4 may need explaining but it is pretty straightforward. What is says is that EIGRP neighbours will not form on secondary IP addresses. Let's take a look at an example:
R1 and R2 are connected on their fa0/0 interfaces. R1 has the following configuration on its fa0/0 interface:
#R1
int fa0/0
ip address 192.168.1.1 255.255.255.0
R1 will expect the source address of a received Hello on fa0/0 to be in the 192.168.1.0/24 subnet. Let's say R2 is figured like this:
#R2
int fa0/0
ip address 192.168.2.1 255.255.255.0
ip address 192.168.1.2 255.255.255.0 secondary
The neighbour relationship will not form as R2 will source its Hellos from its primary IP address and that is not in the same subnet as R1's primary subnet on fa0/0.
Another thing to bear in mind is that the subnet masks do not have to match in order for the neighbour relationship to be formed. Taking the same example as above with R1 and R2 let's configure them with different subnet masks:
#R1
int fa0/0
ip address 192.168.1.1 255.255.255.0
#R2
int fa0/0
ip address 192.168.1.2 255.255.255.128
R1 will be expecting a received Hello to be sourced from an IP address in its primary subnet configured on fa0/0. Therefore it will expect an address in the range of 192.168.1.2 to 192.168.1.254. On R2 the IP address is indeed within that range and hence the neighbour relationship forms.
The other 3 factors that must pass in order for a neighbour relationship to be formed are covered in more detail in other sections within this post.
Metrics - K values
EIGRP uses a composite metric in order to calculate the cost to reach a subnet. By default it uses Path Bandwidth Value and Cumulative Interface Delay to give it its fancy name. They are more generally referred to as Bandwidth and Delay. There are five options in all with the other three being Reliability, Load, and Maximum Transmission Unit (MTU).
To set the EIGRP metrics you issue the metric weights tos k1 k2 k3 k4 k5 command under the EIGRP process. It's worth noting what each K value refers to:
k1 = Bandwidth (measured in kbps. Smallest/slowest bandwidth between the source and destination)
k2 = Load
k3 = Delay (Cumulative. Measured in 10s of microseconds AND DON'T YOU FORGET IT!)
k4 = Reliability
k5 = MTU
Each value is either switched on (binary 1) or off (binary 0). Therefore the K values usually look like 10100. How I remember this is by saying that 10100 has a value of 20 in binary.
Let's say I just want to use bandwidth as my metric. I would have to issue the following (assuming EIGRP uses AS 100).
router eigrp 100
metric weights 0 1 0 0 0 0
Assuming we go back to the default settings of using bandwidth and delay the calculation of a metric is achieved by using the following formula:
Metric = 256(107/bandwidth) + 256(delay)
Let's use an example to show how this works by assuming routers R1 and R2 are connected together using a T1 connection. R1 also has a LAN connection at 100Mbps.
R1:
LAN interface delay = 100. As this is in 10s of microseconds a delay of 100 is 1000 microseconds which is 1 millisecond (1ms).
LAN interface bandwidth = 10000. Bandwidth is in kbps so 100Mbps is 10000kbps
Putting those values in the above formula gives us a metric of 281600.
256(107/10000) + 256(100)
R2 will therefore receive this metric. R2 now has to calculate its metric based on the received metric. R2 receives the metric on its T1 interface hence the bandwidth used in the calculation will be 1544kbps. Now comes the bit that most people tend to miss. remember that fancy name given to Delay? That's right, Cumulative Interface Delay. Let's say R2 has a delay of 1000 (i.e. 10ms). The Delay used in R2s metric calculation will be the 1000 local delay PLUS the delay upstream which in this case is the delay of 100 on R1. Hence, the delay on R2 will be 1100.
The metric on R2 would therefore be:
256(107/1544) + 256(1100) = 1939631
The word "cumulative" in Cumulative Interface Delay just refers to the addition of the upstream delay to the local delay.
EIGRP Packets
Hello - Identifies neighbours, exchanges parameters, and is sent periodically as akeepalive function (every 5 seconds on interfaces above 1544kbps, every 60 seconds for speeds of 1544kbps and below). Sent to multicast address 224.0.0.10.
Update - Sent as a multicast initially. If no acknowledgement received from specific neighbour then sent as unicast to that neighbour. Initially, full updates are sent, including all routes except those omitted due to split horizon. Once all routes have been exchanged, updates cease. Future partial updates occur when one or more routes change. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.
Ack - Acknowledges Update, Query, and Response packets.
Query - Asks neighbouring routers to verify their route to a particular subnet. Reliable multicast.
Reply - Sent by neighbours in reply to a Query packet. Reliable unicast.
Goodbye - Used by a router to notify its neighbours when the router is gracefully shutting down due to removal of EIGRP process or the removal of a network statement under the routing process (e.g. no network 10.0.0.0). This is actually sent in a Hello packet with all K values set to 255.
EIGRP Updates
Once routers are adjacent, they can exchange routes using EIGRP Update messages. The process follows this general sequence:
1. Initially, full updates are sent, including all routes except those omitted due to split horizon.
2. Once all routes have been exchanged, updates cease.
3. Future partial updates occur when one or more routes change.
4. If neighbours fail and recover, or new neighbour adjacencies are formed, full updates are sent.
EIGRP uses the Reliable Transport Protocol (RTP - not to be confused with Real Time Protocol) to send the multicast EIGRP updates. EIGRP sends updates, waiting on a unicast ACK message from each recipient. RTP allows the Update packet to be sent as a multicast. If any neighbours fail to acknowledge receipt of the Update packet, RTP sends a unicast Update to those neighbours.
Let's look at an example where R1 sends an update and R2 fails to respond:
1. R1 starts a Retransmission Timout (RTO) timer for each neighbour when it sends a reliable messgae like an Update packet. Cisco IOS actually calculates a Smoothed Round-Trip Time (SRTT) to each neighbour from which the RTO is derived. These values can vary over time.
2. R1 sends a multicast Update packet
3. R1 notes which neighbour it receives an ACK packet from
4. RTO expires before R2 responds with an ACK packet
5. R1 resends the Update packet, this time as a unicast, to R2.
EIGRP and RTP use a simple acknowledgement process with a window size of one message. Each Update packet has a sequence number, with the returned ACK packet confirming receipt of the Update by listing the same sequence number.
RTO, SRTT, and Sequence Number can all be viewed using the show ip eigrp neighbor command.
Basic Configuration
EIGRP uses a concept of an autonomous system (AS) which defines an area covered by a routing protocol and if you want to form a neighbour relationship with another router you have to be in the same AS. Back in the days of yore you had to advertise the classful network so if you wanted to advertise 10.1.2.0 you only needed to specify 10.0.0.0 in the network command.
conf t
router eigrp 100
network 10.0.0.0
no auto-summary <--turn off automatic summarisation (I do this as a matter of course)
What does the network command tell the router to do? In EIGRP it tells the router to do two things:
1. Advertise all networks that form part of the subnet specified
2. It tells the router to try and form an EIGRP neighbour relationship on the interfaces with IP addresses in that configured subnet.
What happens if we only want one interface in the 10.0.0.0 network to try and form a relationship? We could certainly use the passive-interface command (covered in more detail later) but even better we can now specify a wildcard mask in our network statement to match particular interfaces. Let's say I have two interfaces in the 10.0.0.0/8 network and only want to form a neighbour relationship on fa0/0:
int fa0/0
ip address 10.1.0.1 255.255.255.0
int fa0/1
ip address 10.1.1.1 255.255.255.0
With the original behaviour of EIGRP we would have to do the following:
router eigrp 100
network 10.0.0.0
passive-interface fa0/1
Instead, just like OSPF, we can specify a wildcard mask:
router eigrp 100
network 10.1.0.0 0.0.0.255
Or if we really want to just exactly that interface's IP address only:
router eigrp 100
network 10.1.0.1 0.0.0.0
Choosing the best route
There are a few terms that one should know when it comes to calculating the best route to a particular subnet.
Reported Distance (RD) - The metric received from a neighbour about a particular subnet
Advertised Distance (AD) - The metric advertised by a router about a particular subnet
Feasible Distance (FD) - The metric used by a router to reach a particular subnet
Successor Route - The route with the lowest FD to a particular subnet. This is promoted to the routing table.
Feasible Successor Route - A backup route to a Successor Route. For a route to considered a Feasible Successor it must have an AD less than the FD.
Let's say R1 has a Successor Route to 192.168.1.0/24 with an FD of 100 via R2 (assume R2 has an AD of 85 and our RD to R2 is 15). R3 also tells R1 that it can get to 192.168.1.0/24 with an AD of 150 and R4 can also get to 192.168.1.0/24 with an AD of 90. Do we have a Feasible Successor route? The answer is Yes. R4s AD is less than the FD of the Successor Route (i.e. 100) so it will be considered a Feasible Successor route. Note that R3's AD is 150 which is greater than the FD of 100 so it will not be considered a Feasible Successor route.
If, for example, R2 was to fail, R1 can simply promote the Feasible Successor route via R4 to the routing table thereby drastically reducing any network convergence time.
How do we view feasible successors? We simply use the show ip eigrp topology to view EIGRP's Topology table (this will show Successor and Feasible Successor routes only. If you want to view all routes use the show ip eigrp topology all-links command). I will now show a snippet of an entry to show how we identify a Feasible Successor.
R1# show ip eigrp topology
[output omitted]
P 172.31.24.0/30, 1 successors, FD is 768
via 172.31.11.2 (768/512), FastEthernet0/0
via 172.31.14.2 (1024/512), Serial0/0.4
That snippet shows that the route to 172.31.24.0/30 has one successor route which is always the first route underneath (in this case via FastEthernet0/0). Note the second entry via Serial0/0.4 and the contents of the brackets (1024/512). The 1024 denotes this router's Feasible Distance to reach the 172.31.24.0/30 subnet via Serial0/0.4. The Feasible Distance via FastEthernet0/0 is 768 which makes it better than 1024 and hence become the successor route. The second figure in the brackets is 512 which is the Reported Distance to the 172.31.24.0/30 subnet on Serial0/0.4. If this figure is less than the Feasible Distance of the Successor Route then it can be considered a Feasible Successor. In this case 512 is less than 768 so it can be considered a Feasible Successor. Let's bolden the text in the snippet above to help illustrate that point:
R1# show ip eigrp topology
[output omitted]
P 172.31.24.0/30, 1 successors, FD is 768 - FEASIBLE DISTANCE OF SUCCESSOR ROUTE
via 172.31.11.2 (768/512), FastEthernet0/0
via 172.31.14.2 (1024/512 - MUST BE LESS THAN FD OF SUCCESSOR ROUTE), Serial0/0.4
EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). This simply means that R1 could have 16 Successor Routes to a destination and would load balance across all 16 routes.
Load Balancing and Unequal Cost Load Balancing
I've already alluded to the fact that EIGRP can now support up to 16 equal-cost paths to a destination (not 6 as most books would have you know). Remember that this simply means that R1 could have 16 Successor Routes to a destination and would be able to load balance across all 16 routes.
You can configure this using the maximum-paths command under the EIGRP process. For example:
router eigrp 100
maximum-paths 6 <--sets the maximum number of Successor Routes to 6
A neat feature of EIGRP is to be able to load balance across paths that have different costs. In fact I was asked to configure this just the other day. It uses the concept of a multiplier called variance. This multiplies the FD of a route by the configured figure (let's call this value FDnew). Any Feasible Successor routes that have a value less than FDnew are considered to be equal to the original Successor Route and are promoted to the routing table.
To configure the variance we simply use the variance command under the EIGRP process:
router eigrp 100
variance 2 <--would multiply the FD of all Successor Routes by 2
Let's look at an example. R1 has a Successor Route to 192.168.1.0/24 via R2 with a FD of 100. R1 also has a Feasible Successor route via R3 with an AD of 90 and a total FD of 190. R1 also has a Feasible Successor route via R4 with an AD of 95 and a total FD of 205. R1 has variance 2 configured under its EIGRP process. The FD of the Successor Route is now 100 * 2 = 200. We now look at the FD of each Feasible Successor to see if it is less than 200. In the case of R3 this is true, and with R4 it is false. Therefore the routing table would contain two routes to 192.168.1.0/24 - the original route via R2 and the route via R3.
You can configure how EIGRP shares traffic across links. By default it will balance evenly across routes, ignoring EIGRP metrics. The folliwng can be configured under the EIGRP process:
traffic-share balanced - The router balances across the routes, giving more packets to lower-metric routes
traffic-share min - Although multiple routes are installed in the routing table, the router sends traffic using only the lowest-metric route
traffic-share balanced across-interfaces - If more routes exist than are allowed with the maximum-paths setting, the router chooses routes with different outgoing interfaces, for better balancing.
Going active on a route
There will inevitably be occasions when a route to a particular subnet goes down for some reason. If there is no feasible successor for that route the router will go active on that route. Conversely, if the route is up it is said to be passive.
So what does going active actually mean? Basically the router will query (remember that EIGRP Query packets are sent as a reliable multicast and will expect an Ack to be sent back) all of its neighbours asking them if they know of a route to the subnet in question. The router will then expect all of its neighbours to reply, using a reliable unicast EIGRP Reply packet, before calculating a new route and sending an Ack back.
Neighbours that are queried can do one of three things:
1. Send a Reply packet back stating that they do not have a route
2. Send a Reply packet back with details of their route
3. Go Active themselves if 1 or 2 are not satisfied and withholds its response until it has received all of its replies from the neighbours it is querying.
Hopefully you can see a pitfall here. If R1 went active on a route causing R2 to go active, it may mean R3 goes active too, etc. If a router stays active on a route for too long (default is 3 minutes) it is said to be stuck-in-active on that route and brings down the neighbour relationship to the router it has not received a reply from as it thinks that that router is having some problems. However, that router may be fine and it is downstream where the issue lies. This is clearly an undesirable state.
You can turn off the active timer by issuing the timers active-timer disabled command under the EIGRP process in order to combat a route from being stuck-in-active, however, there are more elegant solutions which revolve around limiting the query scope which we will discuss in the next section.
Limiting the Query Scope
Two methods can be used to limit the query scope in an EIGRP network. The first method that can be used is summarisation. When a Query reaches a router that has a summarised route, but not the specific route in the Query, the router immediately replies that it does not have that route. Put simply, if my router had a summarised route of 192.168.1.0/24 and it received a Query about network 192.168.1.16/28, it will send a Reply saying that it doesn't have a route to 192.168.1.16/28.
The second method for limiting the query scope involves the use of stub routers. Stub routers should not be used as transit routers and non-stub routers do not query stub routers. An ideal candidate for being configured as a stub router is a spoke site router in a hub-and-spoke topology. EIGRP stub routers are very easy to configure:
router eigrp 100
eigrp stub <-- makes this an EIGRP stub router
By default, the eigrp stub command will cause the router that it is issued on to advertise connected and summary routes only and indeed when you issue a show run you will see the following:
router eigrp 100
eigrp stub connected summary
There are other options that can be specified, some of which are not compatible with others. The following describes these options:
eigrp stub connected - Advertise connected routes, but only for interfaces matched with a network command.
eigrp stub summary - Advertise auto-summarised or statically configured summary routes.
eigrp stub static - Advertise static routes, assuming the redistribute static command is configured.
eigrp stub redistributed - Advertise redistributed routes, assuming redistribution is configured.
eigrp stub receive-only - Does not advertise any routes. This option cannot be used with any other option.
Authentication
As I mentioned earlier in this piece, EIGRP can have authentication configured so that EIGRP communication can be secured. Unlike other routing protocols EIGRP supports MD5 authentication only. If authentication is configured a pair of routers must be able to pass the authentication procedure if they are to successfully become neighbours. As you would expect, the passwords on both sides must match in order for the EIGRP neighbour relationship and subsequent updates to be successful.
You configure the passwords in global configuration mode using key-chains which are made up of keys which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen here):
key-chain MyKeyChain
key 1
key MyPassword
To turn EIGRP authentication on you must configure it under the interface which will be sending the updates:
int fa0/0
ip authentication mode eigrp autonomous-system-number md5
ip authentication key-chain eigrp autonomous-system-number key-chain-name
So if I was to use AS 100 my configuration would look like:
int fa0/0
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 MyKeyChain
EIGRP Summarisation
EIGRP supports classless routing but is classful in nature by default. What this means in very simple terms is that EIGRP can be configured to send subnet masks supports Variable Length Subnet Masks. If a router running EIGRP has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen if you issue the no auto-summary command under the EIGRP routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to discontiguous networks which is a fancy name for a class of network that has another class of network in between, for example:
(Class A)R1(Class B)-->(Class B)R2(Class B)-->(Class B)R3(Class A)
Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.
EIGRP also supports summarisation anywhere in the network by configuring a summary address on an interface:
int fa0/0
ip summary-address eigrp as-number ip-address mask [admin-distance] [leak-map name]
The ip summary-address eigrp command is used to configure interface-level address summarization. EIGRP summary routes are given an administrative distance value of 5. The administrative distance metric is used to advertise a summary without installing it in the routing table.
By default, EIGRP summarizes subnet routes to the network level. The no auto-summary command can be entered to configure subnet level summarization.
EIGRP Support for Leaking Routes - Configuring the leak-map keyword allows the advertisement of a component route that would otherwise be suppressed by the manual summary. Any component subset of the summary can be leaked. A route map and access list must be defined to source the leaked route.
The following is default behavior if an incomplete configuration is entered:
If the leak-map keyword is configured to reference a nonexistent route map, the configuration of this keyword has no effect. The summary address is advertised but all component routes are suppressed.
If the leak-map keyword is configured but the access-list does not exist or the route map does not reference the access list, the summary address and all component routes are sent.
Let's have a look at some examples:
The following example configures an administrative distance of 95 on interface FastEthernet0/0 for the 192.168.0.0/16 summary address:
router eigrp 100
no auto-summary
interface fa0/0
ip summary-address eigrp 100 192.168.0.0 255.255.0.0 95
The following example configures the 10.1.1.0/24 subnet to be leaked through the 10.0.0.0 summary address:
router eigrp 100
access-list 1 permit 10.1.1.0 0.0.0.255
route-map LEAK-10-1-1 permit 10
match ip address 1
interface fa0/0
ip summary-address eigrp 1 10.0.0.0 255.0.0.0 leak-map LEAK-10-1-1
Split Horizon
Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 an EIGRP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the no ip split-horizon eigrp autonomous-system-number command under an interface:
interface FastEthernet0/0
no ip split-horizon eigrp 100
Passive Interface
Unlike RIP where the passive-interface command tells a router's interface to stop sending updates out of that interface, that same command under the EIGRP process actually prevents a neighbour relationship from forming.
router eigrp 100
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops EIGRP forming neighbour relationship on fa0/0
Be aware that you can make all interfaces passive by issuing the passive-interface default command. This might be desirable when you want all interfaces except one from forming a neighbour relationship. For example, you may only want a router connected to fa0/0 to form a neighbour relationship with your router so you make every interface passive by default and then issue the no passive-interface [interface] command:
router eigrp 100
network 10.0.0.0
no auto-summary
passive-interface default <--stops EIGRP forming neighbour relationships on all interfaces
no passive-interface FastEthernet0/0 <--allows EIGRP to form a neighbour relationship on fa0/0
Route Filtering
In order to prevent updates about certain networks from being received or sent you should use something called a distribute-list. A distribute-list filters out routes from entering the routing table or being sent by referencing a pre-configured access-list or prefix-list.
For example, let's create an access-list:
access-list 1 permit 192.168.1.0 0.0.0.255
The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:
distribute-list [access-list-number_or_access-list-name] [in | out] [interface]
If there is a match in the access-list then that route is filtered out of the routing update. If you look at my access-list you will see that I am filtering out the 192.168.1.0/24 network.
In the following example I will use a distribute-list to stop updates being received on fa0/0 about 192.168.1.0/24
access-list 1 permit 192.168.1.0 0.0.0.255
router eigrp 100
network 192.168.1.0
no auto-summary
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
The next example shows you how to stop routes being advertised by changing the direction in the distribute-list command.
access-list 1 permit 192.168.1.0 0.0.0.255
router eigrp 100
network 192.168.1.0
no auto-summary
distribute-list 1 out FastEthernet0/0 <--prevents updates out of fa0/0 as specified by ACL 1
Using Offset Lists to change EIGRP's metric for a particular route
You change the metric received or advertised in EIGRP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:
offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]
Let's look at an example:
R1 has a route for 192.168.1.0/24 with a metric of 1544. We want to advertise that route to R2 with a metric of 1600. Let's configure our offset-list:
access-list 1 permit 192.168.1.0 0.0.0.255
router eigrp 100
offset-list 1 out 56 FastEthernet0/0
Here offset-list 1 specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by out. We add 56 to the metric of all routes matched by our access-list as specified by the 1 after the out keyword. Finally we specify the interface out of which our offset-list is applied.
Offset lists are more applicable to RIPv1 and RIPv2 than EIGRP has RIP has such a limited metric range. With EIGRPs complex metric it is very doubtful that you would want to change the metric in this way.
Clearing EIGRP routes from the routing table
The clear ip route * command from privileged mode will not affect EIGRP routes as the routers are in the topology table and will simply go straight back in to the routing table. In the case of EIGRP you have to tear down the neighbour adjacency:
clear ip eigrp neighbor - clears all neighbour adjacencies
clear ip eigrp neighbor ip-address - clears specified neighbour adjacency
clear ip eigrp neighbor interface - clears neighbour adjacencies on specified interface
Conclusion
If you're at ICND2 and above you need to know the majority of what I've written but as with my RIP posting I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on EIGRP. I hope I've got enough detail in here for you to understand the basic operation of EIGRP and some of the extras that can be configured.
As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.
Good luck with your studies!
Tuesday, 9 June 2009
"ip classless" versus "no ip classless"
This often has me confused but the article below, rejigged slightly from the original article here seems to have cleared the fog from my mind and hopefully yours too.
Where the ip classless configuration command falls within the routing and forwarding processes is often confusing. In reality, IP classless only affects the operation of the forwarding processes in IOS; it doesn't affect the way the routing table is built. If IP classless isn't configured (using the no ip classless command), the router won't forward packets to supernets. As an example, let's place three routes in a routing table and route packets through the router.
Note: If the supernet or default route is learned via IS-IS or OSPF, the no ip classless configuration command is ignored. In this case, packet switching behavior works as though ip classless were configured.
router# show ip route
....
172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.30.32.0/20 [90/4879540] via 10.1.1.2
D 172.30.32.0/24 [90/25789217] via 10.1.1.1
S* 0.0.0.0/0 [1/0] via 10.1.1.3
Remembering that the 172.30.32.0/24 network includes the addresses 172.30.32.0 through 172.30.32.255, and the 172.30.32.0/20 network includes the addresses 172.30.32.0 through 172.30.47.255, we can then try switching three packets through this routing table and see what the results are.
A packet destined to 172.30.32.1 is forwarded to 10.1.1.1, since this is the longest prefix match.
A packet destined to 172.30.33.1 is forwarded to 10.1.1.2, since this is the longest prefix match.
A packet destined to 192.168.10.1 is forwarded to 10.1.1.3; since this network doesn't exist in the routing table, this packet is forwarded to the default route.
A packet destined to 172.30.254.1 is dropped.
The surprising answer out of these four is the last packet, which is dropped. It's dropped because its destination, 172.30.254.1, is within a known major network, 172.30.0.0/16, but the router doesn't know about this particular subnet within that major network.
This is the essence of classful routing: If one part of a major network is known, but the subnet toward which the packet is destined within that major network is unknown, the packet is dropped.
The most confusing aspect of this rule is that the router only uses the default route if the destination major network doesn't exist in the routing table at all. However, if ip classless was configured the default route would have been used.
So there you have it. The fundamental difference between the configuration of ip classless and no ip classless is whether the default route would be used.
Where the ip classless configuration command falls within the routing and forwarding processes is often confusing. In reality, IP classless only affects the operation of the forwarding processes in IOS; it doesn't affect the way the routing table is built. If IP classless isn't configured (using the no ip classless command), the router won't forward packets to supernets. As an example, let's place three routes in a routing table and route packets through the router.
Note: If the supernet or default route is learned via IS-IS or OSPF, the no ip classless configuration command is ignored. In this case, packet switching behavior works as though ip classless were configured.
router# show ip route
....
172.30.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.30.32.0/20 [90/4879540] via 10.1.1.2
D 172.30.32.0/24 [90/25789217] via 10.1.1.1
S* 0.0.0.0/0 [1/0] via 10.1.1.3
Remembering that the 172.30.32.0/24 network includes the addresses 172.30.32.0 through 172.30.32.255, and the 172.30.32.0/20 network includes the addresses 172.30.32.0 through 172.30.47.255, we can then try switching three packets through this routing table and see what the results are.
A packet destined to 172.30.32.1 is forwarded to 10.1.1.1, since this is the longest prefix match.
A packet destined to 172.30.33.1 is forwarded to 10.1.1.2, since this is the longest prefix match.
A packet destined to 192.168.10.1 is forwarded to 10.1.1.3; since this network doesn't exist in the routing table, this packet is forwarded to the default route.
A packet destined to 172.30.254.1 is dropped.
The surprising answer out of these four is the last packet, which is dropped. It's dropped because its destination, 172.30.254.1, is within a known major network, 172.30.0.0/16, but the router doesn't know about this particular subnet within that major network.
This is the essence of classful routing: If one part of a major network is known, but the subnet toward which the packet is destined within that major network is unknown, the packet is dropped.
The most confusing aspect of this rule is that the router only uses the default route if the destination major network doesn't exist in the routing table at all. However, if ip classless was configured the default route would have been used.
So there you have it. The fundamental difference between the configuration of ip classless and no ip classless is whether the default route would be used.
Summary Route to Null0 - Routing Loop Prevention
Why is that when we summarise networks we see a static summary route automatically generated to Null0?
Let's assume for a minute that we didn't have this static route automatically generated for us and consider the following example.
I have a router R1 that has subnets 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24, and 192.168.5.0/24 and I decide that R1 should advertise these routes in one summary route to its neighbour at R2 via R1s Serial0/0 interface. As I am using one summary route I could summarise them down to 192.168.0.0/21 which covers 192.168.0.0 to 192.168.7.255. I also have a default route configured on R1 which points all unmatched traffic out of Serial0/0 (ip route 0.0.0.0 0.0.0.0 Serial0/0).
Now let's say that R2 receives a packet destined for 192.168.6.1/24. It will look into its routing table and see that there is a route to 192.168.0.0/16 via R1 which is the summary route sent by R1. R2 forwards this packet to R1 and then what happens? R1 has entries for 192.168.1.0 - 192.168.5.0 in its routing table but no entry for 192.168.6.0/24. So then what does it do? Remember there is a default route configured on R1 pointing to R2 so it will forward the packet back to R2. R2 will look into its routing table and forward it back to R1 ad infinitum. What we have here is a routing loop.
This is why we have the automatically generated summary route to Null0. In our example above the IOS would have generated the following entry in our routing table:
192.168.0.0/21 is a summary, 00:00:05, Null0
Now there is a route for 192.168.6.0 to 192.168.7.255 which will go to Null0 (i.e. be dropped) instead of following the default route, and in this example, creating a routing loop. All of this could be avoided by not oversummarising.
Let's assume for a minute that we didn't have this static route automatically generated for us and consider the following example.
I have a router R1 that has subnets 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24, and 192.168.5.0/24 and I decide that R1 should advertise these routes in one summary route to its neighbour at R2 via R1s Serial0/0 interface. As I am using one summary route I could summarise them down to 192.168.0.0/21 which covers 192.168.0.0 to 192.168.7.255. I also have a default route configured on R1 which points all unmatched traffic out of Serial0/0 (ip route 0.0.0.0 0.0.0.0 Serial0/0).
Now let's say that R2 receives a packet destined for 192.168.6.1/24. It will look into its routing table and see that there is a route to 192.168.0.0/16 via R1 which is the summary route sent by R1. R2 forwards this packet to R1 and then what happens? R1 has entries for 192.168.1.0 - 192.168.5.0 in its routing table but no entry for 192.168.6.0/24. So then what does it do? Remember there is a default route configured on R1 pointing to R2 so it will forward the packet back to R2. R2 will look into its routing table and forward it back to R1 ad infinitum. What we have here is a routing loop.
This is why we have the automatically generated summary route to Null0. In our example above the IOS would have generated the following entry in our routing table:
192.168.0.0/21 is a summary, 00:00:05, Null0
Now there is a route for 192.168.6.0 to 192.168.7.255 which will go to Null0 (i.e. be dropped) instead of following the default route, and in this example, creating a routing loop. All of this could be avoided by not oversummarising.
Index
Follow the links below to find the main articles on this site:
95th Percentile - How ISPs charge
Access Lists vs Prefix Lists
Cabling Cisco devices
Calculate Multicast MAC Address
CCIE - Warm-Up Phase - BGP
CCIE - Warm-Up Phase - Multicast
CCIE - Warm-Up Phase - OSPF
CCNP Training in the UK
Enhanced Interior Gateway Protocol (EIGRP)
Frame Relay - CIR, Bc, Tc
Frame Relay - BECN/FECN
GNS3 Configuration Guide (Linux)
GNS3 Configuration Guide (Windows)
GNS3 PEMU Configuration Guide
GNS3 VPCS Configuration Guide
How to calculate a wildcard mask
"ip classless" versus "no ip classless"
MPLS Command Memoriser Review
Multicast RPF
NAT In A Nutshell
OSPF and Frame Relay
PPP Authentication - AAA
PPP Authentication - PAP and CHAP
PPPoE Server and Client
QoS - Bandwidth, Bandwidth Percent, Bandwidth Remaining Percent
RIP - Routing Information Protocol
RIP - Adjusting timers
Route Maps and Access Lists
Route Summarization - Easy Networks
Route Summarization - Complex Networks
Summary Route to Null 0 - Routing Loop Prevention
Subnetting Made Easy - Critically Acclaimed!
VLAN Trunking - Which combination forms a trunk?
Vyatta on VM Workstation
95th Percentile - How ISPs charge
Access Lists vs Prefix Lists
Cabling Cisco devices
Calculate Multicast MAC Address
CCIE - Warm-Up Phase - BGP
CCIE - Warm-Up Phase - Multicast
CCIE - Warm-Up Phase - OSPF
CCNP Training in the UK
Enhanced Interior Gateway Protocol (EIGRP)
Frame Relay - CIR, Bc, Tc
Frame Relay - BECN/FECN
GNS3 Configuration Guide (Linux)
GNS3 Configuration Guide (Windows)
GNS3 PEMU Configuration Guide
GNS3 VPCS Configuration Guide
How to calculate a wildcard mask
"ip classless" versus "no ip classless"
MPLS Command Memoriser Review
Multicast RPF
NAT In A Nutshell
OSPF and Frame Relay
PPP Authentication - AAA
PPP Authentication - PAP and CHAP
PPPoE Server and Client
QoS - Bandwidth, Bandwidth Percent, Bandwidth Remaining Percent
RIP - Routing Information Protocol
RIP - Adjusting timers
Route Maps and Access Lists
Route Summarization - Easy Networks
Route Summarization - Complex Networks
Summary Route to Null 0 - Routing Loop Prevention
Subnetting Made Easy - Critically Acclaimed!
VLAN Trunking - Which combination forms a trunk?
Vyatta on VM Workstation
Monday, 8 June 2009
RIP - Routing Information Protocol
Whether you are taking ICND1, CCNA, CCNP, CCDA, CCIE etc you should all know about RIP. It is very rare for me to come across RIP in my day-to-day work hence I tend to forget some of the nuances behind it. I will focus on RIPv2 but will touch upon RIPv1 in terms of comparison.
Metric
RIP is a distance vector protocol which uses the notion of hop counts as its metric with any one router up to a maximum of 15 hops away from another router. What this means is that if there is a network that is 16 hops or more away from your RIP router and your entire routing domain is running RIP you won't be able to reach that network. It therefore means that RIP is not suitable for large networks. RIPv1 and v2 both use the same maximum hop count as their metric.
Classful and Classless behaviour
RIPv1 is classful and RIPv2 is classless. What this means in very simple terms is that RIPv1 does not send the subnet mask in its routing updates whereas RIPv2 does and as such RIPv2 supports Variable Length Subnet Masks. If a router running RIPv1 has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen with RIPv2 as you can issue the no auto-summary command under the routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to discontiguous networks which is a fancy name for a class of network that has another class of network in between, for example:
(Class A)R1(Class B)-->(Class B)R2(Class B)-->(Class B)R3(Class A)
Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.
A point that is often overlooked with RIP is the behaviour when the same class of address is used throughout. If my router had an interface with a Class A address but with a non-Class A subnet mask (e.g. 10.1.2.0/24) and I received an update about 10.1.3.0/24 through that interface, the RIP router would assume that it should apply the mask configured on that interface (i.e. a /24) and not the default Class A mask of /8.
Basic Configuration
Always advertise the classful network so if you want to advertise 10.1.2.0 you only need to specify 10.0.0.0 in the network command.
conf t
router rip
version 2 <--RIPv2 enabled
network 10.0.0.0
no auto-summary <--turn off automatic summarisation (I do this as a matter of course)
What does the network command tell the router to do? In RIP it tells the router to do three things:
1. Advertise all networks that form part of the subnet specified
2. It tells the router to listen to RIP updates on the interfaces with IP addresses in that configured subnet.
3. It tells the router to send RIP updates out of the interfaces with IP addresses in that configured subnet.
Passive Interface
The passive-interface command tells a router's interface to stop sending updates out of that interface. Note here that the interface will still receive RIP updates because it never forms neighbour adjacencies, and just receives information from other RIP routers.
router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0
Be aware that you can make all interfaces passive by issuing the passive-interface default command. This might be desirable when you want all interfaces except one from sending updates. For example, you may only want fa0/0 sending RIP updates so you make every interface passive by default and then issue the no passive-interface [interface] command:
router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface default <--stops RIP updates from being sent out of all interfaces
no passive-interface FastEthernet0/0 <--allows RIP updates to be sent out of that interface
How do we stop updates from being received?
As we have seen the passive-interface command tells our router to not send RIP updates out of the specified interface but that same interface can still receive RIP updates. In order to prevent updates from being received you should use something called a distribute-list. A distribute-list filters out routes from entering the routing table by referencing a pre-configured access-list or prefix-list.
For example, let's create an access-list:
access-list 1 permit any
The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:
distribute-list [access-list-number_or_access-list-name] [in | out] [interface]
If there is a match with a deny statement in the access-list then that route is filtered out of the routing update. If you look at my access-list you will see that I am, in effect, matching everything in my access-list so all routes should be filtered out.
Using the earlier configuration example, I will use a distribute-list to stop updates being received on fa0/0 and passive-interface from sending updates out of fa0/0.
access-list 1 deny any
router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
You could replace the passive-interface command with a distribute-list. To do this make sure your access-list permits everything as in my preconfigured ACL 1 and apply it outbound on the outgoing interface:
access-list 1 permit any
router rip
version 2
network 10.0.0.0
no auto-summary
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
distribute-list 1 out FastEthernet0/0 <--filter outgoing updates on fa0/0 as specified by ACL 1
Administrative Distance (AD)
RIP has an AD of 120. Cisco uses AD as a measure of trustworthiness about a certain route. If there are two routes to the same network learnt by different routing protocols then the AD is used as a tiebreaker. The routing protocol with the lowest AD is considered to be more trustworthy and the route learned from that routing protocol will be installed into the routing table. Below are some of the ADs of static routing and routing protocols:
Connected Interface = 0
Static route = 1
EIGRP Summary = 5
eBGP = 20
Internal EIGRP = 90
IGRP = 100
OSPF = 110
ISIS = 115
RIP = 120
EGP = 140
ODR = 160
External EIGRP = 170
iBGP = 200
Unknown = 255
Looking at those ADs, RIP is not a terribly trusted protocol and equivalent routes learned by static, eBGP, Internal EIGRP, IGRP, OSPF, and ISIS would be installed in the routing table before a RIP route. Of course you can change the AD of a routing protocol by issuing the distance command under the routing process:
router rip
version 2
distance 90
Interestingly if you set the distance to 255 no routes learned by that routing protocol will be installed in the routing table.
Sending Updates
RIPv1 broadcasts its routing updates to 255.255.255.255 whereas RIPv2 multicasts its updates to 224.0.0.9. Both use UDP Port 520 at the Transport Layer. A router's full routing table is sent every 30 seconds to the IP address above depending on whether v1 or v2 is used. There are also triggered updates which are sent when a route in a router's routing table changes.
When a router sends its update it adds 1 to the metric of each route it is advertising so that receiving routers know the metric to get to that route. For example, if a router had a route to 192.168.1.0/24 with a metric of 2 , it would advertise it with a metric of 3.
Sending and Receiving version on interfaces
By default a RIP router will send only v1 updates out of an interface but receive both v1 and v2 updates. This allows for a mix of v1 and v2 capable routers. If your router is running RIPv2 it can only send and receive v2 updates only. You can configure it yourself under an interface:
interface Fastethernet0/0
ip rip receive version [1 | 2 | 1 2]
ip rip send version [1 | 2 | 1 2]
Timers
It is worth fully understanding how the timers in RIP work and what their default values are. They are:
Update Timer = 30 seconds
Invalid Timer = 180 seconds
Holddown Timer = 180 seconds
Flush Timer = 240 seconds
When a route is learned via RIP the Invalid and Flush timers are started for that route and are reset when that route is learned again. In normal operation this should be every 30 seconds as the router that has advertised this route should be sending their update every 30 seconds as dictated by the Update Timer. If there is a failure in the network that stops updates about this route from being received from the original advertising router, the Invalid and Flush timers will count up over 30 seconds towards 180 and 240 seconds respectively. If during that time our router learns the same route but from a different source and it has a worse metric (i.e. the hop count is greater than our current route) it won't install that update in its routing table until the original route is flushed. Once the Invalid Timer reaches 180 seconds the Holddown Timer starts counting down from 180 seconds with the Flush Timer only having 60 seconds left as it has already been running for 180 seconds. The route in the routing table will now show something like this:
R 192.168.1.0/24 is possibly down
Whichever is the first out of the Holddown and Flush timers to expire will cause the route to be removed/flushed from the routing table. By default this will always be the Flush timer as it has only 60 seconds left to elapse once the Invalid Timer reaches 180 seconds. Your router can now install previously heard updates that originally had a worse metric once those updates have been received again. You can quickly see why RIP has slow convergence time and would have to wait 240 seconds for the old route to be flushed and could wait for another 30 seconds to receive an update if one exists. That's 270 seconds, or three and a half minutes, which is bloody slow and it could be longer! You can adjust your timers using the timers basic update invalid holddown flush under the routing process:
router rip
version 2
timers basic 30 90 120 120
This sets the Update Timer to 30 seconds, Invalid Timer to 90 seconds, and both the Flush and Holddown Timers to 120 seconds.
Neighbour relationship
RIP has absolutely no concept of neighbours. It simply listens to updates from other routers and it never, ever, ever, sends Hellos, ok? This is what is meant when you hear the term "routing by rumour".
Split Horizon
Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 a RIP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the no ip split-horizon command under an interface:
interface FastEthernet0/0
no ip split-horizon
Interestingly there is a special case where Split Horizon is overridden and that is called Poison Reverse. This is where a router receives an update on an interface specifying that a route is down, as indicated by a hop count of 16 (known as route poisoning), and the receiving router sends that update back out of the same interface. If you run a debug on RIP (debug ip rip) you will see Poison Reverse in action with a line of:
RIP: sending v2 flash update to 224.0.0.9
These flash updates are also seen in triggered updates.
Authentication
RIPv2 allows for passwords to be exchanged between RIP routers to secure updates and stop rogue RIP routers from being deployed in a network and disrupting it.
By default, RIP passwords are sent in plain-text but you can configure it to use MD5 which I would highly recommend if your network is susceptible to eavesdropping. In fact I would do it as a matter of course. As you would expect, the passwords on both sides must match in order for the RIP updates to be successfully exchanged.
You configure the passwords in global configuration mode using key-chains which are made up of keys which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen here):
key-chain MyKeyChain
key 1
key MyPassword
To turn RIP authentication on you must configure it under the interface which will be sending the updates:
int fa0/0
ip rip authentication key-chain [key-chain-name]
So for my example it would be:
int fa0/0
ip rip authentication key-chain MyKeyChain
If you want to send your passwords in plain-text that is all there is to it as you remember RIP defaults to using plain-text passwords. You can specifically tell RIP to send passwords as plain-text by issuing the ip rip authentication mode text command under your outgoing interface as in:
int fa0/0
ip rip authentication mode text
ip rip authentication key-chain MyKeyChain
If you want to use MD5 instead then guess what one word needs to change in the example above? Yes, you've got it, replace the word "text" with "md5" as in:
int fa0/0
ip rip authentication mode md5
ip rip authentication key-chain MyKeyChain
Remember you have to explicitly set the authentication mode to MD5 as RIP defaults to using plain-text passwords.
Changing the next-hop router
Did you know that a RIP router can send updates about a route and change the next-hop router? As you would imagine, if a router, say R1, was to learn a route from R2, R1 would use R2 as the next-hop. R2, however, could conceivably change the next-hop from itself to another router.
In RIPv2, each RIP entry includes a space where an explicit IP address can be entered as the next hop router for datagrams intended for the network in that entry. This feature can help improve efficiency of routing by eliminating unnecessary extra hops for packets sent to certain destinations.
One common use of this field is when the most efficient route to a network is through a router that is not running RIP. Such a router will not exchange RIP messages and would therefore not normally be selected by RIP routers as a next hop for any network. The explicit Next Hop field allows the router to be selected as the next hop regardless of this situation.
The Next-Hop field is changed by using route-maps.
Using Offset Lists to change RIP's metric for a particular route
You change the metric received or advertised in RIP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:
offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]
Let's look at an example:
R1 has a route for 192.168.1.0/24 with a hop count of 0 as it is directly connected. We want to advertise that route to R2 with a hop count of 2. Remember that a RIP router will advertise out its hop count + 1 to other RIP routers so R2 would ordinarily receive a hop count of 1 to reach 192.168.1.0/24 via R1. Let's configure our offset-list:
access-list 1 permit 192.168.1.0 0.0.0.255
router rip
offset-list 1 out 1 FastEthernet0/0
Here offset-list 1 specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by out. We add 1 to the metric of all routes matched by our access-list as specified by the 1 after the out keyword. Finally we specify the interface out of which our offset-list is applied.
Clearing RIP routes from the routing table to speed up convergence
As RIP has no concept of neighbours you can simply issue the clear ip route * command from privileged mode. This will clear out all routes and cause the router to send out RIP request packets. This wouldn't work with a routing protocol that has neighbours such as EIGRP as the routes are promoted to the routing table from the topology table. In that case you would have to tear down the neighbour adjacency.
Conclusion
I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on RIP. I hope I've got enough detail in here for you to understand the basic operation of RIP and some of the extras that can be configured.
As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.
Good luck with your studies!
Metric
RIP is a distance vector protocol which uses the notion of hop counts as its metric with any one router up to a maximum of 15 hops away from another router. What this means is that if there is a network that is 16 hops or more away from your RIP router and your entire routing domain is running RIP you won't be able to reach that network. It therefore means that RIP is not suitable for large networks. RIPv1 and v2 both use the same maximum hop count as their metric.
Classful and Classless behaviour
RIPv1 is classful and RIPv2 is classless. What this means in very simple terms is that RIPv1 does not send the subnet mask in its routing updates whereas RIPv2 does and as such RIPv2 supports Variable Length Subnet Masks. If a router running RIPv1 has a different class of address on two interfaces (e.g. a Class A address on one interface and a Class B address on another interface) an update going out of the Class B interface will automatically summarise the Class A networks in that update to the default mask of /8. For example, the router may have learned about 10.1.2.0/24 on one interface but because it is advertising that network out of an interface with a different class of address it would advertise it as 10.0.0.0/8. This doesn't happen with RIPv2 as you can issue the no auto-summary command under the routing process and the router will advertise 10.128.1.0/24. This is especially important when it comes to discontiguous networks which is a fancy name for a class of network that has another class of network in between, for example:
(Class A)R1(Class B)-->(Class B)R2(Class B)-->(Class B)R3(Class A)
Here R2 could learn a route to 10.0.0.0/8 from both R1 and R3 as both R1 and R3 would have automatically summarised the Class A address to a /8.
A point that is often overlooked with RIP is the behaviour when the same class of address is used throughout. If my router had an interface with a Class A address but with a non-Class A subnet mask (e.g. 10.1.2.0/24) and I received an update about 10.1.3.0/24 through that interface, the RIP router would assume that it should apply the mask configured on that interface (i.e. a /24) and not the default Class A mask of /8.
Basic Configuration
Always advertise the classful network so if you want to advertise 10.1.2.0 you only need to specify 10.0.0.0 in the network command.
conf t
router rip
version 2 <--RIPv2 enabled
network 10.0.0.0
no auto-summary <--turn off automatic summarisation (I do this as a matter of course)
What does the network command tell the router to do? In RIP it tells the router to do three things:
1. Advertise all networks that form part of the subnet specified
2. It tells the router to listen to RIP updates on the interfaces with IP addresses in that configured subnet.
3. It tells the router to send RIP updates out of the interfaces with IP addresses in that configured subnet.
Passive Interface
The passive-interface command tells a router's interface to stop sending updates out of that interface. Note here that the interface will still receive RIP updates because it never forms neighbour adjacencies, and just receives information from other RIP routers.
router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0
Be aware that you can make all interfaces passive by issuing the passive-interface default command. This might be desirable when you want all interfaces except one from sending updates. For example, you may only want fa0/0 sending RIP updates so you make every interface passive by default and then issue the no passive-interface [interface] command:
router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface default <--stops RIP updates from being sent out of all interfaces
no passive-interface FastEthernet0/0 <--allows RIP updates to be sent out of that interface
How do we stop updates from being received?
As we have seen the passive-interface command tells our router to not send RIP updates out of the specified interface but that same interface can still receive RIP updates. In order to prevent updates from being received you should use something called a distribute-list. A distribute-list filters out routes from entering the routing table by referencing a pre-configured access-list or prefix-list.
For example, let's create an access-list:
access-list 1 permit any
The syntax of a distribute-list when using an access-list is as follows and is configured under the routing process:
distribute-list [access-list-number_or_access-list-name] [in | out] [interface]
If there is a match with a deny statement in the access-list then that route is filtered out of the routing update. If you look at my access-list you will see that I am, in effect, matching everything in my access-list so all routes should be filtered out.
Using the earlier configuration example, I will use a distribute-list to stop updates being received on fa0/0 and passive-interface from sending updates out of fa0/0.
access-list 1 deny any
router rip
version 2
network 10.0.0.0
no auto-summary
passive-interface FastEthernet0/0 <--stops RIP sending updates out of fa0/0
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
You could replace the passive-interface command with a distribute-list. To do this make sure your access-list permits everything as in my preconfigured ACL 1 and apply it outbound on the outgoing interface:
access-list 1 permit any
router rip
version 2
network 10.0.0.0
no auto-summary
distribute-list 1 in FastEthernet0/0 <--filter incoming updates on fa0/0 as specified by ACL 1
distribute-list 1 out FastEthernet0/0 <--filter outgoing updates on fa0/0 as specified by ACL 1
Administrative Distance (AD)
RIP has an AD of 120. Cisco uses AD as a measure of trustworthiness about a certain route. If there are two routes to the same network learnt by different routing protocols then the AD is used as a tiebreaker. The routing protocol with the lowest AD is considered to be more trustworthy and the route learned from that routing protocol will be installed into the routing table. Below are some of the ADs of static routing and routing protocols:
Connected Interface = 0
Static route = 1
EIGRP Summary = 5
eBGP = 20
Internal EIGRP = 90
IGRP = 100
OSPF = 110
ISIS = 115
RIP = 120
EGP = 140
ODR = 160
External EIGRP = 170
iBGP = 200
Unknown = 255
Looking at those ADs, RIP is not a terribly trusted protocol and equivalent routes learned by static, eBGP, Internal EIGRP, IGRP, OSPF, and ISIS would be installed in the routing table before a RIP route. Of course you can change the AD of a routing protocol by issuing the distance command under the routing process:
router rip
version 2
distance 90
Interestingly if you set the distance to 255 no routes learned by that routing protocol will be installed in the routing table.
Sending Updates
RIPv1 broadcasts its routing updates to 255.255.255.255 whereas RIPv2 multicasts its updates to 224.0.0.9. Both use UDP Port 520 at the Transport Layer. A router's full routing table is sent every 30 seconds to the IP address above depending on whether v1 or v2 is used. There are also triggered updates which are sent when a route in a router's routing table changes.
When a router sends its update it adds 1 to the metric of each route it is advertising so that receiving routers know the metric to get to that route. For example, if a router had a route to 192.168.1.0/24 with a metric of 2 , it would advertise it with a metric of 3.
Sending and Receiving version on interfaces
By default a RIP router will send only v1 updates out of an interface but receive both v1 and v2 updates. This allows for a mix of v1 and v2 capable routers. If your router is running RIPv2 it can only send and receive v2 updates only. You can configure it yourself under an interface:
interface Fastethernet0/0
ip rip receive version [1 | 2 | 1 2]
ip rip send version [1 | 2 | 1 2]
Timers
It is worth fully understanding how the timers in RIP work and what their default values are. They are:
Update Timer = 30 seconds
Invalid Timer = 180 seconds
Holddown Timer = 180 seconds
Flush Timer = 240 seconds
When a route is learned via RIP the Invalid and Flush timers are started for that route and are reset when that route is learned again. In normal operation this should be every 30 seconds as the router that has advertised this route should be sending their update every 30 seconds as dictated by the Update Timer. If there is a failure in the network that stops updates about this route from being received from the original advertising router, the Invalid and Flush timers will count up over 30 seconds towards 180 and 240 seconds respectively. If during that time our router learns the same route but from a different source and it has a worse metric (i.e. the hop count is greater than our current route) it won't install that update in its routing table until the original route is flushed. Once the Invalid Timer reaches 180 seconds the Holddown Timer starts counting down from 180 seconds with the Flush Timer only having 60 seconds left as it has already been running for 180 seconds. The route in the routing table will now show something like this:
R 192.168.1.0/24 is possibly down
Whichever is the first out of the Holddown and Flush timers to expire will cause the route to be removed/flushed from the routing table. By default this will always be the Flush timer as it has only 60 seconds left to elapse once the Invalid Timer reaches 180 seconds. Your router can now install previously heard updates that originally had a worse metric once those updates have been received again. You can quickly see why RIP has slow convergence time and would have to wait 240 seconds for the old route to be flushed and could wait for another 30 seconds to receive an update if one exists. That's 270 seconds, or three and a half minutes, which is bloody slow and it could be longer! You can adjust your timers using the timers basic update invalid holddown flush under the routing process:
router rip
version 2
timers basic 30 90 120 120
This sets the Update Timer to 30 seconds, Invalid Timer to 90 seconds, and both the Flush and Holddown Timers to 120 seconds.
Neighbour relationship
RIP has absolutely no concept of neighbours. It simply listens to updates from other routers and it never, ever, ever, sends Hellos, ok? This is what is meant when you hear the term "routing by rumour".
Split Horizon
Split Horizon stops a network being advertised out of an interface in which it has been learned. For example, if a router learned about network 192.168.1.0/24 on fa0/0 a RIP routing update out of fa0/0 would not contain 192.168.1.0/24. This is to prevent routing loops from occurring. Split Horizon is enabled by default on all interfaces except Frame Relay interfaces where the IP address is configured on the physical interface. You can turn off Split Horizon on an interface by issuing the no ip split-horizon command under an interface:
interface FastEthernet0/0
no ip split-horizon
Interestingly there is a special case where Split Horizon is overridden and that is called Poison Reverse. This is where a router receives an update on an interface specifying that a route is down, as indicated by a hop count of 16 (known as route poisoning), and the receiving router sends that update back out of the same interface. If you run a debug on RIP (debug ip rip) you will see Poison Reverse in action with a line of:
RIP: sending v2 flash update to 224.0.0.9
These flash updates are also seen in triggered updates.
Authentication
RIPv2 allows for passwords to be exchanged between RIP routers to secure updates and stop rogue RIP routers from being deployed in a network and disrupting it.
By default, RIP passwords are sent in plain-text but you can configure it to use MD5 which I would highly recommend if your network is susceptible to eavesdropping. In fact I would do it as a matter of course. As you would expect, the passwords on both sides must match in order for the RIP updates to be successfully exchanged.
You configure the passwords in global configuration mode using key-chains which are made up of keys which in turn have the password configured on them with optional send and receive lifetimes. Let's configure a basic key-chain (more advanced configuration can be seen here):
key-chain MyKeyChain
key 1
key MyPassword
To turn RIP authentication on you must configure it under the interface which will be sending the updates:
int fa0/0
ip rip authentication key-chain [key-chain-name]
So for my example it would be:
int fa0/0
ip rip authentication key-chain MyKeyChain
If you want to send your passwords in plain-text that is all there is to it as you remember RIP defaults to using plain-text passwords. You can specifically tell RIP to send passwords as plain-text by issuing the ip rip authentication mode text command under your outgoing interface as in:
int fa0/0
ip rip authentication mode text
ip rip authentication key-chain MyKeyChain
If you want to use MD5 instead then guess what one word needs to change in the example above? Yes, you've got it, replace the word "text" with "md5" as in:
int fa0/0
ip rip authentication mode md5
ip rip authentication key-chain MyKeyChain
Remember you have to explicitly set the authentication mode to MD5 as RIP defaults to using plain-text passwords.
Changing the next-hop router
Did you know that a RIP router can send updates about a route and change the next-hop router? As you would imagine, if a router, say R1, was to learn a route from R2, R1 would use R2 as the next-hop. R2, however, could conceivably change the next-hop from itself to another router.
In RIPv2, each RIP entry includes a space where an explicit IP address can be entered as the next hop router for datagrams intended for the network in that entry. This feature can help improve efficiency of routing by eliminating unnecessary extra hops for packets sent to certain destinations.
One common use of this field is when the most efficient route to a network is through a router that is not running RIP. Such a router will not exchange RIP messages and would therefore not normally be selected by RIP routers as a next hop for any network. The explicit Next Hop field allows the router to be selected as the next hop regardless of this situation.
The Next-Hop field is changed by using route-maps.
Using Offset Lists to change RIP's metric for a particular route
You change the metric received or advertised in RIP by using an offset-list. This is very similar in configuration to distribute-lists where you reference an access-list. The access-list will be checked against sent or received updates and the specified offset added to the metric. The basic syntax is:
offset-list [access-list-number_or_access-list-name] [in | out] [specified-offset] [interface]
Let's look at an example:
R1 has a route for 192.168.1.0/24 with a hop count of 0 as it is directly connected. We want to advertise that route to R2 with a hop count of 2. Remember that a RIP router will advertise out its hop count + 1 to other RIP routers so R2 would ordinarily receive a hop count of 1 to reach 192.168.1.0/24 via R1. Let's configure our offset-list:
access-list 1 permit 192.168.1.0 0.0.0.255
router rip
offset-list 1 out 1 FastEthernet0/0
Here offset-list 1 specifies ACL 1 which will match 192.168.1.0/24. This is applied outbound as specified by out. We add 1 to the metric of all routes matched by our access-list as specified by the 1 after the out keyword. Finally we specify the interface out of which our offset-list is applied.
Clearing RIP routes from the routing table to speed up convergence
As RIP has no concept of neighbours you can simply issue the clear ip route * command from privileged mode. This will clear out all routes and cause the router to send out RIP request packets. This wouldn't work with a routing protocol that has neighbours such as EIGRP as the routes are promoted to the routing table from the topology table. In that case you would have to tear down the neighbour adjacency.
Conclusion
I've tried to be as brief as possible as I don't see the point of reinventing the wheel as there are so many quality papers on RIP. I hope I've got enough detail in here for you to understand the basic operation of RIP and some of the extras that can be configured.
As always, if you have any questions about this topic please feel free to leave a comment and/or email me using the Contact Me tab at the top of the screen.
Good luck with your studies!
Sunday, 7 June 2009
Route Maps and Access-Lists
I received an email from one of the readers, Joel, who is getting confused as to how access-lists and route-maps work together. I have therefore created this topic to cover the very basics of access-lists and how they link into route-maps. In turn I have expanded the lesson on route-maps to cover a little more of the nuances of route-map theory as well as an aid to other readers.
Access-lists contain very simple logic. Lists 1-99 (standard access-lists) will permit or deny all IP traffic from a particular source whereas access-lists 101-199 (extended access-lists) extend this functionality allowing you to permit/deny with more granularity, for example, specifying both source and destination address, Layer 4 protocols and port number (i.e. TCP/UDP), and Layer 3 protocols other than IP (i.e. ICMP).
The syntax for standard access-lists is as follows:
"I wish to permit all IP traffic from host [host-ip-address]"
"I wish to permit all traffic from [subnet] [wildcard-mask]"
"I wish to deny all IP traffic from host [host-ip-address]"
"I wish to deny all traffic from [subnet] [wildcard-mask]"
An example is you want to allow all IP traffic from 192.168.1.0/24. The access-list is simple:
access-list [1-99] permit 192.168.1.0 0.0.0.255
The syntax for extended access-lists is slightly different:
"I wish to [permit/deny] [type-of-traffic] going from [source-address] [source-wildcard-mask] to [destination-address] [destination-wildcard-mask] [optional port-number]"
Let's say you would like to permit all Telnet traffic going from 192.168.1.0/24 to a device at 192.168.2.1.
Telnet uses TCP port 23 and here is how you would write the extended access-list:
"access-list [101-199] permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23"
In English, this access-list permits TCP from 192.168.1.0/24 to the host whose address is 192.168.2.1 where the TCP port number is 23.
How to apply access-lists to route-maps
Believe me there is nothing tricky about doing this. A route-map is a way of influencing the routing decision made by a routing device. The basic syntax of a route-map is as follows:
route-map [route-map-name] [permit/deny] [sequence-number]
match [condition]
set [what-you-want-to-do-with-the-packet-if-it-matches-the-match-criteria]
As you build up your route-map you simply increase the sequence number for each match you want to do. Once you have created your route-map you must then apply it to a router interface e.g.
int fa0/0
ip policy route-map [route-map-name] [in/out]
Let's step back up to the match criteria. There are a number of things that we can match on but what we will focus on is how we can influence traffic flows through a router. We do this by using the match ip address [access-list-number] command. The extended access-list in my earlier example called for allowing Telnet traffic from 192.168.1.0/24 to be able to reach host 192.168.2.1. Let's take that example a bit further and say that we want to make all Telnet traffic going from 192.168.1.0/24 to host 192.168.2.1 which has entered my router's fa0/0 interface to leave my router's Serial0/0 interface. We could use that access-list and apply it to our route-map (I've called it MYMAP):
access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23
route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0
int fa0/0
ip policy route-map MYMAP in <---applies the MYMAP route-map inbound on fa0/0
How does the router service the route-map?
Actually it is very logical. The router starts at the lowest sequence number until it finds a match.
So let's run through it. A host at 192.168.1.1 tries to Telnet to 192.168.2.1 and the packet is received on fa0/0 of our router. Our router, looking at fa0/0, realises that policy-based routing is required and that it should look at the route-map named MYMAP in order to make a decision on how to forward the traffic. The router starts at the lowest sequence number in the route-map and checks the match criteria. The example above tells the router to check access-list 101. The packet received matches access-list 101 so the router returns to the route-map and checks what the set command tells it to do. The set command tells it to forward this traffic out of Serial0/0
What if there is no match found?
If there is no match then the router will route the packet based on the contents of the routing table. If a host at 192.168.3.1 tried to Telnet to 192.168.2.1 and the packet is received through fa0/0 of our router, the router will look into MYMAP, then at access-list 101, realise that access-list 101 does not match 192.168.3.1 as a source address and will return to the route-map looking for the next highest sequence number. In our example there is not another sequence number so the router will simply forward the traffic based upon the contents of its routing table (i.e. what it would do if there was no route-map applied to the fa0/0 interface).
How could we use route-maps to drop traffic?
Chris, you've just told us that if no match is found then the packet will be forwarded by the contents of the routing table so how can I influence that?
Generally, you would drop traffic on an interface using an access-list applied directly to the interface, however, it can be done using a route-map. Let's say you want to have control over all traffic coming in on fa0/0 of our router and want to drop anything that doesn't match our defined criteria. Let's say I have created access-lists 101-105 which specifies my criteria. My route-map would look as follows:
route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0
route-map MYMAP permit 20
match ip address 102 <---this line refers to access-list 102
set interface Serial0/1
route-map MYMAP permit 30
match ip address 103 <---this line refers to access-list 103
set interface Serial0/2
route-map MYMAP permit 40
match ip address 104 <---this line refers to access-list 104
set interface Serial0/3
route-map MYMAP permit 50
match ip address 105 <---this line refers to access-list 105
set interface Serial0/4
Now I want to deny everything else. Remember the Null0 interface, what I like to call Packet Heaven (as that is where packets that need to be dropped/die go)? Check this route-map statement out:
route-map MYMAP permit 60
set interface Null0
Whoa Chris! What did you do there? Where has the match statement gone? The beauty is you don't need it. Sure, you could configure an access-list (e.g. access-list 106 permit ip any any) and have:
route-map MYMAP permit 60
match ip address 106
set interface Null0
But there really is no need. If the route-map evaluation has got this far we are just saying "drop everything else, send it to Packet Heaven, Null0". By removing the match statement you are in effect creating a catch-all statement. Equally, you may have wanted all traffic not matching access-lists 101-105 to be routed out of Serial0/5 rather than be routed using the routing table or dropped. Your last route-map clause would have been:
route-map MYMAP permit 60
set interface Serial0/5 <-- all traffic not previously matched will go via Serial0/5
Other Key Points About Route-Maps
1. The route map statements can also be marked with a deny. If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (in other words, destination-based routing is performed). Only if the statement is marked as permit and the packets meet the match criteria are all the set clauses applied. If the statement is marked as permit and the packets do not meet the match criteria, then those packets are also forwarded through the normal routing channel.
2. There can be multiple match criteria on the same line where only ONE of the criteria has to match. There can be multiple match statements on different lines where ALL match statements must match. I think an example here is in order:
route-map MYMAP permit 10
match ip address 101 102 103 104
match ip address 105
set interface Serial0/0
The logic here works thus:
match ip address 101 OR 102 OR 103 OR 104
AND
match ip address 105
So a packet comes in and matches access-list 104, the router then goes on to check access-list 105. If the received packet also matches access-list 105 then the set command is used. If the packet had failed to match access-list 105 then the next statement in the route-map would be evaluated or the packet would be forwarded normally.
3. There are other match criteria such as packet length but I'll focus on the other set criteria.
set ip next-hop [next-hop-ip-address] - specifies where to send the packet. Preferable to use this rather than exit interface.
set default interface [interface] - If there is no entry in the routing table for the destination of this packet route it through the specified interface
set default ip next-hop [next-hop-ip-address] - if there is no entry in the routing table for the destination of this packet route it via the specified next-hop
Notice the use of the "default". This is only true if there is no corresponding entry in the routing table.
4. Like match statements, you can have multiple set statements too. Again, an example will help illustrate this.
route-map MYMAP permit 10
match ip address 101
set interface Serial0/0 Serial0/1
By default any matches to access-list 101 will exit Serial0/0 but if that fails Serial0/1 will be used as the exit interface.
Conclusion
Like everything, route-maps are easy once you understand how the syntax works. Any questions or feedback please feel free to leave comments and/or email me using the Contact Me tab at the top of the screen. Good luck to you all in your studies!
Access-lists contain very simple logic. Lists 1-99 (standard access-lists) will permit or deny all IP traffic from a particular source whereas access-lists 101-199 (extended access-lists) extend this functionality allowing you to permit/deny with more granularity, for example, specifying both source and destination address, Layer 4 protocols and port number (i.e. TCP/UDP), and Layer 3 protocols other than IP (i.e. ICMP).
The syntax for standard access-lists is as follows:
"I wish to permit all IP traffic from host [host-ip-address]"
"I wish to permit all traffic from [subnet] [wildcard-mask]"
"I wish to deny all IP traffic from host [host-ip-address]"
"I wish to deny all traffic from [subnet] [wildcard-mask]"
An example is you want to allow all IP traffic from 192.168.1.0/24. The access-list is simple:
access-list [1-99] permit 192.168.1.0 0.0.0.255
The syntax for extended access-lists is slightly different:
"I wish to [permit/deny] [type-of-traffic] going from [source-address] [source-wildcard-mask] to [destination-address] [destination-wildcard-mask] [optional port-number]"
Let's say you would like to permit all Telnet traffic going from 192.168.1.0/24 to a device at 192.168.2.1.
Telnet uses TCP port 23 and here is how you would write the extended access-list:
"access-list [101-199] permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23"
In English, this access-list permits TCP from 192.168.1.0/24 to the host whose address is 192.168.2.1 where the TCP port number is 23.
How to apply access-lists to route-maps
Believe me there is nothing tricky about doing this. A route-map is a way of influencing the routing decision made by a routing device. The basic syntax of a route-map is as follows:
route-map [route-map-name] [permit/deny] [sequence-number]
match [condition]
set [what-you-want-to-do-with-the-packet-if-it-matches-the-match-criteria]
As you build up your route-map you simply increase the sequence number for each match you want to do. Once you have created your route-map you must then apply it to a router interface e.g.
int fa0/0
ip policy route-map [route-map-name] [in/out]
Let's step back up to the match criteria. There are a number of things that we can match on but what we will focus on is how we can influence traffic flows through a router. We do this by using the match ip address [access-list-number] command. The extended access-list in my earlier example called for allowing Telnet traffic from 192.168.1.0/24 to be able to reach host 192.168.2.1. Let's take that example a bit further and say that we want to make all Telnet traffic going from 192.168.1.0/24 to host 192.168.2.1 which has entered my router's fa0/0 interface to leave my router's Serial0/0 interface. We could use that access-list and apply it to our route-map (I've called it MYMAP):
access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 23
route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0
int fa0/0
ip policy route-map MYMAP in <---applies the MYMAP route-map inbound on fa0/0
How does the router service the route-map?
Actually it is very logical. The router starts at the lowest sequence number until it finds a match.
So let's run through it. A host at 192.168.1.1 tries to Telnet to 192.168.2.1 and the packet is received on fa0/0 of our router. Our router, looking at fa0/0, realises that policy-based routing is required and that it should look at the route-map named MYMAP in order to make a decision on how to forward the traffic. The router starts at the lowest sequence number in the route-map and checks the match criteria. The example above tells the router to check access-list 101. The packet received matches access-list 101 so the router returns to the route-map and checks what the set command tells it to do. The set command tells it to forward this traffic out of Serial0/0
What if there is no match found?
If there is no match then the router will route the packet based on the contents of the routing table. If a host at 192.168.3.1 tried to Telnet to 192.168.2.1 and the packet is received through fa0/0 of our router, the router will look into MYMAP, then at access-list 101, realise that access-list 101 does not match 192.168.3.1 as a source address and will return to the route-map looking for the next highest sequence number. In our example there is not another sequence number so the router will simply forward the traffic based upon the contents of its routing table (i.e. what it would do if there was no route-map applied to the fa0/0 interface).
How could we use route-maps to drop traffic?
Chris, you've just told us that if no match is found then the packet will be forwarded by the contents of the routing table so how can I influence that?
Generally, you would drop traffic on an interface using an access-list applied directly to the interface, however, it can be done using a route-map. Let's say you want to have control over all traffic coming in on fa0/0 of our router and want to drop anything that doesn't match our defined criteria. Let's say I have created access-lists 101-105 which specifies my criteria. My route-map would look as follows:
route-map MYMAP permit 10
match ip address 101 <---this line refers to access-list 101
set interface Serial0/0
route-map MYMAP permit 20
match ip address 102 <---this line refers to access-list 102
set interface Serial0/1
route-map MYMAP permit 30
match ip address 103 <---this line refers to access-list 103
set interface Serial0/2
route-map MYMAP permit 40
match ip address 104 <---this line refers to access-list 104
set interface Serial0/3
route-map MYMAP permit 50
match ip address 105 <---this line refers to access-list 105
set interface Serial0/4
Now I want to deny everything else. Remember the Null0 interface, what I like to call Packet Heaven (as that is where packets that need to be dropped/die go)? Check this route-map statement out:
route-map MYMAP permit 60
set interface Null0
Whoa Chris! What did you do there? Where has the match statement gone? The beauty is you don't need it. Sure, you could configure an access-list (e.g. access-list 106 permit ip any any) and have:
route-map MYMAP permit 60
match ip address 106
set interface Null0
But there really is no need. If the route-map evaluation has got this far we are just saying "drop everything else, send it to Packet Heaven, Null0". By removing the match statement you are in effect creating a catch-all statement. Equally, you may have wanted all traffic not matching access-lists 101-105 to be routed out of Serial0/5 rather than be routed using the routing table or dropped. Your last route-map clause would have been:
route-map MYMAP permit 60
set interface Serial0/5 <-- all traffic not previously matched will go via Serial0/5
Other Key Points About Route-Maps
1. The route map statements can also be marked with a deny. If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (in other words, destination-based routing is performed). Only if the statement is marked as permit and the packets meet the match criteria are all the set clauses applied. If the statement is marked as permit and the packets do not meet the match criteria, then those packets are also forwarded through the normal routing channel.
2. There can be multiple match criteria on the same line where only ONE of the criteria has to match. There can be multiple match statements on different lines where ALL match statements must match. I think an example here is in order:
route-map MYMAP permit 10
match ip address 101 102 103 104
match ip address 105
set interface Serial0/0
The logic here works thus:
match ip address 101 OR 102 OR 103 OR 104
AND
match ip address 105
So a packet comes in and matches access-list 104, the router then goes on to check access-list 105. If the received packet also matches access-list 105 then the set command is used. If the packet had failed to match access-list 105 then the next statement in the route-map would be evaluated or the packet would be forwarded normally.
3. There are other match criteria such as packet length but I'll focus on the other set criteria.
set ip next-hop [next-hop-ip-address] - specifies where to send the packet. Preferable to use this rather than exit interface.
set default interface [interface] - If there is no entry in the routing table for the destination of this packet route it through the specified interface
set default ip next-hop [next-hop-ip-address] - if there is no entry in the routing table for the destination of this packet route it via the specified next-hop
Notice the use of the "default". This is only true if there is no corresponding entry in the routing table.
4. Like match statements, you can have multiple set statements too. Again, an example will help illustrate this.
route-map MYMAP permit 10
match ip address 101
set interface Serial0/0 Serial0/1
By default any matches to access-list 101 will exit Serial0/0 but if that fails Serial0/1 will be used as the exit interface.
Conclusion
Like everything, route-maps are easy once you understand how the syntax works. Any questions or feedback please feel free to leave comments and/or email me using the Contact Me tab at the top of the screen. Good luck to you all in your studies!