topic Re: ASAs and more-specific static routes in Network Security

ASAs and more-specific static routes

mmelbourne — Fri, 12 Jul 2019 13:12:50 GMT

I had a situation with an ASA 5525-X running 9.6(4)25.

There was a static route in place for (say) 10.1.1.0/24 out of one interface, e.g.

route intf-1 10.1.1.0 255.255.255.0 <next-hop>

A more-specific route was then required out of another interface e.g.

route intf-2 10.1.1.48 255.255.255.240 <next-hop>

However, when adding the more-specific route, the traffic was not routed via this interface; the less-specific was still honoured for destinations in 10.1.1.48/28.

When the less-specific (10.1.1.0/24) was removed, the traffic flowed correctly.

Could it be the case that routes to destinations are 'cached' in some way, which might explain why the the more-specific was not used when both routes were present?

Cheers,
Matt

Re: ASAs and more-specific static routes

balaji.bandi — Fri, 12 Jul 2019 13:20:00 GMT

Is the next hop is same for both ? why not consider PBR in this case.

Re: ASAs and more-specific static routes

mmelbourne — Fri, 12 Jul 2019 13:23:30 GMT

Different next-hops (different interfaces), and no PBR required, just want anything that's not in the 10.1.1.48/28 network to be routed out intf-1. This should be basic more-specific route wins.

Re: ASAs and more-specific static routes

Rahul Govindan — Fri, 12 Jul 2019 13:30:36 GMT

Were connection tables already built for the traffic that you were testing? If the ASA matches an existing connection table entry, it will use the destination interface based on that. You may have to clear the connection and xlate table for the corresponding traffic. If it just 1 host you are testing with, use the "clear local-host x.x.x.x" command to do this.

Re: ASAs and more-specific static routes

mmelbourne — Fri, 12 Jul 2019 13:38:06 GMT

Thanks, I think was probably it, the connection tables were likely built (ICMP monitoring and UDP snmp/syslog traffic at the time of routing change).