Good CCIE question: Can multiple site-2-site VPNs support dynamic routing protocols?

Question

Hi All,
Was not sure if this should be posted in LAN routing, WAN routing or VPN forums: I have posted here as the VPN tunnels are the limiting factors...
I am trying to understand if it is possible to have dynamic routing between LANs when using site to site VPNs on three or more ASA55x5-x (9.0).
To best explain the question I have put together an example scenario:
Lets say we have three sites, which are all connected via a separate site-2-site IKEv2 VPNs, in a full mesh topology (6 x SAs).
Across the whole system there would be a 192.168.0.0/16 subnet which is divided up by VLSM across all sites.
The inside / outside interfaces of the ASA would be static IPs from a /30 subnet.
Routing on the outside interface is not of concern in this scenario.
The inside interface of the ASA connects directly to a router, which further uses VLSM to assign additional subnets.
VLSM is not cleanly summarised per site. (I know this flys against VLSM best practice, but makes the scenario clearer...)
New subnets are added and removed at each site on a frequent basis.
EIGRP will be running on each core router, and any stub routers at each site.
So this results in the following example topology, of which I have exaggerated the VLSM position:
(http://www.diagram.ly/?share=#OtprIYuOeKRb3HBV6Qy8CL8ZUE6Bkc2FPg2gKHnzVliaJBhuIG)
Now, using static route redistribution from the ASAs into EIGRP and making the ASAs to be an EIGRP neighbour, would be one way. This would mean an isolated EIGRP AS per site, but each site would only learn about a new remote subnet if the crypto map match ACL was altered. But the bit that I am confused over, is the potential to have new subnets added or removed which would require EIGRP routing processes on the relevant site X router to be altered as well as crypto map ACLs being altered at all sites. This doesn't seem a sensible approach...
The second method could be to have the 192.168.0.0/16 network defined in the crypto map on all tunnels and allow the ASAs routing table to chose which tunnel to send the traffic over. This would require multiple neighbours for the ASA, but for example in OSPF, it can only support one neighbour over a S2S VPN when manually defined (point-to-point). The only way round this I can see is to share our internal routing tables with the IP cloud, but this then discloses information that would be otherwise protected by the IPSEC tunnel...
Is there a better method to propagate the routing information dynamically around the example scenario above?
Is there a way to have dynamic crypto maps based on router information?
P.S. Diagram above produced via http://www.diagram.ly/

Answer 1

Hi Guys,
Thanks for your responses!  I am learning here, hence the post.
David: I had looked in to the potential for GRE tunnels, but the side-effects could out weight the benifits.  The link provided shows how to pass IKEv1 and ISAKMP traffic through the ASA.  In my example (maybe not too clear?) the IPSEC traffic would be terminated on the ASA and not the core router behind.
Marcin: Was looking at OSPF, but is that not limited to one neighbour, due to the "ospf network point-to-point non-broadcast" command in the example (needed to force the unicast over the IPSEC tunnel)? Have had a look in the ASA CLI 9.0 config guide and it is still limited to one neighbour per interface when in point-to-point:
ospf network point-to-point non-broadcastSpecifies the interface as a point-to-point, non-broadcast network.When you designate an interface as point-to-point and non-broadcast, you must manually define the OSPF neighbor; dynamic neighbor discovery is not possible. See the "Defining Static OSPFv2 Neighbors" section for more information. Additionally, you can only define one OSPF neighbor on that interface.
Otherwise I would agree it would be happy days...
Any other ideas (maybe around iBGPs like OSPF) which do not envolve GRE tunnels or terminating the IPSEC on the core router please?
Kindest Regards,
James.