Quick Notes: EIGRP Unequal-Cost Load Balancing, Stub Routing, and Route Summarization (CCIE Official Cert Guide: Chapter 8)

From: CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1, 5th Edition

Router ID

A single 4-byte number representing a particular router instance.
Each address family instance has its own independent RID. The same RID can be used.
Originally, the primary use of the RID was to prevent routing loops in EIGRP environments using redistribution.
If an external route is received with the same RID as the local router, the route is discarded.
The RID was not originally advertised with internal routes.
In recent IOS releases, both internal and external routes carry the RID of the router that injected it into EIGRP.
A router will discard every received route carrying the router's own RID.
The rules of RID value selection:

Manual configuration by eigrp router-id.
The highest IP address among non-shutdown loopback interfaces.
The highest IP address among all other non-shutdown interfaces.

After chosen, the RID will not be reinitialized until the EIGRP process is removed, the RID manually configured or a manually configured RID is removed.
For manual configuration, the values 0.0.0.0 and 255.255.255.255 are disallowed.
If a router's RID changes, it drops and reestablishes its adjacencies.
When interface IP addresses of a running router are changed without restarting it, the EIGRP RID will remain unchanged.
This can cause issues when a new router is introduced into the network, retaking the other router's addresses and tasks, while the old router is renumbered without restarting it.
As a result, it is possible that these two routers have the same EIGRP RID and they will not learn routes injected into EIGRP by each other.
There is no logging message to point to this phenomenon.
Before only show ip eigrp topology and show ipv6 eigrp topology showed the RID.
Now show eigrp protocols and show ip protocols will also display the RID.

Unequal-Cost Load Balancing

Distributing traffic load across multiple unequal-cost paths.
The key element is the presence of Feasible Successors.
Feasible Successors provide a guaranteed loop-free path to the destination, although not necessarily the shortest one.
Enabled through the variance <multiplier> command.
The multiplier 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 multiplier V, the router checks whether a Feasible Successor meets the following condition:
CD via Successor < CD via Feasible Successor < V x CD via Successor
If the route passes the condition, it is installed into the routing table.
A multiplier of 1, the default, implies that no unequal-cost load balancing is performed.
If multiple unequal-cost paths are installed into the routing table, the router will forward proportionally less traffic over the worse paths, and vice versa.
The traffic flow over a particular path can be computed as this ratio: Highest Installed Path Metric / Path Metric.
For paths with metrics 1100, 1100, 2000, and 4000, the traffic amount over these paths would be 4000/1100 = 3, 4000/1100 = 3, 4000/2000 = 2, and 4000/4000 = 1.
The true traffic share ration would be 3:3:2:1 (recall that IOS routers perform integer division).
Routers that do not meet the Feasibility Condition, i.e. non-Feasible Successors, are not considered in unequal-cost load balancing.
The unequal-cost paths installed into the routing table also count toward the maximum number of parallel paths (maximum-paths).

Add-Path Support

Allows a hub router to advertise multiple equal-cost routes to the same destination.
The routes must first be installed in the hub's routing table.
Might require tuning the metrics and the maximum-paths value.
The hub router must have the Split Horizon feature deactivated.
Can be configured only in named mode, and is controlled on a per-interface basis using the add-paths <path-count> command.
The add-paths command allows advertising additional path-count equal-cost routes in addition to the route that would be advertised nonetheless.
The path-count is a mandatory argument in the range of 1 to 4.
In total, the spokes can learn about five different equal paths to a particular destination.
Spokes routers do not need to be specifically configured for the Add-Path feature, apart from possible tuning of the maximum-paths command to be able to insert multiple equal-cost paths into their routing tables.
The Variance and Add-Path features are not compatible with each other.
When using Add-Path, always be sure to set the variance to 1.

router eigrp CCIE
address-family ipv4 unicast autonomous-system 1
    topology base
      variance 1
      maximum-paths 6
      exit
    af-interface Tunnel0
      no split-horizon
      no next-hop-self
      add-paths 4

