skip to content

An EIGRP router peers with any router that sends a valid hello; how do you stop a rogue device on a user LAN from becoming a neighbour?

level: seniorimportance: nice to knowfreq 12%

answer

  1. promiscuous by design
  2. what one captured hello reveals
  3. hashes carried in a TLV
  4. no hellos where no routers live

basics

~20 s

Stop sending and accepting EIGRP hellos on interfaces that face only hosts, and authenticate every adjacency that must exist, preferably with SHA2-256. The AS number and K-values are no defence: every hello carries them in clear text.

solid answer

~40 s

RFC 7868's security section calls EIGRP **promiscuous**: it neighbours with any router that sends a valid hello, and the AS number is only "indirectly" an authentication value, since anyone on the segment can read it, and the K-values, from one hello. So remove the opportunity first: on host-facing LANs, use the implementation option that stops hellos on the interface while still advertising its subnet. Where routers must peer, **authenticate**: RFC 7868 defines MD5 and SHA2-256 in an Authentication TLV and has receivers discard packets that fail it. Prefer SHA2-256, plan key rotation, rate-limit routing packets to the control plane as the RFC suggests, and filter the prefixes each neighbour may advertise. Authentication proves the sender holds the key; it does not hide the routes.

go deeper

for a junior

Know that EIGRP forms neighbours automatically from hellos, and that authentication with MD5 or SHA2-256 is the protocol's own defence.

for a middle

Explain why the AS number and K-values are not secrets, and how stopping hellos on host-facing interfaces removes the risk there without any keys.

for a senior

Combine the controls: no hellos where no router belongs, SHA2-256 on every real adjacency, per-neighbour prefix filtering, control-plane rate limiting, and key rotation that does not drop adjacencies.

for a principal

Weigh the operational cost of keys across many routers against the exposure, and decide where routing-protocol trust ends and segmentation or monitoring has to take over.

## Why EIGRP is open by default EIGRP discovery is automatic. A router multicasts hellos to **224.0.0.10** on every interface where EIGRP runs, and any router that hears one, and finds that the **AS number**, the **K-values** and any configured **authentication** agree, accepts the sender as a neighbour. RFC 7868's security considerations say it plainly: being promiscuous, EIGRP will neighbour with any router that sends a valid hello, and that open stance needs policy to limit peering to valid routers. On a user LAN, "any router" includes a laptop running routing software or a cheap device someone plugged in. Once it is a neighbour, it can: - **advertise more-specific prefixes** and attract traffic meant for servers or the internet edge; - **advertise a default route** and pull the site's outbound traffic towards itself; - **churn routes** repeatedly, forcing recomputation across the routing domain; - **flood the control plane** with packets the router has to process. ## Things that look like protection but are not | Supposed control | Why it fails | |---|---| | A non-default AS number | It is a 16-bit field in every EIGRP header, readable from one captured hello | | Unusual K-values | They travel in clear text in each hello's Parameters TLV | | Non-default hello or hold timers | EIGRP neighbours do not need matching timers, so nothing is checked | | The multicast group | 224.0.0.10 is fixed and registered for every EIGRP router | RFC 7868 does describe the AS number as "indirectly used as an authentication value", but only in the sense that a mismatch makes packets be ignored. Anyone who can read a hello can match it. ## Controls that work 1. **No hellos where no router belongs.** Most implementations offer an option to stop sending and processing hellos on an interface while still advertising that interface's subnet. On a LAN of hosts this removes the risk entirely and needs no keys. 2. **Authenticate every real adjacency.** RFC 7868's **Authentication TLV** carries a hash: type `0x02` for **MD5** and type `0x03` for **SHA2-256**. A receiver discards packets whose authentication does not match. Prefer SHA2-256; the IETF moved other routing protocols away from keyed MD5 because of published attacks on MD5 (RFC 4822 for RIPv2, RFC 5709 for OSPFv2). 3. **Rate-limit the control plane.** RFC 7868 says denial-of-service protection depends on implementations rate-limiting packets to the control plane, so a flood of hellos cannot starve the routing process. 4. **Filter what each neighbour may advertise.** Inbound prefix filters, an implementation feature, limit the damage from a neighbour that is authenticated but misconfigured or compromised. 5. **Rotate keys without outages.** Implementations commonly let a router hold several keys with overlapping validity periods; RFC 7868 also allows more than one authentication type in a single TLV, which helps when moving from MD5 to SHA2-256. ## What authentication does not do - **It does not encrypt.** Routes, the AS number and the K-values remain readable by anyone on the segment. - **It protects only where it is configured.** A forgotten interface with EIGRP enabled and no authentication is still open. - **It moves the risk to the key.** Whoever holds the shared key can peer; keys need the same care as any other credential. - **It can cause outages of its own.** A key mismatch during rotation discards packets and drops the adjacency, exactly as in any other authentication mismatch. ## Where answers go wrong - **Treating discovery parameters as secrets.** The AS number, the K-values and the timers exist so that legitimate routers agree; none of them was designed to keep anyone out, and all of them are visible on the wire. - **Securing only the core.** The exposed interfaces are usually the access LANs, where hosts and visitors sit next to the router. - **Calling authentication encryption.** A hash proves who sent a packet; it does not hide what the packet says. - **Forgetting the operational side.** Keys need an owner, an expiry plan and a rotation procedure, or the first rotation becomes an outage. ## A practical baseline - Run hellos only on interfaces that face other routers. - Authenticate those adjacencies with SHA2-256. - Rate-limit control-plane traffic and filter inbound prefixes per neighbour. - Audit periodically for interfaces where EIGRP runs without authentication.

  • Does EIGRP authentication encrypt the routing information?
    No. RFC 7868's Authentication TLV carries an MD5 or SHA2-256 hash that lets the receiver check that the sender holds the shared key. Routes, the AS number and the K-values still travel in clear text, so anyone on the segment can read them; confidentiality needs a separate mechanism, such as an encrypted tunnel between the routers.
  • How do you change an EIGRP authentication key without dropping the adjacency?
    A mismatch makes the receiver discard packets, so a hard cut-over drops the neighbour until both ends change. Implementations commonly let a router hold several keys with overlapping validity periods, so both sides can move in stages; RFC 7868 also allows more than one authentication type in one TLV, which helps when migrating from MD5 to SHA2-256.

saying these in an interview costs you the question

  • A non-default EIGRP AS number keeps unknown routers from peering.
  • Custom K-values work as a shared secret between legitimate EIGRP routers.
  • EIGRP authentication encrypts the routes so attackers cannot read them.
  • Authenticating the core links is enough; access LANs need nothing.
  • MD5 and SHA2-256 are equally strong choices for EIGRP authentication.