notes: EIGRP Error Messages

Some EIGRP error messages that occur in the log have mystified many network admin-istrators. This section discusses some of the most common EIGRP errors that appear and the meanings behind these EIGRP error messages:



DUAL-3-SIA—

This message means that the primary route is gone and no feasible successor is available. The router has sent out the queries to its neighbor and has not heard the reply from a particular neighbor for more than three minutes. The route state is now stuck in active state. A more detailed discussion about this error is in the "Troubleshooting EIGRP Neighbor Relationships" section.



Neighbor not on common subnet—

This message means that the router has heard a hello packet from a neighbor that is not on the same subnet as the router. A more detailed discussion about this error also can be found in the "Troubleshooting EIGRP Neighbor Relationships" section.



DUAL-3-BADCOUNT—

Badcount means that EIGRP believes that it knows of more routes for a given network than actually exist. It's typically (not always) seen in conjunction with DUAL-3-SIAs, but it is not believed to cause any problems by itself.



Unequal, <route>, dndb=<metric>, query=<metric>—

This message is informa-tional only. It says that the metric the router had at the time of the query does not match the metric that it had when it received the reply.



DUAL-3-INTERNAL: IP-EIGRP Internal Error—

This message indicates that there is an EIGRP internal error. However, the router is coded to fully recover from this internal error. The EIGRP internal error is caused by software problem and should not affect the operation of the router. The plan of action is to report this error to the TAC and have the experts decode the traceback message. Have them identify the bug number and upgrade Cisco IOS Software accordingly.



IP-EIGRP: Callback: callbackup_routes—

At some point, EIGRP attempted to install routes to the destinations and failed, most commonly because of the existence of a route with a better administrative distance. When this occurs, EIGRP registers its route as a backup route. When the better route disappears from the routing table, EIGRP is called back through callbackup_routes so that it can attempt to reinstall the routes that it is holding in the topology table.



Error EIGRP: DDB not configured on interface—

This means that when the router's interface receives an EIGRP hello packet and the router goes to associate the packet with a DDB (DUAL descriptor block) for that interface, it does not find one that matches. This means that the router is receiving a hello packet on the interface in which doesn't have EIGRP configured.



Poison squashed—

The router threads a topology table entry as a poison in reply to an update (the router set up for poison reverse). While the router is building the packet that contains the poison reverse, the router realizes that it doesn't need to send it. For example, if the router receives a query for that route from the neighbor, it is currently threaded to poison.

notes: Troubleshooting EIGRP Route Flapping

This section discusses how to troubleshoot consistent EIGRP route flapping. The most important tool for troubleshooting this problem is the show ip eigrp event command. This command reveals which neighbor is updating and the metric with which it's updating

debugging and verification

show ip route

Router B#debug ip routing 1
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 deny any
show ip eigrp event


Solution:


Investigate the cause of route flapping it can be layer 1 to 2 issue. or loop issues.

notes: Troubleshooting EIGRP Route Summarization

Summarization is extremely important in a well-designed EIGRP network. Summarization is one of the few weapons to prevent stuck in active problems. Most summarization problems are the result of a misconfiguration of the router.

1.  EIGRP Summarization Route Problem—Cause: Subnetworks of Summary Route Don't Exist in Routing Table.


verification:

show run
show ip route

Solution:

The solution to this problem is to configure an interface that falls in the summary range. You can configure a loopback interface with address w/in the summary range to generate the summary route configured.


2.  EIGRP Summarization Route Problem—Cause: Too Much Summarization
Another EIGRP summarization route problem stems from when the summary route covers more subnetworks than exist.


debugs and verification:

show ip route x.x.x.x

solution

This problem is more of a design issue. The main issue is that Router B's summary route is too broad and includes nonexistent subnets. Also, Router A is sending a more general summary route (default route) to Router B. The solution is to have Router B send out only the summary route that covers the 172.16.1.0 through 172.16.15.0 networks.

notes: Troubleshooting EIGRP Redistribution Problems

In many instances, a problem occurs when redistributing from another routing protocol into EIGRP.


scenario1:  the router is the border router between three routing protocols, RIP, OSPF, and EIGRP.

Router A wants to redistribute all the routes in the RIP domain into the EIGRP domain. The problem is that the network 150.150.0.0/16 is not getting redistributed into the EIGRP domain.

debugs and verification:

show ip eigrp topo  150.150.0.0 255.255.255.0

 show ip route 150.150.0.0 255.255.0.0 -shows it was learned via ospf, since ospf has a lower admin distance than rip. the route via ospf was used.

solution:

The resolve this problem, you must make Router A install the RIP route instead of the OSPF route. One way to do this is to configure a distribute list under OSPF to not install the 150.150.0.0/16 route.

Scenario2: redistributing other protocols to eigrp without default metric command.

although the redistribute ospf  command is configured under EIGRP, there is no configuration of the default-metric command. When redistributing between different routing protocols, the default-metric com-mand must be configured. When one routing protocol is being redistributed into another, the router doesn't have a way to translate the routing metric from one routing protocol into another. The default-metric command is used so that the network administrator can manually initialize the routing metric during route redistribution.

solution:
 The fix for this problem: Configure a default metric under EIGRP in Router B.

notes: Troubleshooting EIGRP Route Installation

1. EIGRP Is Not Installing Routes—Cause: Auto or Manual Summarization

debugs and verification

show run | section router bgp
show up route x.x.x.x

solution:

The solution to this problem, based on this cause, is more of a design issue. Two places in the network must not send the same summary routes to one another. configure the no auto-summary command.

2.  EIGRP Is Not Installing Routes—Cause: Higher Administrative Distance

deugs and verification

 show ip eigrp topology 150.150.0.0 255.255.0.0

solution:

To fix this problem, you must change the administrative distance of the routing protocols so that external EIGRP routes are preferred. To do so, use the distance command to manipulate the administrative distance of a routing protocol.


   distance 180 192.168.2.2 255.255.255.255

The distance command  sets the RIP administrative distance to 180 for any updates coming from 192.168.2.2. This allows the external EIGRP routes (administrative distance of 170) coming from Router C to be preferred over RIP routes.

3.  EIGRP Is Not Installing Routes—Cause: Duplicate Router IDs

Many times, EIGRP will not install routes because of a duplicate router ID problem. EIGRP does not use router ID as extensively as OSPF. EIGRP uses the notion of router ID only on external routes to prevent loops. EIGRP chooses the router ID based on the highest IP address of the loopback interfaces on the router. If the router doesn't have any loopback interfaces, the highest active IP address of all the interfaces is chosen as the router ID for EIGRP

debugs and verification:

sho run | section router eigrp
debug ip eigrp
show ip eigrp topology 150.150.0.0 255.255.0.0

solution:
The solution to the duplicate router ID problem is to change the IP address of the loopback interface of Router X or to change the IP address of Ethernet 0 in Router A. The rule of thumb: Never configure the same IP address on two places in the network.

notes: Troubleshooting EIGRP Route Advertisement

1.  EIGRP Is Not Advertising Routes to Its Neighbors—Cause: Distribute List

debugs and verification

show run | section router eigrp

debug ip eigrp

router eigrp 1 

network 192.168.3.0 

network 10.0.0.0 

distribute-list 1 out  

!

access-list 1 permit 192.168.3.160 0.0.0.15

Solution:  Ensure that the distribute list allows the rang of network that needed to be advertised.

 2.  EIGRP Is Not Advertising Routes to Its Neighbors—Cause: Discontiguous Networks


another issue with EIGRP not advertising the network could be manual summarization configured on the interface or auto-summarization across a major network boundary

debugs and verification:

show run | section router eigrp

debug ip eirgrp

Solution:

a.  One is to configure the command no auto-summary under router eigrp. This command tells EIGRP not to autosummarize to major network boundaries.
b.  to change the IP address of the serial interfaces on each side of the link and use different IP that is different with existing.

3. EIGRP Is Not Advertising Routes to Neighbors—Cause: Split-Horizon Issues

EIGRP has its own split-horizon command. This command, configured under the inter-face,

debugs and verification:

show run | section router eigrp

debug ip eirgrp

Solution:

a.  disabling Split horizon

interface serial 0 

ip address 172.16.2.1 255.255.255.0 

no IP split-horizon EIGRP 1 

b.  Another fix for the split-horizon problem is to configure subinterfaces on the hub router and assign different IP address subnets for each subinterface.


 4.  EIGRP advertises unexpected routes to its neighbors.

Router B# interface ethernet 0 

ip address 192.168.130.1 255.255.255.0 

interface serial 0 

ip address 10.1.1.2 255.255.255.0 

router eigrp 1 network 192 .168.130.0  

network 10.0.0.0 

ip route 192.168.1.0 255.255.255.0 ethernet 0 

ip route 192.168 2.0 255.255.255.0 ethernet 0  