The no-ecmp-mode command deactivates EIGRP's internal optimization and forces EIGRP to always walk over all equal-cost paths to a destination recorded in the topology table, making sure that if any of these routes' Successors can be reached over the interface on which the route is going to be readvertised, the no next-hop-self command will be honored and the Successor's address will be retained in the advertisement.
The use of no-ecmp-mode is recommended with the Add-Path feature if the hub uses multiple tunnel interfaces to reach the spoke sites.

Stub Routing

Primarily designed to improve network scalability and stability.
Most commonly used in hub-and-spoke networks.
Only configured on spoke routers.
When configured on a spoke router, the router announces its stub router status using and additional TLV in its EIGRP Hello messages.
The results of a stub router 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 a so-called leak-map construct. The router cannot be considered as a Feasible Successor and cannot become a transit router.
A stub router advertises only a subset of its own EIGRP-enabled networks to its neighbors. Defined in the eigrp stub command with summary, connected, static, redistributed, and receive-only keywords.
Neighbors will never send a Query packet to a stub router. The neighbors cannot converge through a stub router to reach networks that are remote to the stub router.

How a stub router handles 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 is a network that the stub router is allowed to advertise (summary, connected, static, or redistributed), the route will process the Query normally. 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 as described earlier, but the Reply will always indicate infinite distance, regardless of what the stub router truly knows about the network.
Receiving a Query for an unknown network will immediately cause the router to respond with a Reply and an infinite distance; however, this is regular EIGRP behavior not related to the stub feature.

There are two primary reasons why a stub router might receive a Query: 1) The neighbor might run an old IOS that does not recognize the stub TLV, and 2) if there are multiple stub routers on a common segment and if any of these stub routers need to send a Query, it will also send it to all its stub neighbors.
On a common segment with all routers configured as stubs, Queries are sent as usual.
In multiaccess segments with mixed neighbors, EIGRP solves the problem of sending Queries only non-stub neighbors in two ways: 1) send the Queries as unicasts, or 2) use the Conditional Receive mode.
While mixing stub and non-stub routers on a common segment is not a recommended practice, it is inevitable, for example, when the hubs and spokes are interconnected by a DMVPN or a VPLS service.
Benefits of stub routing in hub-and-spoke networks:

Prevents suboptimal routing.
Prevents stub routers with low-speed links from being used as transit routers.
Significantly limits the number of Query packets and the depth of their propagation, allowing EIGRP to converge faster and avoid the SIA states.

receive-only: 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.
leak-map <name>: The stub router can advertise selected EIGRP-learned routes that would not be ordinarily advertised. The <name> references a route-map that matches one or more access-lists or prefix-lists that permit the matched subnets or addresses to be leaked.
connected: The stub router will advertise directly connected networks. The interfaces must still be added to EIGRP using the network command.
static: The stub router will advertised static routes. The static routes must be redistributed into EIGRP to be advertised.
summary: The stub router will advertise summary routes if configured on interfaces.

By default, when the eigrp stub command is enabled without additional keywords, both connected and summary are assumed.
Use show ip protocols and show ip eigrp neighbors details for information about stub routers.
Activating, deactivating, or modifying the stub feature settings will cause the router to drop and reestablish adjacencies with its neighbors.
The stub router feature has no impact on what the hub router will advertise. Therefore, the stub feature is usually combined with route filtering and summarization on the hub router. The hub router can be configured to advertise only a default route to the spoke router(s).

Route Summarization

