Lab Introduction This lab is related to my previous post DMVPN Phase3 IKEv1 and NHS Cluster. The previous post shows 'the crypto keyring can only be t
This lab is related to my previous post DMVPN Phase3 IKEv1 and NHS Cluster. The previous post shows ‘the crypto keyring can only be tagged with fvrf’ and ‘fvrf on match statement of isakmp profile’. So what shall we do if we have a single FVRF (front door VRF) but multiple IVRFs (inside VRF)? – it would be easier if we have FVRF1 and IVRF1, FVRF2 and IVRF2.
This lab demonstrates one solution. DMVPN tunnel will use loopback address instead of physical WAN interface as source interface: DMVPN in IVRF1 with loopback IP 1.1.1.x as source address and DMVPN in IVRF2 with loopback IP 4.4.4.x as source address.
Although there is one FVRF shared by both IVRF1 and IVRF2, we make IVRF1 source 1.1.1.x/24 have a unique key Cisco1 and IVRF2 source 4.4.4.x/24 have a unique key Cisco2.
Similar to the previous lab, HUB1 and HUB2 forms NHS cluster with HUB1 as primary and HUB2 as backup.
Different from the previous lab that used a dummy switch to simulate WAN, this lab uses a router with hostname WAN to simulate WAN. Sites are connected to WAN using eBGP. WAN BGP AS is 7788; HUB1 and HUB2 are in the same AS 65111; SPOKE is in AS 65113.
Please note HUB1 doesn’t receive HUB2’s BGP route advertisement (see Verification section) due to they are in the same AS. BGP uses AS Path attribute to identify path and prevents routes advertised from the same AS from getting in, which is BGP loop prevention mechanism. This post is not going to discuss methods to override BGP loop prevention.
Topology is as below:
- HUB1 and HUB2 forms NHS cluster with HUB1 as primary and HUB2 as backup
- HUB1 and HUB2 are in BGP AS 65111
- WAN is in BGP AS 7788
- SPOKE is in BGP AS 65113
- Physical WAN interface GE2 in FVRF
- Tunnel 11 in IVRF1 with loopback1 as source, IPSec key Cisco1
- Tunnel 41 in IVRF2 with loopback4 as source, IPsec key Cisco2