Lab Prep
Ok so this one takes some ground work. 🙂 Having gone through this in the lab, I can see the benefits when applying templates to new vEdges, but this was a little fiddly for existing vEdges with their respective VPN0 and VPN512 configurations. However after some efforts I got this working successfully.
Goal: To add a new Service VPN – 4 with Loopback 4 at each vEdge using a Device and Feature Template.
When setting this up from scratch, the default device template will use default feature templates. So when I setup a feature template for VPN4, when previewing the intended configuration it will use the factory defaults for VPN0 and VPN512, so be careful or you may cause damage. Therefore templates are infact required for VPN0, VPN512 AND our new VPN4. Its like an investment.. the efforts your put in here will benefit you long term when using intent based / push of templates down to your Edge devices.
Planning
To create VPN 4 and add a Loopback4 interface to each site:
So when this is all done, all sites can ping each others loopbacks within VPN4.
Configuration
Here is a screencap of the Device Template I created and the Transport and Management VPNs:
Device Template
Feature Template
Note – There are 2 transports for VPN0 on each Edge, therefore there are 2 x VPN interfaces added the VPN0 feature template. IMO it is extremely helpful to give the device and feature templates intuitive names, otherwise is starts to become a headache and gets confusing. Any device template is therefore prefixed with ‘DT’ and any feature template is prefixed with ‘FT’.
The way the Feature Templates sit is hierarchical and in alignment with the layout of the actual configuration of the vEdge. Seeing it this way was very helpful to me personally.
What about the Service VPN 4 with the Loopback? More of the same..
So lets now take a look at the actual Feature Templates themselves. For starters look how neat and straightforward the layout is:
Now you can see how important the intuitive names really are. I need to be able to look at the name or description and understand its purpose.
Lets look at the Feature Template for VPN0 and in your head remember how the layout of VPN0 is on the CLI, this really helps get how these templates work and feel.
So I want the VPN number to be 0 and this is a global value, so no matter what vEdge this is pushed onto, it will always be 0.
Don’t forget we need 2 x default routes in VPN0 for each transport:
We also need our physical interfaces that will exist in VPN0, so we have a Feature Template for each as follows:
Looking at one of these for ge0/1 for example:
The interface name I want to be the same on any vEdge this is pushed out to, so will always be ge0/1 and is therefore Global.
What about something that we want to apply to this vEdge that is unique, such as the IPv4 address on the physical interface? Well this time the value will need to be manually entered before we push the configuration to the vEdge, so we choose ‘Device Specific’:
This then becomes similar to a variable logic with a key and a value. The key is ‘vpn_if_ipv4_address-ge0_1’ and the value will be input when pre configuration push.
Note – Huge bit of advice from me on this! Make sure you label the key, again with some intuitive. When you are inputting the values for each key, it will get very confusing as all of the key fields are named the same. So you need to name them with their purpose. In my example above. I added the physical interface name to the end of the key so it made sense when I was ready to push. This also applies to the color of the TLOC which is also done from this screen as it is part of the tunnel interface configuration:
- Tunnel interface is Global as I want this to be the same on any vEdge on the end of a configuration push
- Color needs to be a variable and also note the default key name! Change it to something helpful (You will see what I mean in a minute)
So the same process for VPN 512, but this time I want eth0 to be in a shut state as in my lab I am not using VPN512 on the vEdge devices.
Finally our new service side VPN 4, again the same process is followed as we did on VPN 0, but this time it is a Service VPN and only has Loopback 4 within it:
Some screencaps of the Feature Templates for VPN4:
VPN 4
Global values are used for VPN 4 and the name.
In this example I did not add a default route. VPN 4 only contains the 3 x Loopback interfaces at each site and again is not a tunnel or transport interface. Think of the VPN as a collection of interfaces and networks.
VPN 4 Interface
**VPN 4 is a service VPN, so no tunnel interface is required.
Push
So 1stly we need to attach the Device Template to our devices. In my lab this is vEdge10, vEdge20 and vEdge30. If we then click the 3 dots on the right, vManage lets us edit the values for each key pair:
I have edited vEdge10 as an example and you can now see how important good naming conventions are for your feature templates! Simply add the values and we can then update / push the configurations out to our devices.
Before you push I would advise checking each vEdge in turn to make sure all is as expected. You can either view the ‘show run’ version of configuration, or use the configuration diff view which is quite handy.
vEdge20 show run preview for example:
Or config diff to see any differences in the local vs new configurations:
- Green will be new configuration
- Yellow is a addition/edit
- Red is removing config
Hit Configure Devices and then Confirm. Hope for the best!
We also see the status of the tasks in the tasks view menu. Infact we are taken here after we push:
You can hopefully see how the Template feature of SD-WAN would work at large scale and if you had to make wide changes to the estate or perhaps the onboarding of new devices and ensuring consistent configurations. SDN controllers and intent based networking in all of its glory! 🙂
Verify
Oh and BTW VPN 4 is up and working. Pings from vEdge 20 VPN 4 to vEdge30 and vEdge40 are successful:
Finally how the routes look in VPN 4:
We see 2 x entries for each prefix in our routing table along with the relevant TLOC on the underlay.
CCIEME 
You must be logged in to post a comment.