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  


north
    keyboard_arrow_up
    keyboard_arrow_down
    description
    print
    feedback
    support
    business
    rss_feed
    south