Question 1: User(s) are complaining of delays when using the network. What would you do?

Answer: I would first try to get the user to identify what network resource is slow (email, external web browsing, intranet, network file access, etc.) I would probably also have the user swap locations with another co-worker to identify if the problem lies in the hardware (computer, network cable, switch port, etc.) that is specific to that location. I would check the rest of the network. If there's someone on there that is using lots of bandwidth, that's your problem. For example, multiple people on the network trying to watch videos (especially high quality) would use more bandwidth, someone using P2P software like Kazaa or Torrents would use lots, and generally doing anything that requires lots of streaming or downloading. If neither user identifies a difference, then I would chalk it up to poorly managed expectations and work to explain to the user that just because this is a business network, it doesn't necessarily mean that it'll be faster than their single machine on cable/dsl at home. However, if both users see a difference, then I'd investigate the items that are specific to the slow machine's network. For example, I'd check that the switch port is set to full duplex, that the computer's network drivers are up to date, etc.
Q. Does EIGRP require an ip default-network command to propagate a default route?
A. Although EIGRP can propagate a default route using the default network method, it is not required. EIGRP redistributes default routes directly.

Q. Should I always use the eigrp log-neighbor-changes command when I configure EIGRP?
A. Yes, this command makes it easy to determine why an EIGRP neighbor was reset. This reduces troubleshooting time.

Q. Does EIGRP support secondary addresses?

A. EIGRP does support secondary addresses. Since EIGRP always sources data packets from the primary address, Cisco recommends that you configure all routers on a particular subnet with primary addresses that belong to the same subnet. Routers do not form EIGRP neighbors over secondary networks. Therefore, if all of the primary IP addresses of routers do not agree, problems can arise with neighbor adjacencies.

Q. What debugging capabilities does EIGRP have?

A. There are protocol-independent and -dependent debug commands. There is also a suite of show commands that display neighbor table status, topology table status, and EIGRP traffic statistics. Some of these commands are:

show ip eigrp neighbors

show ip eigrp interfaces show ip eigrp topology show ip eigrp traffic

Q. What does the word serno mean on the end of an EIGRP topology entry when you issue the show ip eigrp topology command?
A. For example:

show ip eigrp topology P 172.22.71.208/29, 2 successors, FD is 46163456 via 172.30.1.42 (46163456/45651456), Serial0.2, serno 7539273 via 172.30.2.49 (46163456/45651456), Serial2.6, serno 7539266
Serno stands for serial number. When DRDBs are threaded to be sent, they are assigned a serial number. If you display the topology table at the time an entry is threaded, it shows you the serial number associated with the DRDB. Threading is the technique used inside the router to queue items up for transmission to neighbors. The updates are not created until it is time for them to go out the interface. Before that, a linked list of pointers to items to send is created (for example, the thread). These sernos are local to the router and are not passed with the routing update.

Q. What percent of bandwidth and processor resources does EIGRP use?

A. EIGRP version 1 introduced a feature that prevents any single EIGRP process from using more than fifty percent of the configured bandwidth on any link during periods of network convergence. Each AS or protocol (for instance, IP, IPX, or Appletalk) serviced by EIGRP is a separate process. You can use the ip bandwidth-percent eigrp interface configuration command in order to properly configure the bandwidth percentage on each WAN interface. Refer to the EIGRP White Paper for more information on how this feature works.

Pacing Packets
Some routing protocols consume all of the available bandwidth on a low bandwidth link while they are converging (adapting to a change in the network). EIGRP avoids this congestion by pacing the speed at which packets are transmitted on a network, thereby using only a portion of the available bandwidth. The default configuration for EIGRP is to use up to 50 percent of the available bandwidth, but this can be changed with the following command:

router(config-if)# ip bandwidth-percent eigrp 2 ? <1-999999> Maximum bandwidth percentage that EIGRP may use
Essentially, each time EIGRP queues a packet to be transmitted on an interface, it uses the following formula to determine how long to wait before sending the packet:

(8 * 100 * packet size in bytes) / (bandwidth in kbps * bandwidth percentage)