Reduces the amount of routing information that routers must exchange, process, and maintain.
Faster convergence and less router load within the network.
Restricts the size of an area that is affected by network changes by hiding details behind a single advertised summary route.
Creates a boundary for Query propagation.
If a router receives a Query for a network it does not have in its topology table, it will immediately send back a Reply indicating an unreachable destination, without itself going active and propagating the Query further.
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 an infinite distance.
Two types of summarization: automatic summarization and manual summarization.
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.
Automatic summarization does not apply to external routes unless there is also an internal network that belongs to the same major network.
Automatic summarization is practically unusable in today's networks, and in fact, starting with IOS Release 15.0(1)M, it is deactivated by default.
Manual summarization allows summarizing routes at any chosen router and its interface in the network.
As opposed to RIP that does not allow supernetting in summarization, EIGRP poses no limitations on the summary address/netmask combination.
You can summarize even into a default route.
Configuring multiple overlapping summary address on an interface is also supported. EIGRP will advertise each configured summary address for which at least one component route exists.
Manual summarization is configured on a per-interface basis.
The optional leak-map allows more specific components of the summary route to be selectively advertised as unsummarized along with the summary route.
The router generating the summary route installs a so-called discard route for the 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.
For presently unknown destinations within an advertised summary, the discard route makes sure that the traffic is dropped rather than routed over a possibly unrelated route.
A discard route's AD is 5 by default.
For example, when summarizing into the default route, the router will attempt to install a discard route to 0.0.0.0/0 into its routing table. If there already is a default route with an AD higher than 5, the discard route will replace it.
In EIGRP named, the AD for a discard route can be changed only in the topology base section.
In recent IOS releases, setting the AD of a discard route to 255 not only prevents the router from installing the discard route into its routing table, but it also causes it to stop advertising the summary route altogether.
By default, EIGRP uses the lowest metric of a component route as the metric of the summary route itself.
EIGRP summary route must adapt to metric changes.
The summary-metric command can be used to define a static metric for a particular summary route.

! The 172.20.63.0/24 prefix is leaked unsummarized.
!
ip prefix-list LEAK-PREFIX permit 172.20.63.0/24
!
route-map EIGRP-LEAK permit 10
match ip address prefix-list LEAK-PREFIX
!
! The prefix is advertised unsummarized along with the summary route.
!
router eigrp CCIE
address-family ipv4 unicast autonomous-system 1
    af-interface FastEthernet0/0
      summary-address 172.20.32.0/19 leak-map EIGRP-LEAK
!
! The metric of the summary route is manually defined.
! The administrative distance of the summary route is set to 10.
!
router eigrp CCIE
address-family ipv4 unicast autonomous-system 1
    topology base
      summary-metric 172.20.32.0/19 1000000 1 255 1 1500 distance 10
      exit-af-topology

R2# do show ip protocols | section Summarization
Automatic Summarization: disabled
Address Summarization:
172.20.32.0/19 for Fa0/0
Summarizing 32 components with metric 1310720

R2#show ip route eigrp | i Null
D 172.20.32.0/19 is a summary, 00:31:34, Null0

R2#show eigrp address-family ipv4 topology 172.20.32.0/19
EIGRP-IPv4 VR(CCIE) Topology Entry for AS(1)/ID(10.255.255.2) for 172.20.32.0/19
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1310720, RIB is
10240
Descriptor Blocks:
0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0
Composite metric is (1310720/0), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 10000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
Originating router is 10.255.255.2

Passive Interfaces

When EIGRP is enabled for a network, the router begins to send out Hello packets and process incoming EIGRP packets on all interfaces that fall within the specified network range.
This default behavior is unnecessary, even dangerous for loopback interfaces and interfaces connected to end hosts.
A passive interface does not send or process EIGRP packets, but the network configured on the interface is still advertised.
Two options: 1) use passive-interface default and no passive-interface on selected interfaces or 2) passive-interface only on selected interfaces.

Graceful Shutdown

A long-implemented feature that cannot, in fact, be controlled - it is only used, mostly not even knowing it is there.
Allows a router to advertise that it is being deactivated, thereby allowing its neighbors to react immediately, rather than wait for the Hold timer to expire.
Accomplished by a Goodbye message = a normal Hello packet with all K values set to 255.
In classic mode for IPv6: shutdown command.
In classic mode for IPv4: the Goodbye message was usually sent when shutting down interfaces, configuring them as passive, removing related network or IPv6 EIGRP commands, or removing the entire EIGRP process or restarting the router.
In 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 address family mode, causing the entire address family instance to be deactivated.
In the af-interface section, causing the EIGRP to cease all operations on that interface.

Securing EIGRP with Authentication

MD5 hashing to ensure the integrity of EIGRP messages and to prevent the injection of false routing information has always been supported.
Since 15.1(2)S and 15.2(1)T, SHA-256 has been supported.
MD5 can be configured in both classic and named mode; SHA can only be configured in named mode.
Essentially, a two-part configuration:

Define a key chain to hold the key IDs, key strings, and optional time ranges.
Activate the authentication on selected interfaces.

