OSPF or EIGRP Over an ASA VTI: Which One Your Release Supports
OSPFv2 and EIGRP ride an ASA VTI only from 9.19(1), and only with multicast enabled. Compare the two on the release you run, then verify neighbors.
Most OSPF-versus-EIGRP arguments assume the tunnel can already carry the protocol, and on an ASA that assumption is the part worth checking first. The comparison only becomes interesting after the image, the VTI type and the multicast path are confirmed. Get that order wrong and you spend an afternoon tuning timers on a tunnel that will never form an adjacency. I start every one of these designs with the release notes and the running configuration, not with the protocol preference.
The release decides before the protocol does
Cisco's ASA 9.24 VTI guide is a usable documentation baseline: it describes static and dynamic VTIs and lists static routing, BGP, OSPF and EIGRP. Its feature history puts OSPFv2 and EIGRP support on VTI at 9.19(1). Anything older than that is a different conversation.
So the first two questions are boring and decisive:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
A statement that an ASA cannot use VTIs, or cannot carry an IGP, was true of some older images and is not a current support matrix. Equally, the 9.24 guide is not an instruction to upgrade every appliance. It tells you what that release supports, and your deployed release has to answer for itself.
Unicast passing does not mean the IGP will form
The same guide notes that unicast passes by default and that multicast has to be enabled for OSPFv2 or EIGRP on the VTI, with documented limits on multicast groups. That one sentence explains most failed adjacencies I have seen on this design. A working ping across the tunnel, or a green IPsec status, only proves the unicast path. Protocol discovery needs the multicast path, and the two are configured separately.
Check the tunnel interface configuration for that multicast setting before you touch hello or hold timers. If the setting is absent, the adjacency is not slow, it is impossible.
OSPF and EIGRP side by side on the same tunnel
On the tunnel itself the two protocols look like what they are elsewhere. OSPF needs a matching network type, area, authentication and neighbor parameters; EIGRP needs its AS number and the interface-level settings that go with it.
The trap is copying neighbor statements from a different tunnel model. Advice about static neighbors on a non-VTI design existed to avoid multicast, and it does not transfer to a VTI that is expected to carry the protocol natively. Configure the supported interface behaviour, then let the protocol form its own adjacency.
Then compare on the axes that actually differ for your topology: interoperability with the other side, convergence behaviour you can test, and the operating knowledge on your team. A historical anecdote about one protocol being faster or lighter is not a measurement of your network.
Neighbors do not equal installed routes
Once the adjacency is up, separate what is originated from what is accepted. Look at which branch prefixes each side advertises, which ones are received, which are selected, and which actually reach the routing table. Import, export and redistribution scope should be deliberate rather than a blanket advertisement of everything the device knows.
show ospf neighbor and show eigrp neighbors tell you the session is alive. show route tells you whether the branch prefix arrived, and those are different questions.
The application path is a third question again. A neighbor relationship distributes reachability; it does not grant permission through the firewall, and it does not prove that traffic selectors and filtering rules agree. Verify the permitted flow and its reply path with an approved test rather than assuming the route implies the policy.
What the finished comparison should record
Write down the tunnel interface, the release that supports it, the control exchange you verified, and the route policy you bounded. Add the multicast setting, because it is the detail that silently decides whether any of the rest works. Keep that record next to the deployed release so a later feature change can be reviewed without restarting from an assumption that has since expired.
If any of those four is missing, you have a preference rather than a design. Fix the missing fact first; the protocol choice is the easy part.