Configuring VTEP Objects with Automatic Fabric Connections

Based on the command sequence in the earlier section, Configuring the Overlay: VTEP Interconnections and VNIs, configuring a series of unidirectional end-point interconnections (even in a simple triangular topology) requires the network administrator to manually issue a long list of explicit (and hence tedious) tunnel-create commands.

Therefore, starting from release 2.6.0, Arista has introduced an additional user-friendly operational simplification element called a logical VTEP configuration object that leverages the intelligence of the fabric’s distributed control plane to automate the aforementioned tedious connection setup process.

With this  configuration paradigm, instead of having to create individual unidirectional connections between the end points (i.e., the tunnel-create model), a user can simply create a single VTEP object per endpoint with the vtep-create command and then map the required VXLAN identifiers to it.

This in turn triggers the automatic creation of all the required VXLAN connections in both directions between endpoints, yielding a significant amount of configuration and time savings.

An example of VTEP object configuration syntax  is displayed below: 

CLI (network-admin@switch) > vtep-create name <vtep-object-name>  vrouter-name <vrouter name> ip <primary IP> virtual-ip <vip> [location <switch name>]

CLI (network-admin@switch) > vtep-vxlan-add name <vtep-object-name> vxlan <vnid1>

CLI (network-admin@switch) > vtep-vxlan-add name <vtep-object-name> vxlan <vnid2>

CLI (network-admin@switch) > vtep-vxlan-add name <vtep-object-name> vxlan <vnid3>

And so on… 

VTEP objects can also be displayed or deleted with the vtep-show and vtep-delete commands, respectively.


Starting from NetVisor OS release 6.0.0 the auto-vxlan parameter is supported as an option of the VLAN creation process and can be used to automate the vtep-vxlan-add operations.

The auto-vxlan parameter can be used either in combination with an explicit VNI value or implicitly without specifying it. In both cases any created VLAN/VNI mapping is automatically added to all the existing VTEP objects. Additionally, in the latter case, the VNI value is automatically picked and assigned out of a predefined range.

Therefore, to automatically assign a certain user-defined VLAN/VNI mapping to all VTEP objects in the fabric, you can use the following command:

CLI (network-admin@switch) > vlan-create id 1234 scope fabric vxlan 5001234 auto-vxlan

If you want the software to automatically pick and assign the VNI too, you can simply enter the shorter command below, which requires the scope to be set to fabric (as the VNI assignment can only be fabric-wide):

CLI (network-admin@switch) > vlan-create id 1234 scope fabric auto-vxlan

The above vlan-create commands with auto-vxlan automatically configure the following (assuming there are 3 VTEPs in the fabric, VTEP1 through VTEP3):

CLI (network-admin@switch) > vtep-vxlan-add name VTEP1 vxlan 5001234

CLI (network-admin@switch) > vtep-vxlan-add name VTEP2 vxlan 5001234

CLI (network-admin@switch) > vtep-vxlan-add name VTEP3 vxlan 5001234

where 5001234 is the VNI value either entered explicitly by the user or automatically selected from the vtep-auto-vxlan range.

The range used for automatic VNI assignment can be controlled and modified, if needed, with the vtep-auto-vxlan-show and vtep-auto-vxlan-modify commands.

Note: You can use the vlan-create command with auto-vxlan in local and cluster scope too provided the VNI is explicitly specified. If it’s not, an error message is printed:

CLI (network-admin@switch) > vlan-create id 1000 scope cluster auto-vxlan

vlan-create: auto-vxlan only allowed for fabric scope

CLI (network-admin@switch) > vlan-create id 1000 scope local auto-vxlan

vlan-create: auto-vxlan only allowed for fabric scope

Also starting from NetVisor OS release 6.0.0 the vlan-show command output displays when auto-vxlan is used:

CLI (network-admin@switch) > vlan-show id 1234 format id, type, vxlan, auto-vxlan, scope, description, active, stats, ports

id   type   vxlan   auto-vxlan scope description active stats ports

---- ------ ------- ---------- ----- ----------- ------ ----- -------------

1234 public 5001234  yes       local  vlan-1234   yes    no    0-48,50-52

If an associated VNI value needs to be changed after a VLAN has been created using the auto-vxlan option, the vlan-modify command can be used for that purpose like so:

CLI (network-admin@switch) > vlan-modify id 1234 vxlan 4001234

For VLANs created with the auto-vxlan option, the new VNI will replace the old VNI in the VTEP connections.

Starting from NetVisor OS release 6.0.0, when a VLAN is deleted, if it was previously created with the auto-vxlan option, the VLAN/VNI mapping will be removed from all the VTEP objects automatically.

In the example of Figure 8-8 above, the following commands can be used to create three VTEP objects on three nodes:

CLI (network-admin@Switch1) > vtep-create name VTEP1 vrouter-name vr1 ip location Switch1

CLI (network-admin@Switch2) > vtep-create name VTEP2 vrouter-name vr2 ip location Switch2

CLI (network-admin@Switch3) > vtep-create name VTEP3 vrouter-name vr3 ip location Switch3

CLI (network-admin@Switch1) > vlan-create id 10 scope fabric vxlan 10010 auto-vxlan

The command sequence above automatically creates bidirectional VXLAN connections between the three nodes and also automatically adds VNI 10010 to all of them, thanks to the auto-vxlan keyword, as shown in the following outputs:

CLI (network-admin@Switch1) > tunnel-vxlan-show

switch    name                        vxlan

--------- --------------------------- -----

Switch1   auto-tunnel- 10010

Switch1   auto-tunnel- 10010

Switch2   auto-tunnel- 10010

Switch2   auto-tunnel- 10010

Switch3   auto-tunnel- 10010

Switch3   auto-tunnel- 10010

CLI (network-admin@Switch1) > vtep-vxlan-show

name  vxlan

----- -----

VTEP1 10010

VTEP2 10010

VTEP3 10010

Inter-fabric VTEP Connections

Starting from NetVisor OS release 6.0.0, the automatic VTEP object creation functionality is further extended to include an additional parameter that can be used to connect a VTEP in one fabric instance to another one in a different fabric instance. In other words, this new capability enables inter-fabric VTEP connections.

As part of the VTEP object creation, a new reserved location keyword, called host-external, is introduced to enable inter-fabric connectivity, as shown in the command output below:

CLI (network-admin@switch1) > vtep-create name ext-VTEP location




Specifying the host-external keyword in the command identifies an external VTEP, whose corresponding unique IP address should then be specified as part of the command like so:

CLI (network-admin@switch1) > vtep-create name FAB2-VTEP1 location host-external ip description "RemoteFabricName:FAB2, SwitchName: FAB2-switch2"

Note: The virtual-ip option is not supported with external VTEPs (it’s meant to be used only with regular VTEPs). For redundancy, the ip option can simply point to the VRRP VIP (virtual IP) of the external VTEP.

Also note that a good practice (which is not enforced in the CLI but is recommended) is to name external VTEPs in a user-friendly and precise way, for example, with the following naming structure: <fabric-name>-vtep-name, or with any other suitable structure that allows the naming to unequivocally and uniquely identify a specific VTEP.

As shown in the example above, a description field is also added to the vtep-create command, which can be used to store additional details about the precise remote VTEP location including switch name, fabric name, switch vendor, etc.

External VTEPs can be displayed along with regular VTEPs in the vtep-show command like so:

CLI (network-admin@switch1) > vtep-show format all name FAB2-VTEP1

scope  name       location      vrouter-name ip         virtual-ip description

------ ---------- ------------- ------------ ---------- ---------- -----------

fabric VTEP1      switch1       vr1

fabric VTEP2      switch2       vr2

fabric VTEP3      switch3       vr3

fabric VTEP4      switch4       vr4

fabric FAB2-VTEP1 host-external                  

RemoteFabricName: FAB2, SwitchName: FAB2-switch2

Hub-and-spoke VXLAN Connectivity

Starting from NetVisor OS release 6.0.1, a new keyword is introduced to support a hub-and-spoke VXLAN connectivity model in which a hub node is connected to all the spokes bidirectionally, but the spokes are not connected to each other (see an example in Figure 8-9 above).

Note: This feature is supported only on Dell, Edgecore, and Freedom series switches.

The new isolated keyword is used along with manual VNI assignment in the vtep-vxlan-add command. Therefore, it is applied on a per-VNI per-VTEP mapping basis.

The isolated keyword is used to configure the spoke nodes, whereas the hub nodes are configured normally. In the example of Figure 8-9 above, the following sequence can set up one hub and two spoke/isolated nodes for VNI 10030:

CLI (network-admin@Switch1) > vlan-create id 30 scope fabric vxlan 10030

CLI (network-admin@Switch1) > vtep-vxlan-add name VTEP1 vxlan 10030

CLI (network-admin@Switch2) > vtep-vxlan-add name VTEP2 vxlan 10030 isolated

CLI (network-admin@Switch3) > vtep-vxlan-add name VTEP3 vxlan 10030 isolated

Due to the hub-and-spoke nature of the configuration, bidirectional VXLAN connections are only created (automatically) between the hub node (Switch1) and the spokes (Switch2 and Switch3), but not between the spokes as shown below:

CLI (network-admin@Switch1) > tunnel-vxlan-show

Switch   name                        vxlan

-------- --------------------------- -----

Switch1  auto-tunnel- 10030

Switch1  auto-tunnel- 10030

Switch2  auto-tunnel- 10030

Switch3  auto-tunnel- 10030 

The default configuration mode is not-isolated (in other words, the isolated keyword is not assigned by default to any VNI mappings). Also, not-isolated is an optional keyword so it can be omitted. Note that, if users need to change a VNI from isolated to not-isolated/normal mode, they need to first execute the vtep-vxlan-remove command in order to delete the VNI assignment and subsequently they can add it back with the default/normal mode.

The per-VNI isolated configuration can be checked with the vtep-vxlan-show command as shown below:

CLI (network-admin@switch) > vtep-vxlan-show

name vxlan isolated

---- ----- --------

vt1  10021 no

vt1  10020 yes

vt1  10023 yes

vt1  10025 no

vt1  10022 no

vt1  10024 yes

vt2  10021 no

vt2  10020 yes

vt2  10023 no

vt2  10025 no

vt2  10022 yes

vt2  10024 yes

vt3  10021 no

vt3  10020 yes

vt3  10023 yes

vt3  10025 yes

vt3  10022 yes

vt3  10024 no