EIGRP only uses the information received from its directly connected neighbors to make routing decisions.

A router only announces the routes its using to its directly connected neighbors. EIGRP doesnt build peer relationships over secondary addresses. All EIGRP traffic is sourced from the primary address. EIGRP store all routes in its routing table, whether its loop-free or not. To see the entire topology table, use show ip eigrp topology all-links instead of show ip eigrp topology network assigns all subnets belonging to the specified major networks to the EIGRP process. EIGRP neighbors are discovered on all the interfaces belonging to the specified major network, and the routing information is exchanged with those neighbors. Vector metric is a 5-element vector containing parameters (bandwidth, delay, load, reliability, and hop count) that describe the distance between a router and the destination subnet. This metric is used in all EIGRP routing updates. Composite metric is an integer number used to compare different routes toward the same destination subnet. Only used internally in the router and never sent to EIGRP neighbors. EIGRP uses triggered routing updates that reflect interface load and reliability at the time of the event. Therefore, load and reliability in EIGRP vector metric are useless. no metric weights reset K-values back to default. By default, metric = 256 * (107/slowest_bandwidth) + 256 * cumulative_delay Poison reverse is advertising a route unreachable (maximum metric) out the interface to which it was received so the originator of the route do not perceive the update as another path toward the network its directly connected to, therefore, avoiding loops. EIGRP uses poison reverse when: - Two routers are exchanging topology table for the first time - Advertising a topology table change - Sending a query When a router changes in such a way that you should advertise a network reversely back to downstream router, split horizon is disabled. You can manipulate EIGRP to mimic other routing protocols by: - To emulate RIP, set delays on all interfaces to equal values and set all Ks, except K3 to 0 - To emulate OSPF, set interface delay to OSPF cost and set all Ks, except K3 to 0 - To select a route with maximum end-to-end bandwidth, set all Ks except K1, to 0. Note: composite metric is always 1 if you set all K-values to 0. Default bandwidth and delay
Interface Type Ethernet Token ring Fddi Serial interface Low-speed serial interface[1] ISDN BRI ISDN PRI Dialer interface Channelized T1 or E1 Async interface Bandwidth (kbps) 10000 16000 100000 1544 115 64[2] 64 56 n * 64 tty line speed Delay (microseconds) 1000 630 100 20000 20000 20000 20000 20000 20000 100000

Loopback

8000000

5000

Setting proper bandwidth is particularly tricky on VLAN interfaces, especially so when different routers attach to the same VLAN through different technology. Its recommended that you set the bandwidth to a sensible value thats the same on all routers attached to the same VLAN. Delay is calculated as a sum of all delays the routers in the path has Bandwidth is the minimum bandwidth of the all interfaces in the path. If router is advertising a directly connected route (its the start router), bandwidth is its interface bandwidth. MTU is also the minimum MTU of all interfaces in the path Hop count is previous hop count + 1

Downstream router (for a subnet) is the router that is closer to the destination subnet and used by current router to forward data packets to the destination subnet. Upstream router (for a subnet) is the router that is closer to the source subnet and uses the current router to forward data packets to the destination subnet. Note: these concepts are relative to a router and a specific flow, not fixed for all routers. To send EIGRP updates, 3 steps are needed: - Individual route updates are enqueued for an interface

- Route updates enqueued for an interface are bundled into a packet when the interface is read to send more EIGRP traffic - Update packet is sent toward individual neighbors reachable over that interface. DUAL logic: - Whenever a router chooses a new successor, it informs all its other neighbors about the new RD - Every time a router selects a successor, it sends a poison update to its source; poison reverse - Poison update is sent to all neighbors on the interface through which the successor is reachable. If split-horizon is turned off, current router only send poison update to source Loss: - Router report a route loss using a normal update packet and delay is set to infinity (-1) - Router report a neighbor loss if an update packet is received from that neighbor with delay set to infinity for every route received from that neighbor - EIGRP handles link loss as the loss of a directly connected subnet + loss of one or more neighbors if there are EIGRP neighbors reachable through the lost interface. An EIGRP router facing increased metric from its successor can find a better route immediately if the new best route goes through a feasible successor. Update packets are send out regarding the new best route. DUAL: Route is marked active in topology table Reply-status table is created to track replies from neighbors Query is sent to neighbors Responses are collected and stored in topology table. Response status of individual neighbors is traced in the reply-status table - Best response is selected in the topology table and the new best route is installed nit he routing table - If necessary, an update is sent to the neighbors to inform the changed topology. Reaction to Query
Condition Action Route not in topology table Reply with infinity. Route already active Reply with current best metric (could be infinity). Query received from nonsuccessor Reply with current best route. Query received only from successor, Reply with infinity. no other EIGRP neighbors Query received from successor Select new best route. If it goes through a feasible successor, reply with new best route, otherwise extend diffused computation. To Display Routes currently under diffused computation Routes currently being converged Whether this router is a potential bottleneck Use the Following Command show ip eigrp topology active show ip eigrp topology pending show ip eigrp neighbor detail

Task Command Change the Stuck-in-Active timeoutrouter eigrp <AS> timers active-time <timeout-in-minutes> Disable the Stuck-in-Active check router eigrp <AS> timers active-time disabled

SIA are usually caused by several route flaps combined with slow-speed or lossy links in large networks. Here are some more general causes:

Flapping interface Configuration change Lossy link Heavily loaded links Misconfiguration of bandwidth parameter Old EIGRP code Routing loops with multiple (E)IGRP processes and redistribution Redistributed IGRP routes Frame Relay

All EIGRP packets share a common header

Where OPCODE can be

OPcode 1 3 4 5 6 Type Update Query Reply Hello IPX SAP

EIGRP can be easily expanded using different TLVs

Number General TLV Types 0x0001 0x0003 0x0004 0x0005 IP-Specific TLV Types 0x0102 0x0103 TLV Type EIGRP Parameters Sequence Software Version 12 Next Multicast Sequence IP Internal Routes IP External Routes

Each TLVs contains the entry type (2 byte), entry length (2 bytes) and entry-specific information. The following are IP internal and External TLVs

Hello protocol is used an unidirectional protocol where each router sends multicast packets over all interfaces on which it runs EIGRP. EIGRP hello packets are always sent from the primary IP address configured on the interface, but the receiving router checks the packets source IP address against all IP subnets configured on the interface. If you reverse primary and secondary subnets on two adjacent routers, EIGRP still works. However, if the primary IP subnet between the neighbor doesn't match, EIGRP doesnt start. Default Hello and hold timer
Interface Encapsulation LAN interface Any WAN interface HDLC or PPP NBMA interface (X.25, Frame Relay, SMDS or Dialer) with bandwidth <= T1 NBMA interface with bandwidth > T1 Point-to-point subinterface over NBMA interface Hello Timer (sec) Hold Timer (sec) 5 15 5 15 60 180 5 5 15 15

When using passive-interface, - No adjacencies are established over the passive interface - No routing updates are accepted over the passive interface - Subnet of the passive interface remains in the EIGRP process and appears in the EIGRP topology table as an internal route. One way to measure the Hello interval is using debugging. However, during loaded times, you should take an extensive sample to determine the average time. Remaining hold time can be displayed using show ip eigrp neighbor RTP support unicast and multicast while TCP only support unicast. ACK (unicast) and Hello (multicast) are not transported using RTP. All reliable multicast packets can also be sent as unicast packet. The unicast version of the packet is used when: - Transmission media doesnt support multicasting. To check, use show ip eigrp interface, unsupported interface has 0/0 in Un/reliable mcasts. - Neighbor didnt acknowledge the packet within multicast timeout interval EIGRP uses the same flow of acknowledge number for both unicast and multicast packets, this means any unicast or multicast packet will not have the same acknowledgment number. EIGRP uses an individual flow for every packet instead of a continuous flow.
Condition Sequence Number Data packets before the first packet Current sequence number is received from remote neighbor Data packets after the first packet Current sequence number is received from remote neighbor ACK packet 0 hello packet 0 ACK Number 0 Last sequence number received from the neighbor Last sequence number received from the neighbor 0

Round trip time (RTT) is defined as the interval between the packet being sent over an interface and the acknowledgement for that packet being received from a neighbor. SRTT is the average of all neighbors reachable over that interface. RTO increases by 50% after each retransmission. After 16 unsuccessful tries, packet is declared dead.

