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

EIGRP Advanced Concepts: Successors + Feasible Successors + Stuck In Active + More variance!

Once the EIGRP neighbor relationships form, DUAL will begin sending a series of queries and responses, and these responses are used to build the EIGRP topology table. *queries and responses are sent by the Reliable Transport Protocol (RTP)*

R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process 100
Hellos sent/received: 110457/115367
Updates sent/received: 43/17
Queries sent/received: 4/0
Replies sent/received: 0/4
Acks sent/received: 14/21
Input queue high water mark 2, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0

EIGRP will keep up to six valid routes for any given destination. Those six routes don’t have to be made up of one successor and five feasible successors, either – when equal-cost load sharing is in effect there will be multiple successor routes.

“SIA” — Stuck In Active

If a route shows as Active in the EIGRP topology table, that means the successor for that route has been lost and that no feasible successor was immediately available in the topology table.

When a route is Passive, that means it’s not being recalculated and it’s a usable route.

Generally, an Active route will be that way for a very short time; by the time you repeat show ip eigrp topology, it’s likely that Active route has gone Passive. That cutover from Active to Passive is so fast that you can work with EIGRP for a long time without even seeing an Active route.

Sometimes that doesn’t cutover doesn’t happen at all, and the route becomes SIA – Stuck In Active.

  • Question: Why does a route become SIA?
  • Answer: Routes generally become SIA when a neighbour either doesn’t answer a query, or either the query or reply took a wrong turn somewhere.
  • Question: Why does a Reply packet not come back to the asking router?
  • Answer: Review of normal process to retrieve a lost route….:
  1. When an EIGRP router loses a Successor route, it looks in its topology table for a Feasible Successor. If there is no Feasible Successor, that router will send DUAL Query packets to its neighbors, asking them if they have a valid route to the now unreachable destination.
  2. If the router receiving the query doesn’t have a valid, loop-free route to the destination in question within a certain amount of time, that router will in turn ask all of its neighbors for such a route – and they’ll ask two friends, and they’ll ask two friends, until a route is discovered or it’s determined that no queried router has a route.
  3. That default time is three minutes and can be changed with the timers active-time command in your EIGRP configuration.
  4. If the neighbour doesn’t answer that query within a certain period of time, the route is Stuck In Active – SIA.

4 main real-world reasons why a route becomes SIA:

  1. The link is unidirectional, so the query can’t possibly be answered.
  2. The queried router’s resources are unavailable, generally due to high CPU utilization.
  3. The queried router’s memory is corrupt or otherwise unable to allow the router to answer the query.
  4. The link between the two routers is of low quality, allowing just enough packets through to keep the neighbor relationship intact, but not good enough to allow the replies through.

Another method of spotting SIA issues is in the EIGRP topology table. If you see a lower-case “r” next to an IP address where the Active route is shown, that means a query packet has been sent to that IP address and it has not yet been answered. This code is shown at the top of the EIGRP topology table:

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

Variance

EIGRP metric calculation: [(10*6 / smallest BW in kbps) + delay] * 256 (*Just for reference)

This is one of those concepts that looks ridiculously complicated in theory but is simple in execution. (See previous posts)

When unequal-cost load balancing is in effect, the load each link carries is proportional to their metric. If one path’s metric indicates that it is twice as good as another, that path will carry roughly twice as much data.

If you want only the best path(s) to carry the traffic, use the traffic share command with the min option. The default is balanced.

R1(config)#router eigrp 100
R1(config-router)#traffic-share ?
balanced Share inversely proportional to metric
min All traffic shared among min metric paths
R1(config-router)#traffic-share min ?
across-interfaces Use different interfaces for equal-cost paths
R1(config-router)#traffic-share min across-interfaces ?
<cr>
R1(config-router)#traffic-share min across-interfaces

Variance is an “all-or-nothing” command — you can’t apply it to just a selected route in the topology table.

EIGRP Advanced Concepts: Hello Packets and Secondary Addresses

Changing metric weights will of course tear down any existing neighbour relationship or prevent any new potential relationships from forming.

A great command to begin troubleshooting adjacencies with is debug eigrp packets, and if there’s a metric weights mismatch, you’ll see the following:

R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB,
SIAQUERY, SIAREPLY)
R2#
01:10:00: EIGRP: Received HELLO on Ethernet0 nbr 172.23.23.3
01:10:00: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0
01:10:00: K-value mismatch

In short, EIGRP neighbours must….

  • … reside in the same EIGRP AS
  • … be on the same subnet
  • … have matching metric weights

*When you change Hello times in EIGRP it DOESN’T dynamically change the dead timer. *By default it is 3 times the Hello time. OSPF DOES dynamically change the dead timer.