ip route 192.168 3.0 255.255.255.0 ethernet 0  

ip route 192.168 4.0 255.255.255.0 ethernet 0 

.

. 

. 

ip route 192.168.127.0 255.255.255.0 ethernet 0

without inserting the redistribute static command under the router eigrp command in Router B, Router B automatically redistributes all the 127 static routes configured to Router A. This can cause unnecessary routes being advertised inadvertently throughout the entire network. The cause of the problem is that the static routes are configured with the outbound interface. In this case, the router thinks that all the static routes are directly connected to the Ethernet 0 interface. These Ethernet interfaces also are covered under the router EIGRP process by the network 192.168.130.0 command. Because Ethernet 0 is considered to run EIGRP, all the networks connected to it by a static route also are considered to belong to the EIGRP process. The router then advertises all these static routes even though redistribute static is not configured.


solution:

 a.  to configure a distribute list that prevents the router from advertising all those static routes 

router eigrp 1  

network 192.168.130.0 

network 10.0.0.0 

distribute-list 1 out  

!

access-list 1 deny 192.168.0.0 0.0.127.255  

access-list 1 permit any  

b.  or to change the static routes to reference the next-hop IP addresses instead of an interface. This way, the router will not advertise all these static routes and flood the entire network with unnecessary routes.

ip route 192.168.1.0 255.255.255.0 192.168.130.2 

ip route 192.168.2.0 255.255.255.0 192.168.130.2 

ip route 192.168.3.0 255.255.255.0 192.168.130.2 

ip route 192.168.4.0 255.255.255.0 192.168.130.2 

.  

.  

.  

ip route 192.168.127.0 255.255.255.0 192.168.130.2  

 5.  EIGRP Is Advertising Routes with Unexpected Metric


advertise an unexpected metric to its neighbors. The EIGRP metric is the basis of route selection done by EIGRP, which selects the route with the lowest EIGRP metric to the destination network. An unexpected EIGRP metric being sent or received on the router might alter route selection to the destination network. The end result might be suboptimal routing.


debugs and verification:

show ip route x.x.x.x

show eigrp topology x.x.x.x y.y.y.y

Solution: Ensure there are no off-set list configured that changes the metrics of the outgoing interface.

notes: Troubleshooting EIGRP Neighbor Relationships

1.  EIGRP Neighbor Problem—Cause: Unidirectional Link

A one-way neighbor relationship usually is caused by a unidirectional connection between the neighbors. The cause for unidirectional connection is usually a Layer 2 problem.

verification:

show ip eigrp neighbor

RtrB#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H Address   Interface Hold Uptime  SRTT   RTO  Q  Seq

                                   (sec) (ms)  Cnt Num

1 10.88.18.2    S0    14   00:00:15  0    5000  4    0

the fact that the SRTT timer is 0 indicates that no acknowledge-ment packets are being received. The Q count is not decrementing, which indicates that the router is trying to send EIGRP packets but no acknowledgement is being received. RTR B will retry 16 times to resend the packet; eventually, RTR B will reset the neighbor relationship with the log indicating RETRY LIMIT EXCEEDED, and the process starts again. Also, keep in mind that the 16 times retransmission of the same packet is done using unicast, not multicast. Therefore, the RETRY LIMIT EXCEEDED message indicates a problem with transmitting unicast packets over the link, and this is most likely a Layer 1 or Layer 2 problem.

Solution:

RtrB#show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H Address   Interface Hold Uptime  SRTT   RTO  Q  Seq

                      (sec)        (ms)       Cnt Num

1 10.88.18.2    S0    14   01:26:30 149   894  0  291

Notice that the Q count column is 0 and that the SRTT and RTO have valid values now.

2.  EIGRP Neighbor Problem—Cause: Uncommon Subnet

Many times, EIGRP won't establish neighbor relationships because the neighbors are not in the same subnet. Usually, the cause of this problem is router misconfiguration. When EIGRP has problems establishing neighbor relationships because of an uncommon subnet, the following error message appears:

IP-EIGRP: Neighbor ip address not on common subnet for interface

3 possible cause


a.  The IP address has been misconfigured on interfaces.

Solution:  configure the correct IP address on interface.

b. The primary and secondary IP addresses of the neighboring interface don't match.

EIGRP sources the hello packet from the primary address of the interface. If the primary network address on one router is used as a secondary network address on the second router, and vice versa, no neighbor relationship will be formed and the routers will complain about the neighbor not being on a common subnet.


