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



north
    keyboard_arrow_up
    keyboard_arrow_down
    description
    print
    feedback
    support
    business
    rss_feed
    south