This topic is to discuss the following lesson:
the 1.2.5 section The spoke router requires a static VTI to communicate with the hub router. Note that we use the ip address assigned command instead of a static IP address:
is command correct where the command is ip address negotiated
Is there any resources on setting up FLEXVPN DUAL HUB DUAL CLOUD with iBGP and dynamic underlay? Preferably EIGRP or OSPF
Hello David!
There is no lesson on NetworkLessons that covers this scenario, but you can take a look at this Cisco documentation that, for the most part, deals with the situation you describe:
Let us know how you get along and if you have any further questions, you know where to find us!
I hope this has been helpful!
Laz
Good Afternoon.
If I am trying to replicate this lab on CML, how do the Hub and spoke routers physically connect? The cloud icon is featured in the topology but I am not sure how to set this up in CML.
Thank you.
Hello Zahary
You will notice that all three routers are on the same subnet of 192.168.1.0/24 for the underlay network (the network configured for the physical interfaces. You can simply connect all three to an L2 switch to replicate the behavior of the cloud.
I hope this has been helpful!
Laz
Hello Lazaros!
Thank you so much for your response. I am still a little confused. I am assuming the cloud represents an ISP in the topology, so would you not just use a dummy router to mimic this in a lab environment?
If not, I just do not understand how the hub and spokes will be able to communicate/ learn routes over the L2 switch. Additionally, what would I need to configure on the switch for this to work?
Thank you for your time.
Hello Zachary
Take a look at the diagram of the topology once again:
In order to get the FlexVPN network up and running between the Hub and spokes, the only prerequisite is that these routes must have connectivity to each other. This can be across a single switch, across several routers, or it can be across the Internet. Now in the case of a production network where this would typically be over the Internet, many routers would intervene between the hub and spokes, and each router would have its own public IP address in completely different subnets.
In the lab, you want the same thing, simply to have the routers able to ping each other on the IP addresses assigned to their physical interfaces. Specifically:
- Hub 1 should be able to ping 192.168.1.1 and 192.168.1.2
- Spoke 1 should be able to ping 192.168.1.2 and 192.168.1.254
- Spoke 2 should be able to ping 192.168.1.1 and 192.168.1.254
Since in the lab all of the physical interfaces of these routers are on the same subnet, putting in an L2 switch will enable this communication. No configuration on that switch is necessary.
Now once that’s done, FlexVPN will create the tunnels necessary to allow communication between the hub and spokes. Spokes won’t actually learn routes over the L2 switch, but they’ll learn them over the FlexVPN tunnels.
I hope this has been helpful!
Laz
Hello Laz,
Thank you so much for your explanation this cleared up my confusion. You are awesome!
1 Like
Hello!
I am having a problem with the spoke-to-spoke communication aspect of this lab.
Each spoke has successfully created a tunnel with the Hub. Both spokes have BGP adjacency with the Hub.
Both the DVTIs and SVTIs are configured according to the lab for each spoke.
When I go to test spoke-to-spoke connectivity by doing a sourced ping from the Spoke1 Backside
Loopback to the Spoke2 Backside Loopback, the following errors pop up:
*Jul 7 04:32:10.998: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1,
changed state to down
*Jul 7 04:32:11.013: %SYS-5-CONFIG_P: Configured programmatically by process Crypto
INT from console as console
*Jul 7 04:32:11.156: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid
spi for destaddr=192.168.1.1, prot=50, spi=0x33B9274D(867772237), srcaddr=192.168.2.1,
input interface=Virtual-Access1
%DMVPN-5-NHRP_NETID_UNCONFIGURED: Virtual-Access1: NETID : 1 Unconfigured
(Tunnel: 0.0.0.0 NBMA: UNKNOWN)
*Jul 7 04:51:42.348: %SYS-5-CONFIG_P: Configured programmatically by process VTEMPLATE
Background Mgr from console as console
I have not really studied NHRP, but the NBMA unknown output caught my eye. I tried adding ip nhrp redirect on both spoke’s DVTIs and SVTIs, as well as ip nhrp nhs [Hub tunnel IP] on the spoke SVTIs but I got the same error after the ping test.
I am also not very familiar with CEF and how it interacts with NHRP, but the ip cef command did not take in my router. I am not sure if it was already enabled by default.
Thank you for your time and any help would be greatly appreciated.
Hello Zachary
The message that is of vital importance here is the “invalid SPI” message for IPSec. For some reason, the Security Parameters Index (SPI) is invalid for the IPSec tunnel created to the other spoke (192.168.1.1 destination).
However, I do see one issue that may be causing the problem. Take a look at this syslog message once again:
*Jul 7 04:32:11.156: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid
spi for destaddr=192.168.1.1, prot=50, spi=0x33B9274D(867772237), srcaddr=192.168.2.1,
input interface=Virtual-Access1
Notice that the source address is 192.168.2.1 and the destination address is 192.168.1.1. These should be the IP addresses configured on the Gi0/0 interfaces of Spoke 1 and Spoke 2 respectively. However, they are not on the same subnet (assuming you are using a /24 subnet mask like in the lesson). This would cause an invalid SPI since the addresses are different that what would be expected, based on the rest of the config. Check your IP addresses once again to see if this is the issue, and let us know how you get along.
I hope this has been helpful!
Laz