Solution:  Ensure Primary and secondary IP matches on both sides of the link.

c.  A switch or hub between the EIGRP neighbor connection is misconfigured or is leaking multicast packet to other ports.

If a single LAN hub connects the EIGRP neighbors for different LAN segment, the hub passes broadcast and multicast packets to other ports between two logical LAN seg-ments. So, the multicast EIGRP hello from LAN segment 1 will be seen on the neighbor located in LAN segment 2 if a single hub connects all the LAN devices on different LAN segments. The solution is to break up the broadcast domain by using a separate hub for each LAN segment or simply configuring no eigrp log-neighbor-warnings under EIGRP con-figuration to stop seeing the error message.


3. EIGRP Neighbor Problem—Cause: Mismatched Masks

Solution:

The solution for this problem: Configure the right subnet mask on Router.

4.  EIGRP Neighbor Problem—Cause: Mismatched K Values

For EIGRP to establish its neighbors, the K constant value to manipulate the EIGRP metric must be the same.

Troubleshooting this problem requires careful scrutiny of the router's configuration. The solu-tion for this problem is to change all the K values to be the same on all the neighboring routers.


5.  EIGRP Neighbor Problem—Cause: Mismatched AS Number

EIGRP won't form any neighbor relationships with neighbors in different autonomous systems.



Solution: Ensure AS are the same.

6.  EIGRP Neighbor Problem—Cause: Stuck in Active

Sometimes, EIGRP resets the neighbor relationship because of a "stuck in active" condition. The error message is

%DUAL-3-SIA: Route network mask stuck-in-active state in IP-EIGRP AS. Cleaning up 

Reviewing the EIGRP DUAL Process

To resolve an EIGRP stuck in active error, you need to understand the DUAL process in EIGRP. Refer to Chapter 6 for thorough coverage of the DUAL process, although it is reviewed here as well.

EIGRP is an advanced distance-vector protocol; it doesn't have LSA flooding, like OSPF, or a link-state protocol to tell the protocol the overall view of the network. EIGRP relies only on its neighbors for information on network reachability and availability. EIGRP keeps a list of backup routes called feasible successors. When the primary route is not available, EIGRP immediately uses the feasible successor as the backup route. This shortens convergence time. Now, if the primary route is gone and no feasible successor is available, the route is in active state. The only way for EIGRP to converge quickly is to query its neighbors about the unavailable route. If the neighbor doesn't know the status of the route, the neighbor asks its neighbors, and so on, until the edge of the network is reached. The query stops if one of the following occurs:

All queries are answered from all the neighbors.

The end of network is reached.

The lost route is unknown to the neighbors.

The problem is that, if there are no query boundaries, EIGRP potentially can ask every router in the network for a lost route. When EIGRP first queries its neighbor, a stuck in active timer starts. By default, the timer is three minutes. If, in three minutes, EIGRP doesn't receive the query response from all its neighbors, EIGRP declares that the route is stuck in active state and resets the neighbor that has not responded to the query.
 

 Determining Active/Stuck in Active Routes with show ip eigrp topology active

You must answer two questions to troubleshoot the EIGRP stuck in active problem:

Why is the route active?

Why is the route stuck?

Determining why the route is active is not a difficult task. Sometimes, the route that constantly is going active could be due to flapping link. Or, if the route is a host route (/32 route), it's possible that it is from a dial-in connection that gets disconnected. However, trying to deter-mine why the active route becomes stuck is a much harder task—and more important to learn. Usually, an active route gets stuck for one of the following reasons:

Bad or congested links

- Low router resources, such as low memory or high CPU on the router

- Long query range

- Excessive redundancy

By default, the stuck in active timer is only three minutes. In other words, if the EIGRP neighbor doesn't hear a reply for the query in three minutes, neighbors are reset. This adds difficulty in troubleshooting EIGRP stuck in active because every time an active route is stuck, you have only three minutes to track down the active route query path and hopefully find the cause.

The tool that you need to troubleshoot the EIGRP stuck in active error is the show ip eigrp topology active command. This command shows what routes are currently active, how long the routes have been active, and which neighbors have and have not replied to the query. From the output, you can determine which neighbors have not replied to the query, and you can track the query path and find out the status of the query by hopping to the neighbors that have not replied.

Methodology for Troubleshooting the Stuck in Active Problem

The methods for troubleshooting an EIGRP stuck in active problem and the show ip eigrp topology active command are useful only when the problem is happening. When the stuck in active event is over and the network stabilizes, it is extremely difficult, if not impossible, to backtrack the problem and find out the cause.