Hello packets find potential neighbors and also keep neighbour relationships alive. On a high-speed link, EIGRP Hello packets are sent every 5 seconds; on slower links, Hellos are sent every 60 seconds.

  • High-speed links include broadcast technologies such as Ethernet, FDDI, and our old friend Token Ring; high bandwidth (over T1 speed) multipoint circuits, including ISDN Primary Rate Interface and Frame Relay; both Frame Relay and ATM point-to-point subinterfaces; and finally, point-to-point serial links, such as PPP and HDLC circuits..
  • Low-speed links include multipoint circuits running at less than T1 speed, such as ATM switched virtual circuits and multipoint interfaces, Frame Relay multipoint interfaces, and ISDN Basic Rate Interface.

An EIGRP neighbor relationship is declared dead when three hello packets are missed, meaning the EIGRP dead time on an Ethernet segment is 15 seconds and 180 seconds on an NBMA interface such as a Serial interface.

Break down of show ip eigrp neighbors command:

(From left to right, let’s examine the meaning of these categories)

  1. IP-EIGRP neighbors for process 100 – The AS these neighbors are contained in.
  2. H – The order in which the neighbors were discovered.
  3. Address – The IP address of the neighbor.
  4. Interface – The interface upon which the router is receiving hellos.
  5. Hold – Short for holdtime, the number of seconds the router will wait until it declares this particular adjacency dead.
  6. Uptime – The amount of time since this neighbor was first heard from.
  7. SRTT – Smooth Round-Trip Time. This is the number of milliseconds it takes for an EIGRP packet to be sent to that neighbor and the amount of time it takes to get an ACK from that neighbor.
  8. RTO – Retransmission TimeOut. The amount of time the software will wait until it retransmits a packet to a neighbor.
  9. Q Cnt – Queue Count. The number of EIGRP packets waiting to be sent.
  10. Seq Num – Sequence Number. This is the sequence number of the last update, reply, or query packet that was received from this particular neighbor.

EIGRP Adjacencies And Secondary Addresses

Officially Cisco deny the fact that you can form neighbour relationships using a secondary address. It is actually possible, when you issue the network command with the secondary address, the adjacency will form, but the primary address will be shown in the neighbour relationship NOT the secondary. One to look out for!

EIGRP Advanced Concepts: EIGRP Fundamentals + Neighbor Relationship Review

Fundamental High Points

  • EIGRP updates do not contain the entire routing table, but reflect only the routes that have been changed.
  • The scope of these updates is limited to the routers that actually need them – they’re not flooded.
  • EIGRP routing update packets contain a prefix length for each individual network, making VLSM support possible.
  • With EIGRP, routing loops have literally no time to form.
  • EIGRP will perform equal-cost load-sharing over four paths by default, with a maximum of 16 paths.
  • Almost all EIGRP packets are multicast to 224.0.0.10, and use IP protocol number 88.

EIGRP Packet Types And RTP

EIGRP uses the Reliable Transport Protocol (RTP) to handle the guaranteed and reliable delivery of EIGRP packets to neighbors.

“Guaranteed and reliable” sounds a lot like TCP, but the two are quite different in how they operate. Not all EIGRP packets are going to be sent reliably.

  • Hello packets are used for neighbour discovery and to keep existing neighbour relationships alive; these are multicast to 224.0.0.10.
  • Acknowledgement packets themselves are simply hello packets that contain no data. Neither Acks nor Hellos use RTP, and are therefore considered unreliable.
  • Update packets are sent to new neighbours to allow the neighbour to build an accurate routing and topology table, and are also sent when a change in the network occurs. Update packets are generally multicast packets, but there’s one important exception that you’ll read about later in this section.
  • Query packets are sent when a router loses a successor route and has no feasible successor.
  • Reply packets are sent in response to query packets, and a reply packet indicates that a new route to the destination has been found. Update, Query, and Reply packets all use RTP and are considered reliable.

To see how many of these packets have passed through a router, run show ip eigrp traffic.

R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process 100
Hellos sent/received: 2/2
Updates sent/received: 13/4
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 0/2
Input queue high water mark 1, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0

To review: Hello and ACK packets are unreliable. Reply, Query, and Update packets are reliable.

That’s a handy troubleshooting command, too. If the Query, Reply, and Update values remain the same over a period of time, your network is stable.

If they’re constantly incrementing, there’s a problem. The Query and Reply values will increment only if a successor route is lost. If you see those incrementing regularly, you have yourself a flapping link

Neighbour Adjacencies

  1. A router will multicast an EIGRP Hello packet to 224.0.0.10 out that interface in an attempt to find potential neighbours.
  2. A downstream router receives this Hello. If certain values are agreed upon between the two, (Metric Weights and AS No) the router will respond with an EIGRP Update packet, which contains all the EIGRP-derived routes known.
  3. Update packets are unicast in this particular situation, but otherwise they’re multicast.
  4. The router will send an EIGRP Acknowledgement packet, or ack, to let the downstream router know the routes in the Update packet were received. The router will also send an Update packet of its own, unicast to the downstream router, containing all known EIGRP routes. The downstream router will respond with an ack of its own.

*The EIGRP hold time has the same function as OSPF dead time – they’re both the duration of time in which a hello must be received in order to retain the neighbor relationship. The default EIGRP hold time is three times the hello time.