EIGRP routers use the Hello protocol to build and maintain neighbor adjacencies in a way that’s similar to Open Shortest Path First (OSPF) and other protocols. Reliable Transport Protocol(RTP) allows routers to initially exchange the complete routing information when synchronizing for the first time, and afterward, advertise changed routes only.
The use of Hellos to establish and maintain router adjacencies and RTP to carry all updates reliably allows EIGRP to completely abandon the periodic updating process.
To maintain a loop-free operation at every instant, EIGRP uses a so-called Feasibility Condition criterion to identify neighbors, providing
guaranteed loop-free paths to a given destination.
The task of searching for a replacement path to a destination diffuses into the affected part of the network, hence the namediffusing computations. The use of diffusing computations is at the core of EIGRP’s rapid convergence.
Diffusing Update Algorithm (DUAL) controls the run of a diffusing computation, processing the replies and eventually inserting the gathered information into the routing table or commencing an additional diffusing computation.
EIGRP has a default hop-count limitation of 100; however, this value can be manually adjusted.
EIGRP Internal routes(AD 90) are those injected into EIGRP by the network command. External routes(AD 170) are redistributed into EIGRP from a different routing source.
EIGRP Classic Metrics
EIGRP uses several types of metrics-bandwidth, delay, reliability, load, MTU, and hop count. The first four are combined together using a well-known formula to produce a single number called composite metric which is used by EIGRP to choose the best path toward a destination.
The bandwidth is a static metric assigned to each router interface using the bandwidth interface level command. Expressed in kilobits per second. When calculating the composite metric to a destination, EIGRP takes the minimal bandwidth along the route into account. This is done by comparing the bandwidth as advertised by a neighboring router to the bandwidth of the interface toward the advertising neighbor, and taking the lower value of these two.
The delay is a static metric assigned to each interface using the delay interface command. This metric component estimates the serialization delay incurred by the interface. If the delay is not configured explicitly, IOS assigns an implicit delay value to each interface, depending on the interface hardware type. When calculating the composite metric to a destination, EIGRP takes the total delay into account. This is done by taking the delay as advertised by a neighboring router and summing it with the delay of the interface toward the advertising neighbor. A delay of 16,777,215 tens of microseconds is used to indicate an infinite distance and is the key to the ability of advertising an unreachable network.
The reliability is a dynamically estimated metric of an interface that evaluates its reliability, and expressed as a fraction of 255; a reliability of 255 expresses a 100 percent reliability. When calculating the composite metric to a destination, EIGRP takes the minimal reliability into account; done by comparing the reliability as advertised by a neighboring router to the reliability of the interface toward the advertising neighbor, and taking the lower value of these two. A change in interface reliability value does not trigger sending EIGRP updates. The reliability metric of a route is just a snapshot of its then-current reliability when it was last advertised. In EIGRP, the reliability metric component is currently just a relic carried over from its predecessor, with no particular usability.
The load is a dynamically estimated metric of an interface that measures the amount of traffic flowing through the interface in relation to its maximum capacity; expressed as a fraction of 255, 1 representing an empty interface and the load of 255 representing a fully utilized interface. When calculating the composite metric to a destination, EIGRP takes the maximal Txload into account. Same as with reliability, changes in the Txload values on interfaces do not trigger EIGRP updates and along with reliability, no particular usability in EIGRP.
Similar to bandwidth and reliability, EIGRP advertises the minimum MTU along the route to the destination. However, MTU is completely unused in the best-path selection process. It is not factored into the composite metric, nor is it used as any kind of a tiebreaker.
The hop count metric component is simply a counter of routers(hops) in the path toward the destination. The route with a hop count over a predefined threshold(default is 100) is considered unreachable. The hop count is not factored into the composite metric calculation and does not impact the best-path selection.
EIGRP routers exchange these component metrics as separate values and each router must independently compute the resulting composite metric on its own. This composite metric is used locally on a router, and is never advertised as a single number in EIGRP messages except when a route is redistributed from one EIGRP process to another.
EIGRP Wide Metrics
With the speeds of interfaces ever increasing, the EIGRP Classic Metrics faced issues with interfaces faster than 1 Gbps. The Bandwidth component itself is unable to differentiate between a 10-Gbps and faster interfaces. In addition, the default Delay component metric is already set to the lowest value of 1 (10 microseconds) on 1-Gbps interfaces and cannot be made smaller on faster interfaces. show eigrp plugins
EIGRP Wide Metrics consist of
Throughput: analogous to the classic Bandwidth component, expressed in kbps.
Latency: analogous to the classic Delay, expressed in picoseconds.
Reliability: identical to the classic Reliability
Load: identical to the classic Load
MTU: identical to the classic MTU
Hop Count: identical to the classic Hop Count
Extended Metrics: considered as placeholders for future extensions to the composite metric computation; not usually used or supported.
In the case of mixed neighbors on a common interface, EIGRP routers supporting Wide Metrics will use both metric formats in their messages, allowing each neighbor to process the metric format it supports.
Because the Wide Metrics composite value can well result in a number wider than 32 bits while the routing table (Routing Information Base, RIB) is capable of handling only 32-bit metrics, the Wide Metrics composite value has to be downscaled before the route can be passed down to the RIB in IOS by dividing Wide Metrics composite value by a factor (default is 128). EIGRP makes all its path selections based on the Wide Metrics composite value; only after a best path toward a destination is selected, its composite metric value is downscaled as the route is installed to the RIB.
Tweaking Interface Metrics to Influence Path Selection
EIGRP metric components that can be manually influenced are the Bandwidth and Delay. Changing the bandwidth can have impact beyond affecting the EIGRP metrics. EIGRP by default throttles to use 50 percent of the configured bandwidth.Changing the delay does not impact other protocols nor does it cause EIGRP to throttle back.
The bandwidth parameter of an interface should always be configured to the true bandwidth of the interface and should never be used to influence EIGRP’s path selection. The delay is the right metric that can be manually modified to affect the best-path selection.
EIGRP Packet Format
Each EIGRP packet carries a 20-byte header, followed by a variably sized body as TLVs which carry diverse information including EIGRP and TLV versions, K-values, Hold timers, control information to facilitate reliable multicasting, and most importantly, route reachability information. There is no clearly delineated RTP header. Instead, the Flags, Sequence number, and Acknowledgment number fields are the ones that provide most of the RTP functionality in EIGRP;TLVs(Type-Length-Values) are a particular format of storing and transmitting different types of information in a single datagram; each TLV contains a particular piece of information that the sender wants to advertise.
A Hello packet with a nonzero ACK field will be treated as an ACK packet rather than as a Hello. Note that an ACK field will only be nonzero if the packet itself is unicast because acknowledgments are never multicasted.
EIGRP uses seven different packet types
Hello messages are used to identify neighbors, verify whether these neighbors are compatibly configured (residing on a common IP subnet, using the same AS number, K-values, and authentication if configured), and serve as a keepalive mechanism between neighbors. Hello packets are sent to the link-local multicast group address 224.0.0.10 in IPv4, and FF02::A in IPv6. If static neighbors are configured, Hello packets are sent as unicasts to the neighbor’s explicitly configured address. The default Hello interval is 5 seconds; Opcode 5.
An EIGRP Acknowledgment (ACK) packet is used to acknowledge selected received EIGRP packets to facilitate their reliable delivery. ACKs are sent in response to Update, Query, Reply, SIA-Query, and SIA-Reply packets, and are always unicasted to the sender of the acknowledged packet. ACK uses the same Opcode as the Hello packet, that is, 5.
In EIGRP, it is allowed to use any unicast reliable packet to also carry an acknowledgment number. If a router has both a unicast reliable packet to send to a neighbor and also needs to acknowledge a previously received reliable packet from that neighbor, the sequence number of the received reliable packet can be sent along with the outbound reliable packet in its Acknowledgment number field. If there is no data to be sent to the peer, only a TCP segment header with an empty body is sent, carrying the proper acknowledgment. The standalone ACK—in reality is a Hello with no TLVs and just its Acknowledgment number field set. Out of reliable packets, only those that are unicasted can be also used to carry acknowledgment numbers.
EIGRP Update packets contain routing information updates and are used to convey the reachability of destinations. Update packets can be both unicasted and multicasted. Update packets are assigned an Opcode of 1. During a new adjacency buildup, Update packets are unicasted between the newly discovered neighbors. After routers have fully synchronized, further Updates are sent as multicasts.
If a neighbor does not acknowledge the arrival of an Update packet, EIGRP will retransmit the Update as unicast to the unresponsive neighbor. On point-to-point interfaces and for statically configured neighbors, EIGRP always uses unicast to send Updates.
EIGRP Query packets are used to involve neighbors in the task of searching for the best route toward a destination. Similarly to Updates, Queries are also delivered reliably. Queries can be both unicasted and multicasted; by default, on multiaccess interfaces with only dynamic neighbors, Queries are sent as multicasts. If not acknowledged in proper time by a neighbor, a Query is retransmitted to the unresponsive neighbor as unicast. On point-to-point interfaces and toward statically configured neighbors, Queries are always sent as unicasts. The ACK does not constitute a response to the Query message, only an acknowledgment that the Query has been received. It uses Opcode of 3.
EIGRP Reply packets are sent in response to Query packets and carry their sender’s current distance to the destination after taking into account the topology change that prompted the Query. Reply packets are always unicasted to the originator of the Query and delivered reliably. Opcode of 4.
SIA-Query and SIA-Reply Packets are used during a prolonged diffusing computation to verify whether a neighbor that has not yet sent a Reply to a Query is truly reachable and still engaged in the corresponding diffusing computation. The SIA-Query packet is used to ask a particular neighbor to confirm that it is still working on the original Query. If the neighbor is reachable and is still engaged in the diffusing computation for the destination specified in the SIA-Query, it will immediately respond with an SIA-Reply packet. As a result, the timer that governs the maximum time a diffusing computation is allowed to run is reset, giving the computation extra time to finish.
Reliable Transport Protocol
The Reliable Transport Protocol(RTP) manages the delivery and reception of EIGRP packets. Packet types that are to be delivered reliably are Update, Query, Reply, SIA-Query, and SIA-Reply, regardless of whether they are unicasted or multicasted (SIA-Query, Reply, and SIA-Reply are only unicasted, of course). Each of these packets carries a nonzero Sequence number in its header.
Packets that are not to be delivered reliably(Hello and ACK packets) set their Sequence number to zero and do not cause the global Sequence number to increase. With a naïve reliable multicast, each recipient of a multicasted message must acknowledge its arrival before the sender can move on to transmit another message. If some recipient does not acknowledge the message, the sender has to postpone further sending of multicast packets and retransmit the missing message to the intended recipient as unicast until the recipient successfully acknowledges its arrival. Waiting for lagging/misbehaving routers causes negative impact on the performance of entire reliable musticast steraming.
This is overcome by the sender first transmitting a Hello packet with two specific TLVs called the Sequence TLV and the Next Multicast Sequence TLV, often called a Sequenced Hello. The Next Multicast Sequence TLV contains the upcoming sequence number of the next reliable multicasted message. The Sequence TLV contains a list of all lagging neighbors by their IP address.
A neighbor receiving this Sequenced Hello packet and not finding itself in the Sequence TLV will put itself into Conditional Receive mode(CR-mode). A neighbor finding itself in the Sequence TLV, or a neighbor not receiving this Hello packet at all for whatever reason will not put itself into the CR-mode. Afterward, the sending router will send the next multicast packet with the CR flag set in its Flags field. Routers in CR-mode will process this packet as usual and then exit the CR-mode; routers not in CR-mode will ignore it.
Router Adjacencies
EIGRP by default discovers neighboring routers dynamically, or it can discover neighbors through manual administrator configuration (static).
Dynamic neighbor discovery is performed by sending EIGRP Hello packets to the destination multicast group address 224.0.0.10 or FF02::A as EIGRP is activated on an interface.
When static EIGRP neighbors are configured, the local router uses the unicast neighbor address to send packets to these routers. It is deployed across media that does not natively support broadcast or multicast packets, such as Frame Relay.
After a static neighbor is defined, all EIGRP multicasts on the interface through which the neighbor is reachable will be disabled. As a result, EIGRP-enabled routers will not establish an adjacency if one router is configured to use unicast (static) while another uses multicast (dynamic) on the same link.
An EIGRP neighbor relationship requires that neighbors agree on
-EIGRP Authentication Parameters(if configured)
-EIGRP K-Values
-EIGRP Autonomous System(AS) Number
-Use of primary addresses for EIGRP neighbor relationships
-Use of the common IP network address on a single subnet
Note that the timers (that is, Hello and Hold) do not need to match between neighbors.
The Hold time tells the router the maximum time it should wait to receive subsequent valid EIGRP packets from a neighbor. If the Hold timer expires before any acceptable EIGRP packet is received, the neighbor is declared unreachable and DUAL is informed of the loss of a neighbor. By default, the Hold time is three times the Hello, equaling either 15 or 180 seconds depending on the interface type.
Router(config-if)# ip hello-interval eigrp 100 ?
Router(config-if)# ip hold-time eigrp 100 ?
After a new neighbor is discovered through a Hello exchange,a router is put into "pending" state in order to defer sending/accepting any EIGRP messages containing routing info between these neigbors until their bidirectional connectivity has been confirmed.
Null Update packet with the Init flag set means this adjacency is starting over from scratch. While in Pending state, the only packets that can be exchanged in both directions with the neighbor are the unreliable packets(Hello, Ack) and reliable packets with the Init flag set that indicate the startup of an adjacency.
A neighbor is moved from the Pending to the Up state if and only if the router receive an acknowledgment for its own null Update to the neighbor and must receive an Init-flagged packet from the neighbor to move the neighbor from the Pending to the Up state. It's like TCP 3 way handshake. After this EIGRP initial three-way handshake, the routers will exchange complete routing information using Update packets.
Hold time is derived from the value advertised by the neighbor and decremented each second; it is reset every time any acceptable EIGRP packet from the neighbor is received.
The SRTT, the Smooth Round Trip Time, estimates the turnover time between sending a reliable packet to the neighbor and receiving an appropriate acknowledgment. The RTO, or Retransmit Time Out, is the time that the router will wait for an acknowledgment of a retransmitted unicast packet after its previous delivery was not acknowledged.
The Q Cnt indicates the number of enqueued reliable packets, that is, packets that have been prepared for sending and even possibly sent but for which no ACK has been received yet from the neighbor. If the Q Cnt value remains nonzero for prolonged periods of time, however, it indicates a communication problem with the neighbor.
The Sequence number shows the sequence number of the last reliable packet (Update, Query, Reply, SIA-Query, or SIA-Reply) received from the neighbor.
Topology Table
The place where EIGRP stores its entire routing information including-The prefix of each known destination network (address/netmask)
-Feasible Distance of the destination network
-Address of each neighboring router that advertised the destination network, including the egress interface toward the neighbor
-Metrics of the destination network as advertised by each neighbor, and the resulting metrics of the path to the destination network through that neighbor
-State of the destination network
An important fact to remember is that a remote network must first be present in the topology table before being installed in the routing table. The sate of each network recorded in the topology table can be either Passive(the shortest path to the network has already been found and EIGRP is satisfied with it) or Active (EIGRP is currently actively involved in a search for a new shortest path). The Active state is always related to the router sending Query packets, asking its neighbors for cooperation in the search for a new path. While in an Active state, the router is prohibited from modifying the routing table entry for this network, meaning that the route must not be removed or its next hop changed. This is to make sure that the route is loop free although it migt be suboptimal or causing blackhole.
show ipv6 eigrp topology is one of very few commands in EIGRP that actually shows the Router ID of the EIGRP process.
By referencing a particular network, detailed information about it can be displayed.
show ipv6 eigrp topology 2001:DB8:CC1E::/64
Using all-links keyword, all neighbors advertising a network, including those who fail to meet the Feasibility Condition check, are displayed.
show ipv6 eigrp topology all-links
Computed, Reported, and Feasible Distances, and Feasibility Condition
The number after the slash sign is called the Reported Distance(RD) and corresponds to the current best distance of the particular neighbor to the destination. In other words, the RD is the neighbor’s distance to the destination as reported in an EIGRP packet received from that neighbor. RD is also called an Advertised Distance. If all other metrics are equal, RD values corresponds to the delay value multiplied by 256.
The number in parentheses before the slash sign is called the Computed Distance(CD) and shows the total metric of reaching the destination over the particular neighbor.
EIGRP also maintains a record of another distance for each destination: the Feasible Distance(FD) which is a record of the lowest known distance since the last transition from the Active to Passive state. FD is not necessarily equal to the current best CD to a destination. In the Passive state, after the FD has been initialized, it can only decrease(if the current best CD happens to fall below the current value of FD) or remain at its current value(if the current best CD rises but the route remains Passive). There is exactly one FD per each destination, regardless of the number of neighbors.
When a route advertise its distance to the network, it would advertise its actual distance instead of FD. FD is an internal value that is used by EIGRP to select loop-free paths, but its value is never advertised in any EIGRP packets.
Feasibility Condition-any neighbor that is closer to the destination than this router has been since the last time the destination became Passive cannot form a routing loop, or more technically, any neighbor whose Reported Distance is strictly smaller than this router’s Feasible Distance cannot form a routing loop .
If a neighbor’s RD is equal to or higher than R1’s FD, it might or might not cause a routing loop. However, it is certain and guaranteed that if a neighbor’s RD is lower than R1’s FD(that is, if the neighbor is closer to the destination than R1 has ever been since the last time the destination became Passive), it will not cause a routing loop.
For a destination, all neighbors that pass the FC and thus are safe to use as next hops are called Feasible Successors . In other words, a Feasible Successor is a neighbor that is guaranteed to provide a loop-free path toward a destination; Feasible Successors are identified by passing the FC check. Among these Feasible Successors, one or more provide the least CD to the destination; these are called Successors.
All Successors and Feasible Successors to a destination can be seen in the show ip eigrp topology output. Neighbors that do not meet the FC are not displayed in this output; to display them as well, the show ip eigrp topology all-links command must be used.
No comments:
Post a Comment