Configuring Virtual Service Groups
Note: This feature is supported only on Dell, Edgecore, and Freedom series switches.
Starting from Netvisor ONE release 6.0.1 it is possible to import/export subnet prefixes between Unicast Fabric VRFs. This operation is sometimes informally referred to as ‘prefix leaking’.
To implement this functionality a new innovative entity called Virtual Service Group (vSG) is introduced: it’s an abstraction that defines in an intuitive and user-friendly way the policies by which prefixes are shared.
Note: As of Netvisor ONE release 6.0.1, this functionality applies only to Unicast Fabric VRFs and not to vRouter-based VRFs.
First a vSG is created with the vsg-create command, specifying a name and optionally (but conveniently) a description string:
CLI (network-admin@switch) > vsg-create name <vsg-name> [description <description>]
Similarly, an existing vSG can be deleted or its description can be modified with the vsg-delete and vsg-modify commands, respectively.
A newly created vSG is a grouping that is meant to contain a list of VRFs, which can be added individually with the command:
CLI (network-admin@switch) > vsg-vrf-add name <vsg-name> vrf <name> [type promiscuous | isolated] [vnet]
The vsg-vrf-add command enables the user to optionally specify the type of prefix sharing to apply to each VRF as well as an associated vNET. The promiscuous keyword (i.e., the default option) identifies VRFs whose prefixes can be freely shared with any other VRF. Instead, the isolated keyword identifies VRFs whose prefixes can only be shared with VRFs marked as promiscuous. So when the type is not specified, it defaults to promiscuous.
Analogously to the vsg-vrf-add command, VRF removal is performed with the vsg-vrf-remove command.
The last vSG configuration step is to identify which subnet(s) and/or prefix(es) to share for each VRF with the command:
CLI (network-admin@switch) > vsg-network-add name <vsg-name> vrf <vrf-name> network <prefix/mask>|subnet <name> [vnet]
If all (current and future) subnets within a VRF have to be shared, you can use the handy shortcut: subnet all.
Once added, subnets/prefixes can be removed with the corresponding vsg-network-remove command.
The sharing of the added prefixes/subnets between VRFs follows the rules dictated by the respective promiscuous/isolated markings, which is a very simplistic configuration model but can also be rather powerful.
Going through a few examples of use cases is the best way to describe the flexibility of such configuration model, as discussed in the following.
Example 1: Full-mesh Connectivity Model
In this scenario there are for example two tenants who share a common service. The three network entities are associated to three VRFs respectively: TENANT-GREEN, TENANT-GREY and SERVICE-AMBER. All three VRFs need to share at least one subnet with the others for proper connectivity.
This is an any-to-any communication model, in which you can use the promiscuous keyword to (explicitly) state that sharing is allowed. Then you can specify which subnets are shared. For example, TENANT-GREEN and TENANT-GREY share one of their subnets with SERVICE-AMBER like so:
CLI (network-admin@switch) > vsg-create name GROUP-A description ANY-TO-ANY-SHARING
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-A vrf TENANT-GREY type promiscuous
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-A vrf TENANT-GREEN type promiscuous
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-A vrf SERVICE-AMBER type promiscuous
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-A vrf TENANT-GREY subnet SUBNET-11
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-A vrf TENANT-GREEN subnet SUBNET-21
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-A vrf SERVICE-AMBER subnet SUBNET-1
SUBNET-11 corresponds to 10.0.11.0/24, SUBNET-21 to 10.0.21.0/24 and SUBNET-1 to 10.1.1.0/24.
CLI (network-admin@switch) > vsg-show
switch name description
------ ------- -------------------
switch GROUP-A ANY-TO-ANY-SHARING
CLI (network-admin@switch) > vsg-vrf-show
switch vsg-name vnet vrf type
------ -------- ---- ------------- -----------
switch GROUP-A 0:0 TENANT-GREY promiscuous
switch GROUP-A 0:0 TENANT-GREEN promiscuous
switch GROUP-A 0:0 SERVICE-AMBER promiscuous
CLI (network-admin@switch) > vsg-network-show
switch vsg-name vrf vnet subnet network network_state
------ -------- ------------- ---- --------- --------------- -------------
switch GROUP-A TENANT-GREY 0:0 SUBNET-11 10.0.11.0/24 ok
switch GROUP-A TENANT-GREEN 0:0 SUBNET-21 10.0.21.0/24 ok
switch GROUP-A SERVICE-AMBER 0:0 SUBNET-1 10.1.1.0/24 ok
Figure 8-16 – Virtual Service Group Example
Example 2: Hub-and-spoke Connectivity Model
In this scenario, the ‘hub’ VRF is the one that needs to share its subnet(s) with all other vSG members without distinction. In other words, it’s the promiscuous VRF. A good example would be a common shared service. Instead, isolated VRFs (spokes) don’t need to share subnets between each other, they only need to share them with the promiscuous VRF. A common case would be different tenants (say, GREEN and GREY) that require routing segregation without any mutual prefix sharing, like so:
CLI (network-admin@switch) > vsg-create name GROUP-B description HUB-AND-SPOKE-SHARING
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-B vrf SERVICE-BLUE type promiscuous
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-B vrf TENANT-GREY type isolated
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-B vrf TENANT-GREEN type isolated
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-B vrf TENANT-GREY subnet SUBNET-12
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-B vrf TENANT-GREEN subnet SUBNET-22
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-B vrf SERVICE-BLUE subnet SUBNET-2
Example 3: Hierarchical Connectivity Model
This example is analogous to #1 above but applies the vSG grouping function to separate service VRFs (say, AMBER, BLUE and CRIMSON). This allows the user to create a hierarchy where the vSG corresponds to the superset (i.e., the union) of multiple VRFs that remain separate. The advantage of this approach compared to having a single merged ‘fat’ VRF is that keeping service VRFs separate can enable better granularity in assigning subnets/prefixes, policies or different vNETs:
CLI (network-admin@switch) > vsg-create name GROUP-C description VRF-UNION
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-C vrf SERVICE-BLUE type promiscuous
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-C vrf SERVICE-AMBER type promiscuous
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-C vrf SERVICE-CRIMSON type promiscuous
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-C vrf SERVICE-AMBER subnet SUBNET-1
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-C vrf SERVICE-BLUE subnet SUBNET-2
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-C vrf SERVICE-CRIMSON subnet SUBNET-3
The vsg-network-add enables full granularity of prefix sharing depending on the specific network requirements. If all current and future subnets have to be shared, then you can use these shortcuts instead:
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-C vrf SERVICE-AMBER subnet all
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-C vrf SERVICE-BLUE subnet all
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-C vrf SERVICE-CRIMSON subnet all
Example 4: Unidirectional Connectivity Model
This example is less common because it is more typical for traffic to flow bidirectionally and hence routing to be applied in both directions. However, it is possible that in some scenarios only unidirectional communication is required, for example, in certain service chaining cases.
To support this use case, you can configure certain VRFs to act only as traffic sources (hence not sharing subnets) and other VRFs to act only as traffic receivers (hence sharing subnets). In other words, in order to accommodate the unidirectional flow scenario, only partial subnet sharing can be configured like so:
CLI (network-admin@switch) > vsg-create name GROUP-E description UNIDIRECTIONAL-SHARING
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-E vrf RECEIVE type typepromiscuous
CLI (network-admin@switch) > vsg-vrf-add vsg-name GROUP-E vrf SOURCE promiscuous
CLI (network-admin@switch) > vsg-network-add vsg-name GROUP-E vrf RECEIVE subnet SUBNET-RCV
Furthermore, sharing of subsets is possible too by using the network keyword in vsg-network-add (say, there are two subnets, 100.1.1.0/24 and 101.1.1.0/24, but only four prefixes have to be shared respectively: 100.1.1.0/30 and 101.1.1.0/30):
CLI (network-admin@switch) > vsg-network-add vsg-name vsg1 vrf vrf1 network 100.1.1.0/30
CLI (network-admin@switch) > vsg-network-add vsg-name vsg1 vrf vrf2 network 101.1.1.0/30
CLI (network-admin@switch) > vsg-network-show
Switch vsg-name vrf vnet subnet network network_state
------ -------- ---- ---- ------ ------------ -------------
switch vsg1 vrf1 0:0 100.1.1.0/30 ok
switch vsg1 vrf2 0:0 101.1.1.0/30 ok