Difference between multicast and unicast packets:n - Must track neighbors that should acknowledge packet and retransmit unacknowledged packets as unicast after RTO timed out. - ACK is always 0. Note: EIGRP has a special mechanism that deal with unacknowledged multicast packets. Recipients of the packets will then receive a unicast copy of the packet instead. This prevents stalling traffic between all neighbors. The number of times such behavior occur is documented in Mcast exceptions from show ip eigrp interface detail EIGRP hello doesnt verify two-way adjacency, but whenever an unknown Hello is heard, this router tries to form an adjacency with it. An EIGRP router tries to exchange its topology table with the new neighbor as soon as its discovered. This causes several initial topology exchange packets to be dropped before this router responded with Hello packet and form adjacency. The initial topology table exchange is signaled by INIT flag in the first update packet sent to the new neighbor. When a neighbor is down, its removed from the neighbor table and a linkdown() event is generated. All routes received from that neighbor are removed from the topology table. All successor routes whose downstream router is the lost neighbor will start local computation or DUAL.
Action Effects on EIGRP Adjacencies No packets are received from the neighbor within hold timer. Neighbor is declared dead. A single reliable packet is retransmitted at least 16 times Neighbor is declared dead. and for a period larger than the hold timer. The interface goes down (line down or line protocol down). All neighbors reachable over that interface are declared dead. The interface is shut down by an operation action. All neighbors reachable over that interface are declared dead. A network is removed from EIGRP process. All neighbors belonging to that network are declared dead.

A change in bandwidth, delay, or MTU size will reset all adjacencies. Change in auto-summary will also reset all adjacencies. An EIGRP router only discovers adjacency reset when the neighbor send it a Hello with INIT flag rather than normal Hello keepalive. However, this probably will cause the other neighbor to time out and declare this neighbor dead, and the problem will have to start again. This approach can result in loss of adjacency for the dead timer.

The only time when EIGRP neighbor logging cant give a lot of information is for SIA events. The adjacency with a nonresponding neighbor is cleared when the EIGRP router experiences an SIA event, but this is not logged using EIGRP neighbor logging. Information can be inserted in the topology table when: - An update packet with non-infinite delay is received - A reply packet with a non-infinite delay is received - A route is redistributed from another routing protocol - A directly connected subnet belong to one of the network become active Information can be updated in the topology table when a query with non-infinite delay is received Information can be deleted from the topology table when: - A neighbor is dead - A redistributed route disappear from the source routing process - Update, query, or reply with infinite delay - Directly connected subnet becomes unreachable Note the next serial in show ip eigrp topology, it shows the number of routes stored in the EIGRP topology table directly affects the memory usage and convergence speed. If the number of routes in an EIGRP topology table is much larger than the number of routes inserted from EIGRP into the IP routing table, it might indicate that your network is too highly meshed or that the EIGRP split horizon is turned off in the wrong place. The next serial field gives you information about the number of changes in the EIGRP topology table; every time a change is introduced into the topology table, the next serial number is increased by one. By monitoring this number over time, you can directly conclude how stable your network is. These are the attributes of external EIGRP route block
Attribute Meaning

Originating router Router ID of the router redistributing external route into this EIGRP process. The router ID is an IP address that follows the same rules as the router ID for OSPF or BGP. AS number AS number of originating BGP or EIGRP process. External protocol The originating protocol from which the route was redistributed into EIGRP. External metric The metric of the redistributed route in the originating protocol. For routes redistributed from OSPF this would be the OSPF cost, for RIP routes the hop count, and for the EIGRP routes the composite metric. Administrator tag 32-bit quantity that can be set in the redistribution point with a route map. Command show ip eigrp topology active show ip eigrp topology pending Printout Displays only the routes for which the diffused computation is performed. Provide approximate time route has entered active state and point out potential bottlenecks. Displays the routes that haven't converged yet (for example, diffused computation is performed or outgoing updates are still pending)

Entries marked with r indicate a waiting reply whereas entries under Remaining replies indicate routers (neighbors) that have not send any information regarding this route to this router before. Local-origin in query-origin indicate local router initiated query. NOTE: - EIGRP may prefer a locally connected subnet with higher FD than remote subnet with lower FD due to local routes have a lower AD. - When an EIGRP router has a route that can be reached using its loopback interface and several other sources, blocking the loopback interface prevents packets for the route being transported using other routes. This route now has no successor and infinite FD - Routes with at least one good successor but ignored due to other sources or routing information can be found with show ip eigrp topology zero-successor The AD becomes the only mean to choosing routes when they are coming from two different EIGRP processes. If they have the same AD, route that was changed more recently (latest flap) takes precedence and replace the older route. Therefore, its mandatory to use different AD for different EIGRP processes if they cover overlapping parts of your network. To change the AD
To Change Default distances for internal and external routes in an EIGRP process Distance of all internal routes received from a neighbor or a set of neighbors Distance of a select set of internal routes received from a neighbor or a set of neighbors Use This Command router eigrp <as distance> <default-internaldistance> <default-external-distance> router eigrp <as> distance <distance> <neighborip-address> <wildcard-bits> router eigrp <as> distance <distance> <neighborip-address> <wildcard-bits> <route-selectionACL>

