Virtual routing and forwarding (VRF) allows a layer 3 networking device to run multiple instances of a routing table simultaneously and independently. On supported Network Security appliances, enabling layer 3 mode automatically maps each monitoring port pair to a distinct network namespace called a VRF namespace. For each port pair, packets are forwarded on the egress interface using the default gateway and route table that you configure for the VRF namespace. Taken together, a VRF namespace and the routing information you configure form a VRF instance.
Limitations
The following limitations apply to layer 3 forwarding using VRF instances:
IPv6 routing is not supported for interfaces in a VRF instance.
DHCP is not supported for interfaces in a VRF instance.
Cross-VRF routing is not supported.
Cross-pair forwarding is not supported.
Inline forwarding is limited to the port pair.
HA functionality is not supported.
Port mirroring and SSL Intercept mirroring are not supported.
Note
If SSL Intercept is enabled, you can change layer 2 to layer 3 or vice versa in a supported appliance.
Appliances that support VRF and network namespaces
Layer 3 forwarding using VRF and network namespaces is supported on the following Network Security appliances.
|
|
A Network Security virtual appliance is an instance of a Network Security appliance system image and does not have an MVX engine. It functions as a sensor, submitting suspect objects to an MVX cluster for detonation and analysis. For information about deploying and working with virtual appliances, see the Trellix Device Deployment Guide on the Trellix documentation portal at https://docs.trellix.com/.
A layer 3-capable virtual appliance on an EXSi host, KVM server, or Hyper-V server operates in layer 2 mode by default, and you must use a CLI command to explicitly enable layer 3 mode in order to support layer 3 forwarding with VRF namespaces.
A layer 3-capable virtual appliance in a cloud deployment, including on an AWS or Azure instance, always operates in layer 3 mode.
Mapping of port pairs to network namespaces
When you enable layer 3 mode on a supported Network Security virtual appliance, the appliance statically maps the monitoring port pairs (pether3 through pether10) to fixed network namespaces (vrfA, vrfB, vrfC, and vrfD) called VRF namespaces:
Network Security virtual appliance ports | Network namespace | |
|---|---|---|
Layer 2 mode | Layer 3 mode | |
Management Ports | ||
ether1 | vrf0 | |
pether2 | vrf0 | |
Monitoring Port Pairs | ||
pether3, pether4 | vrf0 | vrfA |
pether5, pether6 | vrf0 | vrfB |
pether7, pether8 | vrf0 | vrfC |
pether9, pether10 | vrf0 | vrfD |
Within a VRF namespace, you can configure a default gateway and route table to forward packets on the egress interface. By default, egress interfaces are on pether4, pether6, pether8, and pether10. You can configure pether3, pether5, pether7, or pether9 to be the egress interface.
Configuring VRF instances for layer 3 forwarding
This procedure describes how to configure VRF instances to support layer 3 forwarding. In the example, the appliance management port ether1 has already been configured with the default gateway address 10.14.52.1 and static route 10.14.52.0 /22.
Prerequisites
Administrator or Operator access to the supported Network Security appliance.
The appliance is operating in layer 3 mode.
The appliance is deployed in inline mode.
One or more monitoring port pairs is connected to a LAN-facing switch.
Go to CLI configuration mode:
hostname > enable hostname # configure terminal
If the appliance is on an EXSi host, KVM server, or Hyper-V server, enable layer 3 mode. (If the appliance is in a cloud deployment, layer 3 mode is always enabled.)
hostname (config) # policymgr layer3-mode enable hostname (config) # show policymgr layer3-mode status
To disable layer 3 mode, use the
no policymgr layer3-mode enablecommand.Verify that monitoring ports are mapped to VRF namespaces. The following commands list the VF namespaces, indicating that the appliance is operating in layer 3 mode:
hostname (config) # ip default-gateway vrf vrfA vrfB vrfC vrfD
hostname (config) # ip route vrf vrfA vrfB vrfC vrfD
hostname (config) # show vrf config Netns: vrfA vrfB vrfC vrfD
The following commands show that pether3 and pether4 are mapped to network namespace vrfA. In this example, static routes have not yet been configured for vrfA.
hostname (config) # show interfaces pether3 brief Interface pether3 status: Comment: Admin up: yes Link up: yes DHCP running: no IP address: Netmask: IPv6 enabled: no Speed: 10000Mb/s Duplex: full Interface type: ether Interface ifindex: 23 Interface source: physical Interface namespace:vrfA MTU: 1600 HW address: 00:50:56:01:2F:A1
hostname (config) # show interfaces pether4 brief Interface pether4 status: Comment: Admin up: yes Link up: yes DHCP running: no IP address: Netmask: IPv6 enabled: no Speed: 10000Mb/s Duplex: full Interface type: ether Interface ifindex: 24 Interface source: physical Interface namespace:vrfA MTU: 1600 HW address: 00:50:56:01:2F:A2
For each VRF instance connected to a LAN-facing switch, configure a default gateway. Use the
ip default-gateway vrf <netNamespace> <nextHop> [portName]command, where the command-line parameters are as follows:<netNamespace>The network namespace for the VRF instance: vrfA, vrfB, vrfC, or vrfD
<nextHop>The IPv4 address of the next-hop interface.
<portName>The optional monitoring port name (such as pether3).
If you do not specify a monitoring port, the default gateway address you specify is set for the default egress port (pether4, pether6, pether8, or pether10) associated with the VRF instance.
You can use the
no ip default-gateway vrf <netNamespace>command to delete the default gateway for a VRF instance.This example illustrates both forms of the command (with and without the optional
<portname>) used to configure the default gateway for vrfC and vrfD:hostname (config) # ip default-gateway vrf vrfC 192.168.225.3 hostname (config) # ip default-gateway vrf vrfD 192.168.227.5 pether9
Note
Because the first command does not specify a vrfC monitoring port, the specified default gateway address is configured for the default egress port pether8. Because the second command specifies the vrfD monitoring port pether9, pether9 will be used as the egress interface.
List the default gateways by using the
show ip default-gateway [static]command.This example shows the default gateway addresses configured for vrfC and vrfD:
hostname (config) # show ip default-gateway static Configured default gateway: 10.14.52.1 192.168.225.3 (netns: vrfC) 192.168.227.5 (netns: vrfD)
This example shows that the default gateway specified for vrfD was assigned to pether9 instead of the default egress port (pether10):
hostname (config) # show ip default-gateway Active default gateways: 192.168.225.3 (interface: pether8, netns: vrfC) 10.14.52.1 (interface: ether1) 192.168.227.5 (interface: pether9, netns: vrfD)
For each VRF instance connected to a LAN-facing switch, configure a route table. To add a static route, use the
ip route vrf <netNamespace> <nextHop> [portName]command, where the command-line parameters are as follows:<netNamespace>The network namespace for the VRF instance: vrfA, vrfB, vrfC, or vrfD
<nextHop>The IPv4 address of the next-hop interface, specified in the following format:
<networkPrefix> {<netmask> | /<maskLength>}Example:
192.168.11.20 255.255.255.0Example:
192.168.11.20 /24<portName>The optional monitoring port name (such as pether3).
If you do not specify a monitoring port, the next-hop address you specify is set for the default egress port (pether4, pether6, pether8, or pether10) associated with the VRF instance.
You can use the
no ip route vrf <netNamespace> <nextHop> [portName]command to remove the specfied route from a VRF instance.This example illustrates both forms of the command (with and without the optional
<portname>) used to add routes to vrfC and vrfD:hostname (config) # ip route vrf vrfC 192.168.225.0 /24 hostname (config) # ip route vrf vrfD 10.2.7.20 /24 pether9 hostname (config) # ip route vrf vtfD 104.244.42.0 /24 pether9 hostname (config) # ip route vrf vtfD 192.168.227.0 /24 pether9
Note
Because the first command does not specify a vrfC monitoring port, the specified route is added to the default egress port pether8. Because the other commands specify the vrfD monitoring port pether9, pether9 will be used as the egress interface.
Verify the static routes for the VRF instances.
This example displays all static routes configured on the appliance
hostname (config) # show ip route static Destination Mask Gateway Interface Table default 0.0.0.0 10.14.52.1 main Destination Mask Gateway Interface Table default 0.0.0.0 192.168.225.3 main default 0.0.0.0 192.168.227.5 main 10.2.7.20 255.255.255.255 192.168.227.2 main 104.244.42.0 255.255.255.0 192.168.227.2 main
This example displays all static routes and default gateways configured on the appliance:
hostname (config) # show ip route Special routes inside name space Destination Mask Gateway Interface Source Netns Table default 0.0.0.0 192.168.225.3 pether8 static vrfC main 192.168.224.0 255.255.255.0 0.0.0.0 pether7 interface vrfC main 192.168.225.0 255.255.255.0 0.0.0.0 pether8 interface vrfC main default 0.0.0.0 10.14.52.1 ether1 static vrf0 main 10.14.52.0 255.255.252.0 0.0.0.0 ether1 interface vrf0 main default 0.0.0.0 192.168.227.5 pether9 static vrfD main 10.2.7.20 255.255.255.255 192.168.227.2 pether9 static vrfD main 104.244.42.0 255.255.255.0 192.168.227.2 pether9 static vrfD main 192.168.226.0 255.255.255.0 0.0.0.0 pether10 interface vrfD main 192.168.227.0 255.255.255.0 0.0.0.0 pether9 interface vrfD main 192.168.222.0 255.255.255.0 0.0.0.0 pether5 interface vrfB main 192.168.223.0 255.255.255.0 0.0.0.0 pether6 interface vrfB main 192.168.220.0 255.255.255.0 0.0.0.0 pether3 interface vrfA main 192.168.221.0 255.255.255.0 0.0.0.0 pether4 interface vrfA main
Save your changes.
hostname (config) # write memory