Solution:

The ultimate solution for preventing the EIGRP stuck in active problem is to manually sum-marize the routes whenever possible and to have a hierarchical network design. The more network EIGRP summarizes, the less work EIGRP has to do when a major convergence takes place. Therefore, this reduces the number of queries being sent out and ultimately reduces the occurrence of an EIGRP stuck in active error.

notes: EIGRP BFD

Bidirectional Failure Detection

- its not a feature specific for EIGRP
- rapid detection of failures in forwarding path
- configured on interface and under process.
- only detects the failure, protocol responsible for reacting.
- one session for multiple protocols between peers.
I.E OSPF AND EIGRP only one session.

configuration

process level

router eigrp 100
bfd all-interfaces | bfd interface X/Y

interface level timers

bfd interfal

verification

show bfd neighbor detail

example:

int fa0/0
bfd interval 50 min 50 mult 3

router eigrp 100
bfd interface fa0/1

verification:

show bfd neighbor detail

notes: EIGRP Miscellany

- donot update hop reachability (hub/spoke)

interface
no ip next-hop-self- eigrp AS#

used in a ccie scenario: hub and spoke topology , you will add this in the hub

- Prefix limitations
-neighbor maximum-prefix (#prefix) [options]
- Redistribute maximum-prefix (#prefix) [options]
- options include timers and minutes for resets

useful commands

show ip eigrp neigbhors

show ip eigrp topology (table/RIB)

show ip route eigrp routing table entrisy

EIGRP is very verbose in case something isnt working on a peer.

network commands can take mask info

network 10.1.1.0 0.0.0.0.255

and/0r use passive-interface default



-discovery of BB router AS# via debug

- use acl to look at eigrp only
access-list 101 permit ip any host 224.0.0.10
- then "debug ip packet 101 dump" to view hex dump value of header field
- find hex "E000000A" for 224.0.0.10 and skip ahead five 32-bits words.
- the fifth 32-bit word is the AS value sent or received (wacth debug direction)

* ip : source: d: 224.0.0.10, rcvd 2

find E000000A (224.0.0.10) and count 5 32 bit sections and that is the AS number.

hex 0x00000064 is 100 in decimal, so AS 100 is your other side's AS number.

LAB: EIGRP Default Network and Default information originate

Default Network

Using the command, you can configure a default route for the EIGRP process so that it propagates to other EIGRP routers within the same AS. A router configured with the command considers the network listed in that command as the last-resort gateway. You should define the default route using a static route to ensure it is advertised.

ip default-network {network address}


Default-information:

To control the candidate default routing information for Enhanced Interior Gateway Routing Protocol (EIGRP) processes, use the default-information command in router configuration mode.

default-information {in | out} {access-list-number | access-list-name}

no default-information {in | out}

To suppress EIGRP candidate information in incoming or outbound updates, use the no default-information in command.
i.e to supress 0.0.0.0

no default-information in

notes: EIGRP Bandwith percentage

- EIGRP is designed to use no more than 50 percent of the available bandwidth of a link.
- This restriction means that EIGRP's pacing is tied to the configured bandwidth.

Example

> Suppose an interface is connected to a 512K serial link, but the bandwidth is configured at 128K.
> By default EIGRP would limit itself to 50 percent of the configured amount, in this case 64K.
> The command below adjusts the EIGRP bandwidth percent to 200% of 128K, which is 256K, half of the actual link bandwidth.

-----------
COMMANDS
-----------

- Assumes the physical clock is 512k
- Adjusts the EIGRP bandwidth percent to 200% of 128K
- Which is 256K, half of the actual link bandwidth 512k

interface Serial0
bandwidth 128
ip bandwidth-percent eigrp 1 200

notes: EIGRP Stub Routing

Often used in a hub-and-spoke topology. Only routes you specify are propagated from the stub router. The stub router responds to all queries with the message “inaccessible.” A router configured as a stub sends a special peer information packet to all neighboring routers to report its status as a stub router. Nonstub routers do not query stub routers. The stub routing feature does not prevent routes from being advertised to the stub router. You must configure the summarization or default route behavior.

- A router that has EIGRP stub neighbors will not send queries to those stubs, thereby eliminating the chance that a stub will cause stuck-in-active conditions, and routing instabilities in other parts of the network.
- Stub Routing can also be useful to prevent a router from being used as transit/backup by only sending local updates not containing remote learned routes.

-----------
COMMANDS
-----------

- With detail option: (CONNECTED SUMMARY) shows the configured STUB neighbors

show ip eigrp neighbors [detail]

- Configured on a stub router defining which routes to be sent
- DEFAULT: Only updates containing connected and summary routes will be sent
- Receive-Only]: The stub router will not send any route information in updates

eigrp stub [connected | redistributed | static | summary | receive-only]

stub (connected only)

router eigrp 100
eigrp stub connected

stub with leak-map

The leak-map feature of EIGRP stub, like the leak-map for EIGRP
summarization, allows the advertisement of routes that would normally be
suppressed.

ip prefix-list SW2_LOOPBACK seq 5 permit 150.1.8.0/24
!
route-map STUB_LEAK_MAP deny 10
match ip address prefix-list SW2_LOOPBACK
!
route-map STUB_LEAK_MAP permit 20
!
router eigrp 100
eigrp stub connected leak-map STUB_LEAK_MAP


notes: no validate update source and EIGRP Filtering

for Secondary IPs. - neighbor will not form to the secondary IPs.

router eigrp 100
no validate update source


Filtering:

1. offset-list - the offset-list feature in EIGRP is used to modify the metric on a perroute
basis or a per-interface basis.
- Increases the metric.

#offset-list [ACL] {in|out} {offset} {interface}

router eigrp 100
offset-list 1 in 2147483647 FastEthernet0/3
!
access-list 1 permit 150.1.3.0

2. distribute-list

- Filters all routes matching the ACL or prefix-list

distribute-list {ACL | prefix} {in|out}

std acl:

router eigrp 10
distribute-list 1 in Serial0/0
!
access-list 1 permit 0.0.0.0 255.255.254.255

extended acl:

access-list 100 deny ip host 155.1.0.1 host 150.1.2.0
access-list 100 deny ip host 155.1.0.2 host 150.1.2.0
access-list 100 deny ip host 155.1.0.4 host 150.1.2.0
access-list 100 permit ip any any
!
router eigrp 100
distribute-list 100 in Serial0/0


- Filters all routes to/from a neighbor

distribute-list gateway {prefix-list} {in|out} {interface}

router eigrp 100
distribute-list prefix STOP_RIP_SUBNETS out Serial0/1
!
ip prefix-list STOP_RIP_SUBNETS seq 5 deny 30.0.0.0/14 ge 16 le 16
ip prefix-list STOP_RIP_SUBNETS seq 10 deny 31.0.0.0/14 ge 16 le 16
ip prefix-list STOP_RIP_SUBNETS seq 15 permit 0.0.0.0/0 le 32

- Filters prefix from a specific source from entering the routing table

distribute-list prefix {prefix-routes} gateway {prefix-source} {in|out}

router eigrp 100
distribute-list prefix PERMIT_ALL gateway NOT_FROM_R4 in
!
ip prefix-list NOT_FROM_R4 seq 5 deny 155.1.146.4/32
ip prefix-list NOT_FROM_R4 seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list PERMIT_ALL seq 5 permit 0.0.0.0/0 le 32

- Changes the distance for both internal and external EIGRP routes

distance eigrp {ad-internal} {ad-external}

- Using Route-maps

router eigrp 100
distribute-list route-map FILTER_ON_TAGS in
!
route-map FILTER_ON_TAGS deny 10
match tag 4
!
route-map FILTER_ON_TAGS permit 20


3. Using Admin distance:

distance {AD} {address} {wildcard} {acl#|aclname}

- any source

access-list 4 permit 150.1.4.0
!
router eigrp 100
distance 255 0.0.0.0 255.255.255.255 4

- specific per neighbor

access-list 7 permit 150.1.7.0
!
router eigrp 100
distance 255 155.1.37.7 0.0.0.0 7

4. Using redistribution with route-maps

router eigrp 100
redistribute rip metric 100000 100 255 1 1500 route-map RIP_TO_EIGRP
!
ip prefix-list VLAN_43 seq 5 permit 204.12.1.0/24
!
route-map RIP_TO_EIGRP permit 10
match ip address prefix-list VLAN_43
set tag 4
!
route-map RIP_TO_EIGRP permit 20

notes: EIGRP Summarization

- EIGRP by default, auto-summarizes prefixes to classful boundary when passing major network boundary, but this can be disabled. If auto-summary is enabled, interfaces are summarized at class boundary.
- A route to Null0 for summary routes are created to prevent black-holes.
- Disabling automatic summarization can prevent ambiguous routing between similar network subnets. (It is always recommended)

Manual summarization for EIGRP is interface-specific.

- This provides the flexibility to be able to advertise different summary routes out different interfaces for the same process.
- Manual summarization is configured with the "ip summary-address eigrp" command
- By default this will automatically suppress the advertisement of the more specific networks and create a route to Null0
- To have more specific routes sent, use a leak-map.
- The summary routes advertised into EIGRP are not tagged as external routes, like OSPF.
- The floating summary route is created by applying a default route and an administrative distance at the interface level.

command:

- Disables auto-summary to the classful boundary when passing between major network boundaries (default = Enabled)

no auto-summary

- Will automatically suppress the advertisement of the more specific networks
- Specifies the summary, mask, and the process into which the summary is to be advertised
- [leak-map]:Route-map allows more specific routes + summary to be advertised

int E0
ip summary-address eigrp {ASN} {aggregate} [leak-map] [AD]

- Example of a floating summary route with a higher AD.

ip summary-address eigrp 100 0.0.0.0 0.0.0.0 250

notes: EIGRP Authentication

- EIGRP packets can ONLY be authenticated using an MD5 cryptographic checksum.
- Configured using key-chains.
- EIGRP, unlike RIP requires the same key-number on both sides.
- When configuring, the order of operation is important.
- When doing changes to the keychain, first remove the key-chain off the interface.

- The steps for configuring EIGRP authentication are:

1. Define a key chain with a name.
2. Define the key or keys on the key chain.
3. Enable authentication on an interface and specify the key chain to be used.
4. Optionally configure key management.


-----------
COMMANDS
-----------
verification:

- Shows the configured keys and which are currently valid

sh key chain {name}

- Shows received authentication packets.

debug eigrp packet hello

configuration:

1. define key chain.
Specifies the period a key is valid for
Specifies overlapping times for a key to be accepted

key chain {name}
key {key number}
key-string {string}
send-lifetime {from H:M:S MON DAY YEAR} {to H:M:S MON DAY YEAR}
accept-lifetime {from H:M:S MON DAY YEAR} {to H:M:S MON DAY YEAR}

2. interface config.
- Assigns the key-chain to the interface
- Specifies MD5

interface Serial0
ip authentication key-chain eigrp {ASN} {chain name}
ip authentication mode eigrp {ASN] md5

notes: EIGRP Passive Interface, Split Horizon

- The passive-interface command prevents EIGRP hellos from being sent on data links where they don't belong.
- Will prevent neighbor establishments and routes being advertised, as received hellos will be ignored.

The passive-interface command in EIGRP, like in RIPv2, stops the sending of updates out an interface. Unlike RIPv2 however, passive-interface in EIGRP will stop the forming of an adjacency on the interface, and hence the learning of any updates on the link.

The passive-interface default command can be used to make all interfaces passive, and then interfaces can have the passive feature selectively disabled with the no passive-interface command.



command:

Disables the interface from sending hellos

passive-interface {int}

Split-Horizon

- Is always enabled with EIGRP.
- Remember to disable split-horizon with physical multi-point frame-relay interfaces.

command:

interface eth0
no ip split-horizon eigrp {ASN}

notes: EIGRP DUAL Finite state, SIA

- The lowest calculated metric to each destination will become the feasible distance (FD) of that destination.
- The feasibility condition (FC) is a condition that is met if a neighbor's advertised distance (AD) to a destination, is lower than the router's current FD to that same destination.
- If a neighbor's AD to a destination meets the FC, that neighbor becomes a feasible successor (FS) for that destination.
- Because feasible successors are always "downstream," a router will never choose a path that will lead back through itself, thus creating a loop.
- Such a path would have a distance larger than the FD.
- Every destination for which one or more feasible successors exist, will be recorded in a topology table.
- Each route after inserted, when no diffusing is taking place will be in a passive state.
- If there are two successors with the locally calculated metric equal to the FD, both routes are entered into the route table, and equal-cost load balancing will be performed.
- If a link to a successor fails(input event), or if the cost of the link increases beyond the FD (input event), the router will first look into its topology table for a feasible successor.
- If a FS is found, through local computation, it will become the successor. This occurs in the sub-second range. An update is sent to all neighbors and the route remains in the passive state.
- If a feasible successor cannot be found in the topology table, the router will begin a diffusing computation by querying neighbors for possible routes and the route will change to the active state.
- For each neighbor to whom a query is sent, the router will set a reply status flag (r) to keep track of all outstanding queries.
- The diffusing computation is complete when the router has received a reply to every query sent to every neighbor.
- If all expected replies are not received before the Active time expires, the route is declared stuck-in-active (SIA).
- At the completion of the diffusing computation, the originating router will set FD to infinity to ensure that any neighbor replying with a finite distance to the destination will meet the FC and become a feasible successor.
- Remember that queries cause the diffusing calculation to grow larger, whereas replies cause it to diminish/grow smaller.

SIA

A route is considered stuck-in-active if no response to the query has been received for a configured amount of time (default 3 minutes). After this time, the EIGRP drops all neighbors that it has not received replies from.

command:

active timer - to minimize the effect of SIA

eigrp 100
timers active time 180

notes: EIGRP Packets

- EIGRP uses multiple packet types, they are all identified by protocol number 88 in the IP header.

1. Hellos: Are used by the neighbor discovery and recovery process. Hellos are unicast or multicast and use unreliable delivery.
- Establish neighbor relationships.

2. ACKs: Are Hello packets with no data in them. ACKs are always unicast and use unreliable delivery.
- Acknowledge reliable packets.

3. Updates: Convey route information. Updates could be unicast/multicast and always use reliable delivery.
- Send routing updates.

4. Queries/Replies: Used by DUAL for computations. Queries can be unicast or multicast, but replies are always unicast.
- Ask neighbors about routing information.
- Respond to queries.

- Any reliable multicast packets sent, that was not acknowledged by the neighbor it was sent too, will be followed by a retransmitted unicast packet to that neighbor.
- If an acknowledgement was not received after 16 of these unicast retransmissions, the neighbor will be declared dead.
- Retransmission timeout (RTO) is the time between the subsequent unicasts.
- Smooth round-trip time (SRTT) is the time, between a packet sent to the neighbor and the receipt of an acknowledgment.

EIGRP Reliability

Packets that require acknowledgment are as follows:
- Update
- Query
- Reply

Packet that do not are as follows:
- Hello
- Ack

Neighbor reset after retry limit (16) is reached. Slow neighbors are sent unicast packets instead.

The address used for hello packets is 224.0.0.10; AS numbers must match. Hellos are sent every 5 seconds on broadcast links and point-to-point serial links, point-to-point subinterface links, and multipoint circuits greater than T1. They are sent every 60 seconds on other link types. The hold time defaults to 3 times the hello time. Neighborships form even if the values do not match.

notes: EIGRP Updates

- Updates are multicast to 224.0.0.10.
- Updates are non-periodic, partial and bounded(only to relevant neighbors)
- Can be sent as unicast at a process level with the "neighbor" command.
- But both sides must be configured to use unicast.
- BEWARE: If configured, EIGRP stops processing all multicast packets that come inbound on that interface. Also stops sending multicast packets on that interface.
- BEWARE: Upon configuring all sessions from that interface will be dropped.
- Using an ACL to filter EIGRP traffic between two neighbors are recommended.
- Packets sourced by a router are not passed through an outbound ACL by default.

-----------
COMMANDS
-----------
Defines a unicast session to a neighbor. Required on both sides

router eigrp {asn}
neighbor {ip} {interface}


ACL Applied inbound, as outbound would have no effect
- Denies any EIGRP traffic
- Permit all other traffic

ip access-list 100 deny eigrp any any
ip access-list 100 permit ip any any
!
int eth0
ip access-group 100 in


note: " show ip eigrp neighbor" - neighbor will not show.

show run
show ip protocols

CCIE SCENARIO: you should receive only and shouldnt sent out updates on the interface. passive interface is not an option.

ip access-list 100 deny eigrp any any
ip access-list 100 permit ip any any

distribute-list 100 outh eth0

notes: EIGRP Convergence Timers

- Never change the timers unless asked to.
- Hellos are sent using unicast every 60 sec, on access links with speeds of T1 or slower.
- Hellos are sent using multicast every 5 sec, on all other network links.
- The hold-time interval is 180 sec, on low-speed NBMA networks.
- The hold-time interval is 15 sec, on all other networks.

commands:

- Shows each neighbor in the neighbor table with each timer

show ip eigrp neighbors

- Changes the default hello interval

ip hello-interval eigrp {ASN} {seconds}

note: hello interval @ T1 = 5 seconds, >T1 = 60 seconds.


- Changes the default hold-time

ip hold-time eigrp {ASN} {seconds}