Redistribution: More EIGRP Redistribution

EIGRP has a default seed metric of “infinity”, and we need to define a seed metric when we perform the redistribution. With EIGRP, that means defining five different settings.

There are two ways to set the seed metric with EIGRP:

  1. Set the metric for the redistributed routes learned from a specific source at the end of the redistribute command.
  2. Use the default-metric command to set the default metric for all routes being redistributed.

Example:

R3(config-router)#redistribute rip metric 1544 10 255 1 1500
R3(config-router)#redistribute connected metric 1544 10 255 1 1500

Fairly straightforward stuff.

Or using default metric option:

R2(config)#router eigrp 100
R2(config-router)#default-metric 1544 10 255 1 1500

Be very careful when redistributing with RIP as the AD for RIP routes is 120 and will be ‘better’ then External EIGRP routes with an AD of 170. This is example where we may need to change the AD for EIGRP to something lower than 120.

Example:

R2(config)#router eigrp 100
R2(config-router)#distance ?
<1-255> Administrative distance
eigrp IP-EIGRP distance
R2(config-router)#distance eigrp ?
<1-255> Distance for internal routes
R2(config-router)#distance eigrp 90 ?
<1-255> Distance for external routes
R2(config-router)#distance eigrp 90 119

show ip protocols’ is an excellent command for reviewing redistribution.

 

 

An OSPF and EIGRP thought..

To truly refresh my mind on all of the NP high points to both OSPF and EIGRP, I have decided to create ‘flashcards’ for each topic. The idea is every now and then to have a glance, to ensure all the concepts are taken in before stepping into the IE material. More to follow!

-Dean

Advanced EIGRP Concepts: Authentication

When I previously studied for CCNP Route, this was the area that I kind of didn’t pay too much attention to as I wasn’t too interested,  however second time round I have taken this in a lot better and managed to sum this up in the following steps. Quite straight forward really, just a case of remembering the correct syntax and using IOS help along the way.

This is kind of split into 2 parts:

  • 1 define your key globally
  • 2 instruct the interface participating in EIGRP to use MD5 authentication.

Here we go..

How to enable neighbour authentication in EIGRP.

1a. Globally create your key chain and attach your key to it! (Good analogy!)

R3(config)#key chain ?
WORD Key-chain name

R3(config)#key chain EIGRPNEIGHBOR ?
<cr>

R3(config)#key chain EIGRPNEIGHBOR

R3(config-keychain)#key ?
<0-2147483647> Key identifier

R3(config-keychain)#key 1

R3(config-keychain-key)#key-string ?
<0-7> Encryption type (0 to disable encryption, 7 for proprietary) LINE The key

R3(config-keychain-key)#key-string KINISKI

1b. Additionally you can set the send and accept lifetime values for the key.

R3(config-keychain-key)#accept-lifetime 10:00:00 Jan 1 2010 infinite

R3(config-keychain-key)#send-lifetime 10:00:00 Jan 1 2010 infinite

2a. Set your authentication mode under the interface that participates in EIGRP.

R3(config)#int e0

R3(config-if)#ip authentication mode eigrp 100 md5

2b. Define the key chain to be used

R3(config-if)#ip authentication key-chain eigrp 100 EIGRPNEIGHBOR

…and that is all there is to authenticating your EIGRP neighbours. 🙂 More importantly that wraps up EIGRP for the CCNP Revision. 🙂

Advanced EIGRP Concepts: Passive Interfaces + Propagating Default Routes

Passive Interfaces

An interface that is declared ‘passive’, is an interface that doesn’t participate in EIGRP. The interface will not send any Hello packets to any neighbours and therefore not form an adjacency.

  • Option 1: Use the passive-interface default command to make every EIGRP-enabled interface on the router passive, and then use the no passive-interface command to indicate the interfaces that should not be passive.
  • Option 2: Use the no passive-interface default command to disable this feature globally, and then use the passive-interface command to indicate interfaces that should be passive.

Option 1 makes a lot more sense and is a best practice to know intentionally configure the interfaces that SHOULD participate in your EIGRP process. When setting up a new EIGRP router, I would personally set every interface as passive and then nail up the interfaces you want for EIGRP with the no passive command. (We don’t want to accidentally form neighbour adjacencies on unknown interfaces)

This command is performed globally with the EIGRP process and not on an interface level.

EIGRP and the default route

There are several ways of propagating a default route into EIGRP:

  1. We can use the redistribute static command within EIGRP, this will redistribute any static routes such as the default route into the routing process. *We must also specify the K values (Bandwidth, Delay, Reliability, Load and MTU) as per standard redistribution INTO an EIGRP AS.
  2. Using the ‘ip default-network’ command, however we must be sure that the default route is within the routing table of the local router that we issue this command on. This command is issued in global config, not within EIGRP.
  3. Using a network statement with the EIGRP AS. Yes we can in fact use ‘network 0.0.0.0 0.0.0.0’ to advertise our default route to EIGRP neighbours. When we use this command the AD of the route will be internal with 90 and not 170 D EX as per a route learned by redistribution.

Advanced EIGRP Concepts: Design Tips and Recommendations

General guidelines for EIGRP

  1. Make sure you spend some time and set up a solid address allocation scheme before you deploy your network.
  2. Ensure that you’ll be able to perform manual route summarization where desired.
  3. Avoid discontigious networks whenever possible.
  4. Make sure your routers have sufficient memory and CPU to do their jobs. Your hub routers in any hub-and-spoke deployments will be the workhorses of your network.

Cisco best practices with EIGRP over NBMA (Frame Relay)

  • Your EIGRP traffic on each Virtual Circuit (VC) shouldn’t exceed the Committed Information Rate (CIR). (The CIR is the amount of bandwidth the service provider guarantees to be available to us.)
  • The total EIGRP traffic crossing all of your VCs should not be greater than the total capacity of the line.
  • The bandwidth allocated to EIGRP on each VC should be the same on each interface.

The calculation for the bandwidth command varies according to two factors:

  1. the type of interface in use on the hub
  2. the CIR assigned to each circuit

Scenarios

No Subinterfaces, All VCs Using Same CIR

When there are no subinterfaces in use and the CIR is the same for every VC, just add up the CIRs and you’ve got your bandwidth value.

R1(config)#int serial0
R1(config-if)#bandwidth 768

No Subinterfaces, VCs Using Different CIRs

Cisco has stated you can take the lowest CIR value and multiply it by the number of VCs. This isn’t the recommended solution, but it is valid.

R1(config)#int s0
R1(config-if)#bandwidth 168

Point-to-Point Subinterfaces, VCs Using Different CIRs

A more viable solution involves configuring point-to-point interfaces and assigning individual bandwidth values, having those match the individual CIR of each VC. This is Cisco’s recommendation for this situation, and this allows each router to work more closely to capacity.

R1(config)#int serial0.1 point-to-point
R1(config-subif)#ip address 20.1.1.1 255.255.255.0
R1(config-subif)#bandwidth 512
R1(config-subif)#int s0.2 point-to-point
R1(config-subif)#ip address 40.1.1.1 255.255.255.0
R1(config-subif)#bandwidth 256
R1(config-subif)#int s0.3 point-to-point
R1(config-subif)#ip address 50.1.1.1 255.255.255.0
R1(config-subif)#bandwidth 56

Multipoint Subinterfaces, VCs Using Different CIRs

Add the CIR values for each circuit using that multipoint sub interface to arrive at the correct bandwidth setting.

R1(config)#interface s0.467 multipoint
R1(config-subif)#bandwidth 824

By default, EIGRP uses up to 50 percent of a given interface’s bandwidth as set by the bandwidth command. If you wish to change this default, it can be done with the interface-level command ip bandwidth-percent eigrp.

R1(config)#int s0
R1(config-if)#ip bandwidth-percent eigrp ?
<1-65535> Autonomous system number
R1(config-if)#ip bandwidth-percent eigrp 100 ?
<1-999999> Maximum bandwidth percentage that EIGRP may use
R1(config-if)#ip bandwidth-percent eigrp 100 300

Watch this command!

There is always the chance that the actual physical speed of the interface exceeds the logical setting. You could take an interface with a 512 kbps capacity and give it a logical setting of 56 kbps. If you then wanted the line to allow EIGRP to use 168 kbps of the physical bandwidth, you’d set the bandwidth-percent value to 300, which allocates 300% of 56kbps to EIGRP traffic – which is 3 x 56, or 168. (The first number is the EIGRP AS; the second number is the bandwidth percentage)

EIGRP Stub Routers

In a hub and spoke topology, the spoke routers normally have only 1 next hop to breakout. This will always be the same next hop address, beyond the spoke router is nothing so this really is a dead end. Therefore we can configure our spoke routers as stub routers.

  • We can eliminate DUAL Queries, as the hub should never have to ask the spoke routers for the route that has been lost.
  • The spoke routers do not need to carry a full copy of the routing table, but instead can survive with a single default route to the hub.
  • A stub router can only a neighbour with a hub, not a fellow spoke router.
  • This also assist SIA situations as the hub will never send the Query packet into the spoke/stub routers.

Stub Configuration

*On spoke routers:

R1(config)#router eigrp 100
R1(config-router)#eigrp stub ?
connected Do advertise connected routes
receive-only Set IP-EIGRP as receive only neighbor
static Do advertise static routes
summary Do advertise summary routes
<cr>

*We can specify on the stub what networks to advertise to the neighbouring hub router.