The key ID and key string must match between two neighbors.
The key chain names are locally significant.
With SHA authentication, the password can be configured directly in the interface, without creating key chains.
Simpler but makes a seamless rollover to a new key impossible, as there can always be only a single per-interface key configured.
In classic mode, there is no way to configure EIGRP authentication for all interfaces at once; each EIGRP-enabled interface must be configured individually.
In named mode, the af-interface default settings apply automatically to all EIGRP-enabled interfaces; these can be overridden later on selected interfaces using the appropriate af-interfac section.

key chain EIGRP-KEYS
key 1
    key-string EIGRPRocks
!
router eigrp CCIE
address-family ipv4 autonomous-system 1
    af-interface default
      authentication mode md5
      authentication key-chain EIGRP-KEYS
    af-interface FastEthernet0/0
      authentication mode hmac-sha-256 PhonyPassword
    af-interface FastEthernet0/1
      authentication mode hmac-sha-256 BigPASSword
      no authentication key-chain
    af-interface Serial1/0
      no authentication mode

R1#show eigrp address-family ipv4 int detail fa0/0
! Lines omitted for brevity
Authentication mode is HMAC-SHA-256, key-chain is "EIGRP-KEYS"

R1#show eigrp address-family ipv4 int detail fa0/1
! Lines omitted for brevity
Authentication mode is HMAC-SHA-256, key-chain is not set

R1#show eigrp address-family ipv4 int detail s1/1
! Lines omitted for brevity
Authentication mode is md5, key-chain is "EIGRP-KEYS"

R1#show eigrp address-family ipv4 int detail s1/0
! Lines omitted for brevity
Authentication mode is not set

Each key can be time limited in its usability to sign sent packets (send-lifetime) and to authenticate received packets (accept-lifetime).
If multiple keys are eligible to sign egress packets, the key with the lowest key ID is 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.
A seamless key rollover procedure:

On all routers, add a new key with a higher key ID into the key chain.
Configure the old key on all routers with a send-lifetime that is already in the past. The routers will start using the new key. Neighbors will accept either key because the key ID is carried in the packet, and both old and new keys are still valid.
Remove the old key completely from the key chains, completing the migration.

Default Routing Using EIGRP.

No dedicated command to inject a default route.
Other techniques:

Redistributing the default route from another routing source into EIGRP.
Using manual summarization to summarize all advertised routes into a default route.

If a static route is pointing only to the egress interface, IOS treats it as being directly connected. As a result, the network command can be used to advertise such a directly connected static route. If a default route is pointing to an exit interface, it can be advertised in EIGRP with network 0.0.0.0.
Configuring network 0.0.0.0 is almost never a good idea:

It will cause all IPv4 interfaces on the router to be enabled for EIGRP. EIGRP will start advertising all directly connected IPv4 networks, and try to establish adjacencies on those interfaces.
If the default route is not a directly connected static route, the network 0.0.0.0 command has no effect, defeating the entire purpose of configure it to advertise a default route.

Split Horizon

A route must not be advertised over an interface used to reach it.
EIGRP uses Split Horizon with Poisoned Reverse, advertising each learned network out the interface towards its Successor with an infinite metric.
Sometimes necessary to deactivate, specifically for hub-and-spoke topologies.
If possible, better to advertise a default route from the hub to all spokes.
Deactivated on a per-interface basis.

EIGRP Over the ToP

aka OTP
Allows creating ovelay multipoint VPNs between customer edge routers running EIGRP without any special cooperation with the service provider.
The key: Locator/Identifier Separation Protocol, or LISP.
IP address consists of the network prefix and the host suffix, where the network ID identifies the location and the host ID identifies the host itself. If a host moves to a different network, its entire IP address changes.
LISP aims at decoupling the location of a host from its identity. LISP represents each of them as a complete address, and provides a mapping service so that the address representing the identity of a host can be resolved into the address that represents its location.
Tunneling is used to encapsulate packets to end hosts with the addresses representing the end host locations.
In LISP, a host has an Endpoint ID (EID) that identifies its identity that never needs to change.
This EID can be an IPv4/IPv6 address.
To reach the end hosts, the packets must be tunneled to the router behind which the host is currently located.
The outside address of the router effectively represents the location of the EID and is denoted as Routing Locator, or RLOC.
Many EIDs can be located behind a single RLOC.