For instance, if EIGRP queues a packet to be sent over a serial interface that has a bandwidth of 56k, and the packet is 512 bytes, EIGRP waits:

(8 * 100 * 512 bytes) / (56000 bits per second * 50% bandwidth) (8 * 100 * 512) / (56000 * 50) 409600 / 2800000 0.1463 seconds

This allows a packet (or groups of packets) of at least 512 bytes to be transmitted on this link before EIGRP sends its packet. The pacing timer determines when the packet is sent, and is typically expressed in milliseconds. The pacing time for the packet in the above example is 0.1463 seconds. There is a field in show ip eigrp interface that displays the pacing timer, as shown below:

router# show ip eigrp interface IP-EIGRP interfaces for process 2 Xmit Queue Pending Interface Routes Se0 0 Se1 0 router# Peers 1 1 Un/Reliable 0/0 0/0 Mean SRTT 28 44 Pacing Time Un/Reliable 0/15 0/15 Multicast Flow Timer 127 211

The time displayed is the pacing interval for the maximum transmission unit (MTU), the largest packet that can be sent over the interface. In addition, the implementation of partial and incremental updates means that EIGRP sends routing information only when a topology change occurs. This feature significantly reduces bandwidth use. The feasible successor feature of EIGRP reduces the amount of processor resources used by an autonomous system (AS). It requires only the routers affected by a topology change to perform route re-computation. The route recomputation only occurs for routes that were affected, which reduces search time in complex data structures.

Q. Does EIGRP support aggregation and variable length subnet masks?

A. Yes, EIGRP supports aggregation and variable length subnet masks (VLSM). Unlike Open Shortest Path First (OSPF), EIGRP allows summarization and aggregation at any point in the network. EIGRP supports aggregation to any bit. This allows properly designed EIGRP networks to scale exceptionally well without the use of areas. EIGRP also supports automatic summarization of network addresses at major network borders.

Q. Does EIGRP support areas?

A. No, a single EIGRP process is analogous to an area of a link-state protocol. However, within the process, information can be filtered and aggregated at any interface boundary. In order to bound the propagation of routing information, you can use summarization to create a hierarchy.

Q. Can I configure more than one EIGRP autonomous system on the same router?
A. Yes, you can configure more than one EIGRP autonomous system on the same router. This is typically done at a redistribution point where two EIGRP autonomous systems are interconnected. Individual router interfaces should only be included within a single EIGRP autonomous system. Cisco does not recommend running multiple EIGRP autonomous systems on the same set of interfaces on the router. If multiple EIGRP autonomous systems are used with multiple points of mutual redistribution, it can cause discrepancies in the EIGRP topology table if correct filtering is not performed at the redistribution points. If possible, Cisco recommends you configure only one EIGRP autonomous system in any single autonomous system. You can also use another protocol, such as Border Gateway Protocol (BGP), in order to connect the two EIGRP autonomous systems.

Q. If there are two EIGRP processes that run and two equal paths are learned, one by each EIGRP process, do both routes get installed?
A. No, only one route is installed. The router installs the route that was learned through the EIGRP process with the lower Autonomous System (AS) number. In Cisco IOS Software Releases earlier than 12.2(7)T, the router installed the path with the latest timestamp received from either of the EIGRP processes. The change in behavior is tracked by Cisco bug ID CSCdm47037.

Q. What does the EIGRP stuck in active message mean?

A. When EIGRP returns a stuck in active (SIA) message, it means that it has not received a reply to a query. EIGRP sends a query when a route is lost and another feasible route does not exist in the topology table. The SIA is caused by two sequential events:

The route reported by the SIA has gone away. An EIGRP neighbor (or neighbors) have not replied to the query for that route.

When the SIA occurs, the router clears the neighbor that did not reply to the query. When this happens, determine which neighbor has been cleared. Keep in mind that this router can be many hops away.

Q. What Does the EIGRP DUAL-3-SIA Error Message Mean?

A. Background

Information

Routes that have a valid successor are said to be in a passive state. If, for some reason, a router loses a route through its successor and does not have a feasible successor for that route, then the route transitions to an active state. In the active state, a router sends queries out to its neighbors requesting a path to the lost route. When an EIGRP neighbor receives a query for a route, it behaves as follows:

If the EIGRP topology table does not currently contain an entry for the route, then the router immediately replies to the query with an unreachable message, stating that there is no path for this route through this neighbor. If the EIGRP topology table lists the querying router as the successor for this route and a feasible successor exists, then the feasible successor is installed and the router immediately replies to the query. If the EIGRP topology table lists the querying router as the successor for this route and a feasible successor does not exist, then the router queries all of its EIGRP neighbors except those sent out the same interface as its former successor. The router will not reply to the querying router until it has received a reply to all queries that it originated for this route. If the query was received from a neighbor that is not the successor for this destination, then the router replies with its successor information.

What Causes the EIGRP DUAL-3-SIA Error Message?

The DUAL-3-SIA error message indicates that an EIGRP route is in the stuck in active (SIA) state. The SIA state means that an EIGRP router has not received a reply to a query from one or more neighbors within the time allotted (approximately 3 minutes). When this happens, EIGRP clears the neighbors that did not send a reply and logs a DUAL-3-SIA error message for the route that went active. Consider the following topology as an example:

R2 learns about network 10.1.2.0/24 via R1. The link between R1 and R2 goes down. R2 looses its successor (R1) for 10.1.2.0/24. R2 checks the EIGRP topology table for a feasible successor (another neighbor with a route to 10.1.2.0/24 that meets the feasibility condition); it has none. R2 transitions from passive to active for 10.1.2.0/24. R2 sends queries to R3 and R5, asking if they have another path to 10.1.2.0/24. The SIA timer starts. R5 checks the EIGRP topology table for a feasible successor; it has none. R5 transitions from passive to active for 10.1.2.0/24. R5 checks its EIGRP neighbor table and only finds EIGRP neighbors out the interface facing R2 (its former successor for 10.1.2.0/24). R5 replies with an unreachable message because it has no alternative path and has no other neighbors to query. R5 transitions from active to passive for 10.1.2.0/24. R3 checks the EIGRP topology table for a feasible successor; it has none. R3 transitions from passive to active for 10.1.2.0/24. R3 checks its EIGRP neighbor table and finds R4. R3 sends a query to R4 for network 10.1.2.0/24. The SIA timer starts. R4 never receives the query either due to problems with the link between R3 and R4 or congestion. You can see this problem by issuing either the show ip eigrp neighbor command or the show ip eigrp topology active command on R3; the queue count for R4 should be higher than usual. The SIA timer on R2 reaches approximately 3 minutes. R3 can not reply to R2s query until it hears a reply from R4. R2 logs a DUAL-3-SIA error for network 10.1.2.0/24 and clears the neighbor adjacency with R3.

DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.4.3 (Serial0) is down: stuck in active DEC 20 12:15:23: %DUAL-3-SIA: Route 10.1.2.0/24 stuck-in-active state in IP-EIGRP 1. Cleaning up
R3s retry timer for R4 expires. Note: This event prevents R3 from also reporting a DUAL-3-SIA error because R3s SIA timer may also be about to reach 3 minutes.

R3 clears its neighbor adjacency with R4. R3 reports the following error to its log:

DEC 20 12:12:01: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.5.4 (Serial1) is down: retry limit exceeded

R3 now replies to R2s query with an unreachable message. R4 reports the following error to its log:

DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1: Neighbor 10.1.5.3 (Serial0) is down: peer restarted

Note: The DUAL-5-NBRCHANGE messages will only be displayed if you have configured the eigrp log-neighborchanges command under the EIGRP process. Configuring this command on all EIGRP routers is recommended for troubleshooting EIGRP SIA problems. Without it, there is no way to tell why EIGRP neighbors are being reset or which router reset the adjacency. As you can see above, the DUAL-3-SIA error is caused by the following concurrent, yet unrelated, problems: 1. An interface problem between R1 and R2, which causes the 10.1.2.0/24 route to disappear from R2. The route flap may have been caused by something other than an actual link failure (for instance, a remote user disconnected and the PPP-derived host route is then removed). An interface, congestion, or delay problem between R3 and R4.