EIGRP assumes that a serial interface is connected to a T1 line, which runs at 1544 kbps (or 1.544 mbps). If the bandwidth is less that 1.544mbps, such as 56k, then it is best practice to explicitly specify the bandwidth:

R1(config)#int s0
R1(config-if)#bandwidth 56

Advanced EIGRP Concepts: Autosummarization And Manual Route Summarization

EIGRP Route Summarization – Automatic And Manual

EIGRP and RIPv2 automatically summarize routes when they are advertised across classful network boundaries. When you have discontiguous networks (subnets of the same major network number that are separated by another major network number), this behavior can result in suboptimal routing at its worst. *Already covered in previous EIGRP posts.

Where to disable auto summary?

The best place to turn this feature off is normally at the spoke routers, as they are advertising networks and performing summarization facing towards the hub router.

Configuring any kind of manual summarization does NOT enable or disable auto-summarization — they’re two separate operations.

Reasons to use Autosummarization

  1. The routing tables are smaller, making the entire routing process faster.
  2. Since the tables are smaller, the load on the CPU from the routing process is lessened.
  3. The more-specific network numbers are hidden.
  4. Routing updates are smaller.
  5. The impact of flapping routes on the rest of the network is lessened, and correct summarization helps to limit the number of EIGRP queries.

Manual Summarization

R3#show ip route eigrp
100.0.0.0/16 is subnetted, 7 subnets
D 100.4.0.0 [90/2297856] via 172.12.123.1, 00:00:00, Serial0
D 100.5.0.0 [90/2297856] via 172.12.123.1, 00:00:00, Serial0
D 100.6.0.0 [90/2297856] via 172.12.123.1, 00:00:00, Serial0
D 100.7.0.0 [90/2297856] via 172.12.123.1, 00:00:00, Serial0
D 100.1.0.0 [90/2297856] via 172.12.123.1, 00:00:00, Serial0
D 100.2.0.0 [90/2297856] via 172.12.123.1, 00:00:00, Serial0
D 100.3.0.0 [90/2297856] via 172.12.123.1, 00:00:00, Serial0

With the help of manual route summarization, we can knock this table down to one line. First, we use  binary math to convert the subnet numbers to binary strings.

100.1.0.0 01100100 00000001 00000000 00000000
100.2.0.0 01100100 00000010 00000000 00000000
100.3.0.0 01100100 00000011 00000000 00000000
100.4.0.0 01100100 00000100 00000000 00000000
100.5.0.0 01100100 00000101 00000000 00000000
100.6.0.0 01100100 00000110 00000000 00000000
100.7.0.0 01100100 00000111 00000000 00000000

Believe it or not, that’s the hard part of summarizing routes. 😉

The next step in route summarization is to work from left to right and identify the common bits. From there, it’s easy:

  • The decimal value of these bits is the summary route.
  • The number of common bits yields the summary mask.

Here, the value of the common bits (bolded above) is 100.0.0.0. There are 13 common bits, expressed as /13 in prefix notation and 255.248.0.0 in dotted decimal.

Where to configure the manual summarization?

Your manual summary statement should be configured on the physical interface that connects to the adjacent router:

R1(config)#interface ethernet0
R1(config-if)#ip summary-address eigrp 100 100.0.0.0 255.248.0.0
2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0) is down: summary configured
2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0) is down: summary configured

It’s important to keep in mind that when you configure EIGRP summary addresses, your neighbor relationships will be lost. When they come back up, R3 will have a single summary route instead of the seven more specific routes it previously had.

After a manual summary is performed, the neighbours route table will look like this:

R1#show ip route
< code table removed for clarity >
100.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C 100.4.0.0/16 is directly connected, Loopback4
C 100.5.0.0/16 is directly connected, Loopback5
C 100.6.0.0/16 is directly connected, Loopback6
C 100.7.0.0/16 is directly connected, Loopback7
D 100.0.0.0/13 is a summary, 00:07:32, Null0
C 100.1.0.0/16 is directly connected, Loopback0
C 100.2.0.0/16 is directly connected, Loopback2
C 100.3.0.0/16 is directly connected, Loopback3

The summary route is seen as a route to Null0, which is basically a route to the trash can. If a packet comes into this router that doesn’t match one of the seven more-specific routes, it will be “black-holed” – dropped by the router. This default behavior of EIGRP route summarization helps to prevent routing loops. This null route will only be seen on the router performing the manual summarization.

How do we find the AD value of 5 for this summary route?

R1#show ip route 100.0.0.0 255.248.0.0
Routing entry for 100.0.0.0/13
Known via "eigrp 100", distance 5, metric 128256, type internal
Redistributing via eigrp 100
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 128256, traffic share count is 1
Total delay is 5000 microseconds, minimum bandwidth is 10000000 Kbit
Reliability 255/255, minimum MTU 1514 bytes
Loading 1/255, Hops 0

