Visit here for our full Cisco 300-410 exam dumps and practice test questions.
Question 151:
What EIGRP feature allows routes with different metrics to be used simultaneously?
A) Maximum-paths
B) Equal-cost load balancing
C) Variance
D) Traffic-share
Answer: C
Explanation:
The EIGRP variance feature allows routes with different metrics to be used simultaneously for unequal-cost load balancing. Variance is configured as a multiplier that determines how much worse a backup route’s metric can be compared to the successor route’s metric while still qualifying for load balancing. This capability distinguishes EIGRP from routing protocols limited to equal-cost load balancing, enabling utilization of multiple paths with different qualities simultaneously. Variance maximizes bandwidth utilization and provides redundancy even when paths do not have identical metrics.
Variance is configured using the variance command in EIGRP router configuration mode, with a multiplier value ranging from 1 to 128. The default variance of 1 allows only equal-cost load balancing where routes must have identical metrics to be used simultaneously. Setting variance greater than 1 enables unequal-cost load balancing. The multiplier defines the acceptable metric range where routes with feasible distances less than or equal to the successor’s feasible distance multiplied by the variance value qualify for consideration as load balancing paths.
Critical restrictions ensure loop-free operation even with unequal-cost load balancing enabled. Only routes that satisfy the feasibility condition can be used for load balancing regardless of variance settings. A route with metrics within the variance range but failing the feasibility condition will not be used because it cannot be guaranteed loop-free. This requirement maintains EIGRP’s loop prevention guarantees while enabling multipath utilization across paths with diverse quality characteristics.
Traffic distribution across unequal-cost paths is proportional based on route metrics. EIGRP automatically calculates traffic share counts that distribute traffic according to path quality. Routes with better metrics receive proportionally more traffic than routes with worse metrics, optimizing bandwidth usage. This intelligent distribution differs from simple equal distribution and ensures that higher-quality paths carry appropriate traffic loads relative to lower-quality alternatives.
Maximum-paths is a separate feature that limits how many parallel routes are installed in the routing table regardless of variance settings. Even if variance allows many routes to qualify for load balancing, maximum-paths caps how many are actually installed and used. Both variance and maximum-paths must be configured appropriately to achieve desired load balancing behavior. Variance determines which routes qualify while maximum-paths determines how many qualified routes are actually used.
Understanding variance and its effects enables effective implementation of unequal-cost load balancing strategies. Networks with parallel paths of different speeds or qualities benefit from variance configuration that allows simultaneous utilization of all available bandwidth. Careful variance selection based on actual path characteristics ensures appropriate traffic distribution without compromising routing stability.
Question 152:
Which EIGRP state indicates normal stable routing operation?
A) Active
B) Passive
C) Query
D) Pending
Answer: B
Explanation:
The passive state in EIGRP indicates normal stable routing operation where routes are ready for packet forwarding without requiring recalculation. When a route is in passive state, the router has successfully calculated the best path, has a successor route installed in the routing table, and is not performing any route recalculation activities. Passive state represents the desired operational condition where routing information is stable and the network is fully converged. The term passive reflects that the router is passively maintaining the route without actively computing new paths.
Routes in passive state may also have feasible successors pre-computed and stored in the topology table. These backup routes provide immediate failover capability if the successor fails, enabling sub-second convergence without leaving passive state. The presence of feasible successors enhances the stability associated with passive state because routes can handle failures without requiring active state recalculation. This combination of a working primary path and pre-computed backups represents the ideal EIGRP routing situation where both current forwarding and future failover are optimized.
Active state contrasts with passive state and indicates ongoing convergence activity. Routes enter active state when their successors fail and no feasible successors exist in the topology table. During active state, the router queries neighbors seeking alternative paths and cannot forward packets to the destination using EIGRP until convergence completes. Active state represents a period of instability and impaired connectivity. The goal of proper EIGRP network design is maintaining routes in passive state with transitions to active state being rare events.
The transition between states follows predictable patterns based on network events. Routes normally remain in passive state during stable network conditions. When a successor fails and feasible successors exist, routes remain passive as feasible successors are instantly promoted to successor status. Only when successors fail without available feasible successors do routes transition from passive to active state. After DUAL completes its query process and selects a new successor, routes return from active to passive state.
Network health can be assessed by examining how many routes are in active versus passive state. A healthy network has nearly all routes in passive state, with active state routes appearing only transiently during topology changes. Networks with persistently high numbers of active routes or routes remaining active for extended periods indicate problems requiring investigation. The show ip eigrp topology active command specifically displays routes in active state along with how long they have been active.
Understanding EIGRP route states helps administrators interpret protocol behavior and maintain stable routing operations. The passive state represents the desired condition where convergence is complete and routes are ready for reliable packet forwarding. Recognizing when routes enter active state and understanding what triggers these transitions enables effective troubleshooting.
Question 153:
What EIGRP command displays routes with their traffic share counts?
A) show ip eigrp topology
B) show ip route
C) show ip protocols
D) show ip eigrp traffic
Answer: B
Explanation:
The show ip route command displays routes with their traffic share counts when multiple EIGRP routes to the same destination are installed for load balancing. When unequal-cost load balancing is enabled through variance configuration and multiple qualifying routes exist, the routing table shows each route along with its traffic share count. These counts indicate the proportional distribution of traffic across the multiple paths, with routes having better metrics receiving higher traffic share counts meaning more traffic is directed to those preferred paths.
Traffic share counts are calculated automatically by EIGRP based on the relative metrics of paths used for load balancing. The counts specify how traffic should be distributed proportionally across unequal-cost paths, ensuring that routes with better metrics receive more traffic than routes with worse metrics. This intelligent distribution optimizes bandwidth utilization across available paths while preferring higher-quality routes. For example, if one route has a metric of 1000 and another has a metric of 2000, the first route receives twice as much traffic as indicated by proportionally higher traffic share counts.
The routing table output format shows each route to a destination on a separate line with its traffic share count displayed. When examining routes in the routing table, administrators can verify that load balancing is operating as expected by observing multiple routes with their associated traffic share counts. Comparing these counts helps understand how traffic will be distributed across the available paths based on their relative metrics.
The show ip eigrp topology command displays metric information and route states in the topology table but does not show traffic share counts since those are calculated only for routes actually installed in the routing table. The show ip protocols command displays configuration parameters like variance but not the resulting traffic share counts for specific routes. The show ip eigrp traffic command shows packet statistics rather than route information.
Traffic share counts affect only EIGRP route processing and have no impact on routes learned through other protocols. The counts are used by the forwarding process to determine how packets are distributed across multiple paths to the same destination. Routes with higher traffic share counts receive proportionally more packets in the traffic distribution scheme. The actual distribution mechanism depends on the switching method configured on the router, with CEF switching using hash algorithms to achieve proportional distribution across multiple flows.
Understanding traffic share counts helps network administrators plan capacity and predict traffic patterns when implementing unequal-cost load balancing. By examining the metrics of potential paths and the resulting traffic share counts in the routing table, administrators can verify that traffic distribution aligns with expected proportions based on path qualities. This verification ensures load balancing operates as intended.
Question 154:
Which EIGRP timer determines how long to wait before declaring a route stuck-in-active?
A) Hello timer
B) Hold timer
C) Active timer
D) Retransmission timer
Answer: C
Explanation:
The EIGRP active timer determines how long a router waits for Reply packets during active state before declaring a route stuck-in-active. When a route loses its successor and has no feasible successor, it enters active state and the router sends Query packets to all neighbors. The active timer begins counting and the router must receive Replies from all queried neighbors before this timer expires. The default active timer value is 180 seconds or three minutes. If the timer expires before all neighbors have replied, a stuck-in-active condition occurs.
If the active timer expires before all neighbors have replied to queries, the router declares a stuck-in-active condition for that route. The SIA condition indicates a serious problem in the network such as unidirectional links, routing loops, excessive latency, or route filters blocking Query or Reply packets. When SIA occurs, the router resets relationships with neighbors that failed to reply, causing significant routing disruption as all routes learned from those neighbors are removed from topology and routing tables.
Modern EIGRP implementations include SIA-Query and SIA-Reply messages designed to prevent false SIA conditions. At approximately half the active timer interval, if a route remains active, the router sends SIA-Query messages to neighbors that have not yet replied. Neighbors respond with SIA-Reply messages indicating they are still processing the query. This mechanism allows slow-converging networks to avoid premature SIA declarations while still detecting genuine communication failures requiring neighbor relationship resets.
The active timer can be modified using the timers active-time command in EIGRP router configuration mode. Values range from 1 to 65535 minutes, though changing this timer should be done carefully. Increasing the timer might mask underlying network problems rather than solving them, while decreasing it could cause premature SIA conditions in legitimately slow-converging networks. Understanding root causes of convergence delays is preferable to simply extending timers without addressing actual issues.
The hello timer and hold timer serve different purposes related to neighbor relationship maintenance. The hello timer controls how frequently Hello packets are sent for neighbor discovery and keepalive, while the hold timer determines how long to wait without receiving Hello packets before declaring a neighbor down. Neither directly controls the active state timeout. The retransmission timer determines how long to wait for Acknowledgments of reliable packets before retransmitting, which is separate from the overall time limit for route convergence.
Understanding the active timer and its relationship to stuck-in-active conditions helps administrators troubleshoot convergence problems and optimize EIGRP operation. Routes approaching the active timer limit require immediate attention to prevent neighbor resets. Proper network design with route summarization and stub routing limits query scope and active state duration.
Question 155:
What EIGRP feature provides loop prevention through mathematical guarantees?
A) Split horizon
B) Hop count limit
C) Feasibility condition
D) Hold down timer
Answer: C
Explanation:
The EIGRP feasibility condition provides loop prevention through mathematical guarantees, ensuring that backup routes are loop-free without requiring complete network topology knowledge. The feasibility condition states that a route can only qualify as a feasible successor if its advertised distance is less than the feasible distance of the current successor route. This mathematical relationship guarantees that the backup path does not loop through the local router because the neighbor advertising the route has found a better path than routing through the local router would provide.
The mathematical proof behind the feasibility condition is straightforward and elegant. If a neighbor’s advertised distance to a destination is less than the local router’s best metric to that destination, the neighbor must be using a path that does not include the local router. This logical relationship provides certainty about loop freedom without requiring the local router to know the complete network topology or trace the exact path used by the neighbor. The feasibility condition’s simplicity and mathematical certainty make it a powerful loop prevention mechanism.
Routes meeting the feasibility condition are identified as feasible successors and stored in the topology table as pre-qualified backup paths. These routes can be used immediately when primary paths fail without any risk of creating routing loops. The pre-qualification through the feasibility condition enables EIGRP’s sub-second convergence capability while maintaining absolute loop freedom. This combination of rapid convergence and guaranteed loop prevention represents one of EIGRP’s most significant innovations.
The feasibility condition’s strictness requires that advertised distance be strictly less than feasible distance, not less than or equal. This strict inequality ensures conservative loop prevention where even routes with advertised distances equal to the feasible distance are excluded from feasible successor status. While such routes might actually be loop-free in many scenarios, the strict condition provides mathematical certainty without complex analysis of specific network topologies.
Split horizon provides additional loop prevention by preventing routes from being advertised back to their source but does not offer mathematical guarantees applicable to all topology scenarios. Hop count limits in EIGRP exist as safety mechanisms but are not primary loop prevention methods. Hold down timers are not used in EIGRP, which instead relies on the feasibility condition and DUAL algorithm for loop prevention.
Understanding the feasibility condition and its mathematical basis helps administrators appreciate EIGRP’s sophisticated loop prevention mechanisms. The condition’s guarantee of loop freedom enables confident use of feasible successors for rapid convergence. Network designs that maximize feasible successor availability through appropriate topology and metric configuration leverage this powerful feature.
Question 156:
Which EIGRP command shows the locally configured K-values?
A) show ip eigrp neighbors
B) show ip eigrp topology
C) show ip protocols
D) show ip route
Answer: C
Explanation:
The show ip protocols command displays the locally configured K-values for EIGRP along with other protocol configuration parameters. This command provides comprehensive information about all routing protocols running on the router, and for EIGRP specifically, it shows the K-values that determine how the composite metric is calculated. The K-values section displays the weights for bandwidth, load, delay, reliability, and MTU components, allowing administrators to verify that metric calculations are configured consistently across the EIGRP autonomous system.
K-values are metric weights that determine which components contribute to EIGRP’s composite metric calculation. The five K-values, K1 through K5, weight bandwidth, load, delay, reliability, and MTU respectively. Default K-values are K1 equals 1, K2 equals 0, K3 equals 1, K4 equals 0, and K5 equals 0, meaning only bandwidth and delay are used by default. These defaults provide stable routing behavior because bandwidth and delay are relatively static interface characteristics unlike load and reliability which change frequently.
Consistent K-values across all routers in an EIGRP autonomous system are essential for proper operation. EIGRP neighbors must have matching K-values to form adjacencies. During the Hello packet exchange, routers compare K-values and refuse to establish neighbor relationships if mismatches are detected. This strict requirement ensures that all routers calculate metrics identically, preventing routing inconsistencies that could arise from different metric calculations across the network.
The show ip protocols output displays K-values in a format showing each K-value explicitly, such as K1 equals 1, K2 equals 0, K3 equals 1, K4 equals 0, K5 equals 0. Network administrators should verify these values during troubleshooting, especially when neighbor adjacencies fail to form despite apparent connectivity. K-value mismatches are a common cause of EIGRP neighbor problems that can be quickly identified by examining show ip protocols output on both routers attempting to form adjacency.
Other show commands provide different information but do not display K-values. The show ip eigrp neighbors command shows neighbor relationships including IP addresses, interfaces, hold times, and uptime but not the configuration parameters like K-values that were negotiated during adjacency formation. The show ip eigrp topology command displays routing information in the topology table without protocol-specific configuration details. The show ip route command displays routing table contents without configuration parameters.
Understanding where to find K-value information speeds troubleshooting of EIGRP problems. When diagnosing why neighbors fail to form or why route calculations seem incorrect, checking K-values with show ip protocols should be among the first troubleshooting steps. Verifying consistent K-values across all EIGRP routers ensures correct protocol operation.
Question 157:
What is the maximum variance multiplier value supported by EIGRP?
A) 32
B) 64
C) 128
D) 255
Answer: C
Explanation:
The maximum variance multiplier value supported by EIGRP is 128. The variance multiplier can be set from 1 to 128, where 1 is the default value that allows only equal-cost load balancing. Higher variance values permit increasingly diverse path metrics to qualify for unequal-cost load balancing. A variance of 128 represents the most permissive setting, allowing backup routes with metrics up to 128 times worse than the successor route to be used for load balancing, provided they meet the feasibility condition.
Understanding the variance range helps network administrators implement appropriate load balancing strategies. Very high variance values like 128 might seem desirable for maximum path utilization, but excessively high variance can result in using poor-quality backup paths that actually degrade network performance rather than improving it. Best practice recommends setting variance values based on actual path quality differences rather than simply maximizing the value. Typical variance settings range from 2 to 4 for most deployments where parallel paths have reasonably similar characteristics.
The variance multiplier creates an acceptable metric range for load balancing eligibility. Routes with feasible distances less than or equal to the successor’s feasible distance multiplied by the variance value qualify for consideration. For example, with variance set to 3 and a successor metric of 100,000, any feasible successor with a metric up to 300,000 could potentially be used for load balancing. This calculation provides controlled expansion of load balancing criteria beyond equal-cost scenarios.
Critical restrictions apply regardless of variance setting. Only routes satisfying the feasibility condition can ever be used for load balancing, ensuring loop-free operation. A route with a metric within the variance range but failing the feasibility condition will not be used because it cannot be guaranteed loop-free. Additionally, the maximum-paths setting limits how many routes can actually be installed even if more qualify based on variance. These safeguards maintain routing stability while enabling multipath utilization.
Proper variance configuration requires understanding network topology and link characteristics. In networks with parallel paths of similar capacity, low variance values of 2 or 3 typically suffice. Networks with deliberately staged backup paths of different capacities might benefit from higher variance values to utilize all available bandwidth. However, variance values exceeding 4 or 5 should be carefully evaluated to ensure they align with actual network design intent rather than inadvertently using significantly inferior paths.
Verification of variance effects uses show ip route to see which routes are installed for load balancing and show ip eigrp topology to view all feasible successors that could potentially qualify based on variance. Monitoring traffic distribution across paths using interface statistics confirms that load balancing operates as intended.
Question 158:
Which EIGRP packet type requires acknowledgment?
A) Hello
B) Update
C) Acknowledgment
D) All packets require acknowledgment
Answer: B
Explanation:
EIGRP Update packets require acknowledgment to ensure routing information is successfully received by neighbors. Update packets use EIGRP’s Reliable Transport Protocol which mandates acknowledgments for critical routing information. When a router sends an Update packet containing routing changes or initial synchronization data, it expects an Acknowledgment packet in return. If the acknowledgment is not received within the retransmission timeout period, the Update packet is retransmitted up to 16 times before the neighbor relationship is reset.
Update packets contain critical routing information including destination networks, metrics, and other attributes necessary for building topology and routing tables. Because this information is essential for accurate routing, reliable delivery ensures that no routing updates are lost during transmission. Missing updates could cause routing inconsistencies, loops, or black holes in the network where routers have incomplete or incorrect topology information. The acknowledgment mechanism guarantees that both routers maintain synchronized routing information.
Query and Reply packets also require reliable delivery and acknowledgment. Query packets are sent when a router loses its successor route and needs to find alternative paths through the DUAL algorithm. Reply packets respond to queries with route information. Both packet types contain critical information for convergence operations, making reliable delivery essential for proper DUAL algorithm operation and loop-free routing during topology changes.
Hello packets use unreliable delivery and do not require acknowledgments. These packets are sent frequently, every 5 seconds on high-bandwidth links, to maintain neighbor relationships through periodic keepalive messages. Requiring acknowledgments for Hello packets would create unnecessary overhead and defeat their purpose as lightweight monitoring packets. If a Hello packet is lost, the next Hello packet arriving shortly thereafter maintains the neighbor relationship, making acknowledgment unnecessary.
Acknowledgment packets themselves are part of the unreliable delivery mechanism and do not require their own acknowledgments. ACK packets are sent in response to Update, Query, and Reply packets to confirm receipt. They are small and efficient, containing just enough information to confirm receipt of the corresponding reliable packet using sequence numbers. Requiring acknowledgments of acknowledgments would create infinite loops.
Understanding which packet types require reliable delivery helps troubleshoot EIGRP problems. Network congestion or errors causing packet loss primarily affect Update, Query, and Reply packets, potentially leading to stuck-in-active conditions or neighbor relationship resets if acknowledgments are not received. Monitoring retransmission counters using show ip eigrp traffic helps identify network quality issues affecting EIGRP reliable packet delivery.
Question 159:
What does the EIGRP Null0 route prevent?
A) Route flapping
B) Routing loops during summarization
C) Neighbor formation
D) Metric calculations
Answer: B
Explanation:
The EIGRP Null0 route prevents routing loops during summarization by providing a discard path for packets destined to non-existent subnets within the summary range. When a router advertises a summary route, it automatically installs a route to the Null0 interface for that summary address in its local routing table with an administrative distance of 5. This route acts as a catch-all for any packets matching the summary range that do not have more specific matching routes, ensuring such packets are dropped rather than forwarded according to less specific routes that could create loops.
Without the Null0 route, packets destined for non-existent subnets within the summary range could be forwarded according to default routes or other less specific routing entries, potentially creating routing loops. For example, if a router summarizes 10.1.0.0/16 but only has actual subnets 10.1.1.0/24 and 10.1.2.0/24, packets destined for 10.1.3.0/24 would not match any specific route. Without the Null0 route, these packets might be forwarded to a default route which could send them to another router that routes them back based on the summary, creating an infinite loop.
The Null0 interface is a virtual interface that discards all traffic forwarded to it without any processing or transmission. It functions similarly to /dev/null in Unix systems where anything sent simply disappears. When packets match the Null0 summary route because they are destined for non-existent addresses within the summary range, they are immediately dropped. This discard behavior is precisely what prevents routing loops by ensuring packets for truly non-existent destinations are eliminated rather than circulated.
The administrative distance of 5 for the Null0 summary route is carefully chosen to create appropriate routing preferences. It is lower than EIGRP internal routes with administrative distance 90 and external routes with administrative distance 170, ensuring the Null0 route takes precedence over any EIGRP-learned routes. However, it is higher than connected routes with administrative distance 0 and most static routes with default administrative distance 1, allowing more specific routes to override the summary when they exist.
Administrators can observe the automatically created Null0 routes using the show ip route command. The routing table displays these routes pointing to Null0 with administrative distance 5, appearing similar to static routes even though they were automatically created by EIGRP. Understanding this automatic route creation is important for troubleshooting connectivity issues, particularly when overly broad summarization causes legitimate traffic to match Null0 routes and be dropped.
The Null0 discard route mechanism makes route summarization safe by automatically preventing potential loops. This integrated loop prevention allows administrators to confidently implement summarization to achieve scalability benefits while maintaining routing correctness.
Question 160:
Which EIGRP feature allows traffic distribution based on path metrics?
A) Equal-cost load balancing
B) Traffic-share count
C) Maximum-paths
D) Administrative distance
Answer: B
Explanation:
The EIGRP traffic-share count feature allows traffic distribution based on path metrics when multiple routes are used for load balancing. Traffic share counts are automatically calculated by EIGRP based on the relative metrics of paths being used simultaneously. These counts specify how traffic should be distributed proportionally across unequal-cost paths, ensuring that routes with better metrics receive more traffic than routes with worse metrics. This intelligent distribution optimizes bandwidth utilization while preferring higher-quality paths.
Traffic share count calculation is based on the inverse relationship between metric and traffic proportion. Routes with lower metrics, meaning better paths, receive higher traffic share counts indicating more traffic should be directed to these preferred routes. For example, if one route has a metric of 1000 and another has a metric of 2000, the first route receives twice as much traffic as the second. This proportional distribution ensures efficient use of all available bandwidth while still preferring better-quality paths.
The traffic share count is visible in the output of the show ip route command when multiple EIGRP routes to the same destination are installed in the routing table. Each route displays its traffic share count indicating the relative proportion of traffic it will carry. Network administrators can use this information to verify that load balancing is operating as expected and that traffic distribution aligns with path quality as determined by EIGRP metrics.
EIGRP’s automatic calculation of traffic share counts eliminates the need for manual traffic distribution configuration. The protocol intelligently determines appropriate traffic proportions based on metric calculations, adapting automatically to changes in network conditions. If path metrics change due to bandwidth modifications or topology changes, traffic share counts are recalculated to maintain optimal traffic distribution reflecting current path characteristics.
The traffic share count mechanism works only when variance is configured to allow unequal-cost load balancing and when multiple qualifying routes exist. With variance set to the default value of 1, only equal-cost load balancing occurs and traffic is distributed evenly regardless of any metric differences. The variance setting must be greater than 1 for traffic share count proportional distribution to take effect based on metric differences.
Understanding traffic share counts helps network administrators plan capacity and predict traffic patterns when implementing unequal-cost load balancing. By examining the metrics of potential paths and calculating expected traffic proportions, administrators can ensure that all links are appropriately sized for the traffic they will carry. This planning prevents oversubscription of lower-capacity backup paths.
Question 161:
What EIGRP command configures the Hello interval on an interface?
A) hello-interval eigrp
B) ip hello-interval eigrp
C) eigrp hello-interval
D) hello-time eigrp
Answer: B
Explanation:
The ip hello-interval eigrp command configures the EIGRP Hello interval on an interface, allowing administrators to customize how frequently Hello packets are sent on specific interfaces. This interface-level command provides control over neighbor monitoring frequency. The complete syntax is ip hello-interval eigrp autonomous-system-number seconds, where the autonomous system number identifies the EIGRP process and seconds specifies the interval value. Customizing Hello intervals may be necessary for unreliable links, high-latency connections, or specific network requirements.
Modifying the Hello interval affects how quickly EIGRP can detect neighbor failures and how much overhead the protocol generates. Shorter Hello intervals enable faster failure detection because neighbors send keepalive messages more frequently, allowing quicker recognition when Hello packets stop arriving. However, shorter intervals also increase bandwidth consumption and CPU utilization for processing Hello packets. Longer intervals reduce overhead but delay failure detection because more time elapses between Hello transmissions.
When changing the Hello interval, administrators must also consider the hold timer relationship. The hold timer determines how long a router waits without receiving Hello packets before declaring a neighbor down. By default, the hold timer is three times the Hello interval. If the Hello interval is modified without adjusting the hold timer proportionally, the relationship between these timers changes, potentially causing unexpected neighbor timeout behavior. Best practice recommends maintaining the three-to-one ratio.
The hold timer is configured separately using the ip hold-time eigrp command on the same interface. Maintaining appropriate relationships between Hello and hold timers ensures tolerance for occasional packet loss while still detecting genuine failures promptly. For example, if the Hello interval is set to 10 seconds, the hold time should be 30 seconds. This ratio provides reasonable tolerance for temporary network issues.
EIGRP does not require matching Hello and hold timers between neighbors for adjacency formation. Unlike some routing protocols that enforce timer matching, EIGRP allows neighbors to have different timer values. Each router uses its own locally configured hold timer to determine when its neighbor is down based on Hello packet reception. This flexibility can be useful but requires careful planning to ensure consistent behavior.
Timer modifications should be implemented cautiously in production networks. Inappropriate timer values can cause neighbor flapping where adjacencies repeatedly form and tear down, creating routing instability. Testing timer changes in lab environments before deployment helps identify potential issues. Documentation of customized timer values is essential for troubleshooting and future network maintenance.
Question 162:
Which EIGRP route type has an administrative distance of 170?
A) Internal routes
B) External routes
C) Summary routes
D) Connected routes
Answer: B
Explanation:
EIGRP external routes have an administrative distance of 170 by default, making them less preferred than most other routing information sources. External routes are those redistributed into EIGRP from other routing protocols or sources such as OSPF, BGP, RIP, or static routes. The high administrative distance reflects the principle that routes originating outside the EIGRP autonomous system may be less trustworthy than routes learned through native EIGRP operation. This preference hierarchy helps prevent routing loops and ensures optimal path selection in multi-protocol environments.
The administrative distance differentiation between internal and external routes serves important purposes in complex network environments. When the same destination is advertised by multiple routing protocols through redistribution, the administrative distance determines which route is installed in the routing table. EIGRP internal routes with administrative distance 90 are preferred over external routes, ensuring that routes native to EIGRP take precedence over redistributed versions. This preference structure prevents loops and promotes optimal routing.
Internal EIGRP routes, those learned through normal EIGRP operation within the autonomous system, receive an administrative distance of 90. This relatively low value makes EIGRP routes preferred over most other routing protocols in mixed-protocol environments. The 90 value is lower than OSPF’s 110 and RIP’s 120, meaning EIGRP routes are selected when multiple protocols advertise the same destination. This preference reflects EIGRP’s position as a preferred routing protocol in Cisco environments.
Summary routes created by EIGRP receive an administrative distance of 5 for the Null0 component, which is actually lower than internal routes. However, summary routes serve a different purpose as loop prevention mechanisms rather than primary forwarding paths. The low administrative distance ensures the Null0 summary route takes precedence over less specific routes while allowing more specific routes with higher administrative distances to override it when they exist.
The high administrative distance of external routes helps prevent routing loops during mutual redistribution between routing domains. When routes are redistributed from protocol A into protocol B and then back into protocol A, the external administrative distance ensures the original native route is preferred over the redistributed version. For example, if a route originates in EIGRP with AD 90, gets redistributed to OSPF, and then gets redistributed back to EIGRP with AD 170, the original internal EIGRP route is preferred.
Understanding administrative distance differences between route types helps administrators predict routing behavior in multi-protocol networks. When troubleshooting why particular routes are selected, examining administrative distances explains protocol preference. The show ip route command displays administrative distance for installed routes.
Question 163:
What is the purpose of EIGRP route tagging?
A) To modify route metrics
B) To mark routes for policy control
C) To enable authentication
D) To configure load balancing
Answer: B
Explanation:
EIGRP route tagging marks routes for administrative purposes and policy control, providing a mechanism to identify routes with 32-bit values that can be matched by routing policies at various points in the network. Tags are attached to routes during redistribution or through route maps and travel with routes throughout the EIGRP domain, maintaining their values as routes propagate. This persistent identification enables sophisticated policy-based routing implementations, particularly in complex redistribution scenarios involving multiple routing protocols or autonomous systems.
The primary use case for route tags involves preventing routing loops during mutual redistribution between routing domains. When routes are redistributed from protocol A into protocol B, tags can mark these routes to identify their origin. Later, when redistributing from protocol B back into protocol A, the tags can be matched to prevent routes originally from protocol A from being redistributed back into it. This tag-based filtering breaks potential redistribution loops that could otherwise corrupt routing tables throughout multi-protocol networks.
Route tags also enable administrative classification and tracking of routes based on their origins or purposes. Different tags can mark routes from different sites, partners, or network segments, allowing routing policies to treat routes differently based on their sources. For example, routes from internet connections might receive one tag, internal routes might receive another tag, and partner routes might receive a third tag. Subsequent routing policies can match these tags to implement different treatments.
Tags are configured using route maps during redistribution or with the set tag command within route map entries. The redistribute command includes route map specifications that can set tags on redistributed routes based on match conditions. On receiving routers, match tag commands in route maps identify tagged routes for special handling. This framework of setting and matching tags provides flexible policy implementation without requiring complex nested access control lists.
EIGRP preserves route tags as routes propagate through the autonomous system, ensuring that tags set at redistribution points remain intact throughout the EIGRP domain. When a router receives tagged routes from a neighbor and subsequently advertises them to other neighbors, the tags are maintained. This tag persistence ensures routing policies based on tags remain effective regardless of how many EIGRP hops routes traverse before reaching policy enforcement points.
Network administrators implementing complex routing scenarios with multiple protocols or redistribution points should leverage route tags for loop prevention and policy control. Understanding how to set tags during redistribution and match them at policy enforcement points enables sophisticated routing implementations.
Question 164:
Which EIGRP configuration mode organizes settings into address families?
A) Classic mode
B) Named mode
C) Autonomous system mode
D) Advanced mode
Answer: B
Explanation:
EIGRP named mode organizes configuration settings into address families, providing a hierarchical structure that supports multiple protocol versions within a single EIGRP instance. This modern configuration paradigm enables unified management of IPv4 and IPv6 routing from a centralized configuration context while maintaining protocol-specific parameters where necessary. Named mode represents a significant improvement over classic EIGRP configuration which requires completely separate processes for different protocol versions.
The address-family structure within named mode allows protocol-specific configurations while sharing common parameters at the instance level. Each address family contains its own network statements, metrics, and protocol-specific settings for either IPv4 or IPv6. Global parameters configured at the instance level apply to all address families unless overridden within specific address-family contexts. This inheritance model reduces configuration redundancy for parameters that should be consistent across protocols.
Named mode configuration begins with the router eigrp command followed by a descriptive instance name rather than a numeric autonomous system number. Within this instance context, administrators enter address-family ipv4 autonomous-system or address-family ipv6 autonomous-system to configure protocol-specific parameters. The autonomous system number is configured within each address family rather than globally, providing flexibility for scenarios requiring different AS numbers for different protocols.
Classic mode handles each protocol version as a completely independent EIGRP process. IPv4 routing requires router eigrp configuration while IPv6 routing requires ipv6 router eigrp configuration with separate commands and configuration contexts. Parameters that should be consistent across protocols must be configured multiple times, increasing administrative burden and potential for configuration errors or inconsistencies between protocol implementations.
The transition from classic to named mode supports gradual migration strategies. Both configuration modes can coexist on the same router using different EIGRP instances without interference. Additionally, routers running classic mode can form neighbor relationships with routers running named mode for the same autonomous system because the on-wire protocol format maintains backward compatibility. This compatibility allows organizations to migrate routers to named mode incrementally.
Understanding named mode’s address-family organization helps network administrators plan efficient dual-stack implementations. As networks continue supporting both IPv4 and IPv6 during extended transition periods, unified routing configuration reduces operational complexity. Named mode’s centralized management, reduced redundancy, and improved consistency make it the recommended approach for new EIGRP deployments.
Question 165:
What EIGRP feature determines the maximum number of parallel routes?
A) Variance
B) Maximum-paths
C) Traffic-share
D) Load balancing
Answer: B
Explanation:
The EIGRP maximum-paths feature determines the maximum number of parallel routes that can be installed in the routing table for load balancing to the same destination. This setting limits how many routes are simultaneously used regardless of how many paths qualify based on equal-cost or unequal-cost load balancing criteria. The default maximum-paths value is 4, meaning EIGRP will install up to four routes for any given destination. This default balances the benefits of multipath utilization against the complexity and resource consumption of maintaining many parallel routes.
The maximum-paths limitation applies to both equal-cost and unequal-cost load balancing scenarios. For equal-cost paths where multiple routes have identical metrics, EIGRP will install up to the maximum-paths limit of them by default. When variance is configured to enable unequal-cost load balancing, the maximum-paths setting still limits how many routes are installed even if more routes qualify based on variance criteria. The maximum-paths value represents an absolute ceiling on parallel route installation.
Administrators can modify the maximum-paths value using the maximum-paths command in EIGRP router configuration mode. The syntax is maximum-paths followed by a number ranging from 1 to 32 on modern Cisco IOS platforms. Setting maximum-paths to 1 effectively disables load balancing, causing only the single best route to be installed even if multiple equal-cost paths exist. Increasing maximum-paths beyond 4 allows more parallel routes when network topology provides many qualifying paths.
The maximum-paths setting interacts with other EIGRP features affecting load balancing. Variance determines which unequal-cost routes qualify for consideration based on their metrics relative to the successor route. Maximum-paths then limits how many of those qualifying routes are actually installed in the routing table. Both parameters must be configured appropriately to achieve desired load balancing behavior. For example, setting high variance but low maximum-paths allows many routes to qualify but limits how many are actually used.
Traffic distribution across installed paths depends on the switching method configured on the router. Process switching distributes traffic per-packet across available paths, while fast switching and CEF switching distribute per-destination based on hash algorithms. The per-destination approach is generally preferred because it maintains packet ordering within individual flows while still achieving load distribution across multiple flows. The maximum-paths setting determines how many paths are available for distribution.
Understanding the default and configurable maximum-paths values helps administrators plan load balancing implementations. Networks with two parallel paths operate effectively with the default setting of 4. Networks with more than four parallel paths require explicit maximum-paths configuration to utilize all available bandwidth.