Two EIGRP routers on the same link can ping each other but never become neighbours; what do you check, and why?
answer
- ping is not the same traffic
- a protocol number and a multicast group
- header field, metric weights, keys
- timers are deliberately absent
basics
~20 sFirst check that hellos cross the link: EIGRP enabled, IP protocol 88 and 224.0.0.10 not filtered. Then the three things RFC 7868 makes neighbours agree on: the AS number, the K-values and authentication. Hello and hold timers need not match.
solid answer
~40 sA ping proves unicast ICMP, not EIGRP. First confirm that each router sends hellos on that interface and that nothing between them drops IP protocol `88` or multicast to `224.0.0.10`. Then walk the adjacency checklist: the **AS number** in the packet header must be identical, or the packet is ignored; the **K-values** in the hello's Parameters TLV must be identical; and **authentication** must agree in type and key, because RFC 7868 discards packets whose authentication does not match. On IPv4, implementations commonly also require the sender to be on the receiving interface's subnet, an implementation check, since RFC 7868 says IPv6 neighbours need no common prefix. Timers are not on the list. A neighbour that appears and keeps resetting points instead at one-way unicast.
go deeper
Recall the three things that must match between EIGRP neighbours: the AS number, the K-values and authentication. Know that hello and hold timers are not among them.
Explain where each checked value travels (header AS number, hello Parameters TLV, Authentication TLV) and what the receiver does on a mismatch. Separate hellos not arriving from hellos being rejected.
Show a troubleshooting order: prove hellos cross the link before comparing parameters, recognise a one-way unicast fault in a neighbour that keeps resetting, and name the IPv4 subnet check as implementation behaviour.
Talk about prevention: standard interface templates, consistent K-values and keys across the domain, and change processes that keep a key rotation from taking adjacencies down.
## The symptom and what a ping proves Two routers share a link, each can ping the other, and EIGRP never lists the other as a neighbour. A successful ping proves only that **unicast ICMP** works in both directions. EIGRP discovery depends on different traffic: **hello** packets carried directly in IP as **protocol 88** and, on a multicast-capable link, sent to **224.0.0.10** (FF02::A over IPv6). A filter, a firewall rule or a switch feature can drop those while passing ping untouched. So the investigation splits in two: are hellos reaching the other router at all, and if they are, why is it rejecting them? ## Step 1: are hellos leaving and arriving? - **Is EIGRP running on the interface?** Hellos go out only on interfaces where EIGRP is enabled. Many implementations also offer an option that stops hellos on an interface while still advertising its subnet: useful on a LAN with only hosts, fatal on a link to another router. - **Is anything filtering them?** An access list or firewall that permits ICMP but not IP protocol 88, or a switch that drops the multicast group, produces exactly this symptom. - **Can the link carry multicast?** Where it cannot, hellos must be sent unicast to a neighbour configured by address, and both sides need that configuration. If one router lists the other as a neighbour but not the reverse, hellos are crossing in one direction only. ## Step 2: the adjacency checklist When hellos do arrive, these are the three parameters RFC 7868 makes neighbours agree on: | Parameter | Where it travels | What RFC 7868 says | |---|---|---| | Autonomous system (AS) number | 16-bit field in every EIGRP packet header | A packet carrying a different AS number is ignored; valid values are 1 to 65,535 | | K-values (K1 to K6) | Parameters TLV in each hello | Two routers become neighbours only if their K-values are the same | | Authentication | Authentication TLV, MD5 or SHA2-256 | A packet whose authentication does not match is discarded | The **AS number** here identifies the EIGRP routing process whose routes are shared; it is not the organisation's BGP autonomous system number and only has to agree between the routers meant to exchange routes. The **K-values** are the weights of EIGRP's composite metric; why they must agree is a question about the metric, but for discovery the effect is simply that a mismatch stops the neighbourship. For **authentication**, both sides need the same type and the same key: a router that authenticates its packets discards unauthenticated ones, so it will not neighbour with a router that sends none. ## Step 3: addressing On IPv4, implementations commonly reject a hello whose source address is not on the receiving interface's subnet. RFC 7868 does not state that check for IPv4, so treat it as implementation behaviour, but a wrong mask on one side is a frequent real cause. For IPv6, RFC 7868 says the opposite outright: neighbours need not share a prefix on the link, and a hello must come from a valid **link-local** source address. ## What is not on the list **Hello and hold timers do not have to match.** Each router puts its own hold time in its hellos, and the neighbour times it out on that advertised value. OSPF differs here: RFC 2328 requires all routers on a network to agree on their Hello and Dead intervals. Copying the OSPF checklist onto EIGRP sends people chasing timers that are not the problem. ## A neighbour that comes up and drops again A different symptom, where the neighbour appears and then resets over and over, usually means multicast works but **unicast** does not. A new neighbour is held in a **pending** state while the routers exchange unicast packets that must be acknowledged; if those never get through, the retransmissions run out (RFC 7868 resets the neighbour after 16 retransmissions without an acknowledgement) and the cycle starts again at the next hello. Look for asymmetric filtering or a one-way path rather than a parameter mismatch. ## A checking order that saves time 1. Confirm that both routers send hellos on the interface. 2. Confirm that IP protocol 88 and 224.0.0.10 cross the link both ways. 3. Compare the AS numbers. 4. Compare the K-values. 5. Compare the authentication type and key. 6. On IPv4, compare each side's address and mask on the link. Each step rules out a whole class of causes, and the cheap, common ones come first.
- If one EIGRP router authenticates its packets and the other sends none, what happens?They do not become neighbours. RFC 7868 has a receiver discard packets whose authentication does not match what it expects, so the authenticating router drops the other router's unauthenticated hellos and the adjacency never completes, whatever the second router does with the authenticated ones. Both sides need the same type, MD5 or SHA2-256, and the same key.
- Is the EIGRP AS number related to the organisation's BGP autonomous system number?No. It is a 16-bit value in the EIGRP packet header identifying the routing process whose routes are shared, and RFC 7868 has receivers ignore packets carrying a different one. It needs to match only between routers meant to exchange EIGRP routes and can differ from any BGP AS number the organisation holds.
- Two EIGRP routers on IPv6 have global addresses from different prefixes on their shared link; can they become neighbours?Yes. RFC 7868 states that EIGRP IPv6 neighbours need not share a common prefix on the connecting interface; hellos are sourced from the link-local address, which must be valid. The AS number, K-value and authentication checks still apply exactly as on IPv4.
saying these in an interview costs you the question
- If two routers can ping each other, EIGRP hellos must be getting through.
- EIGRP neighbours need matching hello and hold timers, just as OSPF neighbours do.
- A different EIGRP AS number still forms a neighbour; its routes are just marked external.
- The EIGRP AS number has to equal the organisation's BGP AS number.
- Configuring authentication on one side is enough to protect the link.