Route summarization is more efficient when it’s configured on the ASBR. (OSPF concept, but also referenced in EIGRP)

EIGRP Advanced Concepts: EIGRP Administrative Distances – FD + AD

Feasible Distance and Advertised Distance

From all these views of the topology table, you’ve probably noticed that there are two numbers in parenthesis following each next-hop IP address:

P 172.23.0.0/16, 2 successors, FD is 2195456
via 172.12.123.2 (2195456/281600), Serial0
via 172.12.123.3 (2195456/281600), Serial0
  • The first number, 2195456, is the route’s feasible distance. This is the full metric of the route to the destination network.
  • The second number, 281600, is the route’s advertised distance. This is simply the metric from the next-hop router to the destination network.

For the path to be considered valid, the advertised distance must be less than the feasible distance. This ensures that the next-hop router is indeed closer to the destination and acts as a routing loop prevention mechanism.

These distances are also used by EIGRP to determine what routes can be feasible successors.

Example

P 3.0.0.0/8, 1 successors, FD is 2297856
via 172.12.123.3 (2297856/128256), Serial0
via 172.12.123.2 (2323456/409600), Serial0

The second route can’t be a successor, because its FD (2323456) is higher than the FD of the successor (2297856). Can it be a feasible successor? Yes, because the advertised distance of that route (409600) is lower than the feasible distance of the successor (2297856).

This is the Feasibility Condition. That route is then entered into the topology table as a feasible successor, and should the successor go down, the feasible successor will become the successor.

Another Example

Successor: FD 5, AD 4

Possible Feasible Successor #1: FD 9, AD 7

Possible Feasible Successor #2: FD 8, AD 6

Possible Feasible Successor #3: FD 6, AD 4

To decide if any of these three routes could be a feasible successor, just compare the AD of the route to the FD of the successor.

If the successor is lost and there is no feasible successor, the router takes two actions:

  1. The route is put into Active state, making the route unusable.
  2. The router sends DUAL Query packets to EIGRP neighbors, asking them if they have a loop-free path to the destination in question.

The Feasibility Condition In Action

Capture

R1 has three potential paths to R3. The feasible distances and advertised distances for the paths from R1’s point of view are:

PATH A: R1 – R4 – R3: FD 40, AD 20

PATH B: R1 – R2 – R3: FD 70, AD 20

PATH C: R1 – R5 – R3: FD 115, AD 75

  • Successor: PATH A
  • Feasible Successor: PATH B

Explanations

  • PATH B qualifies as a feasible successor as it’s AD is lower than the FD of the successor. (PASS)
  • PATH C doesn’t qualify as a feasible successor because it’s AD is higher than the FD of the successor (FAIL)

The Feasibility Condition And The variance Command

You cant apply the variance command to any path that doesn’t meet the feasibility condition.

In the real world, make sure any routes you want to use in unequal-cost load balancing meet the Feasibility Condition

Capture2

A simpler approach specifically for variance is to add the costs of all paths:

  • PATH 1 – r1-r2-r3 = FD 40 AD 20
  • PATH 2  – r1-r4-r5 = FD 55 AD 35
  • PATH 3  – r1-r6-r7 = FD 115 AD 75
  • Successor = PATH 1
  • Feasible Successors = PATH 2

PATH 3 fails the check and therefore we can’t include this path with our load balancing. But what if we want to include this link in our load balancing?….

So… we use a variance of 2 which will multiply the FD of the successor to 80. Path 3 with an AD of 75 is now lower than the FD of 80 and passes the Feasibility Condition. PATH 3 can now be used with the variance command as it qualifies as a Feasible Successor.

This is a really simple concept, but for some reason when going through a real world example it does hurt the head a bit.. Best to be calm and approach any example as above.

  1. 1. Refer to a network diagram
  2. 2. Details the FD and AD values
  3. 3. Draw a table showing the values
  4. 4. Make your calculations and work out the required variance multiplier to be used

Simple! 😉

EIGRP Administrative Distances

As well as Internal EIGRP routes with an AD of 90 there are 2 other types of EIGRP routes.

  1. External Routes with an AD of 170 and highlighted by D EX which are learned by redistribution.
  2. Summary Routes with an AD of 5 are routes sent back to their classful boundary using auto summary or a specific subnet mask by using manual summarization.

You can also change the AD values with EIGRP using the ‘distance eigrp’ command:

R1(config)#router eigrp 100
R1(config-router)#distance ?
<1-255> Administrative distance
eigrp IP-EIGRP distance
R1(config-router)#distance eigrp ?
<1-255> Distance for internal routes
R1(config-router)#distance eigrp 45 ?
<1-255> Distance for external routes
R1(config-router)#distance eigrp 45 100

*Big thanks to Chris Bryants study guide for the example diagrams