EIGRP Features

• Increased network width--With IP Routing Information Protocol (RIP), the

largest possible width of your network is 15 hops. When EIGRP is enabled, the
largest possible width is increased to 100 hops, and the EIGRP metric is large
enough to support thousands of hops.

• Fast convergence--The DUAL algorithm allows routing information to converge

as quickly as any currently available routing protocol.

• Partial updates--EIGRP sends incremental updates when the state of a

destination changes, instead of sending the entire contents of the routing table.
This feature minimizes the bandwidth required for EIGRP packets.

• Neighbor discovery mechanism--This simple protocol-independent hello

mechanism is used to learn about neighboring devices.

• Scaling--EIGRP scales to large networks.

EIGRP Autonomous System Configuration

Configuring the router eigrp command with the autonomous-system-number argument
creates an EIGRP configuration called the EIGRP autonomous system configuration, or
EIGRP classic mode. The EIGRP autonomous system configuration creates an EIGRP
routing instance that can be used for exchanging routing information.

In EIGRP autonomous system configurations, EIGRP VPNs can be configured only under
IPv4 address family configuration mode. A virtual routing and forwarding (VRF)
instance and a route distinguisher must be defined before the address family session
can be created.

When the address family is configured, we recommend that you configure an

autonomous system number either by using the autonomous-system-number argument
with the address-family command or by using the autonomous-system command.

EIGRP Named Configuration

Configuring the router eigrp command with the virtual-instance-name argument
creates an EIGRP configuration referred to as the EIGRP named configuration or EIGRP
named mode. An EIGRP named configuration does not create an EIGRP routing instance
by itself; it is a base configuration that is required to define address-family
configurations that are used for routing.

In EIGRP named configurations, EIGRP VPNs can be configured in IPv4 and IPv6 named
configurations. A VRF instance and a route distinguisher must be defined before the
address family session can be created.
A single EIGRP routing process can support multiple VRFs. The number of VRFs that can
be configured is limited only by the available system resources on the device, which is
determined by the number running processes and available memory. However, only a
single VRF can be supported by each VPN, and redistribution between different VRFs is
not supported.

EIGRP Neighbor Relationship Maintenance

Neighbor relationship maintenance is the process that devices use to dynamically learn
of other devices on their directly attached networks. Devices must also discover when
their neighbors become unreachable or inoperative. Neighbor relationship maintenance
is achieved with low overhead by devices when they periodically send small hello
packets to each other. As long as hello packets are received, the Cisco software can
determine whether a neighbor is alive and functioning. After the status of the neighbor
is determined, neighboring devices can exchange routing information.

The reliable transport protocol is responsible for the guaranteed, ordered delivery of
Enhanced Interior Gateway Routing Protocol (EIGRP) packets to all neighbors. The
reliable transport protocol supports intermixed transmission of multicast and unicast
packets. Some EIGRP packets (such as updates) must be sent reliably; this means that
the packets require acknowledgment from the destination. For efficiency, reliability is
provided only when necessary. For example, on a multiaccess network that has
multicast capabilities, hello packets need not be sent reliably to all neighbors
individually. Therefore, EIGRP sends a single multicast hello packet with an indication
in the packet informing receivers that the packet need not be acknowledged. The
reliable transport protocol can send multicast packets quickly when unacknowledged
packets are pending, thereby ensuring that the convergence time remains low in the
presence of varying speed links.

Some EIGRP remote unicast-listen (any neighbor that uses unicast to communicate) and
remote multicast-group neighbors may peer with any device that sends a valid hello
packet, thus causing security concerns. By authenticating the packets that are
exchanged between neighbors, you can ensure that a device accepts packets only from
devices that know the preshared authentication key.
• Neighbor Authentication

Neighbor Authentication

The authentication of packets being sent between neighbors ensures that a device
accepts packets only from devices that have the same preshared key. If this
authentication is not configured, you can intentionally or accidentally add another
device to the network or send packets with different or conflicting route information
onto the network, resulting in topology corruption and denial of service (DoS).
Enhanced Interior Gateway Routing Protocol (EIGRP) authentication is configurable on
a per-interface basis; packets exchanged between neighbors connected through an
interface are authenticated. EIGRP supports message digest algorithm 5 (MD5)
authentication to prevent the introduction of unauthorized information from
unapproved sources. MD5 authentication is defined in RFC 1321.

