How does a vEdge decide which tunnels to create ?

[rthomas2]

I'm trying to understand how a vEdge decides which other vEdges it needs to create tunnels to.

When it starts, the device learns the network topology from the vSmart controller. But if it finds it's in a network with say 300 other vEdges, does it create tunnels to all of those ? (let's assume this is a simple network so there is only one tloc / path / colour involved, so there's no potential to create multiple tunnels).

That's a lot of tunnels to maintain and to do performance tests over, especially if the other 299 devices do the same thing. Does it create tunnels on demand (ie the first time it needs to send traffic to another device/tloc) and then time the tunnel out after some inactivity ? Or does it use some intelligence around routing or other config info ("This looks like a hub and spoke network, so I'll just build tunnels to the core") ?

If this information is in the documentation somewhere please feel free to point me at it ! I haven't been able to find anything on this.

Richard 

[stefan.radovanovici · Accepted solution]

By default, all vedges in the network will try to create a full mesh of BFD sessions (i.e. data plane connections). There is no "hub" concept in the overlay network. You decide which vedges are the hubs from a logical/design point of view.

Once you decide that, you can implement control policies which will dictate how the vedges will form their data plane connections. You do that by creating custom control policies which will allow the "remote" vedges to only receive the TLOCs of the "hub" vedges.  

This can be done in various was but one policy example could be something like this: 

policy
 control-policy tloc-and-route-filter
    sequence 1
     match route
      site-list AllBranches
     !
     action reject
     !
    !
    sequence 11
     match tloc
      site-list AllBranches
     !
     action reject
     !
    !
   default-action accept
   !
   lists
   site-list AllBranches
    site-id 300-400
    !
   !
  !
  apply-policy
   site-list AllBranches
    control-policy tloc-and-route-filter out
    !
   !
  !
 !

What the policy does is to define a list of branches and a control policy. The control policy rejects TLOCs/routes from all the other branches, but allows the rest by default (i.e. the hubs). The policy is applied outbound direction (i.e. from the controllers to the vedges.  

[ekhabaro]

absolutely correct. with SD-WAN you can build arbitrary topology of your choice and by default, any vEdge/cEdge will try to form data plane tunnels with all possible TLOCs advertised by vSmart(s) (considering you don't have "restrict" keyword for your color config anywhere and no control policy to control TLOC advertisements).
There is no concept of on-demand (except for last-resort-circuit).
https://sdwan-docs.cisco.com/Product_Documentation/Command_Reference/Configuration_Commands/last-resort-circuit
https://sdwan-docs.cisco.com/Product_Documentation/Command_Reference/Configuration_Commands/color (search for "restrict") here
About control policy:
https://sdwan-docs.cisco.com/Product_Documentation/Software_Features/Release_18.4/06Policy_Basics/02Centralized_Control_Policy

[rthomas2]

Thanks for answering, Stefan - that makes sense.  I guess in any large network you would want to avoid thousands of tunnels being set up (a full mesh) so a policy along these lines would be a good idea.