Unicast eigrp updates

The receiving EIGRP router calculates the route distance based on the received metrics and the locally assigned cost of the link to that neighbor. After this initial full route table update, EIGRP sends incremental updates to only those neighbors affected by the route change. Reliable Transport Protocol. Neighbor Discovery and Recovery. Diffusing Update Algorithm. See the Neighbor Discovery and Recovery section. The Reliable Transport Protocol supports an intermixed transmission of multicast and unicast packets.

The reliable transport can send multicast packets quickly when unacknowledged packets are pending. This provision helps to ensure that the convergence time remains low for various speed links. See the Configuring Advanced EIGRP section for details about modifying the default timers that control the multicast and unicast packet transmissions.

The Reliable Transport Protocol includes the following message types:. Hello—Used for neighbor discovery and recovery. By default, the hello interval is 5 seconds.

Acknowledgment—Verify reliable reception of Updates, Queries, and Replies. Updates—Send to affected neighbors when routing information changes.

Updates include the route destination, address mask, and route metrics such as delay and bandwidth. EIGRP adds neighbors to the neighbor table. The information in the neighbor table includes the neighbor address, the interface it was learned on, and the hold time, which indicates how long EIGRP should wait before declaring a neighbor unreachable. By default, the hold time is three times the hello interval or 15 seconds. These Update messages contain only the new or changed information and are sent only to the neighbors affected by the change.

The topology table includes the following information:. Successors—The IP address and local interface connection for all feasible successors or neighbors that advertise a shorter distance to the destination than the current feasible distance. Feasibility distance FD —The lowest calculated distance to the destination. The feasibility distance is the sum of the advertised distance from a neighbor plus the cost of the link to that neighbor. DUAL uses the distance metric to select efficient, loop-free paths.

When a topology change occurs, DUAL looks for feasible successors in the topology table. If there are feasible successors, DUAL selects the feasible successor with the lowest feasible distance and inserts that into the unicast RIB, avoiding unnecessary recomputation.

When there are no feasible successors but there are neighbors advertising the destination, DUAL transitions from the passive state to the active state and triggers a recomputation to determine a new successor or next-hop router to the destination. The amount of time required to recompute the route affects the convergence time. Neighbors that have a feasible successor send a Reply message with that information.

Neighbors that do not have feasible successors trigger a DUAL recomputation. When a topology change occurs, EIGRP sends an Update message with only the changed routing information to affected neighbors. This Update message includes the distance information to the new or updated network destination. The distance information in EIGRP is represented as a composite of available route metrics, including bandwidth, delay, load utilization, and link reliability.

Each metric has an associated weight that determines if the metric is included in the distance calculation. You can configure these metric weights. You can fine-tune link characteristics to achieve optimal paths, but we recommend that you use the default settings for most configurable metrics. These routes have the following metrics:.

Next hop—The IP address of the next-hop router. Delay—The sum of the delays configured on the interfaces that make up the route to the destination network. The delay is configured in tens of microseconds. Bandwidth—The calculation from the lowest configured bandwidth on an interface that is part of the route to the destination. Cisco recommends that you use the default bandwidth value.

MTU—The smallest maximum transmission unit value along the route to the destination. Hop count—The number of hops or routers that the route passes through to the destination. This metric is not directly used in the DUAL computation. Reliability—An indication of the reliability of the links to the destination. Load—An indication of how much traffic is on the links to the destination.

You can modify the metric weights to include the other metrics in the calculation. EIGRP supports wide bit metrics to improve route selection on higher-speed interfaces or bundled interfaces. Routers supporting wide metrics can interoperate with routers that do not support wide metrics as follows:. A router that supports wide metrics—Adds local wide metrics values to the received values and sends the information on.

A router that does not support wide metrics—Sends any received metrics on without changing the values. EIGRP uses the following equation to calculate path cost with wide metrics:. Jitter—Measured in microseconds and accumulated across all links in the route path.

Energy—Measured in watts per kilobit and accumulated across all links in the route path. EIGRP prefers a path with low or no jitter or energy metric values over a path with higher values.

For more information, see the Enabling Wide Metrics section. AS number—The autonomous system number of the destination. Protocol ID—A code that represents the routing protocol that learned the destination route. Tag—An arbitrary tag that can be used for route maps. Metric—The route metric for this route from the external routing protocol. You cannot configure the same feature in more than one configuration mode.

For example, if you configure the default metric in router configuration mode, you cannot configure the default metric in address family mode. You can configure authentication on EIGRP messages to prevent unauthorized or invalid routing updates in your network. You can configure the EIGRP authentication per virtual routing and forwarding VRF instance or interface using keychain management for the authentication keys. Keychain management allows you to control changes to the authentication keys used by MD5 authentication digest.

If the message has not changed, the calculation is identical, and the EIGRP message is considered valid. MD5 authentication also includes a sequence number with each EIGRP message that is used to ensure that no message is replayed in the network. You can use the EIGRP stub routing feature to improve network stability, reduce resource usage, and simplify stub router configuration.

See the Stub Routing section. EIGRP stub routing does not automatically enable summarization on the distribution router. In most cases, you need to configure summarization on the distribution routers. Without EIGRP stub routing, even after the routes that are sent from the distribution router to the remote router have been filtered or summarized, a problem might occur.

For example, if a route is lost somewhere in the corporate network, EIGRP could send a query to the distribution router. The distribution router could then send a query to the remote router even if routes are summarized. If a problem communicating over the WAN link between the distribution router and the remote router occurs, EIGRP could get stuck in an active condition and cause instability elsewhere in the network.

EIGRP stub routing allows you to prevent queries to the remote router. You can configure a summary aggregate address for a specified interface. Route summarization simplifies route tables by replacing a number of more-specific addresses with an address that represents all the specific addresses. For example, you can replace If more specific routes are in the routing table, EIGRP advertises the summary address from the interface with a metric equal to the minimum metric of the more specific routes.

In case of process restart or system switchover, the summary address can cause traffic loss. The traffic loss will be seen on the PEER where traffic is routed using the summary address. EIGRP does not support automatic route summarization. You must configure a route map with the redistribution to control which routes are passed into EIGRP.

A route map allows you to filter routes based on attributes such as the destination, origination protocol, route type, route tag, and so on. See Configuring Route Policy Manager. You use distribute lists to filter routes from routing updates. These filtered routes are applied to each interface with the ip distribute-list eigrp command.

You can use load balancing to allow a router to distribute traffic over all the router network ports that are the same distance from the destination address. Load balancing increases the usage of network segments, which increases effective network bandwidth. You can use split horizon to ensure that EIGRP never advertises a route out of the interface where it was learned. When you enable split horizon on an interface, Cisco NX-OS does not send update and query packets for destinations that were learned from this interface.

Controlling update and query packets in this manner reduces the possibility of routing loops. EIGRP uses split horizon or split horizon with poison reverse in the following scenarios:. Exchanging topology tables for the first time between two routers in startup mode.

By default, the split horizon feature is enabled on all interfaces. BFD is a detection protocol designed to provide fast forwarding-path failure detection times. BFD provides subsecond failure detection between two adjacent devices and can be less CPU-intensive than protocol hello messages because some of the BFD load can be distributed onto the data plane on supported modules.

With nonstop forwarding NSF , peer networking devices do not experience routing flaps. During failover, data traffic is forwarded through intelligent modules while the standby supervisor becomes active. If a Cisco NX-OS system experiences a cold reboot, the device does not forward traffic to the system and removes the system from the network topology.

During a switchover, EIGRP uses nonstop forwarding to continue forwarding traffic based on the information in the FIB, and the system is not taken out of the network topology. The graceful restart-capable router uses Hello messages to notify its neighbors that a graceful restart operation has started. When a graceful restart-aware router receives a notification from a graceful restart-capable neighbor that a graceful restart operation is in progress, both routers immediately exchange their topology tables.