DUAL Finite State Machine

The DUAL finite state machine embodies the decision process for all route
computations. It tracks all routes advertised by all neighbors. DUAL uses the distance
information (known as the metric) to select efficient, loop-free paths. DUAL selects
routes to be inserted into a routing table based on feasible successors. A successor is a
neighboring device (used for packet forwarding) that has the least-cost path to a
destination that is guaranteed not to be part of a routing loop. When there are no
feasible successors but only neighbors advertising the destination, a recomputation
must occur to determine a new successor. The time required to recompute the route
affects the convergence time. Recomputation is processor-intensive, and unnecessary
recomputation must be avoided. When a topology change occurs, DUAL will test for
feasible successors. If there are feasible successors, DUAL will use any feasible
successors it finds to avoid unnecessary recomputation.

Protocol-Dependent Modules
Protocol-dependent modules are responsible for network-layer protocol-specific tasks.
An example is the EIGRP module, which is responsible for sending and receiving EIGRP
packets that are encapsulated in the IP. The EIGRP module is also responsible for
parsing EIGRP packets and informing DUAL about the new information received. EIGRP
asks DUAL to make routing decisions, but the results are stored in the IP routing table.
Also, EIGRP is responsible for redistributing routes learned from other IP routing
protocols.

Goodbye Message
The goodbye message is a feature designed to improve EIGRP network convergence.
The goodbye message is broadcast when an EIGRP routing process is shut down to
inform adjacent peers about an impending topology change. This feature allows
supporting EIGRP peers to synchronize and recalculate neighbor relationships more
efficiently than would occur if the peers discovered the topology change after the hold
timer expired.

The following message is displayed by devices that run a supported release when a
goodbye message is received:
*Apr 26 13:48:42.523: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1
(Ethernet0/0) is down: Interface Goodbye received
A Cisco device that runs a software release that does not support the goodbye message
can misinterpret the message as a K-value mismatch and display the following error
message:
*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor
10.1.1.1 (Ethernet0/0) is down: K-value mismatch

Note The receipt of a goodbye message by a nonsupporting peer does not disrupt
normal network operation. The nonsupporting peer terminates the session
when the hold timer expires. The sending and receiving devices reconverge
normally after the sender reloads.

EIGRP Metric Weights

You can use the metric weights command to adjust the default behavior of Enhanced
Interior Gateway Routing Protocol (EIGRP) routing and metric computations. EIGRP
metric defaults (K values) have been carefully selected to provide optimal performance
in most networks.

Note Adjusting EIGRP metric weights can dramatically affect network performance.
Because of the complexity of this task, we recommend that you do not change
the default K values without guidance from an experienced network designer.

By default, the EIGRP composite cost metric is a 32-bit quantity that is the sum of
segment delays and the lowest segment bandwidth (scaled and inverted) for a given
route. The formula used to scale and invert the bandwidth value is 107/minimum
bandwidth in kilobits per second. However, with the EIGRP Wide Metrics feature, the
EIGRP composite cost metric is scaled to include 64-bit metric calculations for EIGRP
named mode configurations.

For a network of homogeneous media, this metric reduces to a hop count. For a network
of mixed media (FDDI, Gigabit Ethernet (GE), and serial lines running from 9600 bits
per second to T1 rates), the route with the lowest metric reflects the most desirable
path to a destination.
• Mismatched K Values

Mismatched K Values

EIGRP K values are the metrics that EIGRP uses to calculate routes. Mismatched K
values can prevent neighbor relationships from being established and can negatively
impact network convergence. The example given below explains this behavior between
two EIGRP peers (Device-A and Device-B).

The following configuration is applied to Device-A. The K values are changed using
the metric weights command. A value of 2 is entered for the k1 argument to adjust the
bandwidth calculation. A value of 1 is entered for the k3 argument to adjust the delay
calculation.
Device(config)# hostname Device-A
Device-A(config)# interface serial 0
Device-A(config-if)# ip address 10.1.1.1 255.255.255.0
Device-A(config-if)# exit
Device-A(config)# router eigrp name1
Device-A(config-router)# address-family ipv4 autonomous-system 4533
Device-A(config-router-af)# network 10.1.1.0 0.0.0.255
Device-A(config-router-af)# metric weights 0 2 0 1 0 0 1

The following configuration is applied to Device-B, and the default K values are used.
The default K values are 1, 0, 1, 0, 0, and 0.
Device(config)# hostname Device-B
Device-B(config)# interface serial 0
Device-B(config-if)# ip address 10.1.1.2 255.255.255.0
Device-B(config-if)# exit
Device-B(config)# router eigrp name1
Device-B(config-router)# address-family ipv4 autonomous-system 4533
Device-B(config-router-af)# network 10.1.1.0 0.0.0.255
Device-B(config-router-af)# metric weights 0 1 0 1 0 0 0

The bandwidth calculation is set to 2 on Device-A and set to 1 (by default) on Device-B.
This configuration prevents these peers from forming a neighbor relationship.

The following error message is displayed on the console of Device-B because the K
values are mismatched:
*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1
(Ethernet0/0) is down: K-value mismatch

The following are two scenarios where the above error message can be displayed:

• Two devices are connected on the same link and configured to establish a
neighbor relationship. However, each device is configured with different K
values.

• One of two peers has transmitted a “peer-termination” message (a message that

is broadcast when an EIGRP routing process is shut down), and the receiving
device does not support this message. The receiving device will interpret this
message as a K-value mismatch.

Routing Metric Offset Lists

An offset list is a mechanism for increasing incoming and outgoing metrics to routes
learned via EIGRP. Optionally, you can limit the offset list with either an access list or an
interface.

Note Offset lists are available only in IPv4 configurations. IPv6 configurations do
not support offset lists.

EIGRP Cost Metrics

When EIGRP receives dynamic raw radio link characteristics, it computes a composite
EIGRP cost metric based on a proprietary formula. To avoid churn in the network as a
result of a change in the link characteristics, a tunable dampening mechanism is used.

EIGRP uses metric weights along with a set of vector metrics to compute the composite
metric for local RIB installation and route selections. The EIGRP composite cost metric
is calculated using the formula:

EIGRP composite cost metric = 256*((K1*Bw) + (K2*Bw)/(256 – Load) +

(K3*Delay)*(K5/(Reliability + K4)))

EIGRP uses one or more vector metrics to calculate the composite cost metric. The table
below lists EIGRP vector metrics and their descriptions.

Vector Description
Metric

bandwidth The minimum bandwidth of the route, in kilobits per second. It

can be 0 or any positive integer. The bandwidth for the formula
is scaled and inverted by the following formula:
(107/minimum bandwidth (Bw) in kilobits per second)
delay Route delay, in tens of microseconds.

delay The likelihood of successful packet transmission, expressed as a

reliability number between 0 and 255, where 255 means 100 percent
reliability and 0 means no reliability.

load The effective load of the route, expressed as a number from 0 to

255 (255 is 100 percent loading).

mtu The minimum maximum transmission unit (MTU) size of the

route, in bytes. It can be 0 or any positive integer.
 Vector Description
Metric
Table 1 EIGRP Vector Metrics

EIGRP monitors metric weights on an interface to allow the tuning of EIGRP metric
calculations and indicate the type of service (ToS). The table below lists the K values
and their defaults.

Setting Default Value

K1 1

K2 0

K3 1

K4 0

K5 0
Table 2 EIGRP K-Value Defaults

Most configurations use the delay and bandwidth metrics, with bandwidth taking
precedence. The default formula of 256*(Bw + Delay) is the EIGRP metric. The
bandwidth for the formula is scaled and inverted by the following formula:

(107/minimum Bw in kilobits per second)

Note You can change the weights, but these weights must be the same on all
devices.

For example, look at a link whose bandwidth to a particular destination is 128 k and the
delay is 84,000 microseconds.

By using a cut-down formula, you can simplify the EIGRP metric calculation to 256*(Bw
+ Delay), thus resulting in the following value:

Metric = 256*(107/128 + 84000/10) = 256*86525 = 22150400

To calculate route delay, divide the delay value by 10 to get the true value in tens of
microseconds.

When EIGRP calculates the delay for Mobile Ad Hoc Networks (MANET) and the delay is
obtained from a device interface, the delay is always calculated in tens of microseconds.
In most cases, when using MANET, you will not use the interface delay, but rather the
delay that is advertised by the radio. The delay you will receive from the radio is in
microseconds, so you must adjust the cut-down formula as follows:

Metric = (256*(107/128) + (84000*256)/10) = 20000000 + 2150400 = 22150400

Route Summarization
You can configure EIGRP to perform automatic summarization of subnet routes into
network-level routes. For example, you can configure subnet 172.16.1.0 to be
advertised as 172.16.0.0 over interfaces that have been configured with subnets of
192.168.7.0. Automatic summarization is performed when two or more network router
configuration or address family configuration commands are configured for an EIGRP
process. This feature is enabled by default.
Route summarization works in conjunction with the ip summary-
address eigrp command available in interface configuration mode for autonomous
system configurations and with the summary-address (EIGRP) command for named
configurations. You can use these commands to perform additional summarization. If
automatic summarization is in effect, there usually is no need to configure network-
level summaries using the ip summary-address eigrp command.

Sometimes, EIGRP summary route might be incorrectly promoted in the topology table
when the metric of the summary route and the externally received route match. This
occurs if a similar route with a mask is received as external and the same summary
prefix or length that originates internally via the summary-address on the interface and
sent to next hop neighbors. configure the summary-metric command to increase or
decrease the metric of the summary route.

Summary Aggregate Addresses

You can configure a summary aggregate address for a specified interface. If there are
specific routes in the routing table, EIGRP will advertise the summary address of the
interface with a metric equal to the minimum metric of the specific routes.

Floating Summary Routes

A floating summary route is created by applying a default route and an administrative
distance at the interface level or address family interface level. You can use a floating
summary route when configuring the ip summary-address eigrp command for
autonomous system configurations or the summary-address command for named
configurations. The following scenarios illustrate the behavior of floating summary
routes.

The figure below shows a network with three devices, Device-A, Device-B, and Device-C.
Device-A learns a default route from elsewhere in the network and then advertises this
route to Device-B. Device-B is configured so that only a default summary route is
advertised to Device-C. The default summary route is applied to serial interface 0/1 on
Device-B with the following autonomous system configuration:
Device-B(config)# interface Serial 0/1
Device-B(config-if)# ip summary-address eigrp 100 0.0.0.0 0.0.0.0

The default summary route is applied to serial interface 0/1 on Device-B with the
following named configuration:
Device-B(config)# Router eigrp virtual-name1
Device-B(config-router)# address-family ipv4 unicast vrf vrf1 autonomous-system 1
Device-B(config-router-af)# interface serial 0/1
Device-B(config-router-af-interface)# summary-address 192.168.0.0 255.255.0.0 95
Figure 1. Floating Summary Route Applied to Device-B

The configuration of the default summary route on Device-B sends a 0.0.0.0/0 summary
route to Device-C and blocks all other routes, including the 10.1.1.0/24 route, from
being advertised to Device-C. However, this configuration also generates a local discard
route—a route for 0.0.0.0/0 on the null 0 interface with an administrative distance of
5—on Device-B. When this route is created, it overrides the EIGRP-learned default
route. Device-B will no longer be able to reach destinations that it would normally reach
through the 0.0.0.0/0 route.

This problem is resolved by applying a floating summary route to the interface on

Device-B that connects to Device-C. The floating summary route is applied by
configuring an administrative distance for the default summary route on the interface of
Device-B with the following statement for an autonomous system configuration:
Device-B(config-if)# ip summary-address eigrp 100 0.0.0.0 0.0.0.0 250

The floating summary route is applied by configuring an administrative distance for the
default summary route on the interface of Device-B with the following statement for a
named configuration:
Device-B(config)# router eigrp virtual-name1
Device-B(config-router)# address-family ipv4 unicast vrf vrf1 autonomous-system 1
Device-B(config-router-af)# af-interface serial0/1
Device-B(config-router-af-interface)# summary-address eigrp 100 0.0.0.0 0.0.0.0 250
The administrative distance of 250, applied in the summary-address command, is now
assigned to the discard route generated on Device-B. The 0.0.0.0/0, from Device-A, is
learned through EIGRP and installed in the local routing table. Routing to Device-C is
restored.

If Device-A loses the connection to Device-B, Device-B will continue to advertise a

default route to Device-C, which allows traffic to continue to reach destinations attached
to Device-B. However, traffic destined to networks connected to Device-A or behind
Device-A will be dropped when the traffic reaches Device-B.

