> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # EIGRP on the Cisco ASA: Configuration and Neighbor Gotchas - URL: https://www.pinglabz.com/asa-eigrp-configuration/ - Published: 2026-07-13T10:04:04.000Z - Updated: 2026-08-24T09:42:16.000Z - Description: Full EIGRP build on the Cisco ASA captured live from an ASAv 9.24, from working adjacency to the number-one neighbor failure that produces no error, no log, just an empty neighbor table. - Author: Jaime - Tags: ASA, EIGRP, CCIE, Labs, #Import 2026-08-01 19:54 EIGRP on the Cisco ASA is one of the most straightforward things you will configure on the platform, right up until a neighbor refuses to form. And the number-one reason an EIGRP neighbor will not come up on the ASA fails completely silently: no error, no log, nothing but an empty neighbor 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](https://www.pinglabz.com/cisco-asa/), and if you want EIGRP internals beyond the firewall, the [EIGRP pillar](https://www.pinglabz.com/eigrp/) 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 neighbor 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 neighbor, which is what you want in steady state, a non-zero Q that never drains points at a transport problem. Once the neighbor 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](https://www.pinglabz.com/asa-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 neighbors 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 neighbors 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 neighbors 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 neighbor cycling through states you can watch. An EIGRP AS mismatch produces none of that. It looks exactly like "no neighbor is out there". The practical lesson: when an EIGRP neighbor 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 neighbor 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 neighbor 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 neighbor. 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 neighbor 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: AS number mismatch Symptom: empty neighbor table Logged? **No, completely silent** Fix: match the AS on both ends K-value mismatch Symptom: neighbor will not stay up Logged? Yes, a K-value mismatch message Fix: align the metric weights on both ends Authentication mismatch Symptom: no adjacency Logged? Yes, auth failure messages Fix: match key ID, key string, and mode Interface not in a network statement Symptom: no hellos sent on that link Logged? No Fix: add a `network` statement covering the interface subnet Passive interface Symptom: interface advertised but no neighbor Logged? No Fix: remove `passive-interface` on the link that needs the adjacency No IP reachability / ACL Symptom: hellos never arrive Logged? No Fix: confirm the two neighbor IPs can reach each other on the segment 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. That loud-versus-silent split is not an ASA quirk; it is how EIGRP behaves everywhere, so the same ordering works on the IOS side of the link. [Seeing which EIGRP adjacency failures announce themselves and which do not](https://www.pinglabz.com/troubleshooting-eigrp-neighbor-adjacencies/) breaks each cause deliberately on a router and shows exactly what syslog says, or does not say. ## 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 neighbor 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 neighbor will not form on a link you intentionally silenced. ## Key Takeaways - EIGRP on the ASA is compact: `router eigrp `, `no auto-summary`, and a `network` statement with a real subnet mask and no `ip` keyword. - A working neighbor 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 neighbor table and nothing in syslog. Always check the AS on both ends. - Matching the AS brought the neighbor 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](https://www.pinglabz.com/eigrp/); for the rest of the firewall build, the [Cisco ASA cluster](https://www.pinglabz.com/cisco-asa/).