Apologies if this has been asked before. I have looked around for an answer to my query, could just be my fried brain missing it.
The situation is this: we have a requirement to implement a large hub and spoke network whereby each spoke should have its data traffic encrypted. There will be approximately 250 spoke sites.
Clearly, a static approach, i.e. static VTIs at the head-end/hub and the spokes would not scale well and would require a great deal of config (human error) at either end. So a more dynamic approach is needed.
I was looking into a static and dynamic VTI approach where I create a dynamic VTI at the head-end/hub and static VTIs at each spoke. This way the head-end config is minimal with the majority of config done at each branch site.
I did find a great article here that explains how to configure the static/dynamic VTI:
With two trusty routers I set about my mission and successfully got it working where a VTI was established between the head-end/hub and the spoke, as confirmed using the following commands:
SPOKE#show crypto session Crypto session current status
Interface: Tunnel0 Session status: UP-ACTIVE Peer: 10.254.0.1 port 500 IKEv1 SA: local 10.254.0.3/500 remote 10.254.0.1/500 Active IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 Active SAs: 2, origin: crypto map
HUB1#show crypto session Crypto session current status
Interface: Virtual-Access1 Profile: DVTI Session status: UP-ACTIVE Peer: 10.254.0.3 port 500 IKEv1 SA: local 10.254.0.1/500 remote 10.254.0.3/500 Active IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 Active SAs: 2, origin: crypto map
HUB1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Embedded-Service-Engine0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/1 10.254.0.1 YES manual up up
Loopback0 10.122.20.1 YES manual up up
Virtual-Access1 10.122.20.1 YES unset up up
Virtual-Template1 10.122.20.1 YES unset up down
Vlan1 unassigned YES unset down down
The VTI is indeed up but this does not necessarily mean that any traffic emanating from the spoke is being encrypted right? Would I not need to somehow define what should be encrypted? For example, with the crypto map style of configuration you would create an ACL that defines the "interesting traffic".
Behind the spoke I have a LAN and any traffic from that LAN into the head-end/hub should be encrypted. On the link above it says:
Dynamic VTIs can also mimic the functionality of dynamic crypto maps. A central site can be reconfigured to use dynamic VTIs while retaining existing IPsec tunnels from remote sites using static crypto maps. Functionality like that of reverse route injection (RRI) is automatic with dynamic VTIs, whereby a static route is created automatically for each remote network negotiated via IKE.
As I understand it RRI will dynamically enter a static route into the hub's IP routing table for a spokes LAN subnet. However, this is not the case on my test lab. And it's probably something really simple that I am missing.
Can someone in easy to understand language please explain where I'm going wrong? In a nutshell how do I let the head-end know about the spoke's LAN subnet that the head-end would then need to create a dynamic static route (RRI) to?
SVTI negotiates "any any" as their IPsec SAs. You can accomodate multiple of those (unlike crypto maps) because of separate VA for each tunnel.
In case you have "any any" it makes little sense to perform RRI, it's way better to rely on dynamic routing protocol (unicast or mcast based) to route traffic you want over the tunnels (if you're going to BGP, look into listen range).
First off thanks for your reply and suggestions. Unfortunately due to time constraints I am unable to consider DMVPN or FlexVPN. Another point I should mention is that all sites will be interconnected through a Layer 3 VPN service. The BGP config above simply mimics this connection with the subsequent advertisement of the loopback for the VTI establishment. I understand I could have simply used another IGP for this purpose in my lab scenario.
Running a routing protocol over the VTI is an avenue I have explored and got working, however, again there are constraints which would take a long time to go into here.
So essentially I am very keen to try (I emphasise the word 'try') to get this working using RRI. It would make my life so much easier. Therefore I ask you and the community once more for any advice that could make this work.
RRI is not the way to go with SVTI on spoke ends. What you can try to go for in this case is multi-SA DVTI on hub with crypto maps on spoke, in which case proxy IDs could be negotitated more specificailly and inserted into routing table.
Or just use DVTI ezvpn... Or move to crypto maps completely.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :