An emergency-management office configures EIGRP on two civic hubs but adjacency never forms. The hubs use different autonomous-system numbers. What is the correct conclusion?
Select an answer to reveal the explanation.
Short Explanation
EIGRP AS number is the team jersey. Two emergency hubs wearing different numbers will not scrimmage together—no adjacency, period. Pick one AS for the municipal domain and stick to it.
Full Explanation
EIGRP neighbors must use the same autonomous-system number; mismatched AS values prevent adjacency between the two emergency-management civic hubs. Classic and named EIGRP both treat AS identity as a fundamental neighbor gate—different AS numbers mean different EIGRP domains, not a redundant hub trick. Aligning AS numbers on both hubs is the fix before chasing metrics, auth, or timers.
Claiming different AS numbers are required for hub redundancy and adjacency should still form fails by concept: redundancy uses multiple links or routers inside one AS (or controlled redistribution between domains), not mismatched AS on a intended single-domain adjacency. Claiming EIGRP forms the neighbor but marks all routes external until AS matches fails—the neighbor does not form. Claiming AS mismatch only affects IPv6 AF while IPv4 ignores AS fails; AS matching applies to the EIGRP process/AF context for that adjacency.
Exam caveat: named mode still embeds AS identity for the domain—do not confuse “named process” with “AS optional.” Operational check: compare AS configuration on both emergency hubs, set a single municipal AS, bounce or await adjacency, and confirm neighbors up before validating critical emergency prefixes.