Pages

Wednesday 5 May 2021

Cisco: Optimising EIGRP

 The two main EIGRP optimization techniques are route summarization and stub routing.

Stub configurations limit query scope. Support for Unequal Cost Load Balancing also provides optimization.

EIGRP Queries

When a router loses a route and doesn’t have a feasible successor in its topology table, it searches for an alternative path to the destination. This condition is known as going active on a route. Queries are send when a route is lost and no feasible successor is available. Queries are sent to all neighboring routers on all enabled interfaces except the interface of the successor. If neighbors have the lost route information, the stop the query from spreading otherwise queries are further propagated.

Active routes can be viewed in the topology command #show ip eigrp topology

Query exchange can be optimized using EIGRP stub routing and route summarization.

EIGRP Stub Routers

One way to reduce the number of EIGRP queries and improve network scaling is to mark the spokes of a large network as stubs. EIGRP stub routing;

  • improves networking stability

  • reduces resource utilisation

  • simplifies remote router configuration

EIGRP Stub options enable you to precisely specify which routes the EIGRP stub should advertise;

  • Connected: advertises connected routes that are included with a network command.

  • Summary: advertises configured summary routes

  • Static: advertises static routes if redistribute static command is configured.

  • Redistribute: advertises redistributed routes if redistribution is configured.

  • Receive-only: prevents the stub from sending any type of route.

Stub configuration defaults are connected and summary. You can combine all stub options except for receive-only to achieve the desired result. Receive-only option can be used in only two scenarios;

  • when the router has a single interface

  • if NAT with PAT is configured so that all hosts are hidden behind a single WAN interface.

Configuration

Classic mode

#router eigrp 10

#eigrp stub


To verify stub status on a neighboring router;

#show ip eigrp neighbor detail

EIGRP Stuck in Active

Failure to receive a response to a query message can lead a session termination. A router must receive replies to all queries sent and before a new path is calculated. If any reply is lost or missing;

  • the route enteres Stuck-in-active state

  • neighbor status is verified; if no response is received, the neighbor relationship is reset.

SIA messages are level 3 messages.

When no reply to a query is received, EIGRP sends an SIA query when the active timer is halfway through (90 seconds). This enables the neighboring router to respond with an SIA-Reply and confirm to the upstream router that is still searching for a replacement route.

EIGRP Summary Routes

Summarization limits query scope and improves convergence. If a router receives an EIGRP query for a prefix which is described in the routing table by a summary route, it immediately responds with a reply. Summarization is implemented on the interface in classic mode. In named mode, it is implemented in the address-family interface mode. The summary masks can be in dotted decimal format or prefix notation.

CAUTION: if a more specific route is in the RIB, it is always preferred regardless of the metric. For alternate paths, ensure that the summary address is configured on all the interfaces otherwise, the more specific routes will only be suppressed on the interface on which the summary address is configured.

A null route is automatically created in the RIB after configuring a summary route. The lowest metric of any of the routes within the summary route is used as the metric for the summary route.

Default Route

To redistribute a default route in EIGRP;

  • redistribute a static default router. To inject a default route and not every static route;

    Step 1: create an ACL to identify the default route #permit 0.0.0.0 0.0.0.0
    Step 2: define a route-map and reference the ACL from Step 1. #match ip addresss ACL_DEFAULT

    Step 3: Redistribute the static route; in named mode # topology base #redistribute static route-map RM_DEFAULT.

    The redistributed default route will have an AD of 170 with a code D EX. Usually, when redistributing into EIGRP, a seed metric must be specified. This is because EIGRP needs to know all the metric components of a route i.e. bandwidth, delay, reliability, load, MTU, hop count. In the case of static and connected routes, EIGRP takes these values from the outgoing interface associated with the route.

  • default network command.

When configuring summarization, ensure that the routes exist in the routing table.

EIGRP Load Balancing

EIGRP can distribute traffic over multiple links leading to the same destination to increase the effective network bandwidth. It supports load-balancing over equal metric and unequal-metric paths. Load balancing refers to the distribution of traffic over multiple paths. ECMP is enabled by default across four paths.

Note: Hardware-implemented load-balancing and IP CEF load-balancing may override EIGRP implemented load-balancing.

When network traffic is process switched (by CPU), load-balancing over ECMP occurs on a per packet basis. If fast-switching is being implemented, (data-plane), load-balancing over ECMP occurs on a per destination basis. This behaviour due to CEF characteristics. One some platforms, CEF, allows for configuration on a per packet or per destination load-balancing. Both are enabled by default. To enable Unequal cost load-balancing, use the EIGRP topology base command #variance <1 – 128>. it is disabled by default (one) ECMP.

Variance causes the router to include routes with a metric in a specific range.

Note: variance is applied only after the feasibility condition check is completed;

  • Only paths that pass the feasibility condition have the variance multiplier applied to their metric

  • to add a feasible successor to the RIB, the metric of the path must be less than the FD of the successor X the variance multiplier.

EIGRP Authentication

EIGRP authentication uses preshared-keys and is configured in interface configuration mode. MD5 is supported by classic and named mode. HMAC-SHA 256 is supported only by named mode. To configure EIGRP classic mode authentication;

Step 1: configure the key chain;

#key chain R1CHAIN

#key 1

#key-string firstkey

Step 2: Configure the authentication mode for EIGRP;

#interface ethernet 0/0

#ip authentication mode eigrp 110 md5

Step 3: Enable authentication to use the key chain.

#ip authentication key-chain eigrp 110 R1CHAIN


The key ID and keys string need to match on all EIGRP peers. In named configuration mode;

#af-interface ethernet 0/0

#authentication key-chain R1CHAIN

#authentication mode md5


In named mode, to configure SHA hashing, use the interface command;

# authentication mode hmac-sha-256 password

Dual stack load-balancing can be enabled with load-balancing supported on both IP or IPv6 or enabled on one and disabled on the other.

Load Balancing

If similar load-balancing configuration is not implemented in EIGRP peers, local routing may implement load-balancing across more links but return traffic utilises a single link resulting in asynchronous routing. Some security mechanisms may e.g. uRPF may block such traffic. Ensure same variance multiplier is used in remote router as well as maximum-path command.

In IPv6 load-balancing, the #show ipv6 route will display only the metric of the best route. To view other unequal routes, view EIGRP topology table.

Authentication

Key ID and key string must match. Verify with #show key chain.

Authentication type (MD5 or SHA256), key ID, key sequence and Digest (of Key ID and key string) is sent in the packet header under authentication (type) section.

To confirm that authentication is running on an interface;

#show ip eigrp interface detail

If configuring keyrings with accept and send lifetimes ensure that;

  • The clocks of the routers are synchronized with an NTP server or are similar timestamps

  • Provide for some overlap in times of key change so that during the changing of authentication using one key, the second key becomes active by several minutes before the first key becomes invalid.

If two keys are valid at the sametime (overlap in accept/send timestamps), the first valid key in the list will be used e.g. key ID 1 is used instead of key ID 2. The default starttime and earliest acceptable date is 1st January, 1993.

Verification, in named mode, of authentication is #show eigrp address-family ipv6 interfaces detail ethernet1/2.

For hmac-sha-256, there’s no need for a key chain.





No comments: