EIGRP Overview Summary
EIGRP Overview Summary
| Function/Feature |
Description |
| Protocol Type |
Advanced Distance Vector |
| RFC / Proprietary |
Cisco Proprietary |
| Administrative Distance (AD) |
90 – Internal EIGRP
170 – External EIGRP |
| Algorithm |
Diffusing Update Algorithm (DUAL) |
| Transport protocol |
IP Protocol 88 |
| Metric |
Bandwidth and Delay (default) |
| Best path selection |
Lowest metric cost (Feasible Distance) |
| Hello interval |
5 Seconds |
| Update destination |
224.0.0.10 |
| Update interval |
Triggered updates only |
| Full of partial updates |
Partial triggered updates bound to ‘need-to-know’ routers |
| Triggered updates |
Yes |
| Authentication |
Clear-text, MD5 and SHA2 |
| Route-tags |
On redistribution into and out of EIGRP |
- Protocol dependent modules – Layer 3
- AS number must match on adjacent neighbors
Router-ID
- 4bytes
- Multiple processes or AF interfaces can use the same RID
- Originally used for EIGRP redistribution to prevent routing loops
- Identifys the originator of EIGRP External routes
- If route was received with same RID then its discarded
- New IOS versions now include the RID on Internal EIGRP routes to determine originator
- RID decision is same as OSPF
- Configured through process command:
- (config-if)#eigrp router-id <RID>
- 0.0.0.0 and 255.255.255.255 are not valid
- Highest non-shutdown Loopback interface
- Highest non-shutdown Interface
- Verify the current RID:
- Versions previous to IOS 15.x
[_/su_spoiler]
EIGRP Databases
EIGRP Databases
Neighbor Table
- Contains following information:
- Handle
- Internal number EIGRP assigns neighbors
- Starts at 0
- Neighbors address
- Interface
- Hold time
- Reset every time an EIGRP packet received
- If decreases to 0 neighbor is down
- Uptime
- SRTT
- Smooth Round Trip Timer
- Time taken to send packet and receive acknowledgement
- RTO
- Retransmission Time Out
- Time to wait for a ACK of retransmitted unicast after previous attempt didn't receive acknowledgement
- Q Cnt
- Number of queued packets EIGRP is trying to send but no acknowledgement is being received
- Should always be 0
- Sequence number
- Number of last reliable EIGRP packet received from neighbor
[_/su_spoiler]
Topology Table
- Lists all routes from all neighbors
- Passive Routes
- Active Routes
- Router programming a recomputation
- Topology Table Status Codes:
- (P) - Passive - Network Stable
- (A) - Active - Not Available, outstanding queries
- (U) - Update - Network Updating, waiting acknowledgeable from update
- (Q) - Query - Outstanding query packet, not in active state
- (R) - Reply - Generating reply, waiting for acknowledgement on reply packet
- (SIA) - Stuck In Active - Convergence problem. Not received a response to QUERY packet
- 2 composite metrics are displayed in the Topology table for prefixes
- Feasible Distance (local metric to destination)
- Advertised Distance (Neighbors metric to destination)
- Displayed as:
- Composite metric is (Feasible Distance / Advertised Distance)
[_/su_spoiler]
Routing Table
- Route types:
- D - Local AS EIGRP routes
- EX - External AS EIGRP routes
- EIGRP Summary routes
- No default routes can be directly injected in to EIGRP
[_/su_spoiler]
EIGRP Neighbors
EIGRP Messages
HELLO Packets
- Opcode 5
- Multicast to 224.0.0.10
- If static neighbors are configured, Unicast Hello packets are sent
- No acknowledgements
- Used for neighbor discovery
- Tagged with a DiffServe of 0x30 (AF12)
[__/su_spoiler]
UPDATE Packets
- Opcode 1
- Unicast or Multicast
- Depending on type of update
- On initial adjacency, Updates are unicast
- After sync complete, further Updates are multicast
- If a router doesn't acknowledge an Update, EIGRP will then unicast it to neighbor
- On P-2-P links updates are always unicast
- Tells neighbors about prefix updates
- Uses RTP (Reliable Transport Protocol)
[__/su_spoiler]
QUERY Packets
- Opcode 3
- Unicast or Multicast
- Multicast by default
- If neighbor doesn't acknowledge Multicast Update, EIGRP will send as Unicast
- P-2-P interfaces are always Unicast
- Static configured neighbors are Unicast
- Asks neighbors for information on prefixes
- Uses RTP (Reliable Transport Protocol)
[__/su_spoiler]
REPLY Packets
- Opcode 4
- Unicast
- Responds to QUERY packets
- Carry senders current distance to destination after topology change taken place
- Uses RTP (Reliable Transport Protocol)
[__/su_spoiler]
ACK Packets
- Opcode 5
- Unicast
- Acknowledges UPDATE, QUERY and REPLY packets for reliable delivery
- Format is a Hello packet with an empty payload
- Uses sequence numbers to acknowledge transmission
[__/su_spoiler]
SIA-QUERY Packets
- Opcode 10
- Unicast
- Used when a neighbor hasn't sent a REPLY to a QUERY packet
- Asks neighbor to confirm is still working on original QUERY
- Confirms with SIA-UPDATE packet immediately
- Max time is reset to allow neighbor to reply
- Uses RTP
[__/su_spoiler]
SIA-UPDATE Packets
- Opcode 11
- Unicast
- Used to respond instantly to SIA-QUERY packet
- Uses RTP
[__/su_spoiler]
[_/su_spoiler]
EIGRP Adjacencies
- Requires the following to match in Hello packets to form neighboring adjacencies
- Primary address used for adjacency
- IP Subnet
- Autonomous System number
- K-values
- Authentication
- Once a static neighbor is configured on an interface, multicast on that interface is disabled
- On multiaccess interfaces if one neighbor is statically configured, EIGRP will not form adjacency with any other unless statically configured as well
Neighbor Adjacency Process
- R1 multicasts HELLO to subnet
- R2 receives HELLO and puts R1 in the Pending state
- Only packets that can be sent/received in Pending state are:
- HELLO
- ACK
- UPDATE with INIT flag set
- R2 sends HELLO packet immediately back to R1
- R1 receives HELLO and puts R2 in the Pending state
- R1 sends Null UPDATE packet, with INIT flash set to R2
- INIT flag indicates new adjacency and neighbor should send full database
- R2 acknowledges this packet and sends Null UPDATE to R1
- Acknowledgement can be through individual ACK packet
- Can also be sent in Null UPDATE packet by setting acknowledgement number to the sequence number of the neighbors Null UPDATE packet received (x)
- When R1 receives acknowledgement from R2 on Null UPDATE, R2 is moved to Up state
- R1 sends ACK back to R2 to acknowledge Null UPDATE packet
- R2 recieves ACK from R1 and puts neighbor in Up state
- Bidirectional communication is established
- Neighbors exchange UPDATE packets (with ACKnowledgements) with full database information
- Once synchronised only incremental UPDATE of changes will be sent
- Updates by default use 50% of the bandwidth available
- Configurable bandwidth for routing updates
- Command:
- (config-if)#ip bandwidth-percent eigrp <%>
- For hub-and-spoke multiple different bandwidth (CIRs), set the bandwidth to the lowest CIR multiplied by number of PVC on interface.
[__/su_spoiler]
- As EIGRP is Distance Vector protocol it uses SPLIT-HORIZON rule
- Can't advertise updates out same interface on which they were learned
- Can be manually disabled on both Named-mode and Classic-mode
- Named-mode command:
- Configured at address-family interface level
- (config-router-af-interface)#no split-horizon
- Classic-mode command:
- (config-if)#no ip split-horizon eigrp <AS>
Split-Horizon Enabled
Split-Horizon Disabled
[__/su_spoiler]
EIGRP Timers
- Default Timers:
- HELLO
- 5 seconds on LAN
- 60 seconds on WAN (<1544Kbps)
- HOLD
- 15 seconds on LAN
- 180 seconds in WAN (<1544Kbps)
- Active Timer
- A querying router waits 3 minutes for a reply before declaring a neighbor down
- Can be manually configured with command:
- (config-router)#timers active-time <1-65535>
- Timers don't need to match to form adjacency
- Can be manually configured in Classic-mode and Named-mode
- Classic-mode commands:
- (config-if)#ip hello-interval eigrp <AS> <seconds>
- (config-if)#ip hold-time eigrp <AS> <seconds>
- Named-mode commands:
- Configured under the address-family interface mode
- (config-router-af-interface)#hello-interval <seconds>
- (config-router-af-interface)#hold-time <seconds>
[__/su_spoiler]
Graceful Restart/Shutdown
- Advertises to neighbors local node is going down
- Sends a HELLO message with all K-values set to 255
- EIGRP Classic-mode:
- Automatically sent when shutting down interface
- EIGRP Named-mode:
- Can shut down the EIGRP process globally on for specific neighbors under the af-interface process
- Commands:
- (config-router-af)#shutdown
- (config-router-af-interface)#shutdown
[__/su_spoiler]
[_/su_spoiler]
EIGRP Classic mode
EIGRP Classic-mode
- Legacy method of configuring EIGRP
- Represented by AS number at router process level
- Version used before IOS v15.x
- Some features aren’t supported in Classic mode
- Wide metrics
- IPv6 VRF-Lite
- Has issues calculating metrics accurately for link speeds faster than 1Gbps
- Add-path
Classic mode Configuration
Classic-mode Configuration
- Process enabled globally on the node:
- Command:
- (config)#router eigrp <AS #>
- Network command enables EIGRP on those interfaces
- Command:
- (config-router)#network <network> <wildcard mask>
- To disable EIGRP on an interface use the passive interface feature
- Command:
- (config-router)#passive-interface <IF>
[_/su_spoiler]
Classic-mode Metric Options
Classic-mode Composite Metric Options
- Metric carried in Hello packets
- Need to match neighbor for adjacency to form
- Must be the same in the entire topology for it to work
- Uses a 32-bit metric
- Default K values for metric calculation:
- K1 (Bandwidth) = 1 (Yes)
- K2 (Load) = 0 (No)
- K3 (Delay) = 1 (Yes)
- K4 (Reliability - Link Quality) = 0 (No)
- K5 (Reliabiity - Packet Loss) = 0 (No)
- Default use of K values can be modified with command:
- (config-router)#metric weights <tos> <k1> <k2> <k3> <k4> <k5>
- MTU
- Not used as part of metric calculation
- Carried in packet for minimum path MTU discovery
Composite Metric: K1 - Bandwidth
Composite Metric: K1 - Bandwidth
- Used by default in calculation
- Lowest bandwidth between the source and destination
- Measured in Kbps
- Capable of calculating 1Kbps to 10Gbps interfaces
- Can be set manually on an interface
- Command:
- (config-if)#bandwidth <kbps>
- Formula to calculate Bandwidth:
- (10^7 *256)/BANDWIDTH(min)
[__/su_spoiler]
Composite Metric: K2 - Loading
Composite Metric: K2 - Loading
- Not used by default in calculation
- Worst load on a link along a path
- Value can be 1 to 255
[__/su_spoiler]
Composite Metric: K3 - Delay
Composite Metric: K3 - Delay
- Used by default in calculation
- Cumulative interface delay along a link
- Measured in 10's of microseconds
- e.g. Configuring a delay of 20 on an interface will set the delay to 200 microseconds
- Split-Horizon with Poison Reverse and Route Poisoning sets the Delay to the maximum value to make a prefix unreachable
- Can be configured manually on an interface
- Command:
- (config-if)#delay <10's microseconds>
- Value can be 1 to 16,777,214 (10's of microseconds)
- Formula to calculate DELAY:
- Delay(summed in 10's microseconds) * 256
[__/su_spoiler]
Composite Metric: K4&K5 - Reliability
Composite Metric: K4 & K5 - Reliability
- Not used by default in calculation
- Reliability of path from source to destination
- Set to the lowest value along the path
- Value can be 1 to 255
- 255 indicates 100% reliability
[__/su_spoiler]
Hop Count
- Hop count isn't used as part of the composite metric
- Doesn't impact best path selection
- Can filter out prefixes based on hop count reachability
- Can be configured manually
- Command:
- (config-router)#metric maximum-hops <1-255>
- Default value is 100
[__/su_spoiler]
[_/su_spoiler]
Classic-mode Metric Formula
Classic-mode Composite Metric Formula
Formula
Composite Metric = (K1 x Bandwidth) + (K2 x (Bandwidth / (256 – load)) + (K3 x Delay) x (K5 / (reliability + K4)
Default Used Formula
Composite Metric = Bandwidth + Delay
- With default values calculation becomes:
- Composite Metric = (K1 x Bandwidth) + (K3 x Delay)
- Composite Metric = (1 x Bandwidth) + (1 x Delay)
- Composite Metric = (1 x ((10^7 x 256)/BW) + (1 x ((DLY/10) x 256))
- Composite Metric = (1 x 2560000000 / BW) + (1 x ((Delay/10) x 256))
- Example on a 100Mb link with 6000 total delay along path
- (10^7 x 256) / 10000 = 256000 (Bandwidth)
- (6000/10) x 256 = 153600 (Delay)
- (1 x 256000) + (1 x 153600) = 409600 (Computed Distance)
- To convert IGRP metric to an EIGRP metric, multiply the IGRP metric by 256.
[_/su_spoiler]
EIGRP Named-mode
EIGRP Named-mode
- EIGRP Named-mode also known as Multi-AF (address-family) mode
- Wide-Metrics are used for calculating best path
- Overcomes the issue of calculating metric values of links faster than 1Gbps
- Process identifier is represented by a string
- Arbitrary and locally significant value
- Autonomous System number is configured under the address-family container
- AFI (Address Family Identifier) = IPv4
- SAFI (Sub-Address Family Identifier = Unicast
- K6 value added to Hello packets to indicate Named Mode is used
- Set to 0 by default for Classic Mode compatibility
- Used for future capability
- Currently 3 extended metrics defined:
- Jitter
- Energy
- Quiescent Energy
- Supports the Add-Path feature
- Specifically used for DMVPN Phase 2 where there are multiple spokes advertising the same prefix to the hub
- To build spoke-to-spoke tunnels both paths need to be advertised
- Installs multiple best paths in EIGRP RIB and passes to Global Routing Table (GRT)
- Configured at the interface level
- Command:
- (config-router-af)#add-paths <1-4>
Named Mode Configuration
- Non-VRF aware configuration
- Commands:
- (config)#router eigrp [name]
- (config-router)#address-family ipv4 unicast autonomous-system <AS>
- VRF aware configuration:
- Commands:
- (config)#router eigrp [name]
- (config-router)#address-family ipv4 unicast vrf <vrf-name> autonomous-system <AS>
- Can upgrade from Classic-mode to Named-mode
- From version 15.4S
- Performs graceful restart automatically
- Data-plane still forwards traffic
- Control plane is restarted
- Also know as NSF (Non-Stop Forwarding)
- Command:
- (config-router)#eigrp upgrade-cli
[_/su_spoiler]
Named-mode Wide-Metrics
- Used by default when using Named-mode
- Backwards compatible with Classic-mode
- When running both Classic and Named EIGRP there can be differences in metric values which will effect the chosen path.
- Wide metric uses 64bits
- RIB can still only handle 32bit metrics
- Similar metric values as Classic-mode except:
- K1 - Bandwidth is now Throughput
- K3 - Delay is now Latency
- Throughput is scaled higher to handle faster speed links (655.36Tbps):
- Throughput = 10^7 * 65536 / bandwidth
- Latency is calculated in picoseconds
- On Interfaces equal to or slower than 1Gbps the delay is calculated as:
- Latency = Delay * 65536 / 10^6 (1000000)
- On interfaces faster that 1Gbps the delay is calculated as:
- Latency = Delay * 65536 / 10^13 (10000000000000)
- When installed in the RIB there is another calculation that takes place called RIB_SCALE
- This is a multiplier to scale down the metric so it doesn't overflow the RIB table
- RIB only supports 32bit metrics
- Scaled down after DUAL
- Can be manually configured using command:
- (config-router-af)#metric rib-scale <1 - 255>
- Set by default to 128
[_/su_spoiler]
Named-mode Wide-Metric Formula
Named-mode Wide-Metric Formula
Formula
Wide Metric = (K1 x Throughput) + (K2 x (Throughput/ (256 – load)) + (K3 x Latency) x (K5 / (Reliability + K4))
Default Used Formula
Wide Metric = Throughput) + Latency)
- Uses a similar formula as the Classic-mode metric formula
- incorporates the new K value Wide-Metrics
- With default values calculation becomes:
- Wide Metric = (K1 x Throughput) + (K3 x Latency)
- Wide Metric = (1 x Throughput) + (1 x Latency)
- If link is =< 1Gbps
- Wide Metric = (1 x ((10^7 x 65536)/Throughput) + (1 x ((Latency x 65536)/10^6))
- Wide Metric = (1 x (655360000000/ Throughput) + (1 x ((Latency x 65536)/1000000))
- Wide Metric = (655360000000/ Throughput) + ((Latency x 65536)/1000000)
- If link is > 1Gbps
- Wide Metric = (1 x ((10^7 x 65536)/Throughput) + (1 x ((Latency x 65536)/10^13)
- Wide Metric = (1 x (655360000000/ Throughput) + (1 x ((Latency x 65536)/10000000000000)
- Wide Metric = (655360000000/ Throughput) + ((Latency x 65536)/10000000000000)
- Example on a 1Gb link with 6,000,000,000 (picoseconds) total delay along path
- (10^7 x 65,536) / 1,000,000 = 655,360 (Throughput)
- (6,000,000,000 x 65,536) / 1,000,000 = 393,216,000 (Latency)
- (1 x 6,553,600 ) + (1 x 6,000,000,000 ) = 393,871,360 (Computed Distance)
- 393,871,360 / 128 = 3077120 (RIB metric)
[_/su_spoiler]
EIGRP Successor and Feasible Successor
EIGRP Successor and Feasible Successor
- EIGRP runs a Feasibility Condition to select a loop-free backup paths
- Route Types
- Successor route
- Primary path installed in RIB
- Next-hop router with the lowest Computed Distance, loop-free path
- Lowest Computed Distance to destination
- Feasible Successor route
- Backup path stored in EIGRP topology table
- Backup router with loop-free path
- Must meet the Feasibility Condition (FC) to be counted as a Feasible Successor
- Provides sub-second re-convergence when Successor route fails
- Can also be used for unequal cost load-balancing
- Advertised Distance (AD) / Reported Distance (RD)
- Metric from next hop router to destination
- Computed Distance (CD)
- Calculated metric of Advertised Distance (AD/RD) + local cost to next-hop router
- Used to determine Successor routes and Feasible Successor routes
- For each neighbor there is one Computed Distance and one Advertised Distance
- Feasible Distance (FD)
- Lowest known Computed Distance since the last transition from the Active to Passive state
- Historical copy of the lowest CD
- Not necessarily the current best CD to a destination
- There can be only one FD for a prefix on a router
- Never advertised to neighbor
Feasibility Condition
Feasibility Condition Rule
The Advertised Distance of a neighbors route must be lower than the current Computed Distance of the Sucessor route
- In the above example Path A becomes the Successor route because it has the lowest Computed Distance of 5632
- Path B and C both become Feasible Successor routes because
- R2's Advertised Distance (3840) is lower than Path A's Computed Distance (5632)
- R6's Advertised Distance (5120) is lower than Path A's Computed Distance (5632)
[_/su_spoiler]
QUERY and REPLY
- Successor fails, no Feasible Successors:
- Route moves to ACTIVE state
- Sends QUERY to all neighbors for that prefix
- QUERY message is for exact match on prefix
- Convergence relies on all REPLY to QUERY messages
- REPLY sent immediately if no match on prefix
- If there is a summary route that covers the prefix that is in the QUERY message, this doesn't count as a match
- After REPLY received from all neighbors, EIGRP re-converges
- When loop-free path found, installed in routing table
- QUERY domain can be limited by
- Summarization
- EIGRP Stub routers
Feasible Successor available
- Successor fails, Feasible Successor available:
- Route doesn't become ACTIVE
- Feasible Successor promoted to Successor
- Sub-second reconvergence
[_/su_spoiler]
EIGRP Authentication
EIGRP Authentication
- MD5 Authentication
- Supported by Named-mode and Classic-mode
- Uses key chains
- SHA-256 Authentication
- Only supported in Named-mode
- Doesn’t use key chains
Classic-mode Authentication
Classic-mode Authentication
- Key chains can be used with EIGRP Classic-mode
- Can be used to set:
- Key IDs (must match)
- Cryptographic algorithms
- Key lifetimes
- Can have multiple keys, with automatic key rotation based on time
- Can only send one key at a time
- Lowest active key is always sent
- Can accept multiple keys
- Recommend to overlap keys for a small time-frame
- Keychain set on interface
- Commands:
- (config)#key chain <keychain name>
- (config-keychain)# key <key ID>
- (config-keychain-key)# keystring <key>
- (config-keychain-key)# cryptographic-algorithm <algorithm>
- (config-keychain-key)#send-lifetime [infinite | <end-time> | duration <seconds>]
- (config-keychain-key)#accept-lifetime [infinite | <end-time> | duration <seconds>]
- (config-if)#ip authentication mode eigrp <AS> md5
- (config-if)# ip authentication-key-chain eigrp <AS> <keychain name>
- #show key chain
[_/su_spoiler]
Named-mode Authentication
Named-mode Authentication
- MD5 uses same method of key chains as Classic-mode
- Defined under af-interface
- Interoperable with Classic-mode MD5 authentication
- SHA256 uses a static key configuration
- Defined under af-interface
- Can use af-interface default
- specific interface configuration will over-ride the default configuration
- Command:
- (config-router-af-interface)#authentication mode hmac-sha-256 <key string>
- Configuration on physical interface doesn't apply
[_/su_spoiler]
EIGRP over DMVPN
EIGRP over DMVPN
- Split-Horizon rule
- Can be disabled
- Feasibility Condition rule prevents loops in the topology when disabling split-horizon
- DMVPN doesn’t support multicast, uses replicated unicast
- EIGRP is a good protocol to use with DMVPN
- Good design to use EIGRP Stub for Spokes
- Next hop Processing
- Updates include Next-hop address
- If set to 0, next-hop is the node that sent the update
- Result is all traffic traverses the Hub
- Effects DMVPN Phase 2
- To resolve this issue use the next-hop-self function
- Can be run under Classic-mode or Named-mode
- Classic-mode command:
- (config-if)#no ip next-hop-self eigrp <AS>
- Named-mode command:
- Run under address-family interface mode
- (config-router-af-interface)#no next-hop-self
- Summarization isn’t supported in DMVPN Phase 2
- For DMVPN with dual-hubs to perform ECMP between them, need to use the add-path feature
- Only supported in Named-mode configuration
- Configured in the af-interface section
- Command:
- (config-router-af-interface)#add-path <1-4>
- Allows a Hub to send multiple ECMP paths to spokes
- Not compatible with VARIANCE command (needs to be set to 1)
- Need to adjust the next-hop of advertised routes using the command:
- (config-router-af-interface)#no next-hop-self
EIGRP Over the ToP (OTP)
EIGRP Over the ToP (OTP)
- Creates overlay multipoint VPNs between CE routers running EIGRP
- Nothing special needed from providers to make this happen
- Uses LISP (Locator/Identifier Separation Protocol) protocol to enable this
 
- LISP protocol:
- IP address consists of 2 parts
- Network portion/ID
- Host portion/ID
- When a host moves in the network, its whole address changes; network and host
- LISP decouples this function
EIGRPv6
EIGRPv6
- Same process and functionality as EIGRP for IPv4
- Few key differences include:
- Sends to EIGRP packets to multicast address FF02::A
- Process needs a Router-ID before it will start, even if neighbors configured
- EIGRP Classic Mode:
- Enabled at process level
- Command:
- (config)#ipv6 router eigrp <ASN>
- Enabled at interface level
- Command:
- (config-if)#ipv6 eigrp <ASN>
- Process shut down by default
- Requires to be manually not shut down
- Command:
- (config-router)#no shutdown
- EIGRP Named Mode:
- Process not shut down by default
- Enables EIGRP on all IPv6 enabled interfaces by default
- AFI changed from IPv4 to IPv6
- Command:
- (config-router)#address-family ipv6 unicast [vrf <vrf-name>] autonomous-system <ASN>
EIGRP Troubleshooting Commands
EIGRP Troubleshooting Commands
- #show ip eigrp traffic – Displays the number of different packets types sent and received
- #show ip eigrp interfaces – Show interface information on EIGRP
- #show ip eigrp interfaces detail <interface> – Show detailed interface information about EIGRP including if QUERY packets are supressed
- #show ip eigrp neighbors – Display information about connected neighbors
- #show ip eigrp neighbors detail
- #show ip protocols
- #show ip eigrp topology [all-links | prefix] – Displays all paths to destination, include paths that don’t meet the Feasibility Condition
- #debug ip eigrp packet
- #debug eigrp packet query reply – Enables debugging on EIGRP re-convergence events
- #show eigrp address-family ipv6 interfaces – Displays IPv6 interfaces where EIGRP is enabled
