ASA, Site to Site VTI, EIGRP, Maps/ACL's, NAT

[cco@leferguson.com]

I have spent a good deal of time with ASAv (9.7) in GNS3 experimenting with VTI tunnels between ASA's, trying to get routing to be exchanged gracefully, and could use some sanity checking.  There are two issues generally.

The first is that the documentation seems to skip necessary parts, e.g. Configuration guide look toward end do not show a ikev1 policy, but I found it necessary to have one for the tunnel to come up (maybe it's just assumed one already knows that).  But other postings (such as this) lead one to think "nat (inside,any)" is needed and/or ACL's that should be applied but cannot be (including reference to TAC saying they needed a way to add them). I also saw PSK's on tunnel groups and separately in crypto map statements.

I seem to have it working with a policy statement, but without any nat statements or ACL's for specifying subnets (which I wanted to avoid and use routing). 

So the first question comes really down to this: Is there a recommended, or best way to configure this? I am attaching my config in total (it's all model so there's nothing private in it, not even real addresses) in case anyone wants to look at the detail and suggest if this is off base. Note I did ikev1 as ikev2 is apparently only in 9.8 and I did not have an asav for 9.8. This looks fairly simple, and parallels the first link (with the addition of the policy statement), but diverges from a lot of the blogs and examples I have found online.

The second question is eigrp and bgp.  I really wanted to exchange routing over eigrp, but it says only bgp is supported (that first link above).  Eigrp can be configured, but never sees a neighbor. Trying to force a neighbor fails because you can't specify the vti interface, and the inside and outside interfaces give a "wrong interface" error as you might expect. So a curiousity question is whether there's something innate in VTI that keeps eigrp from being supportable (and so we may never see it), or maybe it's coming in a future release?

But the real question on routing is this: Is there a downside of having eigrp redistribute into bgp and vice versa and letting that exchange routing?   It SEEMS to work, I seem to have connectivity in all the failure modes I have tried in internal and external network links (remembering this is all simulation).  Note the attached config has fairly random values for metrics for redistribution so I recognize that may need some tuning, and no attempt at general ASA hardening or service protections has been done, it is just to test VTI's.  But in general, any reason why this can't be used in production?  Is there a better way to realize full routing topology exchange across ASA L2L tunnels? 

Thanks in advance for any sanity checks.

Linwood

PS. I attached only one ASA, the other is symmetric at 192.168.4.1 outside.  The 10.127.99.x and 10.127.98.x are inside interfaces and 10.127.66.1 -> .2 is the tunnel interface between.  The use of a track/sla is not terribly relevant to this, but used for internal routing failover to the default gateway by route injection back into eigrp. 

[Richard Burts]

I do not have much experience with VTI on ASA but have done lots of VTI on IOS routers. My responses are based on the assumption that the implementation on ASA is similar to implementation in IOS routers. It is a bit confusing about what is really required, ex IKE. It is very clear in IOS and I am confident that it is also true in ASA that you do not need ACL, or crypto map, etc to identify traffic for the VTI. The assumption is that any traffic going through the tunnel needs to be encrypted, so no need to maps or ACL. On routers nat is usually not involved and I am not sure what the requirement is for ASA. Your posted config does not have any identify nap (or nat exemption) to not translate the VPN traffic going through the tunnel. If you say that traffic is successfully going through the tunnel without any nat exemption then it appears that it is not needed.

Redistribution can make things tricky, especially if you are redistributing at more than one place in the network. The most significant issue when doing mutual redistribution is the possibility that a route could originate in one protocol, get redistributed into a second protocol, get advertised, and then get redistributed back into the original protocol. So now the route appears to originate from a different place and with a different metric than the original. But if you are careful about controlling it redistribution is helpful.

I do not have any insight about using EIGRP through VTI on ASA. I hope someone else can share some wisdom about this.

HTH

Rick

[cco@leferguson.com]

Thank you @Richard Burts.  Yes, as best I can tell it's working without NAT and ACL's; inexperience made me worry I was missing something since there were postings showing it.  Basically was worried as mine looked a lot simpler than some postings I saw (if a bit more complex than the config guide, but it clearly didn't work until I added the policy section).

Do you have any pointers or recommendations for how to mitigate redistribution risks?  Or how to tell if it's causing an issue? Since both ASA's in normal circumstances can see all of the internal network, both's EIGRP route list will be exhaustive. I take it you are saying that, passed on by BGP, can cause issues.  What would I look for, an unexpected metric perhaps? 

[cco@leferguson.com]

Well, I certainly see how they are causing a problem, am researching fixes.  The routes over the tunnels are coming across and being preferred over the routes from eigrp on the inside of the ASA's.  I think all I really want is any redistributed route is never preferred, but am struggling a bit to find the right control for that, but am getting closer.  Thanks for the heads up to check for that, otherwise I might have missed it until something later stopped working (this is a proof of concept for a real install not an exercise). 

[cco@leferguson.com]

What I ended up doing was change the administrative distance for all external routes on both ASA's in both BGP and EIGRP redistribution, with the idea being these routes exchanged over the tunnels were last-ditch fallbacks and only relevant if the internal network (which is itself pretty redundant) were ever severed so there were no internal EIGRP derived routes available.

That's kind of a niche case of course, i really hope someone comes along and shows me a way to use eigrp without bgp, or a new version comes out which does.  Seems all too likely there's something else hiding in this redistribution closet that I haven't found yet.

[Richard Burts · Accepted solution]

I have several comments that I hope will be helpful.

- If you are just redistributing on two ASA connected by a tunnel then the chances for reintroducing routes back into the originating protocol is not likely. So your particular situation is pretty safe.

- the common way to control redistribution to prevent reintroducing routes is to control redistribution with a route map. If you are redistributing routes into a protocol your route map will set a tag value on the redistributed route. If you redistributing routes from a protocol your route map will look for that tag value and deny those routes and permit routes that do not have that tag.

- I do not know much about your environment but I wonder if you really need mutual redistribution. Would it be enough to redistribute EIGRP into BGP without redistributing from BGP back into EIGRP. I see that you need to redistribute EIGRP into BGP to get the route advertisements over the tunnel. But is it enough that the routes are in the routing table of the peer ASA? Do you really need to advertise all of the EIGRP routes in the remote EIGRP AS? If the ASA advertises a default route into its network then all the traffic will come to the ASA and the ASA can use the routes it learned via BGP to determine what to forward through the tunnel.

- Certainly changing the administrative distance of redistributed routes is also a way to deal with it.

I agree with you that it is odd that it seems not supported to run EIGRP over the tunnel. If it is not yet supported I certainly hope that a new version will come at some point that does support EIGRP over VTI.

HTH

Rick 

[cco@leferguson.com]

@Richard Burts thanks.

I'm thinking your last point may be true.  I need to give it some thought and experimentation. 

The issue I'm trying to deal with is a couple dozen sites that might conceivably have their connectivity severed, leaving an island of (say) 8 sites on one side, 16 on the other. I had been thinking that the routing updates from side A needed to propagate all the way into side B (i.e. EIGRP on A -> BGP at A's firewall -> BGP at B's firewall -> EIGRP in B to pass out to B's sites), but that may not be needed.  If I only redistribute EIGRP into BGP not the reverse, the default gateway will still exist and so a subnet on A's side might not know it has a route to a subnet on B, but they will end up there via the default gateway.

Needs more experimentation and thought; thank you for these.  

By the way, I looked at route maps but was trying to use them to give preference to certain routes, not filter them, and had no luck (without somehow making assumptions about where in the internal network the break would occur and so which would end up on A and B's side.

Thank you again; this is new territory for me.

[Richard Burts]

You are welcome. I am glad that my suggestions have been helpful. I hope that exploring this new territory will be good for you. You know your environment much better than we do, but my guess is that the devices in site A do not really need to know all the details about what is in the network at site B. They really just need to have a correct default gateway to reach remote sites. And I believe that reducing the complexity of the routing table becomes even more important as the number of remote sites increases.

HTH

Rick

[Siva Arunagiri]

Has Cisco come up with solution on supporting EIGRP/OSPF over VTI interface in the latest release?