2.

When the SIA error message occurs, it indicates that the EIGRP routing protocol failed to converge for the specified route. Usually, this failure is caused by a flapping interface, a configuration change, or dialup clients (the route loss is normal). The routing to other destinations is not affected while the EIGRP process is in active state for the specified route. When the SIA timer for the neighbor that did not reply expires, the neighbor is cleared (EIGRP does not trust the state of a neighbor that exceeds the timer). As a consequence, routes in the topology table beyond that neighbor are cleared and must then re-converge. This means that the forwarding table can be effected by an SIA, and that packets can be dropped while the network is converging.

Resolving DUAL-3-SIA Problems

This section provides the steps necessary to troubleshoot SIA issues and provides common causes of SIA issues. Although there are many different ways in which an SIA can occur, the problem should always be approached in the same manner. Whenever you troubleshoot SIA errors, you should answer the following two questions (listed in order of urgency) to identify the possible causes of the SIA. 1. 2. Why did the router not get a response from all of its neighbors? Why did the route disappear?

Note: With Cisco bug ID CSCdp33034 (registered customers only) effective with Cisco IOS Software Release 12.1(4.4)Ethe following enhancements have been made to help resolve the SIA problem:

The router leaves a trail to the source of the SIA event. The detection and correction of a SIA event is pushed to the failing link.

Use these commands to gather more details for troubleshooting:

show ip eigrp neighbors from both ends show log | in DUAL show ip eigrp topology active

Why Did the Router Not Get a Response from All of its Neighbors?
Unfortunately, this question is the hardest part of troubleshooting SIAs. Because the SIA timer is a little over 3 minutes by default, it is necessary to track down an unresponsive router within this time period. To do so, make sure that you have a network topology diagram that includes all routers in the network along with their IP addresses. You should also have the Telnet password for each router. With this information in hand, go to the router that has been reporting SIAs and watch for that route or other routes to go active. You can determine which routes are active on a router by issuing the show ip eigrp topology active command. It is normal for this command to list some active routes. The existence of an active route does not, by itself, indicate a problem; pay particular attention to routes that have been active for longer than one minute.

R2# show ip eigrp topology active IP-EIGRP Topology Table for process 1 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status A 10.1.2.0 255.255.255.0, 1 successors, FD is 2733056 1 replies, active 0:00:38, query-origin: Multiple Origins !--- The output above will appear on one line. via 10.1.4.3 (Infinity/Infinity), r, Serial0, serno 1232 via 10.1.6.5 (Infinity/Infinity), Serial1, serno 1227
The output above tells you that EIGRP has been active for 10.1.2.0/24 for 38 seconds, has queried two neighbors, and is still waiting on a reply from 10.1.4.3. The lowercase r indicates that the router is waiting for a reply to a query. A capital R indicates that it received a reply from this neighbor. Depending on the state of the topology table when you issue this command, you can also see the neighbor in a separate section called Remaining Replies. Once you identify from which router EIGRP is awaiting a response, you can Telnet to that router to determine for what EIGRP is waiting. This process should eventually lead to the actual router that is not responding to queries. Once you identify this router, troubleshoot why it is not responding to queries. Several common reasons are explained below.

Use of older EIGRP code (Cisco IOS Releases earlier than 10.3[11], 11.0[8], and 11.1[3])
EIGRP was enhanced in Cisco IOS Software Releases 10.3(11), 11.0(8), and 11.1(3). One of these enhancements prevents any single EIGRP process from using more than 50 percent of the available bandwidth for that link; you can adjust this percentage, which may differ on multipoint interfaces. This enhancement uses pacing, which allows EIGRP packets to be delivered more reliably on congested links. For more information on packet pacing, refer to the Enhanced Interior Gateway Routing Protocol White Paper.

Missing or incorrect bandwidth interface configuration parameter

If the bandwidth statement is not properly configured for an interface or subinterface, EIGRP can not properly pace EIGRP data packets. The default value of the bandwidth parameter for a serial interface is T1 or 1500 kbps. For serial interfaces other than T1sincluding fractional or channelized T1 interfacesthis parameter must be manually set to reflect the correct bandwidth based on the interfaces clock rate. Never use the bandwidth parameter to influence EIGRP path selection.

Incorrect bandwidth configured to influence path selection

In the case of redundant paths, a common practice to force a routing protocol to select one path instead of another is to modify the bandwidth parameter on the interface. Configuring an artificially low bandwidth value on one interface prevents the routing protocol from using the path across that interface. You should avoid this method with EIGRP, as it also uses this bandwidth setting for EIGRP packet pacing. To influence EIGRP path selection on an interface basis, use the delay interface configuration parameter. You should always ensure that the bandwidth parameter is set to the actual available bandwidth for the interface or subinterface.

EIGRP routing loops

Routing loops can also cause SIA errors. You can identify this problem using the show ip eigrp topology active command. If you see a circular pattern of unanswered EIGRP queries, continue troubleshooting the issue as a routing loop problem.

Mismatched primary and secondary addresses

--R1 --interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip address 10.2.1.1 255.255.255.0 secondary ! --R2 --interface Ethernet0 ip address 10.2.1.2 255.255.255.0 !
In the example above, R1 receives EIGRP hello packets from R2, and shows R2 as an EIGRP neighbor. However, R2 does not see R1 as a neighbor because R1s hello packets are sourced from 10.1.1.1, which is not a subnet that R2 recognizes. In later versions of Cisco IOS Software, R2 will return the neighbor not on common subnet error. This error causes SIAs because queries sent from R1 to R2 are never answered. To see if R1 continually clears R2 as a neighbor, use the show ip eigrp neighbor command.

Router with limited resources

A lack of system resourcessuch as CPU, memory, or bufferscan also prevent a router from replying to queries or from processing packets of any type. To identify a problem with resources, ping the affected router and troubleshoot it as if it were any other router resource problem.

Why Did the Route Disappear?

There are several common causes of flapping routes, explained below.

A flapping link. Use the show interface command to look for an increasing interface resets or carrier transitions counter.

A degraded WAN link. Use the show interface command to look for an increasing input errors or output errors counter.

A dialup serversuch as a Cisco AS5800which has not been configured to summarize host routes created by the dialup PPP links. By default, PPP connections install a 32-bit host route for the remote side of the PPP link. If these routes are not aggregated, EIGRP goes active when every dialup user disconnects.

Q. What does the neighbor statement in the EIGRP configuration section do?
A. The neighbor command is used in EIGRP in order to define a neighboring router with which to exchange routing information. Due to the current behavior of this command, EIGRP exchanges routing information with the neighbors in the form of unicast packets whenever the neighbor command is configured for an interface. EIGRP stops processing all multicast packets that come inbound on that interface. Also, EIGRP stops sending multicast packets on that interface. The ideal behavior of this command is for EIGRP to start sending EIGRP packets as unicast packets to the specified neighbor, but not stop sending and receiving multicast packets on that interface. Since the command does not behave as intended, the neighbor command should be used carefully, understanding the impact of the command on the network.

Q. Why does the EIGRP passive-interface command remove all neighbors for an interface?
A. The passive-interface command disables the transmission and receipt of EIGRP hello packets on an interface. Unlike IGRP or RIP, EIGRP sends hello packets in order to form and sustain neighbor adjacencies. Without a neighbor adjacency, EIGRP cannot exchange routes with a neighbor. Therefore, the passive-interface command prevents the exchange of routes on the interface. Although EIGRP does not send or receive routing updates on an interface configured with the passive-interface command, it still includes the address of the interface in routing updates sent out of other non-passive interfaces. Refer to How Does the Passive Interface Feature Work in EIGRP? for more information.

Q. Why are routes received from one neighbor on a point-to-multipoint interface that runs EIGRP not propagated to another neighbor on the same point-to-multipoint interface?
A. The split horizon rule prohibits a router from advertising a route through an interface that the router itself uses to reach the destination. In order to disable the split horizon behavior, use the no ip split-horizon eigrp as-number interface command. Some important points to remember about EIGRP split horizon are:

Split horizon behavior is turned on by default.