The figure below shows a network with two connections from the core, Device-A and
Device-D. Both Device-B and Device-E have floating summary routes configured on the
interfaces connected to Device-C. If the connection between Device-E and Device-C fails,
the network will continue to operate normally. All traffic will flow from Device-C
through Device-B to hosts attached to Device-A and Device-D.
Figure 2. Floating Summary Route Applied for Dual-Homed Remotes

However, if the link between Device-A and Device-B fails, the network may incorrectly
direct traffic because Device-B will continue to advertise the default route (0.0.0.0/0) to
Device-C. In this scenario, Device-C still forwards traffic to Device-B, but Device-B drops
the traffic. To avoid this problem, you should configure the summary address with an
administrative distance only on single-homed remote devices or areas that have only
one exit point between two segments of the network. If two or more exit points exist
(from one segment of the network to another), configuring the floating default route can
result in the formation of a black hole route (a route that has quick packet dropping
capabilities).

Hello Packets and the Hold-Time Intervals

You can adjust the interval between hello packets and the hold time. Hello packets and
hold-time intervals are protocol-independent parameters that work for IP and
Internetwork Packet Exchange (IPX).

Routing devices periodically send hello packets to each other to dynamically learn of
other devices on their directly attached networks. This information is used to discover
neighbors and to learn when neighbors become unreachable or inoperative.

By default, hello packets are sent every 5 seconds. The exception is on low-speed,
nonbroadcast multiaccess (NBMA) media, where the default hello interval is 60
seconds. Low speed is considered to be a rate of T1 or slower, as specified with
the bandwidth interface configuration command. The default hello interval remains 5
seconds for high-speed NBMA networks. Note that for the purposes of EIGRP, Frame
Relay and Switched Multimegabit Data Service (SMDS) networks may or may not be
considered to be NBMA. These networks are considered NBMA only if the interface has
not been configured to use physical multicasting.

You can configure the hold time on a specified interface for a particular EIGRP routing
process designated by the autonomous system number. The hold time is advertised in
hello packets and indicates to neighbors the length of time they should consider the
sender valid. The default hold time is three times the hello interval or 15 seconds. For
slow-speed NBMA networks, the default hold time is 180 seconds.

On very congested and large networks, the default hold time might not be sufficient for
all devices to receive hello packets from their neighbors. In such cases, you may want to
increase the hold time.

Note Do not adjust the hold time without informing your technical support
personnel.

Split Horizon
Split horizon controls the sending of EIGRP update and query packets. Split horizon is a
protocol-independent parameter that works for IP and IPX. When split horizon is
enabled on an interface, update and query packets are not sent to destinations for which
this interface is the next hop. Controlling update and query packets in this manner
reduces the possibility of routing loops.
By default, split horizon is enabled on all interfaces.

Split horizon blocks route information from being advertised by a device out of any
interface from which that information originated. This behavior usually optimizes
communications among multiple routing devices, particularly when links are broken.
However, with nonbroadcast networks (such as Frame Relay and SMDS), situations can
arise for which this behavior is less than ideal. In such situations and in networks that
have EIGRP configured, you may want to disable split horizon.

EIGRP Dual DMVPN Domain Enhancement

The EIGRP Dual DMVPN Domain Enhancement feature supports the no next-hop
self command on dual Dynamic Multipoint VPN (DMVPN) domains in both IPv4 and
IPv6 configurations.
EIGRP, by default, sets the local outbound interface as the next-hop value while
advertising a network to a peer, even when advertising routes out of the interface on
which the routes were learned. This default setting can be disabled by using the no ip
next-hop-self command in autonomous system configurations or the no next-hop-
self command in named configurations. When the next-hop self command is disabled,
EIGRP does not advertise the local outbound interface as the next hop if the route has
been learned from the same interface. Instead, the received next-hop value is used to
advertise learned routes. However, this functionality only evaluates the first entry in the
EIGRP table. If the first entry shows that the route being advertised is learned on the
same interface, then the received next hop is used to advertise the route. The no next-
hop-self configuration ignores subsequent entries in the table, which may result in
the no-next-hop-self configuration being dishonored on other interfaces.
The EIGRP Dual DMVPN Domain Enhancement feature introduces the no-ecmp-
mode keyword, which is an enhancement to the no next-hop-self and no ip next-hop-
self commands. When this keyword is used, all routes to a network in the EIGRP table
are evaluated to check whether routes advertised from an interface were learned on the
same interface. If a route advertised by an interface was learned on the same interface,
the no next-hop-self configuration is honored and the received next hop is used to
advertise this route.

