cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1236
Views
0
Helpful
3
Replies

Viptela (simple, newbie) Transport Question

jblake00111
Level 1
Level 1

I’m trying to interpret the Viptela documentation, and I’m coming across some apparent contradictions, probably because I don’t have all the facts or understand them. Can anyone enlighten me?

 

I understand that VPN0, the Transport VPN, must be configured on each vEdge router, to allow it to talk to vSmart and vManage entities, using a TLOC (IP address, color and encapsulation). I also understand that there can be multiple connections to different WAN networks. The Viptela documentation states that “A vEdge router can have up to four TLOCs, so you can configure more than one tunnel connection.” Getting to the area where I’m unclear: Consider a vEdge with multiple TLOCs, bound to different physical ports. The documentation states that ALL WAN traffic must travel over VPN0 (VPN 1-511 are for Service VPNs, VPN512 is the management VPN). In such a multi-TLOC environment, additional tunnel interfaces must be configured in VPN0, to support the additional TLOCs.

 

So as described above, it is possible to have up to 4 TLOCs on a vEdge, and they will all be in VPN0. When the overlay is created, I have read that the default is to create a full mesh over the available connections. However, policies can be crafted to create Hub-Spoke or partial mesh if required.

 

Now to the question: I’ve seen high level marketing diagrams showing several different overlay networks, but if I only have VPN0 to play with, how do I create (and use) different topologies? With them all being in VPN0, won’t the different topologies be lost and the full mesh (or the aggregate of all the separate topologies) prevail? I've watched the videos, and that appears to imply that you can create several transport VPNs...is that right?

 

I’ve gone through the documents time and again, but I’m missing something, so can anyone advise….

https://sdwan-docs.cisco.com/Product_Documentation/Software_Features/Release_18.1/04Segmentation/02Configuring_Segmentation_(VPNs)

 

Thanks

 

Jim

3 Replies 3

jblake00111
Level 1
Level 1

I've been delving deeper, and now it looks like the transport VPN is just a bunch of pipes, with no fixed association with service VPNs. I think that was where I was getting it wrong: I expected particular service VPNs to be restricted to each site and connected to particular transport VPNs, that were responsible for carrying data to other service VPNs on other sites.

 

However, my interpretation now is that the service VPNs are globally significant (VPNx on any site is part of the VPN x that is found across the whole of the network) and run through/over the transport VPN. Thus, they can form any kind of topology over the existing tunnels they need to. That is the latest interpretation after reading and re-reading the documentation, and spending ages on DCloud....

 

Does that sound about right, or am I barking up the wrong tree.....Anyone?

 

Thanks

Jim

Hi Jim,

 

The Service VPNs routes are redistributed into the Overlay tunnels, i.e. the TLOCs to the other ends branches if they have the same VPN. 

 

My understanding is that VPN0 is more or less just a grouping of all the "WAN" side ports. In some other vendors implementation they use LAN side-WAN side for easier understanding in my opinion.

 

The tunnels are meshed by default, and inside this mesh you can create diff topo per VPN. Alternatively you can also restrict the forming of tunnels (i.e. from default mesh to others like hub-spoke..etc) via policy in vManage. This can be achieved by cutting the concerned BFD session I believe.

 

I am also a learner, so hope my understanding is correct and be of help to you. Tks.

The tunnels are meshed by default, and inside this mesh you can create diff topo per VPN. Alternatively you can also restrict the forming of tunnels (i.e. from default mesh to others like hub-spoke..etc) via policy in vManage. This can be achieved by cutting the concerned BFD session I believe

 

I think that this is a very interesting part! As I understand this would mean, that if I use a centralized policy to build e.g. a Hub&Spoke actually in VPN0 - I‘ll be not able to use a Full-Mesh in any of the Service-VPN, correct?

 

What does this mean for on-Demand tunnels? That would probably mean that if enabled all Service-VPNs will have to deal with that and it‘s not possible to say only VPN4 should use this method and VPN2 can have a statically default Full-Mesh… if so, is there another solution which can achieve that goal?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: