A diffusing computation grows by querying additional routers for their current RD to the affected destination, and it shrinks by receiving replies from them. Unaffected routers send replies immediately, terminating the growth of the diffusing computation over them. These intrinsic properties cause the diffusing computation to self-adjust in scope and terminate as soon as possible.
One attribute of DUAL is its ability to control the point at which the diffusion of a route calculation terminates by managing the distribution of reachability information through the network. This provides the ability to create effective failure domains within a single AS, and allows the network administrator to manage the convergence and processing characteristics of the network. Consequently, in PASSIVE state, the router does not perform any route recalculation in coordination with its neighbors because no such recalculation is needed.
In ACTIVE state, the router is actively involved in re-computing the least-cost loop-free path in coordination with its neighbors. The state is reevaluated and possibly changed every time a topology change is detected. A topology change is any event that causes the CD to the destination over any neighbor to be added, changed, or removed from EIGRP's topology table. More exactly, the two states are defined as follows: o Passive A route is considered to be in the Passive state when at least one neighbor that provides the current least-total-cost path passes the Feasibility Condition check that guarantees loop freedom.
A route in the ACTIVE state is considered unusable and this router must coordinate with its neighbors in the search for the new loop- free least-total-cost path. Feasible Successors providing the least-total-cost path are also called "successors". While these neighbors are guaranteed to provide a loop-free path, that path is potentially not the shortest available.
The fact that the least-total-cost path can be provided by a neighbor that fails the Feasibility Condition check may not be intuitive. However, such a situation can occur during topology changes when the current least-total-cost path fails and the next-least-total-cost path traverses a neighbor that is not a Feasible Successor. Feasibility Condition The Feasibility Condition is a criterion used to verify loop freedom of a particular path. The Feasibility Condition is a sufficient but not a necessary condition, meaning that every path meeting the Feasibility Condition is guaranteed to be loop free; however, not all loop-free paths meet the Feasibility Condition.
Based on the result of the Feasibility Condition check after a topology change is detected, the route may either remain PASSIVE if, after the topology change, the neighbor providing the least cost path meets the Feasibility Condition or it needs to enter the ACTIVE state if the topology change resulted in none of the neighbors providing the least cost path to meet the Feasibility Condition. Nodes that are not affected by the topology change are not required to perform a DUAL computation and may not be aware a topology change occurred.
This can occur in two cases: Savage, et al. A route that meets the Feasibility Condition is determined to be loop free and downstream along the path between the router and the destination. Second, if informed about a topology change for which it does not currently have reachability information, a router is not required to enter into the ACTIVE state, nor is it required to participate in the DUAL process.
In order to facilitate describing the Feasibility Condition, a few definitions are in order. Typically, the successor is chosen based on the least-cost path to reach the destination.
A Feasible Successor is regarded as a downstream neighbor towards the destination, but it may not be the least-cost path but could still be used for forwarding data packets in the event equal or unequal cost load sharing was active. A Feasible Successor can become a successor when the current successor becomes unreachable. It should be noted it is not necessarily the current best distance; rather, it is a historical record of the best distance known since the last diffusing computation for the destination has finished.
Thus, the value of the FD can either be the same as the current best distance, or it can be lower. A neighbor that advertises a route with a cost that does not meet the Feasibility Condition may be upstream and thus cannot be guaranteed to be the next hop for a loop-free path. Routes advertised by upstream neighbors are not recorded in the routing table but saved in the topology table.
It tracks all routes advertised by all neighbors. The distance information, known as a metric, is used by DUAL to select efficient loop-free paths. A successor is a neighboring router used for packet forwarding that has a least-cost path to a destination that is guaranteed not to be part of a routing loop. When there are no Feasible Successors but there are neighbors advertising the destination, a recalculation must occur to determine a new successor.
Even though the recalculation is not processor intensive, it is advantageous to avoid recalculation if it is not necessary. If there are Feasible Successors, it will use any it finds in order to avoid any unnecessary recalculation.
The FSM, which applies per destination in the topology table, operates independently for each destination. However, a separate SDAG is computed for each destination, so loop- free topologies can be maintained for each reachable destination.
Split horizon takes effect for a query or update from the successor it is using for the destination in the query. The route stays in ACTIVE state if there are more replies pending because the router has not heard from all neighbors.
Each node is labeled with its costs to destination N. The arrows indicate the successor next hop used to reach destination N. The least-cost path is selected. C determines that it has a Feasible Successor and replies immediately with metric 3. D now has a viable path to N through C. D selects C as its successor to reach node N with a cost of 4. Notice that nodes A and B were not involved in the recalculation since they were not affected by the change.
Note that nodes A and D were not involved in the recalculation since their successors were not affected. Each packet transmitted will use either multicast or unicast network- layer destination addresses.
When multicast addresses are used, a mapping for the data link multicast address when available must be provided. The source address will be set to the address of the sending interface, if applicable.
The following network-layer multicast addresses and associated data link multicast addresses: Network-layer addresses will be used and the mapping to media addresses will be achieved by the native protocol mechanisms. When a new neighbor is discovered, unicast UPDATE packets are used to transmit a full table to the new neighbor, so the neighbor can build up its topology table.
An infinite metric is encoded by setting the delay part of the metric to its maximum value. When a REPLY packet is received, there is no reason to process the packet before an acknowledgment is sent. Therefore, an acknowledgment is sent immediately and then the packet is processed. The sending of the acknowledgment is accomplished either by sending an ACK packet or by piggybacking the acknowledgment onto another packet already being transmitted.
Exception Handling 4. Any neighbor that fails to send Savage, et al. Implementation note: Cisco currently implements option b. A lost packet, congestion on the link, or a slow neighbor could cause a lack of REPLY from a downstream neighbor. This enables an EIGRP router to determine if there is a communication issue with the neighbor or if it is simply still attempting to converge with downstream routers.
By sending an SIA-QUERY, the originating router may extend the effective active time by resetting the ACTIVE timer that has been previously set, thus allowing convergence to continue so long as neighbor devices successfully communicate that convergence is still underway. The SIA-REPLY informs the recipient that convergence is complete or still ongoing; it is an explicit notification that the router is still actively engaged in the convergence process.
It supports intermixed transmission of multicast and unicast packets. For efficiency, reliability is provided only when necessary. For example, on a multi-access network that has multicast capabilities, such as Ethernet, it is not necessary to send HELLOs reliably to all neighbors individually.
The reliable transport has a provision to send multicast packets quickly when there are unacknowledged packets pending. This helps ensure that convergence time remains low in the presence of varying speed links. DUAL assumes there is lossless communication between devices and thus must depend on the transport protocol to guarantee that messages are transmitted reliably.
EIGRP implements the reliable transport protocol to ensure ordered delivery and acknowledgment of any messages requiring reliable transmission. State variables such as a received sequence number, acknowledgment number, and transmission queues MUST be maintained on a per-neighbor basis. The sequence number wraps around to one when the maximum value is exceeded sequence number zero is reserved for unreliable transmission.
The sender includes the receivers sequence number in the acknowledgment number field of the fixed header. Otherwise, it is acknowledging a single packet. When a router transmits a packet, it increments its sequence number and marks the packet as requiring acknowledgment by all neighbors on the interface for which the packet is sent.
When individual acknowledgments are unicast addressed by the receivers to the sender with the acknowledgment number equal to the packets sequence number, the sender SHALL clear the pending acknowledgment requirement for the packet from the respective neighbor. If the required acknowledgment is not received for the packet, it MUST be retransmitted.
Retransmissions will occur for a maximum of 5 seconds. This retransmission for each packet is tried 16 times, after which, if there is no ACK, the neighbor relationship is reset with the peer that didn't send the ACK. The protocol has no explicit windowing support. A receiver will acknowledge each packet individually and will drop packets that are received out of order. Implementation note: The exception to this occurs if a duplicate packet is received, and the acknowledgment for the original packet has been scheduled for transmission, but not yet sent.
In this case, EIGRP will not send an acknowledgment for the duplicate packet, and the queued acknowledgment will acknowledge both the original and duplicate packet. Duplicate packets are also discarded upon receipt. Acknowledgments are not accumulative. Therefore, an ACK with a non-zero sequence number acknowledges a single packet. The reliable transport mechanism MUST ensure that all multicasts are transmitted in order and not mix the order among unicast and multicast packets.
The reliable transport provides a mechanism to deliver multicast packets in order to some receivers quickly, while some receivers have not yet received all unicast or previously sent multicast packets. This will be explained in more detail in this section. Figure 5 illustrates the reliable transport protocol on point-to- point links. This example will assume no packet loss.
This example will assume there is heavy packet loss on a network. The initial packet is always multicast and subsequent retransmissions are unicast addressed. The acknowledgments sent are always unicast addressed. Figure 7 shows an example with four routers on an Ethernet. B and C receive it and send acknowledgments. Router A detects that there is at least one neighbor on the interface with a full queue. Therefore, it MUST signal that neighbor not to receive the next packet or it would receive the retransmitted packet out of order.
In this case, the only neighbor address in the list is Router B. If not found, they put themselves in CR- Mode. Router B already has , so it discards and acknowledges it. Router B then accepts and acknowledges packet Once an acknowledgment is received, Router A can remove both packets from Router B's transmission list. If the bandwidth does not match the physical bandwidth the network architect may have put in an artificially low or high bandwidth value to influence routing decisions , EIGRP may: 1.
Generate more traffic than the interface can handle, possibly causing drops, thereby impairing EIGRP performance. To control such transmissions, an interface-pacing timer is defined for the interfaces on which EIGRP is enabled. When a pacing timer expires, a packet is transmitted out on that interface. Routers MUST also discover when their neighbors become unreachable or inoperative. As long as any packets are received from a neighbor, the router can determine that neighbor is alive and functioning.
Only after a neighbor router is considered operational can the neighboring routers exchange routing information. Neighbor Hold Time Each router keeps state information about adjacent neighbors. When newly discovered neighbors are learned the address, interface, and Hold Time of the neighbor is noted. The Hold Time is the amount of time a router treats a neighbor as reachable and operational. HELLO packets, when used for neighbor discovery, are normally sent multicast addressed.
Two routers become neighbors only if the K-values are the same. This enforces that the metric usage is consistent throughout the Internet. This value indicates to all receivers the length of time in seconds that the neighbor is valid. HELLO packets will be transmitted every 5 seconds by default. There may be a configuration command that controls this value and therefore changes the Hold Time. HELLO packets are not transmitted reliably, so the sequence number should be set to 0.
The INIT-Flag instructs the neighbor to advertise its routes, and it is also useful when a neighbor goes down and comes back up before the router detects it went down. In this case, the neighbor needs new routing information. Failure to do so will result in a Cisco device posting a "stuck in INIT state" error and subsequent discards. The second packet is queued, but it cannot be sent until the first is acknowledged. The acknowledgment gets lost.
Router B dequeues packet 11 from A's transmission list, and both routers are up and synchronized. Neighbor Formation To prevent packets from being sent to a neighbor prior to verifying multicast and unicast packet delivery is reliable, a three-way handshake is utilized. Unicast packets are then used to exchange known routing information and complete the neighbor relationship Section 5. When Router A receives the unicast acknowledgment from Router B, it will change the state from "pending" to "up".
QUERY Packets during Neighbor Formation As described above, during the initial formation of the neighbor relationship, EIGRP uses a form of three-way handshake to verify both unicast and multicast connectivity are working successfully.
During this period of neighbor creation, the new neighbor is considered to be in the pending state, and it is not eligible to be included in the convergence process. It would perform the DUAL process without the new peer in the conversation. If it determines that it must go active, each fully established neighbor that participates in the convergence process will be sent a QUERY packet, and REPLY packets are expected from each. Associated with each entry are the destination address, a list of neighbors that have advertised this destination, and the metric associated with the destination.
The metric is referred to as the "CD". The CD is the best-advertised RD from all neighbors, plus the link cost between the receiving router and the neighbor. In other words, the Computed Distance, when sent by a neighbor, is referred to as the "Reported Distance" and is the metric that the neighboring router uses to reach the destination its CD as described above. If the router is advertising a destination route, it MUST be using the route to forward packets; this is an important rule that distance vector protocols MUST follow.
Internal routes MUST be preferred over external routes, independent of the metric. In practical terms, if an internal route is received, the diffusing computation will be run considering only the internal routes. Only when no internal routes for a given destination exist will EIGRP choose the successor from the available external routes. Therefore, a directly attached network that is configured to run EIGRP is considered an internal route and is propagated with this information throughout the network topology.
External Routes External routes are destinations that have been learned from another source, such as a different routing protocol or static route. These routes are marked individually with the identity of their origination. A border router is one that runs more than one routing protocol. The router-id is set to BR1. BR2, then, has enough information to determine the AS entry point for the route, the original routing protocol used, and the metric.
Using EIGRP route tagging can give a network administrator flexible policy controls and help customize routing. Route tagging is particularly useful in transit ASes where EIGRP would typically interact with an inter-domain routing protocol that implements global policies. Within Cisco, the split horizon rule suggests: "Never advertise a route out of the interface through which it was learned".
EIGRP implements this to mean, "if you have a successor route to a destination, never advertise the route out the interface on which it was learned". The poison reverse rule states: "A route learned through an interface will be advertised as unreachable through that same interface".
As with the case of split horizon, EIGRP applies this rule only to interfaces it is using for reaching the destination. This can occur for a destination under any of the following conditions: o two routers are in startup or restart mode o advertising a topology table change o sending a query 5.
Startup Mode When two routers first become neighbors, they exchange topology tables during startup mode. For each destination a router receives during startup mode, it advertises the same destination back to its new neighbor with a maximum metric Poison Route. This adjustment allows for per-deployment tuning of network behavior. Setting K-values up to scales the impact of the scalar metric on the final composite metric. EIGRP default coefficients have been carefully selected to provide optimal performance in most networks.
Coefficients K1 and K2 K1 is used to allow path selection to be based on the bandwidth available along the path. This inversion results in a larger number more time ultimately generating a worse metric. If K2 is used, the effect of congestion as a measure of load reported by the interface will be used to simulate the "available Throughput" by adjusting the maximum Throughput.
Coefficient K3 K3 is used to allow delay or latency-based path selection. Latency and delay are similar terms that refer to the amount of time it takes a bit to be transmitted to an adjacent neighbor.
EIGRP uses one-way- based values either provided by the interface or computed as a factor of the link s bandwidth. Coefficients K4 and K5 K4 and K5 are used to allow for path selection based on link quality and packet loss. Packet loss caused by network problems results in highly noticeable performance issues or Jitter with streaming technologies, voice over IP, online gaming and videoconferencing, and will affect all other network applications to one degree or another.
The final metric can be weighted based on the reported link quality. The handling of K5 is conditional. If K5 is equal to 0, then reliability quotient is defined to be 1. Coefficient K6 K6 has been introduced with Wide Metric support and is used to allow for Extended Attributes, which can be used to reflect in a higher aggregate metric than those having lower energy usage.
Currently there are two Extended Attributes, Jitter and energy, defined in the scope of this document. Jitter Use of Jitter-based Path Selection results in a path calculation with the lowest reported Jitter. Jitter is reported as the interval between the longest and shortest packet delivery and is expressed in microseconds. Higher values result in a higher aggregate metric when compared to those having lower Jitter calculations.
Jitter is measured in microseconds and is accumulated along the path, with each hop using an averaged 3-second period to smooth out the metric change rate.
Performance-based solutions such as PfR could be used to populate this field. Energy Use of Energy-based Path Selection results in paths with the lowest energy usage being selected in a loop-free and deterministic manner. The amount of energy used is accumulative and has results in a higher aggregate metric than those having lower energy. Classic Metrics The composite metric is based on bandwidth, delay, load, and reliability. MTU is not an attribute for calculating the composite metric, but carried in the vector metrics.
Implementation note: Cisco IOS routers display reliability as a fraction of Load is a value between 1 and These values are not dynamically measured; they are only measured at the time a link changes. When converting the composite bandwidth to the real bandwidth, apply the scaling factor before the division and only then truncate. The delay is the sum of the outgoing interface delay in tens of microseconds to the destination. The bandwidth and delay for an Ethernet interface are 10 Mbps and 1 ms, respectively.
Bandwidth Classic Wide Metrics Interface kbps Delay Delay Type 9 Tunnel 56 56 kbps 64 DS0 T1 E1 Ethernet TokRing16 HSSI FDDI FastEthernet ATM Mbps GigaEthernet 2 Gig 5 Gig 10 Gig 20 Gig 50 Gig Gig 50 Gig 20 Gig 5. This change allows EIGRP to choose paths based on the computed time measured in picoseconds information takes to travel though the links.
These values are calculated from destination to source as follows: o Throughput - Minimum value o Latency - accumulative o Load - maximum o Reliability - minimum o MTU - minimum o Hop count - accumulative There are two additional values: Jitter and energy. These two values are accumulated from destination to source: o Jitter - accumulative o Energy - accumulative These Extended Attributes, as well as any future ones, will be controlled via K6.
If K6 is non-zero, these will be additive to the path's composite metric. Higher Jitter or energy usage will result in paths that are worse than those that either do not monitor these attributes or that have lower values. EIGRP will not send these attributes if the router does not provide them.
If the attributes are received, then EIGRP will use them in the metric calculation based on K6 and will forward them with those routers values assumed to be "zero" and the accumulative values are forwarded unchanged. The use of the vector metrics allows EIGRP to compute paths based on any of four bandwidth, delay, reliability, and load path selection schemes.
The schemes are distinguished based on the choice of the key-measured network performance metric. Of these vector metric components, by default, only minimum Throughput and latency are traditionally used to compute the best path. Unlike most metrics, minimum Throughput is set to the minimum value of the entire path, and it does not reflect how many hops or low Throughput links are in the path, nor does it reflect the availability of parallel links.
Latency is calculated based on one- way delays and is a cumulative value, which increases with each segment in the path. For example, Quality of Service QoS also looks at the bandwidth on an interface. Lowering the bandwidth can cause EIGRP to starve an adjacency, causing slow or failed convergence and control- plane operation. Changing the delay does not impact other protocols, nor does it cause EIGRP to throttle back; changing the delay configured on a link only impacts metric calculation.
For example, delay is expressed in microseconds per kilobyte, and would be converted to kilobytes per second; likewise, energy would be expressed in power per kilobytes per second of usage. Latency Calculation Transmission times derived from physical interfaces MUST be n units of picoseconds, converted to picoseconds prior to being exchanged between neighbors, or used in the composite metric determination.
This includes delay values present in configuration-based commands i. Protocol Number The IPv6 and IPv4 protocol identifier number spaces are common and will both use protocol identifier 88 [ 8 ] [ 9 ].
Unicast packets directed to a specific neighbor will contain the destination link-local address of the neighbor. Protocol Assignment Encoding The External Protocol field is an informational assignment to identify the originating routing protocol that this route was learned by. Current Version is 2. This field is not the same as the TLV Version field. Opcode: Indicates the type of the message. The checksum will be the standard ones' complement of the ones' complement sum.
For purposes of computing the checksum, the value of the checksum field is zero. The packet is discarded if the packet checksum fails. Flags: Defines special handling of the packet. There are currently four defined flag bits. It instructs the neighbor to advertise its full set of routes. CR-Flag 0x02 : This bit indicates that receivers should only accept the packet if they are in Conditionally Received mode.
Each Configuration Exercise assumes that you have completed the previous chapters' Configuration Exercises on your pod. NOTE Throughout this exercise, the pod number is referred to as x, and the router number is referred to as y.
Substitute the appropriate numbers as needed. Refer to this list if you need configuration command assistance during the exercise. Table Be careful when addressing your routers! Refer to the exercise instructions and the appropriate visual objective diagram for addressing details. NOTE The exercise tasks include answers and solutions. Some answers cover multiple steps; the answers are given after the last step to which that answer applies. Disable autosummarization on the edge routers.
Make sure that the autonomous system number is correct and that all neighbors are exchanging routes. P1R3 replies to the query, indicating that This will add stability and speed convergence of the network by controlling the scope of queries, minimizing update traffic, and minimizing routing table size. If both edge routers are configured correctly, you should see two equal-cost paths available to BBR1. Remember that this bounds queries but does not affect the routing table.
Solution: The following shows sample output on the P1R1 router. The highlighted lines indicate that P1R1 sees P1R3 To demonstrate this situation, use the debug ip eigrp command on the internal router. You should not see the "processing incoming QUERY" debug message on the internal routers, because they are configured as stub routers.
Solution: The following shows the required command on the P1R3 router, the configuration on the P1R1 router, and example output on the P1R3 router. Queries are no longer being sent to the internal routers. This change adds stability and speed convergence to the network by minimizing update traffic and routing table size.
You can do this by configuring a summary route of 0. You should see the default routes and the connected routes, but the more specific routes from the edge router should have been filtered. Solution: The following shows sample output on the P1R3 router.
The ping is successful: P1R3 ping Solution: The following shows how to perform the required step on the P1R1 router: P1R1 copy run start Destination filename [startup-config]? Building configuration By default only K1 and K3 are enabled. Set bandwidth to 64Kbps. Used to influence the metric Router config-if bandwidth 64 calculation.
0コメント