The Cisco ASA is a firewall that happens to route. That framing matters, because when you sit down at an ASA after years on IOS routers, the routing looks familiar right up until it doesn't. The commands are subtly different, a few defaults are inverted, and the box is opinionated about which routes it will actually install. This article is the orientation stop for the routing side of our Cisco ASA cluster: what the firewall will and won't do when you ask it to run a dynamic routing protocol, and why.
The ASA supports OSPF, EIGRP, RIP, and BGP. All four are real, all four are testable, and every capture in this article came from a live ASAv 9.24(1) running in Cisco Modeling Labs, driven over SSH from a real Linux host. If you have already worked through static routing on the ASA, this is where the box starts learning routes on its own.
The first thing that trips up IOS people: show route
On an IOS router you type show ip route without thinking. On the ASA, that command does not exist. The ASA uses show route. There is no ip keyword because the ASA route table is not split the way an IOS RIB is presented, it is simply the route table. Here is the real table from our lab firewall, FW1:
FW1# show route
Gateway of last resort is 203.0.113.2 to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via 203.0.113.2, outside
C 10.20.10.0 255.255.255.0 is directly connected, inside
L 10.20.10.1 255.255.255.255 is directly connected, inside
D 10.20.20.0 255.255.255.0 [90/128512] via 10.20.10.2, 00:08:55, inside
O 10.20.20.1 255.255.255.255 [110/11] via 10.20.10.2, 00:12:31, inside
O 10.255.0.1 255.255.255.255 [110/11] via 10.20.10.2, 00:12:31, inside
C 172.20.30.0 255.255.255.0 is directly connected, dmz
L 172.20.30.1 255.255.255.255 is directly connected, dmz
C 203.0.113.0 255.255.255.0 is directly connected, outside
L 203.0.113.10 255.255.255.255 is directly connected, outsideThe route codes are the same ones you already know: C for connected, L for the local host route (the interface address as a /32), S for static (the S* is the gateway of last resort), O for OSPF, and D for EIGRP. The ASA adds a couple of its own that IOS does not use in the same way (V for VPN-learned routes, and SI / BI for inter-VRF static and BGP). Interfaces are named, not numbered, so the next-hop line reads via 10.20.10.2, inside rather than pointing at GigabitEthernet0/1. On the ASA, "inside" is the interface.
Two details in that table are worth pausing on because they confuse people coming from IOS. First, every connected network produces two lines: the network itself as C, and the firewall's own interface address as an L host route with a /32 mask. That is not clutter, it is how the box knows a packet destined for its own interface is for it and not to be forwarded. Second, the S* at the top is your default route, and the phrase "Gateway of last resort is 203.0.113.2" is the ASA telling you where anything it does not have a more specific route for will go. On this firewall that next hop lives out the outside interface toward the ISP, exactly as you would expect on an edge box.
The second surprise: network statements take a real mask
On IOS, network 10.20.10.0 0.0.0.255 area 0 uses a wildcard mask. On the ASA, the OSPF and EIGRP network statement takes a real subnet mask, and again there is no ip keyword. Here is the minimal OSPF configuration from FW1:
router ospf 1
router-id 10.20.10.1
network 10.20.10.0 255.255.255.0 area 0
area 0 authentication message-digest
redistribute static subnetsIf your muscle memory types a wildcard there, the ASA will either reject it or match the wrong set of interfaces, and you will spend twenty minutes wondering why the adjacency never comes up. Real mask, no wildcard, no ip. Write that on a sticky note before you touch OSPF or EIGRP on this platform.
The centrepiece: administrative distance, proven on one box
Look back at the route table above. The network 10.20.20.0/24 is installed with the code D and a metric of [90/128512]. The 90 is administrative distance, and it is EIGRP's. But that same prefix was also being advertised into this firewall by OSPF at the same time. So why did EIGRP win?
Because administrative distance is the tie-breaker the router uses when two protocols both offer a path to the same prefix. Lower distance wins. EIGRP internal routes carry an AD of 90; OSPF carries 110. When both protocols hand the firewall a route to 10.20.20.0/24, the ASA installs exactly one of them, and it picks the lower distance. EIGRP's 90 beats OSPF's 110, so the prefix installs as D, not O. The OSPF version does not vanish, it simply sits in the OSPF database as a backup that never makes it into the route table while EIGRP is healthy.
This is worth internalising because it is the same ordering that decides a story we tell later in the cluster. RIP's administrative distance is 120. On a firewall that is already learning 10.20.20.0/24 via EIGRP (90) and OSPF (110), a RIPv2 route to that same prefix at distance 120 never installs at all, no matter how correctly you configure RIP. It is not broken, it is simply outranked. That is most of the reason you rarely see RIP win a route in a mixed network, and we prove it end to end in the RIPv2 on the ASA article.
Should a firewall run a routing protocol at all?
Here is the honest part. Running a dynamic routing protocol on a firewall is, more often than not, a design smell. A firewall's job is to enforce policy at a boundary, and every routing adjacency you form is another trust relationship and another moving part on a device whose whole reason for existing is to be predictable. The cleaner design for most edge firewalls is a default route out to the ISP, a handful of static routes toward internal networks, and a properly designed routed core (running OSPF, EIGRP, or BGP among the routers and layer-3 switches) that hides its complexity behind a single summarised next hop.
That said, "often a smell" is not "never". There are entirely legitimate reasons an ASA speaks a routing protocol: it sits inline in a campus core that already runs OSPF and needs to learn dozens of internal prefixes without a static-route sprawl; it peers BGP with a cloud provider or an upstream carrier; it participates in a redundant path where you want fast reconvergence rather than tracking a static route by hand. And on the exam side, CCNP and CCIE Security both expect you to configure and troubleshoot these protocols on the ASA, silent failures and all. So the correct instinct is: prefer static plus a clean routed core, but know how to run the dynamic protocols cold, because you will meet them.
Of the four, OSPF is by far the most common thing you will see on a real ASA, which is why it gets the longest treatment in this cluster. EIGRP shows up in Cisco-only shops that standardised on it years ago. BGP is the specialist case: it is genuinely useful at a data-centre or cloud edge, but it is also the most configuration-heavy of the four and deserves its own build rather than a paragraph here. RIP, frankly, you keep in your back pocket for the day a legacy device on the far end speaks nothing else. The point of this overview is that all four sit on the same route table, obey the same administrative-distance rules, and are reached with the same show route command, so once you understand the model, each protocol is just a different way of populating it.
Where to go next in this cluster
This overview is the map. Each protocol gets its own deep-dive with the full build, the verification output, and the specific way it bites you on this platform:
Key Takeaways
- The ASA is a firewall first and a router second. It runs OSPF, EIGRP, RIP, and BGP, but with defaults and syntax that differ from IOS.
- Use
show route, notshow ip route. There is noipkeyword on the ASA route commands. - OSPF and EIGRP
networkstatements take a real subnet mask, not an IOS-style wildcard. - Administrative distance decides which protocol installs a prefix. On our one box, EIGRP (90) beat OSPF (110) for 10.20.20.0/24, so it installed as
D. The same ordering is why RIP (120) never wins. - Dynamic routing on a firewall is often a design smell. Prefer a default plus static routes and a clean routed core, but know the protocols cold because they are real and testable.
- Start with the Cisco ASA cluster pillar, then work through the OSPF, EIGRP, and RIPv2 deep-dives linked above.