The graceful restart-aware router performs the following actions to assist the restarting router as follows:. This process allows the graceful restart-aware router to reply to the restarting router more quickly and reduces the amount of time required for the restarting router to rediscover neighbors and rebuild the topology table. The router starts the route-hold timer.

This timer sets the period of time that the graceful restart-aware router will hold known routes for the restarting neighbor. The default time period is seconds. The router notes in the peer list that the neighbor is restarting, maintains adjacency, and holds known routes for the restarting neighbor until the neighbor signals that it is ready for the graceful restart-aware router to send its topology table or the route-hold timer expires. If the route-hold timer expires on the graceful restart-aware router, the graceful restart-aware router discards held routes and treats the restarting router as a new router that joins the network and reestablishes adjacency.

Every instance uses the same system router ID. You can optionally configure a unique router ID for each instance. When you configure a table map, administrative distance of the routes and the metric, the configuration commands cause the EIGRP neighbors to flap. This is an expected behavior. Names in the prefix-list are case-insensitive. We recommend using unique names.

Do not use the same name by modifying uppercase and lowercase characters. To understand this, let us configure a new loopback interface Lo1 Below is the Wireshark capture of R1 sending an update to R2 on multicast address Update Packets have OPCode of 1. R1's physical interface IP address is R1 clear ip eigrp neighbors. Below is wireshark capture of R1 sending unicast update to R2. This Query Packet is sent as a multicast on a multicast address If no response is received in 16 attempts, the EIGRP neighbor relationship is reset with that neighbor.

Query Packets have OPCode of 3. Reply Packets have OPCode of 4. Both Ack and Hello Packets have Opcode 5. With graceful shutdown, a goodbye message is broadcast when an EIGRP routing process is shut down, to inform adjacent peers about the impending topology change. If a router establishes an adjacency over an interface that previously had no adjacencies, it will send the Updates as multicast because there is a fair chance that there are multiple neighbors on the segment, and the router needs to synchronize with all of them.

If, however, the interface already has at least one fully synchronized adjacency, and a new neighbor is detected, the router will synchronize to this neighbor using unicasted Updates.

Consider this scenario: R1 and R2 connected via a switch, detecting themselves - they will sync to each other using multicasts. Afterwards, R3 joins the segment. Finally, R4 joins the segment. R1 R2. R4 R3. Keep in mind that the motivation for the multicast here is: "I'm starting over an interface where I had no neighbors before, and now there is at least one - so it's possible there are actually many of them, and I need to talk to all of them because everybody is interested in knowing what I know - ideally at once, so let's use multicast".

Not really. Even though there are only two neighbors on each of those links, the idea is: "I have news that is relevant to anyone on the link, so I am going to multicast the update. When trying to decide on the use of multicasts vs. Is it just a single neighbor out of many neighbors, or are those potentially all neighbors on the wire, regardless of how many? Regarding the draft, it is still being imprecise in a number of places, so at this point, I suggest not taking it as a definitive reference.

Being generously accepted as one of its co-authors, I can say that we're currently in the process of overhauling it and removing the ambiguosities - it will take some time but we'll get it done. Thank you Peter for your detailed reply, for analyzing the packet capture, for explaining the EIGRP 3-way handshake process, for explaining how EIGRP routers initialy establish a peeing, exchange topology information and poison routes. Buy or Renew. Find A Community. Cisco Community.

Thank you for your support! We're happy to announce that we met our goal for the Community Helping Community campaign! Turn on suggestions. Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type. Showing results for. Search instead for. Did you mean:. All Community This category This board. George Servetas. Labels: Labels: Routing Protocols. I have this problem too. All forum topics Previous Topic Next Topic.

Accepted Solutions. Peter Paluch. Hall of Fame Cisco Employee. In response to George Servetas. Best regards, Peter. In response to Peter Paluch. Furthermore, the draft states: When two routers first become neighbors, they exchange topology tables during startup mode.

Which is the normal protocol behavior? That is: Should unicast topology updates be sent during the startup process? Should routes be poisoned partially during the startup process?