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, Pluribus 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.
Auto-VXLAN
Starting from Netvisor ONE 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 ONE 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 ONE 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 1.1.1.1 location Switch1
CLI (network-admin@Switch2) > vtep-create name VTEP2 vrouter-name vr2 ip 2.2.2.2 location Switch2
CLI (network-admin@Switch3) > vtep-create name VTEP3 vrouter-name vr3 ip 3.3.3.3 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-1.1.1.1_2.2.2.2 10010
Switch1 auto-tunnel-1.1.1.1_3.3.3.3 10010
Switch2 auto-tunnel-2.2.2.2_1.1.1.1 10010
Switch2 auto-tunnel-2.2.2.2_3.3.3.3 10010
Switch3 auto-tunnel-3.3.3.3_1.1.1.1 10010
Switch3 auto-tunnel-3.3.3.3_2.2.2.2 10010
CLI (network-admin@Switch1) > vtep-vxlan-show
name vxlan
----- -----
VTEP1 10010
VTEP2 10010
VTEP3 10010
Inter-fabric VTEP Connections
Starting from Netvisor ONE 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
host-external
switch1
switch2
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 20.1.1.1 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 190.11.1.2 190.11.1.1
fabric VTEP2 switch2 vr2 190.11.1.3 190.11.1.1
fabric VTEP3 switch3 vr3 190.12.1.3 190.12.1.1
fabric VTEP4 switch4 vr4 190.12.1.2 190.12.1.1
fabric FAB2-VTEP1 host-external 20.1.1.1
RemoteFabricName: FAB2, SwitchName: FAB2-switch2
Hub-and-spoke VXLAN Connectivity
Starting from Netvisor ONE 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-1.1.1.1_2.2.2.2 10030
Switch1 auto-tunnel-1.1.1.1_3.3.3.3 10030
Switch2 auto-tunnel-2.2.2.2_1.1.1.1 10030
Switch3 auto-tunnel-3.3.3.3_1.1.1.1 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