Link Bandwidth Percentage

By default, EIGRP packets consume a maximum of 50 percent of the link bandwidth
when configured with the bandwidth interface configuration command for
autonomous system configurations and with the bandwidth-percent command for
named configurations. You might want to change the bandwidth value if a different level
of link utilization is required or if the configured bandwidth does not match the actual
link bandwidth (which may have been configured to influence route metric
calculations). This is a protocol-independent parameter that works for IP and IPX.
EIGRP vNETs
The EIGRP vNET feature uses Layer 3 routing techniques to provide limited fate sharing
(the term fate sharing refers to the failure of interconnected systems; that is, different
elements of a network are interconnected in such a way that they either fail together or
not at all), traffic isolation, and access control with simple configurations. EIGRP virtual
network (vNET) configurations are supported in both autonomous-system
configurations and named configurations.

The vNET feature allows you to have multiple virtual networks by utilizing a single set
of routers and links provided by the physical topology. Routers and links can be broken
down into separate virtual networks using separate routing tables and routing
processes by using vNETs and VRF configuration commands. The virtual networks
facilitate traffic isolation and limited fate sharing. EIGRP's primary role in vNETs is to
populate routing tables used by each vNET so that appropriate forwarding can take
place. In the vNET model, each vNET effectively has its own complete set of EIGRP
processes and resources, thus minimizing the possibility of actions within one vNET
affecting another vNET.

The vNET feature supports command inheritance that allows commands entered in
interface configuration mode to be inherited by every vNET configured on that
interface. These inherited commands, including EIGRP interface commands, can be
overridden by vNET-specific configurations in vNET submodes under the interface.

The following are some of the limitations of EIGRP vNETs:

• EIGRP does not support Internetwork Packet Exchange (IPX) within a vNET.

• vNET and VRF configurations are mutually exclusive on an interface. Both VRFs
and vNETs can be configured on the router, but they cannot both be defined on
the same interface. A VRF cannot be configured within a vNET and a vNET
cannot be configured within a VRF.

• Each vNET has its own routing table, and routes cannot be redistributed directly
from one vNET into another. EIGRP uses the route replication functionality to
meet the requirements of shared services and to copy routes from one vNET
Routing Information Base (RIB) to other vNET RIBs.

• Bidirectional Forwarding Detection (BFD) is not supported with EIGRP mode

vNET.

• EIGRP vNET Interface and Command Inheritance

EIGRP vNET Interface and Command Inheritance

A vNET router supports two types of interfaces: Edge interface and core (shared)
interface.

An edge interface is an ingress point for vNET-unaware networks and is restricted to a

single VRF. Use the vrf forwarding command to associate the edge interface with a
VRF. The vrf forwarding command also allows entry into VRF submodes used to define
interface settings on a per-VRF basis.
A vNET core interface is used to connect vNET-aware systems and can be shared by
multiple vNETs. Use the vnet trunk command to enable a core interface.
When the vnet trunk command exists on an interface, with or without a VRF list, any
EIGRP interface commands on that interface will be applied to the EIGRP instance for
every vNET on that interface, including the instance running on the base or the global
RIB. If the vnet trunk command is deleted from the interface, EIGRP interface
commands will remain on and apply to only the global EIGRP instance. If an EIGRP
interface command is removed from the main interface, the command will also be
removed from every vNET on that interface.

End systems or routing protocol peers reached through an edge interface are unaware
of vNETs and do not perform the vNET tagging done in the core of the vNET network.

EIGRP also supports the capability of setting per-vNET interface configurations, which
allow you to define interface attributes that influence EIGRP behavior for a single vNET.
In the configuration hierarchy, a specific vNET interface setting has precedence over
settings applied to the entire interface and inherited by each vNET configured on that
interface.

EIGRP provides interface commands to modify the EIGRP-specific attributes of an

interface, and these interface commands can be entered directly on the interface for
EIGRP autonomous system configurations, or in address family interface configuration
mode for the EIGRP named mode configurations.