EIGRP on the Cisco ASA: Configuration and Neighbor Gotchas

EIGRP on the Cisco ASA is one of the most straightforward things you will configure on the platform, right up until a neighbour refuses to form. And the number-one reason an EIGRP neighbour will not come up on the ASA fails completely silently: no error, no log, nothing but an empty neighbour table. This article walks the full build, the working adjacency, and then that silent failure end to end, all captured from a live ASAv. It belongs to our Cisco ASA cluster, and if you want EIGRP internals beyond the firewall, the EIGRP pillar covers DUAL, metrics, and feasibility in depth.

As with the rest of this cluster, every capture below came from an ASAv 9.24(1) in Cisco Modeling Labs, driven over SSH, peering with an IOS-XE router called CORE1. It is a real ASA-to-IOS EIGRP relationship, not a theoretical one.

The configuration

EIGRP on the ASA is compact. Here is the whole thing on FW1:

router eigrp 100
 no auto-summary
 network 10.20.10.0 255.255.255.0

The 100 after router eigrp is the autonomous system number, and remember that number because it is the hero of this article. As with OSPF, there is no ip keyword anywhere, and the network statement takes a real subnet mask (a classful network with an optional mask), not an IOS wildcard. The no auto-summary line disables classful auto-summarisation so that your subnetted routes are advertised with their real prefix lengths rather than being collapsed to a classful boundary. On any modern design you want no auto-summary on, because auto-summary causes routing black holes the moment you have discontiguous subnets of the same major network.

The working adjacency and the learned route

With CORE1 configured in the same AS, the neighbour forms. You verify it with show eigrp neighbors (no ip):

FW1# show eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address     Interface   Hold Uptime   SRTT   RTO   Q  Seq
0   10.20.10.2  inside       14  00:00:33  10     200   0    3

The header tells you which AS you are looking at (AS(100)), and the single row is CORE1 at 10.20.10.2 off the inside interface. The Q column reading 0 means there is nothing queued waiting to be sent to that neighbour, which is what you want in steady state, a non-zero Q that never drains points at a transport problem. Once the neighbour is up, the route it advertises shows up in the table:

FW1# show route eigrp
D        10.20.20.0 255.255.255.0 [90/128512] via 10.20.10.2, 00:00:31, inside

There it is: 10.20.20.0/24 learned via EIGRP, code D, with the administrative distance and metric in the brackets as [90/128512]. The 90 is EIGRP's internal administrative distance, and it is exactly why this prefix wins over the OSPF copy of the same route (OSPF's distance is 110). The 128512 is the composite EIGRP metric. If you ever need to know why the firewall preferred EIGRP for a prefix that multiple protocols advertise, that 90 is your answer, and we cover the full administrative-distance story in the dynamic routing overview.

Reading that composite metric

The 128512 in [90/128512] is the EIGRP composite metric, and it is worth understanding at a glance even if you rarely compute it by hand. EIGRP builds this number from the slowest bandwidth along the path and the cumulative delay, scaled by the K-values (the metric weights). Bandwidth and delay are the two components that matter by default; the other potential inputs (load, reliability, MTU) are switched off in the standard K-value set, which is exactly why a K-value mismatch, covered below, breaks an adjacency. Both neighbours must agree on which components count, or they cannot agree on a metric.

The practical takeaway is that if two paths to the same prefix exist, EIGRP picks the one with the lower composite metric, and it does so using the feasible-distance and reported-distance logic that underpins the DUAL algorithm. You do not need to memorise the arithmetic to operate an ASA, but you should know that the second number in the brackets is a path-quality figure, not an administrative distance, and that the first number (90) is the administrative distance that decides protocol preference. People conflate the two constantly. On the ASA route table they sit side by side, so it is a good place to keep them straight.

The silent failure: an AS number mismatch

Here is the teaching moment, and it is the whole reason this article exists. EIGRP neighbours will only form between routers configured in the same autonomous system. To demonstrate what happens when they are not, we put CORE1 into EIGRP AS 200 while leaving FW1 in AS 100. Everything else stayed correct: interfaces up, IP reachability fine, network statements right. Here is what the firewall showed:

FW1# show eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
FW1#

An empty table. Just the header for AS 100 and then the prompt. And here is the part that catches even experienced engineers: there was nothing in syslog. No "AS mismatch" message, no warning, no hint. The firewall did not tell us anything was wrong, because from its point of view nothing was wrong. It is running EIGRP in AS 100 and simply has no neighbours in AS 100.