Variance
Task Configure unequal-cost load balancing Configure proportional load balancing between unequal-cost routes based on composite metric Use only minimum-cost routes for load balancing, rest only for DUAL Configure With router eigrp <as> variance <factor> router eigrp <as> traffic-share balanced

router eigrp <as> traffic-share min acrossinterfaces

Configure the maximum number of equal-cost route eigrp <as> maximum-paths <1 to 6> or unequal-cost routes for a given destination Configure per-packet load balancing over an interface <int> no ip route-cache interface on all platforms Configure Cisco Express Forwarding (CEF) per interface <int> ip route-cache cef ip load-sharing source-destination pair load balancing per-destination Configure CEF per-packet load balancing interface <int> ip route-cache cef ip load-sharing per-packet Switching Path Process switching Fast switching, Optimum switching, Autonomous switching, Silicon switching, Netflow switching Cisco Express Forwarding Cisco Express Forwarding with per-packet load sharing configured Load Sharing Mechanism Per-packet load sharing Per-prefix load sharing (for example, all traffic for a certain prefix in the routing table flows over one interface)

Per source-destination-pair load sharing (for example, all traffic for a certain source-destination IP address pair flows over one interface) Per-packet load sharing

Variance: - Calculate the variance needed for the path you wish to load balance against - Always verify load-balancing works in both directions - If there is more than one router connected to a LAN (or multiaccess network) and you want to load-balance outgoing traffic from that LAN, you need additional mechanisms like HSRP to select proper exit from LAN - You can solve some load-balancing problems where load balancing intuitively works but does not work in reality due to feasible successor limitations by introducing another layer of routers to distribute the traffic. Query should be limited in these types of situations: - Query received when the route is already active - Query received from the only successor with the router having no other EIGRP neighbor. - Query received but the route is not in topology database To reduce EIGRP query diameter, there are generally 2 methods: - Reduce overall EIGRP AS size by enforcing hard boundaries such as using another routing protocol. - Establish query boundaries using EIGRP built-in features such as summarization and stub routers. EIGRP is a protocol that can take abuse before breaking, but a minor event can bring the entire network down. On the other hand, you have to continuously monitor the network to discover potential symptoms of EIGRP overload. Here are some tips: - Use Syslog or any other logging tool to discover an SIA ASAP - Monitor EIGRP traffic with show ip eigrp traffic on the core router. If query number is high, its likely that some remote router cant be able to cope with all the queries - Monitor the number of active routes and the time they stay in active state with show ip eigrp topology active. If the time is long, it indicates a slow response and unstable network if there are many routes. Autosummarization never announce the subnets of one major network into another major network. Only the major network prefix is announce with the metric of the closest subnet (usually a directly connected interface). Logic:

- Whenever an EIGRP process has more than one network defined, it creates a summary route for each of the defined networks as soon as at least one of the subnets of that network is in the EIGRP topology table. This route point to Null0 and uses the smallest metric of a subnet covered by the network. - On router where autosummarization is configured, AD of summary route is 5. However, remember that AD is local to a router. - Subnets of the network are suppressed, only the major network is advertised - Subnets that dont belong to any of the network listed in EIGRP process are not summarized Autosummarization also applies to external routes redistributed into EIGRP. Queries of subnets pass through different networks as the subnet rather than the network (when its summarized) Manual summarization logic: - For each summary range configured over any interface belonging to an EIGRP process, EIGRP process creates a summary route for the summarization range as soon as at least one more specific route falling within the summary range appears in EIGRP topology table. - Summary route created above points to Null0 and minimum metric of all the more specific routes covered by the summary route. Summary route is also inserted into the IP routing table with an AD of 5 - More specific routes summarized are suppressed when updates are sent over the interface where summarization range is configured. Updates send to other interfaces are not affected. Note: subnet with lowest metric must remain stable as flapping cause instability and induce DUAL on router.

