Configuring vSG Route Sharing
In certain configurations it can be convenient to implement the automatic sharing of one or more routes in accordance with the vSG rules. For example, a firewall (or a DC gateway or another similar device) may be a common next hop for all the end devices across the entire vSG. Such device (or devices) is typically deployed to enable shared service(s): in the case of a firewall, it supports external connectivity, security policies, etc.
In these configurations with shared services, it can be convenient to add routes directly to the vSG so that they get automatically shared to all the members based on the vSG rules chosen by the user.
Starting from Netvisor ONE release 6.1.0 a new capability is introduced to add routes to the vSG, which can save significant configuration overhead especially in large vSG configurations.
For example, let’s consider a scenario in which there are two isolated VRFs (blue and red) that need to communicate through a firewall. (For the sake of simplicity, the example only uses two VRFs but it can be scaled to N VRFs making the new automation even more advantageous.)
The firewall is in a subnet associated with a promiscuous VRF called transit. blue and red are isolated VRFs that share one subnet each (10.1.1.0/24 and 20.1.1.0/24) with transit, which uses a third subnet. In particular, the firewall is the actual common service to be shared in such subnet and uses the address 30.1.1.2.
This is the corresponding configuration of the vSG:
CLI (network-admin@switch) > vrf-create name blue
CLI (network-admin@switch) > vrf-create name red
CLI (network-admin@switch) > vrf-create name transit vrf-gw 30.1.1.2
CLI (network-admin@switch) > subnet-create name vlan_10 vrf blue vlan 10 network 10.1.1.0/24 anycast-gw-ip 10.1.1.1
CLI (network-admin@switch) > subnet-create name vlan_20 vrf red vlan 20 network 20.1.1.0/24 anycast-gw-ip 20.1.1.1
CLI (network-admin@switch) > subnet-create name vlan_30 vrf transit vlan 30 network 30.1.1.0/29 anycast-gw-ip 30.1.1.1
CLI (network-admin@switch) > vsg-create name vSG-1 description "Firewall Access"
CLI (network-admin@switch) > vsg-vrf-add name vSG-1 vrf blue type isolated
CLI (network-admin@switch) > vsg-vrf-add name vSG-1 vrf red type isolated
CLI (network-admin@switch) > vsg-vrf-add name vSG-1 vrf transit type promiscuous
CLI (network-admin@switch) > vsg-network-add name vSG-1 vrf blue subnet vlan_10
CLI (network-admin@switch) > vsg-network-add name vSG-1 vrf red subnet vlan_20
CLI (network-admin@switch) > vsg-network-add name vSG-1 vrf transit network 30.1.1.2/32
In this example, the need is to automatically share across all the VRFs in the vSG the default gateway route (0.0.0.0/0) pointing to the firewall's IP address (30.1.1.2/32).
That could be achieved by manually configuring in both blue and red the same route by using the vrf-route-add command twice.
Alternatively and more conveniently, starting from release 6.1.0 a single command, vsg-route-add, can be used to share the default route across all of the VRFs that are part of a vSG, like so (by virtue of the promiscuous nature of transit):
CLI (network-admin@switch) > vsg-route-add vsg-name vSG-1 vrf transit network 0.0.0.0/0 gateway-ip 30.1.1.2
Note: The gateway-ip address (i.e., the next hop) in the vSG route must be shared from the promiscuous VRF prior to the vsg-route-add command. Hence the sequence of commands is in the order displayed above with the network highlighted in bold. If by mistake this requirement is not met, the vsg-route-add command will produce an error message: network 30.1.1.2 not leaked from vrf transit
Note: The network in the vSG route should not overlap with local subnets or shared prefixes. For example, the command: vsg-route-add name vsg1 vrf transit network 10.1.1.2/30 gateway-ip 30.1.1.2 produces the error message: vsg-route-add: !! Overlapping subnet found for network 10.1.1.2 in vrf blue because 10.1.1.2 overlaps with the local subnet of VRF blue.
To verify that a vSG route was correctly added, you can use the vsg-route-show command:
CLI (network-admin@switch) > vsg-route-show
switch name vrf vnet network gateway-ip
------ ---- ------- ---- --------- ----------
switch vsg1 transit 0:0 0.0.0.0/0 30.1.1.2
Moreover, to verify the entire vSG configuration the following commands can be used:
CLI (network-admin@switch) > subnet-show
switch name scope vlan vrf network anycast-gw-ip packet-relay forward-proto state enable
------ ------- ----- ---- ------- ----------- ------------- ------------ ------------- ----- ------
switch vlan_10 local 10 blue 10.1.1.0/24 10.1.1.1 disable dhcp ok yes
switch vlan_20 local 20 red 20.1.1.0/24 20.1.1.1 disable dhcp ok yes
switch vlan_30 local 30 transit 30.1.1.0/24 30.1.1.1 disable dhcp ok yes
CLI (network-admin@switch) > vsg-vrf-show
switch vsg-name vnet vrf type
------ -------- ---- ------- -----------
switch vsg1 0:0 blue isolated
switch vsg1 0:0 red isolated
switch vsg1 0:0 transit promiscuous
CLI (network-admin@switch) > vsg-network-show
switch vsg-name vrf vnet subnet network network-state
------ -------- ------- ---- ------- ----------- -------------
switch vsg1 blue 0:0 vlan_10 10.1.1.0/24 ok
switch vsg1 red 0:0 vlan_20 20.1.1.0/24 ok
switch vsg1 transit 0:0 vlan_30 30.1.1.2/32 ok
Once added, a vSG route can also be removed with the corresponding vsg-route-remove command:
CLI (network-admin@switch) > vsg-route-remove name vsg1 vrf transit network 0.0.0.0/0 gateway-ip 30.1.1.2