Why is it silent? Because the autonomous system number is part of what identifies an EIGRP hello as belonging to a particular EIGRP process. CORE1's hellos carry AS 200; FW1 is listening for AS 100. The AS 200 hellos do not match the AS 100 process, so the firewall discards them the same way it would discard traffic for a protocol it is not running. There is no negotiation and therefore no mismatch to report. Contrast this with the RIP authentication failure elsewhere in this cluster, which the ASA logs loudly at severity 1, or an OSPF area mismatch, which at least leaves the neighbour cycling through states you can watch. An EIGRP AS mismatch produces none of that. It looks exactly like "no neighbour is out there".

The practical lesson: when an EIGRP neighbour will not form and everything else looks fine, check the AS number on both ends before you do anything else. Do not trust that the far end matches just because your side is correct. The moment we reconfigured CORE1 back to AS 100, the neighbour came up within seconds and the D route reappeared. No reload, no clearing, no drama, the adjacency was ready the instant the AS numbers agreed.

Why the AS number silence is worse than it sounds

It is tempting to shrug this off. You configured the AS, surely you know what it is. But consider how these mistakes actually happen. Someone templated the firewall config from a different site that used AS 200. Someone fat-fingered 100 as 200 in a change window at 2 a.m. Someone stood up a new core switch and used the AS number from the design doc, which was stale. In every one of those cases, the person looking at the firewall sees a perfectly valid EIGRP process with an empty neighbour table and no errors, and their instinct is to suspect a layer-1, layer-2, or ACL problem, because those are the things that usually produce a silent dead neighbour. They can burn an hour checking cabling and interface counters before anyone thinks to diff the AS number against the peer. Knowing that this specific failure is silent is what saves you that hour.

Everything that stops an ASA EIGRP neighbour forming

The AS mismatch is the sneakiest, but it is not the only thing that blocks an adjacency. Here is the field checklist, with the silent one flagged because it deserves the warning:

Notice how many of these are silent. That is the theme with EIGRP adjacency troubleshooting: only a couple of failure modes announce themselves, so you cannot rely on syslog to point you at the problem. You have to work the checklist. Start with the two things that are both common and silent, the AS number and whether the interface is actually in a network statement, and only then move to the noisier candidates.

A verification workflow that finds the silent ones fast

Because so many EIGRP failures on the ASA are silent, a consistent verification order beats poking around. Start with show eigrp neighbors and read the AS number in the header against what the peer is configured for; if the table is empty and the AS numbers differ, you are done. If the AS matches but the table is still empty, confirm the interface is actually enabled for EIGRP by checking that a network statement covers its subnet, and that the interface is not passive. Only after those two silent suspects are cleared should you look for the noisy failures (authentication and K-value mismatches do log, so a clean syslog effectively rules them out). Finally, confirm plain IP reachability between the two neighbour addresses on the segment, because EIGRP hellos are just packets and a broken layer-2 path or an ACL will stop them like anything else.

This ordering is deliberately front-loaded with the silent, common problems. It is the opposite of how people instinctively troubleshoot, which is to check the loud, dramatic things first. On EIGRP the loud things are the rare ones. Trust the checklist over your gut, and you will find the AS-number typo in thirty seconds instead of an hour.

A note on passive interfaces and firewall security

The passive-interface item in that grid is worth calling out on a firewall specifically. Making an interface passive means the ASA still advertises that interface's subnet into EIGRP but stops sending hellos out of it, so no adjacency forms there. On a firewall you often want that on interfaces facing untrusted networks: you would never want the ASA forming an EIGRP relationship with something out on the internet-facing side. So passive-interface is both a troubleshooting suspect (you removed an adjacency you needed) and a security control (you removed an adjacency you did not want). Configure it deliberately, and document which interfaces are passive so the next person does not spend an afternoon wondering why a neighbour will not form on a link you intentionally silenced.

Key Takeaways

• EIGRP on the ASA is compact: router eigrp <AS>, no auto-summary, and a network statement with a real subnet mask and no ip keyword.
• A working neighbour shows in show eigrp neighbors, and the learned route appears as D with administrative distance 90, which is why EIGRP beats OSPF for the same prefix.
• The number-one adjacency killer, an AS number mismatch, is completely silent: an empty neighbour table and nothing in syslog. Always check the AS on both ends.
• Matching the AS brought the neighbour up within seconds with no reload or clearing.
• Most EIGRP adjacency failures on the ASA are silent. Work a checklist rather than waiting for a log message: AS number, network statement coverage, passive interface, authentication, K-values, and basic IP reachability.
• Passive-interface is both a troubleshooting suspect and a legitimate security control on a firewall. Use it deliberately on untrusted-facing links.
• For EIGRP internals see the EIGRP pillar; for the rest of the firewall build, the Cisco ASA cluster.