When you change the EIGRP split horizon setting on an interface, it resets all adjacencies with EIGRP neighbors reachable over that interface. Split horizon should only be disabled on a hub site in a hub-and-spoke network. Disabling split horizon on the spokes radically increases EIGRP memory consumption on the hub router, as well as the amount of traffic generated on the spoke routers. The EIGRP split horizon behavior is not controlled or influenced by the ip split-horizon command.

For more information on split horizon and poison reverse, refer to Split Horizon and Poison Reverse. For more information on commands, refer to EIGRP Commands.

Q. When I configure EIGRP, how can I configure a network statement with a mask?
A. The optional network-mask argument was first added to the network statement in Cisco IOS Software Release 12.0(4)T. The mask argument can be configured in any format (such as in a network mask or in wild card bits). For example, you can use network 10.10.10.0 255.255.255.252 or network 10.10.10.0 0.0.0.3.

Q. I have two routes: 172.16.1.0/24 and 172.16.1.0/28. How can I deny 172.16.1.0/28 while I allow 172.16.1.0/24 in EIGRP?

A. In order to do this you need to use a prefix-list as shown here:

router eigrp 100 network 172.16.0.0 distribute-list prefix test in auto-summary no eigrp log-neighbor-changes ! ip prefix-list test seq 5 permit 172.16.1.0/24
This allows only the 172.16.1.0/24 prefix and therefore denies 172.16.1.0/28. Note: The use of ACL and distribute-list under EIGRP does not work in this case. This is because ACLs do not check the mask, they just check the network portion. Since the network portion is the same, when you allow 172.16.1.0/24, you also allow 172.16.1.0/28.

Q. I have a router that runs Cisco Express Forwarding (CEF) and EIGRP. Who does loadbalancing when there are multiple links to a destination?
A. The way in which CEF works is that CEF does the switching of the packet based on the routing table which is populated by the routing protocols such as EIGRP. In short, CEF does the load-balancing once the routing protocol table is calculated. Refer to How Does Load Balancing Work? for more information on load balancing.

Q. How can I use only one path when a router has two equal cost paths?
A. Configure the bandwidth value on the interfaces to default, and increase the delay on the backup interface so that the router does not see two equal cost paths.

Q. What is the difference in metric calculation between EIGRP and IGRP?

A. The EIGRP metric is obtained when you multiply the IGRP metric by 256. The IGRP uses only 24 bits in its update packet for the metric field, but EIGRP uses 32 bits in its update packet for the metric field. For example, the IGRP metric to a destination network is 8586, but the EIGRP metric is 8586 x 256 = 2,198,016. Integer division is used when you divide 10^7 by minimum BW, so the calculation involves integer division, which leads to a variation from manual calculation.

Q. What is the EIGRP Stub Routing feature?

A. The Stub routing feature is used to conserve bandwidth by summarizing and filtering routes. Only specified routes are propagated from the remote (Stub) router to the distribution router because of the Stub routing feature. For more information about the stub routing feature, refer to EIGRP Stub Routing. The EIGRP stub feature can be configured on the switch with the eigrp stub command, and it can be removed with the no eigrp stub. When you remove the eigrp stub command from the switch, the switch that runs the IP Base image throws the error:

EIGRP is restricted to stub configurations only

This issue can be resolved if you upgrade to Advanced Enterprise Images. This error is documented in CSCeh58135.

Q. How can I send a default route to the Stub router from the hub?
A. Do this under the outbound interface on the hub router with the ip summary-address eigrp X 0.0.0.0 0.0.0.0 command. This command suppresses all the more specific routes and only sends the summary route. In the case of the 0.0.0.0 0.0.0.0, it means it suppresses everything, and the only route that is in the outbound update is 0.0.0.0/0. One drawback to this method is that EIGRP installs a 0.0.0.0/0 route to Null0 is the local routing table with an admin distance of 5.

