Address Family (AF) section: Created using the address-family command, this is a mandatory section directly inside router eigrp name configuration that specifies the particular address family for which an EIGRP instance shall be started.
Per-AF-interface section: Optional. It holds EIGRP settings pertaining to the specified interface and AF. One per-AF-interface section can be created for each routed interface or subinterface.
Per-AF-topology section: This is a section present inside a particular AF, related to the support of Multi Topology Routing (MTR) in EIGRP.
Multiple-name EIGRP processes can be started on a single router as long as their names are unique. The process name is not sent in EIGRP messages; it is a locally significant value and is never compared to process names on other routers.
Each named EIGRP process can hold only a single instance for an address family. It cannot have 2 IPv4 address family in the same process. 1 IPv4 and 1 IPv6 is ok. Also, two or more distinct named EIGRP processes cannot run the same address family instance with the same AS number.
In the classic mode configuration of IPv6 EIGRP, an IPv6 EIGRP process was shut down by default after configuring it, and a no shutdown command was necessary to actually start it. In the named configuration mode, as soon as you configure an IPv6 address family, it automatically adopts all interfaces on which IPv6 has been enabled (even a link-local address is sufficient) and starts running on them.
Note the difference between deactivating an EIGRP address family instance on an interface using the shutdown command and declaring an interface as passive using the passive-interface command (both used in an af-interface section): No EIGRP adjacencies will be formed over a passive interface, but its global prefixes will still be advertised over other interfaces. Deactivating an EIGRP address family instance makes the EIGRP completely ignore the interface, not forming any adjacencies over it and also not advertising any of its prefixes.
Address Family Section: This section is where any configurations specific to the EIGRP process itself are applied. Commonly used commands include network and neighbor statements.
Per-AF-Interface Configuration Section: This configuration section is where all EIGRP interface-specific commands are applied. Except non-EIGRP-specific commands such as bandwidth and delay, every other EIGRP-related command can now be configured in this section.
Per-AF-Topology Configuration Section: This configuration mode relates to the support of multiple routing topologies in EIGRP. Multiple topologies can be used to segregate different classes of traffic, such as data, voice, and video, and carry them over different links in the same physical network, or to keep separate and independent topologies for IPv4 and IPv6 routing.
Together with the named mode, related show commands have also been updated. Instead of show ip eigrp, the new show eigrp address-family ipv4; instead of show ipv6 eigrp, show eigrp address-family ipv6 .
Additional and Advanced EIGRP Features
Router ID
As with many protocols, EIGRP also uses a concept of a Router ID(RID), a single 4-byte number representing a particular router instance. The primary use of the EIGRP RID has been to reduce the possibility of routing loops in networks where route redistribution is being performed on more than one router. A router will discard every received route carrying the router’s own RID.
The rules of RID value selection are the same as with OSPF. First, the eigrp router-id command in EIGRP configuration is preferred. If not configured, the highest IP address among nonshutdown loopback interfaces is chosen. If not, the highest IP address among all other nonshutdown interfaces. If a router’s RID changes, it drops and reestablishes its adjacencies; a brief connectivity outage might therefore ensue.
When you are changing interface addresses of a running router without restarting it, the EIGRP RID will remain unchanged. This can cause unpleasant issues when a new router is introduced into the network, retaking other routers’ addresses and tasks, while the old router is renumbered without restarting it. They will not learn route injected by each other becuase of the same RID. show eigrp address-family ipv4 events can be used to view such event.
Router ID can be viewed via show ip eigrp topology, show ipv6 eigrp topology, show eigrp protocols and show ip protocols commands.
Unequal-Cost Load Balancing
Unlike most internal routing protocols, EIGRP has a feature that allows you to distribute the load of your traffic across multiple unequal-cost paths and not just over paths providing the least distance to a destination. The key to unequal-cost load balancing is the presence of Feasible Successors.
Unequal-cost load balancing is enabled through the variance multiplier command which essentially defines how many times worse than the best path a route through a Feasible Successor can be to be still used by EIGRP for unequal-cost load balancing. A multiplier of 1, which is the default, implies that no unequal-cost load balancing is being performed.The current variance valued is viewed va show ip protocols command. If multiple unequal-cost paths to a destination are installed into the routing table, the router will forward proportionally less traffic over the worse paths, and vice versa.
The key to performing unequal-cost load balancing is first to have Feasible Successors toward a destination. Routers that do not meet the Feasibility Condition and thus are not considered Feasible Successors are not considered in the unequal-cost load balancing.
Add-Path Support
Starting with IOS Release 15.3(2)T, EIGRP was extended with a so-called Add-Path support, allowing a hub to advertise multiple equal-cost routes to the same destination. The prerequisite is to first have them installed in its routing table. This might require tuning the metrics and the maximum-paths command value first. Also, the hub router must have the Split Horizon deactivated on the multipoint tunnel interface toward individual spokes.
The Add-Path feature can be configured only in the named mode, and is controlled on a per-interface basis.
Spoke routers do not need to be specifically configured for the Add-Path feature, apart from possible tuning of the maximum-paths command to be allowed to insert multiple equal-cost paths into their routing tables. The Variance (Unequal Cost Load Balancing) and Add-Path features are not compatible with each other.
Stub Routing
The stub routing feature is most commonly used in hub-and-spoke networks and is configured only on spoke routers. The results of configuring a router as a stub are multifold:
-A stub router does not propagate routes learned through EIGRP to its neighbors, with the exception of EIGRP-learned routes that are explicitly selected using leak-map construct. This prevents a stub router from ever being considered a Feasible Successor for remote networks by its neighbors.
-A stub router advertises only a subset of its own EIGRP-enabled networks to its neighbors.
-Neighbors of a stub router aware of its stub status (thanks to the specific TLV in the stub router’s Hello packets) will never send a Query packet to a stub router.
The following rules summarize the stub router behavior with respect to handling Query packets:
-Originating Query packets is not modified in any way. Rules for entering the Active state and sending Queries are precisely the same.
-Processing received Query packets depends on what network was queried for. If the network in the received Query is a network the stub router is allowed to advertise, meaning that it falls under the configured category of summary , connected, static, or redistributed, the router will process the Query normally (even possibly causing the stub router to become Active itself) and send back an appropriate Reply. The same is valid for an EIGRP-learned network that is allowed to be further advertised using a leak-map. If the Query contains a network that the stub router knows about but is not allowed to advertise, it will be processed in the usual way but the Reply will always indicate infinite distance, regardless of what the stub router truly knows about the network.
There are two primary reasons why even a stub router might receive a Query. First, a stub router’s neighbor might be running an old IOS that does not recognize the stub TLV yet. Second, if there are multiple routers on a common segment and all of them are configured as stub routers, if any of these stub routers need to send a Query, it will also send it to all its stub neighbors.
In case of multiaccess segments with mixed neighbors (stub and nonstub), EIGRP solves the problem of sending Queries only to nonstub neighbors in two ways: Either it sends the Queries as unicasts to the nonstub neighbors or it uses the Conditional Receive mode in RTP to send multicast Queries. Although mixing stud/nonstub router on a common subnet is not a recommended practice, it is used in cases where the hubs and spokes are interconnected by a DMVPN or a VPLS service.
The EIGRP stub routing feature provides important advantages when implemented in hub-and-spoke networks:
-It prevents suboptimal routing from occurring within hub-and-spoke networks.
-It prevents stub routers with low-speed links from being used as transit routers.
-It significantly limits the number of Query packets and the depth of their propagation, allowing the EIGRP network to convergence faster and avoid the SIA states.
In named mode, the eigrp stub command is used in the particular address family section.
When using receive-only keyword, the stub router does not advertise any prefixes. It only receives prefixes advertised to it by its neighbors. This keyword cannot be used with any other keywords when configuring stub routing.
The leak-map name keyword configures the stub router to advertise selected EIGRP-learned routes that would not be ordinarily advertised. The name references a route-map. The leak-map is crucial in scenarios where a branch office uses a pair of interconnected routers configured as stub routers. If these routers are to provide backup connectivity to each other, they must be allowed to readvertise EIGRP-learned routes to each other, even in stub mode.
The connected keyword configures the stub router to advertise connected subnets. Note that the directly connected interfaces will not be advertised automatically; it is still necessary to add them to EIGRP using the usual network command.
The static keyword configures the stub router to advertise static routes. The static routes need to be redistributed into EIGRP to be advertised.
The summary keyword configures the stub router to advertise summary routes if configured on interfaces.
By default, when eigrp stub is enabled without additional keywords, both connected and summary are assumed. In a hub-and-spoke network, the hub router can be configured to advertise only the default route to the spoke router(s), filtering out all other more specific route entries, effectively reducing the routing table on the spoke to a single EIGRP-learned default route entry.
Use show ip protocols - to check current router stub setting. show ip eigrp neighbors detail - to check neighbor's stub settings.
Route Summarization
Route summarization reduces the amount of routing information that routers must exchange, process, and maintain, which allows for faster convergence and less router load within the network. With particular respect to EIGRP, summarization is also a powerful tool to create a boundary for Query propagation.
Neighbors of a router performing route summarization do not know the individual component routes. Queries originated inside the summarized part of network, including those for component routes, will be propagated according to the usual rules; a router performing route summarization does not modify the Query contents nor influence its flooding scope. However, when a Query asking for a particular component route is forwarded to the summarizing router’s neighbor, this neighbor has no knowledge of the component, so it immediately responds with a Reply containing infinite distance. As a result, summarization causes the propagation of Queries to be bounded by directly connected neighbors of routers that perform route summarization.
EIGRP supports automatic and manual route summarization. In automatic summarization, a subnet of a particular major network is advertised as the major network itself if the subnet is to be advertised out an interface that lies in a different major network. In EIGRP, automatic summarization does not apply to external routes unless there is also an internal network that belongs to the same major network as the external routes. The no auto-summary command should be used in the EIGRP configuration to deactivate it.
Manual summarization allows summarizing routes at any chosen router and its interface in the network. EIGRP poses no limitations on the particular manual summary address/netmask combination. If it suits you, you can summarize even into a default route. Furthermore, configuring multiple overlapping summary addresses on an interface is also supported. Manual summarization is configured on a per-interface basis using the ip summary-address eigrp autonomous-system address netmask [distance] [leak-map name] command in classic config mode. In named mode in the corresponding af-interface section, use the summary-address address netmask [leak-map name] command.
Whenever a summary route is advertised, the router performing the summarization automatically installs a so-called discard route for this summary route into its routing table. The network and netmask in this discard route are identical to the network and netmask of the advertised summary, and the outgoing interface is set to Null0. The discard route prevents suboptimal routing or routing loops in situations when a router advertises a summary route but has no knowledge of a more specific matching subnet for incoming traffic. A discard route’s administrative distance is 5 by default. To raise the discard route’s administrative distance, use the admin-distance optional argument in the ip summary-address eigrp per-interface command and use the summary-metric address netmask distance admin-distance command in topology base section of named mode.
Be careful about setting the discard route’s administrative distance to 255. In earlier IOS releases, this prevented the discard route from being installed into the routing table, but the summary address was nonetheless advertised.
By default, when an EIGRP router originates a summary route, it looks up the lowest metric from among all known component routes that are covered by this summary, and uses this metric as the metric of the summary route itself. The summary-metric command in topology base section can be used to set a static metric.
Using a leak-map leak-map optional keyword allows the prefixes permitted by the route-map(EIGRPLeak) to be advertised unsummarized along with the summary route.
R2(config-router-af-interface)# summary-address 172.20.32.0/19 leak-map EIGRPLeak
The show ip protocols command will list all configured summaries and interfaces they are placed on, including the advertised computed metric. In show ip route the corresponding discard route will be shown if the summary is being advertised,
Passive Interfaces
Can enabled on logical interfaces such as loopback interfaces and on interfaces connected to networks with end hosts.
A passive interface does not send or process received EIGRP packets, but the network configured on the interface is still advertised. In the classic configuration mode, the passive-interface command accepts an interface name or the default keyword, causing all interfaces to be considered passive; in that case, the no passive-interface command can subsequently be used to make selected interfaces active again.
Graceful Shutdown
The Graceful Shutdown allows a router to advertise that it is being deactivated, either on an interface, for a particular address family, or as the entire process, thereby allowing its neighbors to react immediately, rather than wait for the Hold timer to expire.
Classic config mode allows only IPv6 EIGRP to use the shutdown command. IPv4 EIGRP has no direct shutdown command. In the classic mode, the Goodbye message was usually sent when shutting down interfaces, configuring them as passive, removing the related network or ipv6 eigrp
commands, or removing the entire EIGRP process or restarting the router. In the named mode, the shutdown command can be used in various places:
-Directly in the router eigrp mode, causing all configured address family instances under that process name to be deactivated
-In the particular address family mode, causing the entire particular address family instance to be deactivated
-In the particular af-interface section in the address family mode
Securing EIGRP with Authentication
Since its inception, EIGRP supports Message Digest 5(MD5) hashing to ensure the integrity of EIGRP messages and to prevent the injection of false routing information into the EIGRP domain. In addition, starting with IOS Releases 15.1(2)S and 15.2(1)T, EIGRP authentication support has been extended with the second-generation Secure Hash Algorithm, also known as SHA-2.
MD5 authentication can be configured both in classic and named mode; SHA authentication can only be configured in the named mode.
As with all key chain–based authentication schemes, for the authentication between two neighbors to succeed, they must match on the key ID and key string used to authenticate exchanged packets.
In the classic mode, ip authentication mode eigrp and ip authentication key-chain eigrp interface commands to activate MD5 authentication. There is no way to configure EIGRP authentication for all interfaces at once. In named mode, confgiure in af-interface section using the authentication mode and authentication key-chain commands.
If multiple keys in the key chain are eligible to sign egress packets, the key with the lowest key ID will be used. To authenticate received packets, EIGRP will try to use the key indicated by its ID in the received packet if the key is still valid.
Default Routing Using EIGRP
EIGRP has no dedicated command to inject a default route into an EIGRP domain. Well-known techniques to advertise default route are
-Redistributing the default route from other routing source into EIGRP,
-Using manual summarization to summarize all advertised routes into a default route. Often used in hub-and-spoke scenarios, this requires a suitable topology.
Configuring network 0.0.0.0 is almost never a good idea. Take note that if the default route on the router is not configured specifically as a directly connected static route, the network 0.0.0.0 command has no effect on it and will not cause it to be advertised.
Split Horizon
A route must not be advertised over an interface used to reach it. This prevents the “re-advertising” of routing information back to the next hop from which it is learned in the first place.
While Split Horizon with Poisoned Reverse is a powerful loop-prevention mechanism, it is sometimes necessary to deactivate it. This is particularly important in hub-and-spoke networks, where multiple spoke routers are reachable over a single interface on a hub using (Frame Relay or ATM multipoint interfaces, multipoint GRE tunnels in DMVPN deployments). If the topology and requirements permit it, the most scalable solution to this issue is to advertise a default route to all spokes.
EIGRP can be configured to deactivate the Split Horizon with Poisoned Reverse on a per-interface basis.
EIGRP Over the ToP
Over the ToP, or OTP. This feature allows creating overlay multipoint VPNs between customer edge routers running EIGRP without any special cooperation with the service provider that operates the network interconnecting the edge routers. The key to the OTP functionality is the Locator/Identifier Separation Protocol, or LISP.
The Locator/Identifier Separation Protocol (LISP) aims at decoupling the location of a host from its identity, allowing the host to retain its identity regardless of its location in a network. The general idea in LISP is to separate the identity and location into two independent entities, each of them represented by a complete address, and provide a mapping service.
In LISP, a host has an Endpoint ID, or EID, that identifies its identity that never needs to change. This EID can be an IPv4 address, an IPv6 address, or any other address format as needed. The outside address of the router effectively represents the location of the EID and is denoted as Routing Locator, or RLOC.
In OTP, EIGRP serves as the replacement for LISP control plane protocols. Instead of doing dynamic EID-to-RLOC mappings in native LISP-mapping services, EIGRP routers running OTP over a service provider cloud create targeted sessions, use the IP addresses provided by the service provider as RLOCs, and exchange routes as EIDs.
With just a few OTP routers, configuring a full mesh of static neighbors is relatively easy. However, if the OTP network grows, this would not be a scalable approach. Therefore, OTP also introduces a special router role, a so-called route reflector that allows collapsing the full mesh of OTP neighbors to a hub-and-spoke model of neighbor configuration, with the route reflector collecting learned networks from its clients and readvertising them back to individual clients, optionally maintaining the original next-hop value.
EIGRP Logging and Reporting
The eigrp event-logging enables the router to store a log of EIGRP events. The contents of the EIGRP log can be viewed by issuing the show eigrp address-family {ipv4 | ipv6} events command. By default, the EIGRP event log stores up to 500 lines of events.
The eigrp log-neighbor-changes router configuration command allows the router to log EIGRP neighbor relationship changes. This command is enabled by default.
EIGRP Route Filtering
Outbound and inbound EIGRP updates can be filtered at any interface, or for the entire EIGRP address family instance, in either direction. EIGRP allows ACLs, prefix lists, and route-maps to be used for route filtering in a distribute-list command.
-ACLs: distribute-list acl-number | acl-name {in | out} [interface]
-Prefix lists: distribute-list prefix prefix-list-name {in | out} [interface]
-Route maps: distribute-list route-map route-map-name {in | out} [interface]
Prefix lists is recommended. Distribute lists do not directly limit the propagation of Queries. Instead, what they do is more involved:
-For distribute lists in the out direction: All outgoing Updates, Queries, Replies, SIA-Queries, and SIA-Replies will indicate the correct metric for permitted prefixes and infinite metric for denied prefixes.
-For distribute lists in the in direction: In all incoming Updates, Replies, and SIA-Replies, permitted prefixes are processed normally while denied prefixes are ignored. Received Queries and SIA-Queries are not influenced by the distribute list and are processed without modification.
EIGRP Offset Lists
EIGRP offset lists allow EIGRP to add to a route’s metric, either before sending an update or for routes received in an update. The offset list also specifies which routing updates to examine by specifying a direction(in or out) and, optionally, an interface. If the interface is omitted from the command, all updates for the defined direction will be examined.
Clearing the IP Routing Table
Because EIGRP keeps all possible routes in its topology table, a clear ip route * command does NOT cause EIGRP to send any messages or learn any new topology information; the router simply refills the IP routing table with the best routes from the existing topology table. The clear eigrp address-family {ipv4 | ipv6} neighbors command can be used to clear all neighbor relationships and have the router reestablish them from scratch. An optional soft keyword allows for a graceful restart, in which the topology databases between the router and its neighbors are resynchronized but the adjacencies are not torn down.
No comments:
Post a Comment