EIGRP route filters doesnt apply to all EIGRP packets; query packets are not affected at all. All other EIGRP packets are affected by: - Route received in update packet but rejected by distribute-list in is ignored - Route in topology database but rejected by distribute-list out is not sent in outgoing update packet - Reply packet for a route filtered using distribute-list out is sent with infinite metric - Reply packet for a route filtered using distribute-list in is processed as if it has infinite metric EIGRP route filters always create query boundaries because the router itself doesnt have an entry in its topology database for some subnets filtered by inbound or outbound filters. Default route has 2 sorts of behavior: - Classless: if a default route exist and no more specific subnets has matched the destination, default route is used. - Classful: if a default route exist and no classful networks for which the destination belongs to exist, the default route is used. If a subnet of that classful network exist, but doesnt match the destination IP address, the packet is discarded. Typically, classful works fine when all routes are known by the router. If not, the classless method should be preferred. Default candidate means that they mark the exit from the local routing environment toward another layer that has more routing information. Default candidates are not used as default routes themselves, IOS only use the least routing metric and least AD to choose the best route. The next hop of the best default candidate becomes the gateway of last resort.
Command Results ip default-network Marks the network as default candidate in the IP routing table. Starts <major-network> redistributing the network in all IGRP and EIGRP processes. Marks the network for connected networks in the EIGRP topology database with default candidate flag. ip default-network Marks the network as default candidate in the IP routing table. If the network <major-network> is already in EIGRP topology database, marks the network with default for nonconnected candidate flag. Takes no further actions to insert the network into EIGRP networks topology database. ip default-network Equivalent to ip route <major-network> <mask> <subnet>. Inserts the <subnet> summary route for the major network into which the subnet belongs in the routing table. EIGRP Router Configuration Command default-information in <ACL> default-information out <ACL> no default-information in no default-information out Result Erases the default candidate marker from all received routes not matched by the IP access list <ACL> Erases the default candidate marker from all routes not matched by <ACL> when they are advertised to EIGRP neighbors Does not accept any default candidate markers Does not mark any routes as default candidates in outgoing updates. The router itself still uses the default candidate markers on the routes in the EIGRP topology database to select its own gateway of last resort.

Only routes from the source routing protocol that the router itself uses for packet forwarding are redistributed into the target routing protocol. In other words, redistribution is done from the routing table. If two routing processes are carrying the same information with the same administrative distance, the results are unpredictable. Usually, the route appearing last in the topology

database (the less stable route) overwrites the previous route that came into the routing table from another routing protocol with the same administrative distance. Switched WAN network provide more challenge to implementing EIGRP as no multicasting is supported.
Challenge Output drops due to emulated multicasts Solution Extend the output queue length Divide the neighbors across several subinterfaces Configure broadcast queue Neighbor maps are hard to maintain Applicable WAN Technology All All Frame Relay Use automatic PVC discovery Frame Relay and ATM Use subinterfaces

Frame Relay

Build dynamic maps using inverse ARP Neighbors reachable over one interface have to handled in different ways

All

Multicasts can only be emulated by creating several copies of the unicast packets and send to neighbors that have broadcast option configured on the DLCI. All the copies are created at a time and send to the interface output queue in a burst. No shaping or rate limiting is performed on these packets. The results of these traffic bursts are usually output queue overloads, and associated output drops whenever a large number of neighbors are reachable over the same interface. Solution: subinterfaces Another drawback is the significant amount of jitter introduced by large multicast traffic bursts. To design the Frame Relay broadcast queue, you should consider: - The only multicast packets generated by EIGRP over Frame Relay are the hello packets that are sent every hello-interval seconds and are approximately 40 bytes long unless the Frame Relay network supports Frame Relay level multicasting configured with the frame-relay multicast-dlci command. - The maximum overall byte rate should not exceed one quarter of the local interface speed (or access rate) to prevent local congestion. The per-neighbor byte rate (overall byte rate divided by the number of neighbors) should not exceed one quarter of the slowest remote access rate or one quarter of the smallest CIR to prevent remote congestion. - The number of packets sent per second (packet-rate) should not exceed the output queue size minus some safety margin. A good value in uncongested networks would be three quarters of the output queue. - The overall broadcast queue size must be large enough to prevent multicast packet drops. EIGRP pacing prevents WAN link overload by emitting the EIGRP packets onto the WAN link in predefined time intervals. When designing the network, you specify the overall bandwidth available to EIGRP by using the bandwidth configuration command on the interface to indicate physical or logical interface bandwidth and the ip bandwidth-percent eigrp configuration command to indicate the interface bandwidth percentage available to EIGRP.