Q. How EIGRP behaves over a GRE tunnel compared to a directly connected network?
A. EIGRP will use the same administrative distance and metric calculation for the GRE tunnel. The cost calculation is based on bandwidth and delay. The bandwidth and delay of the GRE tunnel will be taken from the tunnel interface configured on the router. The tunnel will also be treated like a directly connected network. If there are two paths to reach a network either through a VLAN interface or tunnel interface, EIGRP prefers the Virtual-Access Interface (VAI) VLAN interface because the VLAN interface has greater bandwidth than the tunnel interface. In order to influence the routing through the tunnel interface, increase the bandwidth parameter of the tunnel interface, or increase the delay parameter of the VLAN interface.

Q. What is an offset-list, and how is it useful?

A. The offset-list is an feature used to modify the composite metrics in EIGRP. The value configured in the offset-list command is added to the delay value calculated by the router for the route matched by an access-list. An offset-list is the preferred method to influence a particular path that is advertised and/or chosen.

Q. How can I tag external routes in EIGRP?

A. You can tag routes that EIGRP has learned from another routing protocol using a 32 bit tag value. Starting with ddts CSCdw22585, internal routes can also be tagged. However, the tag value cannot exceed 255 due to packet limitations for internal routes.

Q. What are the primary functions of the PDM?

. EIGRP supports 3 protocol suites: IP, IPv6, and IPX. Each of them has its own PDM. These are the primary functions of PDM:

Maintaining the neighbor and topology tables of EIGRP routers that belong to that protocol suite Building and translating protocol specific packets for DUAL Interfacing DUAL to the protocol specific routing table Computing the metric and passing this information to DUAL; DUAL handles only the picking of the feasible successors (FSs) Implement filtering and access lists. Perform redistribution functions to/from other routing protocols.

Q. What are the various load-balancing options available in EIGRP?

A. The offset-list can be used to modify the metrics of routes that EIGRP learns through a particular interface, or PBR can be used.

EIGRP Adjacencies and Secondary Addresses

I've read some non-Cisco documentation that EIGRP will not allow adjacencies to form when secondary addresses are used. This is incorrect, but there is one common error that can result if both addresses are not secondary. To fully prepare for the 642-901 BSCI exam, you should know about this error. Let's take a look at R2 and R3, which will be using secondary addresses to form an EIGRP adjacency across an ethernet segment. R2(config)#interface ethernet0 R2(config-if)#ip address 172.12.23.2 255.255.255.0 R2(config-if)#ip address 23.23.23.2 255.255.255.0 secondary R2(config)#router eigrp 100 R2(config-router)#no auto-summary R2(config-router)#network 23.23.23.0 0.0.0.255 R3(config)#interface ethernet0 R3(config-if)#ip address 172.12.23.3 255.255.255.0 R3(config-if)#ip address 23.23.23.3 255.255.255.0 secondary R3(config)#router eigrp 100

R3(config-router)#no auto-summary R3(config-router)#network 23.23.23.0 0.0.0.255 Here's the partial output of show ip eigrp neighbor on R3: R3#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface 0 172.12.23.2 Et0 The adjacency has formed! Note the address is actually the primary IP address on the interface, even though we used the secondary network number in the EIGRP network command. Personally, I stay away from secondary network numbers if at all possible, but you should know that secondary IP addresses can be used to create EIGRP adjacencies. What's the common error with using secondary addresses, you asked? It's when an address from the same subnet is the primary interface address on one neighbor and the secondary interface address on another. Let's say we had configured R2 and R3 as follows: R2(config)#int e0 R2(config-if)#ip address 23.23.23.2 255.255.255.0 R3(config)#interface ethernet0 R3(config-if)#ip address 172.12.23.3 255.255.255.0 R3(config-if)#ip address 23.23.23.3 255.255.255.0 secondary On R2, we get this message: 01:54:05: IP-EIGRP: Neighbor 172.12.23.3 not on common subnet for Ethernet0 (23.23.23.2 255.255.255.0) Since we configured 23.23.23.2 as a primary interface address on R2, the EIGRP process is looking at the primary interface address on potential neighbors. R3's primary ethernet0 address is 172.12.23.2, so you get the "not on common subnet" error message - and what you don't get is an adjacency! That's something to be aware of on your 642-901 BSCI exam as well as when working with EIGRP in production networks.