LISP has both a control and a data plane.
LISP control plane: registration protocol and procedures to map EIDs into RLOCs.
LISP data plane: the actual tunnel encapsulation between routers.
In OTP, EIGRP serves as the replacement for LISP control plane.
EIGRP OTP routers create targeted sessions, use the public IP addresses as RLOCs, and exchange routes as EIDs.
R2 would learn R1's network 10.0.1.0/24 through EIGRP, treat the network as an EID prefix, and take the advertising next hop 192.0.2.31 as the RLOC for this EID prefix.
The LISP data plane is reused in OTP and does not change; however, the native LISP mapping and resolving mechanisms are replaced by EIGRP.
OTP is based on fully customer-controlled targeted EIGRP sessions.
Closely resembles Dynamic Multipoint VPN (DMVPN).
The key differences are:

DMVPN uses multipoint GRE tunnels, encapsulating both data and control plane traffic. As a result, certain priming in DMVPN is necessary for it to start (for example, creating the tunnel interfaces and manual mappings). In LISP, no tunnel interface configuration is required, and the only mandatory static configuration is specifying the remote static neighbor. Optionally, the entire OTP traffic can be protected using GETVPN.
DMVPN also depends on running the Next Hop Resolution Protocol (NHRP) to provide mappings between multipoint tunnel interfaces and real router addresses.

! Changing the LISP interface bandwidth from its default of 56 kbps.
!
interface LISP0
bandwidth 1000000
!
interface GigabitEthernet0/0
ip address 192.0.2.31 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.0.2.2
!
! The neighbor command refers to the remote neighbor reachable through GigabitEthernet0/0
! The lisp-encap command activates LISP-based OTP functionality.
! The network command is required to form static neighbors over the interface.
!
router eigrp CCIE
address-family ipv4 unicast autonomous-system 64512
    neighbor 198.51.100.62 GigabitEthernet0/0 remote 100 list-encap
    network 10.0.1.0 0.0.0.255
    network 192.0.2.31 0.0.0.0

Running OTP does not require a route toward the remote neighbor.
Because the neighbor command specifies the interface toward the remote neighbor, EIGRP in fact places its packets on the interface queue directly, bypassing the routing table.
For large implementations, OTP has a special router role, a so-called route reflector.
The route reflector 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.

R1#
router eigrp CCIE
!
address-family ipv4 unicast autonomous-system 64512
!
af-interface GigabitEthernet0/0
no next-hop-self
no split horizon
exit-af-interface
!
topology base
exit-af-topology
remote-neighbors source GigabitEthernet0/0 unicast-listen lisp-encap
network 10.0.1.1 0.0.0.0
network 192.0.2.31 0.0.0

EIGRP Logging and Reporting

The eigrp event-logging configuration is the default, and enables the router to store a log of EIGRP events.
Viewed by show eigrp address-family {ipv4 | ipv6} events.
By default, the EIGRP event log stores up to 500 lines of events.
The eigrp log-neighbor-changes and eigrp log-neighbor warnings are also enabled by default.

EIGRP Route Filtering

EIGRP updates can be filtered at any interface or for the entire EIGRP address family instance in either direction.
By the distribute-list command.
In classic mode, the command is applied directly in the EIGRP process.
In named mode, the command is configured under the topology base.
EIGRP allows ACLs, prefix-lists, and route-maps to be used for route filtering in the distribute-list command.
In general, the use of prefix-lists is recommended, as they are specifically designed to match ranges of networks and netmasks.
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. Receive Queries and SIA-Queries are not influenced by the distribute-list and are processed without modification.

EIGRP Offset-Lists

Allows EIGRP to add to a route's metric, either before sending an update or for routes received in an update.
Refers to an access-list to match the routes; any matched routes have the specified offset, or extra metric, added to their Delay metric component.
Any routes not matched by the offset-list are unchanged.
Also specify a in or out direction and optionally an interface.
If the interface is omitted, all updates for the chosen direction will be examined.

Clearing the IP Routing Table

clear ip route *
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 clears all neighbor relationships and has the router establish them from scratch.
A soft keyword allows for a graceful restart, the databases are resynchronized but the adjacencies are not torn down.

Network Playroom

Search This Blog