Different intervals are used for reliable packets (update, query and reply), which can be as large as MTU of the interface and for unreliable packets that have fixed length. Both pacing interval are displayed in show ip eigrp interface

Minimum reliable_pacing_interval is 10 msec and there is no minimum for unreliable_pacing_interval. Bandwidth available to EIGRP over an interface is shared between all EIGRP neighbors reachable over that interface. Round-robin mechanism is used. Every time EIGRP is allowed to send another packet to the interface, a packet is emitted from a different per-neighbor output queue. You can estimate the length of an individual per-neighbor output queue from the Q Cnt field displayed with the show ip eigrp neighbor command General EIGRP pacing design: 1. Compute VC_based_EIGRP_bandwidth = slowest_VC_speed * EIGRP_bandwidth_percentage * number_of_neighbors 2. Compute physical_EIGRP_bandwidth = physical_interface_speed * EIGRP_bandwidth_percentage If the sum of all VCs bandwidth < physical interface bandwidth, design is complete. Use VC-based EIGRP bandwidth to compute either bandwidth or ip bandwidth-percent eigrp command. If the sum of all VCs bandwidth > physical interfaces bandwidth, reduce VCbased EIGRP bandwidth. The VC-based EIGRP bandwidth of all routers connected to the other ends of affected VCs must also be adjusted to reduce the EIGRP load received by the affected router. EIGRP bandwidths on a virtual circuit must be symmetrical. The design rules compute the EIGRP bandwidth available to outgoing traffic, but the same limitations have to apply to incoming traffic, otherwise the incoming EIGRP traffic could overload your WAN link. Whenever possible, you should use default routes or route summarization and not to disable split horizon. Disabling split horizon increases EIGRP topology database on the remote routers and the traffic generated. Change split horizon settings on an interface ([no] ip split-horizon eigrp ASN) resets all the adjacencies with EIGRP neighbors. EIGRP implementations over Frame Relay usually suffer from the following symptoms: - Slow convergence due to very long hello intervals and hold timers, unless you use pointto-point interfaces where the default values for hello interval and hold timer are 5 and 15 seconds - Retransmissions and output drops due to misconfigured interface bandwidths or badly designed EIGRP pacing - Heavy EIGRP traffic due to nonscalable network design, lack of query boundaries, or misplacement of the query boundaries

EIGRP implementations over ATM are usually straightforward; the speed of a typical ATM link is usually high enough to make any EIGRP WAN-related issues irrelevant. However, a few caveats do exist, even in the ATM environment: - Similar to X.25, ATM uses map statements to specify mapping between ATM PVCs or ATM NSAPs and the IP addresses of the remote routers. These map statements have to include a broadcast option for EIGRP to work correctly. - EIGRP does not work well if the ATM cloud is implemented with Classical IP over ATM (RFC 1577) encapsulation. Due to the way IP multicast packets are propagated within the ATM network configured as Classical IP over ATM, EIGRP adjacencies are established only between the ARP server and other routers, resulting in all the IP traffic being routed through the ARP server. EIGRP MD5 authentication assign every EIGRP packet with an MD5 hash, which: - Changes half the hash if a single bit in the original message changes - Make forge very hard to achieve - Security relies exclusively on shared secret (password), which should be periodically changed.

Key chain rules:

- If several keys have an overlapping send-lifetime, key with lowest sequence number are used - If several keys have an overlapping accept-lifetime, incoming packets can be signed with any one of those keys. Key number must match between routers to form neighborship If R1 try to match the latter (in situation of 2 or more keys in the key chain) to check on authentication, R2 can't establish authentication check regardless whether it had the correct/wrong password, matching/unmatching key number/chain. Note these shortcomings when designing a highly secure EIGRP network: - EIGRP packets are only authenticated, not encrypted. The information exchange is reliable, but not confidential. Intruder can still obtain information based on routing information exchange - Passwords must be manually configured - Passwords are stored in router configuration in plain text format EIGRP leaking routes allow a subnet, along with its aggregate, to be advertised. This is done using ip summary-address eigrp ASN x.x.x.x y.y.y.y leak-map NAME command. Note that if the route map is nonexistent, keyword has no effect. However, if the route map exists but the ACL doesnt exist, or no ACL is referred, the summary address and all subnets routes are sent.