This topic is to discuss the following lesson:
Hi Rene and Team,
How about if I use 1 Router is same ISP, spoke routers will have different IP public, so we need one default route to ISP. So my question is: in the case. can we do Hub advertise 0.0.0.0/0 to spoke routers ? and when I did lab in this case, My lab can not advertise subnet to peer 
, can you show idea to troubleshoot ?
Thank a lot !
Hello Tung
You must remember that in such a topology, you have an overlay network and an underlay network. The underlay network in the lesson is the 192.168.1.0/24 network. This represents the Internet or any other network over which you will create your tunnels. This underlay network can be anything, using the same ISPs or different ISPs, just as long as the routers have connectivity between them. The routing between routers here is the responsibility of the ISPs. In fact, a static IP is needed only for the hub. The IP addresses of the spokes can actually be dynamic. Notice the hub configuration doesn’t include any information bout the IP addresses of the spokes.
Now the overlay network is the network you create that will be tunneled over the underlay network. In the lesson, this is the 172.16.1.0/24 network. Here, there is no actual routing protocol being used, but you can see, in the verification section of the lesson, that the spokes have been configured with a static default route to the hub, via the tunnel interface, which was “advertised” based on the flexVPN configuration. Similarly, the routes in the hub to the spokes were also advertised via IKEv2 and are based on the configuration in the IKEv2 authorization policy of the spokes themselves.
So in the lesson, the 0.0.0.0/0 is already configured in the spoke routers, due to the configuration implemented at the hub.
I hope this has been helpful!
Laz
Spoke2(config-ikev2-profile)#identity local fqdn SPOKE1.FLEXVPN.LAB
should this conf line be
Spoke2(config-ikev2-profile)#identity local fqdn SPOKE2.FLEXVPN.LAB
Hello Terry
Yes, you seem to be correct. I will let @Rene know…
Laz
Thanks Terry. I just fixed this.
Rene
Hello Laz ,
how does the Hub Router advertise the default Route to Spoke ? with access list permit any? BUT There is no command to advetise the default route or this will occur automatically ?
Thanks in Advanced .
Hello Mohammad
The routes in this network topology are shared using IKEv2 routing. The default route that the spokes learn about comes from the hub, and is based on the configuration found in the IKEv2 Authorization Policy found in section 1.1.2 of the lesson.
Specifically, it is the route set access-list FLEXVPN_ROUTES command that advertises the default route. Tee FLEXVPN_ROUTES access list says permit any, which is the same as 0.0.0.0 0.0.0.0 which is the default route.
This then appears as a static route that sends all default traffic via the Tunnel0 interface, which connects to the hub.
I hope this has been helpful!
Laz
Unless I am mistaken it seems to be a mistake in this configuratin,
although the shou running config at the bottom is correct but they are not the same as the step by step configuration when you are explaine the command,
1-Spoke1(config-ikev2-profile)# aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION is missing on the IKEv2 Profile - on Spoke1 router
2- on Spoke2 the above command is there but ends with “default” and not IKEV2_AUTHORIZATION here:
Spoke2(config-ikev2-profile)#aaa authorization group psk list FLEXVPN_LOCAL default
but on the full config(show run) the config is correct, I am not sure if i am missing something here or not since although i followed your config step by step but the tunnel was down and had to trubolshoot it, because when I copy your entire “sho run” into my spoke routers it worked for me, and that is when I noticed the difference between the step by step config and the running config,
apart from that I have a question, the loopback interface on the HUB1 is 172.16.1.254/32 while this subnet is /24 on the spokes, is this ok?
Cheers
Hello Ryfa
Yes, it looks like you are correct. I’ll let Rene know to make the necessary modifications. Thanks for pointing that out!
Idealy the subnets should be the same, however, because FlexVPN simply needs communication between the spoke and the hub routers, something that has been established not by simple routing, but by the virtual access ports created in the hub. If you take a look at the output of the show ip route command on the Hub router, you will see that both 172.168.1.1 and 172.168.1.2 are reachable from the hub because they are directly connected to the virtual access ports, and not because they are directly connected via the loopback interface. If the latter was the case, the subnet mask of /32 would make those two spokes unreachable.
I hope this has been helpful!
Laz
1 Like
I am not seeing the full configs of the routers only the ip interfaces are showing up in the article
Hello Timothy
The configs that appear near the beginning of the lesson are the startup configurations of each device. This includes only configurations that are necessary to prepare before applying any of the configurations you see in the lesson. These initial configs don’t include all of the default settings that are already set up in the config of IOS routers. They only include the changes you need to make before you begin. Those changes include only the configuration of the hostname and the loopback and GE interfaces.
The configurations near the end of the lesson show all of the configs that have been applied in all of the sections of the lesson, so you can see the results that you should have after applying all of the described configs.
I hope this has been helpful!
Laz
why the config of DVTI of hub doesn’t have tunnel source cmd?
Hello Nipun
When configuring a DVTI, it is unnecessary to use the tunnel source command. When creating a static VTI, you must bind that VTI to a physical interface. However, when creating a dynamic VTI, you create a virtual template that is not associated with any physical interface. Whenever a new IPSec session is needed, the router automatically creates a virtual access interface that is cloned from the virtual template. This can occur on any of the router’s interfaces, so there is no single interface that is the tunnel’s source.
For more information on DVTIs and SVTIs, take a look at this lesson:
I hope this has been helpful!
Laz
Hi all,
How to use this with ip sla?
I mean that when the connexion goes down, how to tell the router to upload another route to spoke or from hub to spoke?
Regards!
Hello Boubou
IP SLA can be used in many ways to respond to changes on a network. In this particular case, it depends upon what you want to achieve.
This will depend upon your topology. Generally, a hub and spoke topology will have only one route from the hub to each spoke. There are no alternative routes, so an IP SLA would not help us here at all. To achieve redundancy in such a case, you would have to create a dual hub. An example of a FlexVPN dual hub and spoke configuration can be found in this Cisco documentation:
If you want to learn more about IP SLA in general and how you can apply it in various situations, take a look at this lesson:
I hope this has been helpful!
Laz
Hi Lagapides,
Good morning,
At first I configured the connection between the HQ and the 7 remote sites through a WAN and then I configured the WAN2 to make a backup link by configuring cisco ip SLA. The tracking has been put on the main WAN and everything is working correctly.
From HQ I track all remote ip addresses. And from the remote sites I track the HQ ip address. When an address does not respond, the router loads the route that passes through the WAN2 on the HQ side as well as on the remote site side.
Now I have configured FLEXVPN on the main WAN. WAN2 is safe. and everything works. I still have to implement ip sla.
From HQ I can track the ip addresses of the FLEXVPN of the spokes, but from the remote sites which ip address of the HQ to track?
So as you can see, the DUAL HUB does not suit me.
Hello Boubou
That’s an interesting setup. Typically, the hub loses connectivity with the IP address of a spoke, the same will occur with the spoke on its end, so both IP SLAs on both devices will begin using the backup link. That makes sense.
I believe it would be best to track the IP addresses of the tunnel and not of the physical interfaces. So if we look at the lesson as our example, Spoke 1 should monitor the 172.16.1.1 IP address. If the tunnel fails, but the physical address is still reachable, that would not result in traffic rerouting if a failure occurred.
In your topology, you have marked the interface of the hub connected to the FlexVPN WAN as 10.10.20.10. If that is the IP address of the tunnel interface and not of the physical interface, then you can track that address. As soon as a spoke loses connectivity to that address, it can switch to WAN2. Does that make sense?
I hope this has been helpful!
Laz
Hi Lazaros,
I have follow your advises.
So now from the Hub, when failure accur (physical interface admistrative down or link loss), backup routes are not loaded in routing table as virtual-access interfaces still remain.
I have to issue manually the command : clear crypto session
Then backup routes are all loaded and the connexions to spokes networks become up.
And when physical interface become available, flexvpn connexions come up very slowly.
So please how can solve this.
Hello Boubou
In a FlexVPN Hub and Spoke setup, backup routes do not load automatically when the hub fails because the spoke routers are still maintaining an active IPsec Security Association (SA) with the hub. The virtual-access interfaces that are associated with the IPsec SAs remain up, even though the hub is no longer reachable. This is because the routing used in the setup is not aware of the underlying IPsec tunnel’s actual state. Otherwise, any backup routes would kick in.
Issuing the clear crypto session command forces the IPsec SAs to be torn down and the associated virtual-access interfaces to be removed. This triggers the routing to re-evaluate the routes and load the backup routes into the routing table.
The SA will remain up for the configured lifetime duration, which by default is 86400 seconds or one full 24-hour day.
One solution would be to reduce the lifetime to something on the order of several seconds, but this will cause the router to reestablish the SA continually, which may not cause disruption to the network, but will increase the burden of resources on the router. Another solution would be to automate the process of issuing the clear crypto session command in the event the hub fails. You can do this by incorporating an Embedded Event Manager (EEM) applet with an IPSLA, where the command will be run whenever communication with the hub has failed.
Yes, this is because of a related issue. If the SAs on the spokes haven’t expired yet when the hub comes back up, they will still be active, so the spokes won’t attempt to reestablish the new SAs with the hub. The spokes will wait until the SAs time out before attempting to reestablish. If Dead Peer Detection (DPD) is activated, which is a mechanism used by IPSec VPN devices to detect if the remote peer is still alive. The default timeout is 30 seconds with a retry interval of 10 seconds. The delay in detecting the peer’s state can affect the reestablishment of the connections.
To be able to further troubleshoot the issue, it would be a good idea to take a look at the syslogs and do some debugging to determine the specific reason behind the delay.
I hope this has been helpful!
Laz