Configuring vFlow for Network Traffic Filtering
Netvisor ONE vFlow incorporates a Pluribus technology used to define fabric-wide policies for line-rate control, manipulation and redirection of traffic flows.
Netvisor ONE implements vFlow objects in hardware that have no impact on the forwarding performance of the switch. vFlows can be applied to traffic flows regardless of the forwarding method or provisioning construct employed. As such, vFlow objects can be implemented for bridging, routing and extended bridging operations and as well for transparent forwarding services like Virtual Wire and vLE.
Netvisor ONE vFlow offers a versatile, programmable and distributed method for implementing security access control policies, security service insertion, flow monitoring and telemetry, quality of service and optimized flow-based forwarding.
Elements of a vFlow
Netvisor ONE identifies a vFlow object by a unique name and uses five elements:
Administrative scope and state
Implementation stage
Traffic flow filter
Forwarding action
Flow control
Administrative Scope and State
The administrative state of a vFlow object determines if you enable or disable the corresponding flow policy in the switch hardware, as defined by mutually exclusive keywords enable and no-enable. By default, Netvisor ONE enables newly created vFlow objects.
The administrative scope defines the set of switches in the fabric where you create the vFlow object and controlled by the keyword scope, which can have two possible values: fabric and local.
Fabric Scope
Netvisor ONE distributes a fabric-scoped vFlow as a single managed object distributed to all switches part of the Adaptive Cloud Fabric
A fabric-scoped vFlow can be modified concurrently on all switches of the fabric with a single CLI or API command, by referencing the unique name. You can disable the vFlow named example.FabricScope for the entire fabric. Netvisor ONE does not delete the object, but uninstalls the object from hardware tables. You must first create the vflow example.FabricScope and then modify the object. For example:
CLI network-admin@switch > vflow-create name example.FabricScope scope fabric no-enable
CLI network-admin@switch > vflow-modify name example.FabricScope scope fabric no-enable
Local Scope
Netvisor ONE defines a local-scoped vFlow as an object defined and instantiated on one switch.
To create a locally scoped vFlow, use the following command:
CLI network-admin@switch > vflow-create name name-string scope {local|fabric} table-name vflow-table name
For example,
CLI network-admin@switch > vflow-create name example.LocalScope scope local {filter}{action}
The table name is not mandatory and the default table is System-L1-L4-Tun-1-0
Implementation Stage
You may want to apply multiple policies in parallel or in series to a particular traffic flow, the vFlow construct provides two main attributes to control the sequential order of execution relative to other vFlows:
Hardware table
Precedence
Hardware Table
Netvisor ONE has multiple filter tables present along the internal flow hardware datapath. Netvisor ONE enables the vFlow by default and installs in the ingress filter table, but you can implement the vFlow in any other available table, although flow filtering, manipulation and redirection capabilities may be limited.
Figure 1: vFlow tables: packet forwarding stage and filter and action capabilities
Figure 2:Concatenation of vFlow hardware tables
 
Figure 2 describes the available hardware tables with the corresponding vFlow table-name value and how Netvisor ONE concatenates, allowing both cascading and parallel execution patterns. Figure 2 also highlights the datapath forwarding stage for each filter table and which tables Netvisor ONE always enables (in white) and which ones require manual enabling (in grey). The hardware table can be selected using the keyword table-name.
Configurable hardware tables can be displayed with the following command and Netvisor ONE disables optional tables by default:
CLI network-admin@switch > vflow-table-profile-show layout vertical
switch: techpub-accton-2
profile: system
hw-tbl: switch-main
enable: enable
flow-capacity: 768
flow-slices-needed: 2
flow-slices-used: 3
comment: System-L1-L4-flows
switch: techpub-accton-2
profile: npu-app
hw-tbl: npu-main
enable: enable
flow-capacity: 0
flow-slices-needed: 0
flow-slices-used: 0
comment: L1-L4-flows
switch: techpub-accton-2
profile: application
hw-tbl: switch-main
enable: disable
flow-capacity: 0
flow-slices-needed: 1
flow-slices-used: 0
comment: User-Application
switch: techpub-accton-2
profile: qos
hw-tbl: switch-main
enable: disable
flow-capacity: 0
flow-slices-needed: 1
flow-slices-used: 0
comment: QoS
switch: techpub-accton-2
profile: ipv6
hw-tbl: switch-main
enable: disable
flow-capacity: 0
flow-slices-needed: 1
flow-slices-used: 0
comment: IPv6
switch: techpub-accton-2
profile: pbr
hw-tbl: switch-main
enable: enable
flow-capacity: 0
flow-slices-needed: 0
flow-slices-used: 0
comment: PBR
 
 
* 
Informational Note: The capacity and availability of the hardware tables vary between switch models.
You can enable optional tables with the command vflow-table-profile-modify.
CLI network-admin@switch > vflow-table-profile-modify profile qos enable
When you enable optional hardware tables, Netvisor ONE allocates a minimum number of entries in the order of 256 vFlow objects. For maximum vFlow scalability, enable hardware tables only when necessary.
Monitoring the resource consumption of active hardware tables with the following command:
CLI network-admin@switch > vflow-table-show layout vertical
switch: techpub-accton-2
name: Egress-Table-1-0
id: 0:0
flow-max-per-group: 512
flow-used: 0
flow-tbl-slices: 1
capability: match-metadata
flow-tbl-bank:
flow-profile: system
switch: techpub-accton-2
name: System-L1-L4-Tun-1-0
id: 0:0
flow-max-per-group: 2048
flow-used: 49
flow-tbl-slices: 2
capability: set-metadata
flow-tbl-bank:
flow-profile: system
switch: techpub-accton-2
name: System-VCAP-table-1-0
id: 0:0
flow-max-per-group: 512
flow-used: 0
flow-tbl-slices: 1
capability: none
flow-tbl-bank:
flow-profile: system
switch: techpub-accton-1
name: Egress-Table-1-0
id: 0:0
flow-max-per-group: 512
flow-used: 0
flow-tbl-slices: 1
capability: match-metadata
flow-tbl-bank:
flow-profile: system
switch: techpub-accton-1
name: System-L1-L4-Tun-1-0
id: 0:0
flow-max-per-group: 2048
flow-used: 49
flow-tbl-slices: 2
capability: set-metadata
flow-tbl-bank:
flow-profile: system
switch: techpub-accton-1
name: System-VCAP-table-1-0
id: 0:0
flow-max-per-group: 512
flow-used: 0
flow-tbl-slices: 1
capability: none
flow-tbl-bank:
flow-profile: system
Precedence
When you implement two or more vFlow objects within the same hardware table, it may be necessary to enforce a particular evaluation order.
The keyword precedence can be used for this purpose as Netvisor ONE executes higher precedence vFlows first.
When a flow matches two or more vFlows with the same precedence, the corresponding vFlow actions are merged and executed altogether. When you create the vFlow, Netvisor ONE validates that the new object is consistent and can be merged with objects with the same precedence.
The precedence value is within a numerical range of 2 and 15, with 2 as the default value.
Filtering
The filter describes the traffic characteristics where the administrator intends to undertake a certain action.
You define the filter through an arbitrary set of matching qualifiers:
Operating at an OSI or Internet Protocol layer, and based on the packet header content,
or based on Netvisor ONE logical constructs, like vNET, distributed VRF, distributed bridge domain, or vFlow metadata.
Physical Layer
in-port — ingress physical interface or LAG interface identifier(s). Netvisor ONE accepts values as a single value, a dash-separated value range, or comma-separated list of values and ranges.
out-port — egress physical interface or LAG interface identifier. Netvisor ONE accepts values as a single value, a dash-separated value range, or comma-separated list of values and ranges. This out-port is applicable for Egress_table.
Data Link Layer
vlan — VLAN (Virtual LAN) identifier (IEEE 802.1q)
vxlan —VxLAN Network Identifier or VNI
ether-type — Ethertype
src-mac — Source MAC address
src-mac-mask — Mask for source MAC address
dst-mac — Destination MAC address for the vFlow
dst-mac-mask — Mask for destination MAC address
vlan-pri — Class of Service (CoS) or VLAN priority (IEEE 802.1p)
Internet Layer
src-ip — Source IP address for the vFlow
src-ip-mask — Mask for source IP address
dst-ip — Destination IP address
dst-ip-mask — Mask destination IP address
ttl — Packet time-to-live
proto — IP protocol
dscp — Differentiated Services Code Point (DSCP) for Quality of Service (QoS), in the range of 0 to 63
dscp-start — Start value for DSCP
dscp-end — End value for DSCP
tos — Type of Service (ToS) value for Quality of Service (QoS)
tos-start — Start value for Type of Service (ToS) range
tos-end — End value for Type of Service (ToS) range
Transport Layer
src-port — Source transport port
src-port-mask — Mask for source transport port
dst-port — Destination transport port
dst-port-mask — Mask for destination transport port
tcp-flags — Comma-separated list TCP flag values
User Defined Fields
udf-name[1-3] — Reference to a User Defined Field (UDF) object, and defines advanced multi-layer filtering. Up to 3 objects are supported.
udf-data[1-3] — Data value applied to the corresponding UDF object
udf-data[1-3]-mask — Mask value applied to the corresponding UDF object
Logical Filtering
metadata — Metadata tag value assigned to packets along the internal hardware forwarding path, which can be used to correlate different vFlow objects operating at different ingress and egress stages
bridge-domain — Logical abstraction of a data-link learning and forwarding domain, implemented using a combination of physical interfaces, VLANs and VNI
vrouter-name — Reference to an Internet layer VRF context defined on a local vRouter
vrf-name — Reference to an Internet layer distributed VRF context
vnet — Virtual Network (vNET) value, used for identifying traffic belonging to a logical network partition for multi-tenancy and network segmentation purposes
Forwarding Action
The forwarding action defines the switch behavior for traffic matching the vFlow filter. Depending on the use case, possible actions for the traffic flow include dropping, forwarding or customized forwarding, as well as redirection and replicating to the switch processor, to a physical port, or to an IP address destination.
Access Control
Providing security access control policies operating on high-speed distributed networks, the switch, employing low-cost high-capacity technology like ASIC Ternary Content Addressable Memory (TCAM), is the ideal point of insertion. With Pluribus Adaptive Cloud Fabric, high-performance security access control using a whitelist or blacklist approach can be implemented consistently across the entire network using fabric-wide vFlow policies.
In the context of securing network traffic with Access Control Lists (ACL), Netvisor ONE provides two vFlow actions:
action none — (default action) permit filtered traffic
action drop — block filtered traffic
When implementing access control policies using a blacklist approach, for example, approving all traffic by default and explicitly restricting certain traffic categories, Netvisor ONE can use certain vFlows and ACLs to provide a level of security.
 
Figure 3: Blacklist Topology Example
As an example, using Figure 3, you want to block HTTP traffic ingressing the switches in VLAN 10 going from the black host to the white host, while still permitting all other traffic. You can configure a vFlow for this purpose using the following parameters:
vFlow name ACL01
VLAN 10
TCP port 80
Source IP address 10.0.30.10
Destination IP address 192.168.0.40
Action drop
CLI network-admin@switch > vflow-create name ACL01 scope fabric vlan 10 src-ip 10.0.30.10 dst-ip 192.168.0.40 proto tcp dst-port 80 action drop
For maximum Access Control List scalability, the blacklist policy can be also implemented using the System-VCAP table and provide additional capacity based on the switch models.
Using this approach, Netvisor ONE drops blacklisted traffic at the pre-ingress stage and without consuming resources in the default ingress table.
 
Figure 4: Scaling the Blacklist using a Pre-ingress Filter
The following configuration code illustrates how to build the same blacklist example in the System-VCAP table.
CLI network-admin@switch > vflow-create name ACL01 scope fabric vlan 10 src-ip 10.0.30.10 dst-ip 192.168.0.40 proto tcp dst-port 80 action drop table-name System-VCAP-table-1-0
Implementing Whitelists
The Whitelist model consists of defining explicitly what network traffic Netvisor ONE allows and uses a default drop policy.
Figure 5: Whitelist Topology Example
Figure 5 uses an example similar to the Blacklist, you want to deny default traffic and approve traffic ingressing the switches on VLAN 10 for the following conditions:
Traffic between the black hosts
Traffic between the two subnets (clouds)
Secure Shell (SSH) traffic between the white hosts where one acts as a responder.
Create four fabric-scope vFlow objects, with the last one having the least (default) precedence and using the following parameters:
vFlow ACL01
Filter VLAN 10
Source IP address 10.0.31.4
Destination IP address 192.168.0.41
Forwarding Action none
Precedence 4
CLI network-admin@switch > vflow-create name ACL01 scope fabric vlan 10 precedence 4 src-ip 10.0.31.4 dst-ip 192.168.0.41
vFlow ACL02
Filter VLAN 10
Source IP address 10.0.31.128/28
Destination IP address 192.168.1.144/30
Forwarding Action none
Precedence 4
CLI network-admin@switch > vflow-create name ACL02 scope fabric vlan 10 precedence 4 src-ip 10.0.31.128 src-ip-mask 255.255.255.250 dst-ip 192.168.1.244 dst-ip-mask 255.255.255.252
vFlow ACL03
Filter VLAN 10
TCP port 22
TCP flags ACK
Source IP address 10.0.31.4
Destination IP address 192.168.0.40
Forwarding Action none
Precedence 4
CLI network-admin@switch > vflow-create name ACL03 scope fabric vlan 10 precedence 4 src-ip 10.0.31.4 dst-ip 192.168.0.40 proto tcp dst-port 22 tcp-flags ack
vFlow ACL104
Filter VLAN 10
Forwarding Action drop
Precedence default (2)
CLI network-admin@switch > vflow-create name ACL104 scope fabric vlan 10 action drop
For maximum Access Control List scalability, the whitelist policy can be implemented using the System-VCAP table and provide additional capacity based on the switch models.
Using this approach, Netvisor ONE examines Whitelisted traffic and labeled the traffic with an arbitrary metadata value at the pre-ingress stage, without consuming resources in the default ingress table. During next ingress stage, Netvisor ONE uses a single vFlow object with highest precedence to permit traffic already allowed at pre-ingress stage.
Figure 6:Scaling Whitelist ACLs Using a Pre-ingress Filter
Figure 7:Scaling Whitelist ACLs Using a Pre-ingress Filter
The following configuration code illustrates building the same Whitelist example using both System-VCAP and the default System-L1-L4 tables. Note the additional vFlow object, named ACL00, used to permit all vFlows in table System-VCAP.
vFlow ACL00
CLI network-admin@switch > vflow-create name ACL00 scope fabric metadata 10 precedence 5
vFlow ACL101
CLI network-admin@switch > vflow-create name ACL01 scope fabric vlan 10 precedence 4 src-ip 10.0.30.10 dst-ip 192.168.0.41 table-name System-VCAP-table-1-0 action set-metadata 10
vFlow ACL02
CLI network-admin@switch > vflow-create name ACL02 scope fabric vlan 10 precedence 4 src-ip 10.0.31.128 src-ip-mask 255.255.255.250 dst-ip 192.168.1.244 dst-ip-mask 255.255.255.252
vFlow ACL03
CLI network-admin@switch > vflow-create name ACL03 scope fabric vlan 10 precedence 4 src-ip 10.0.31.4 dst-ip 192.168.0.40 proto tcp dst-port 22 tcp-flags ack
vFlow ACL04
CLI network-admin@switch > vflow-create name ACL04 scope fabric vlan 10 action drop
Configuring vFlows for Analytics
A vFlow can be used to capture packets for analysis, and you can determine if the vFlow captures packets across the fabric or on a single switch. Netvisor ONE captures packets by forwarding them from the data plane of the switch to the control plane.
A flow that directs packets to the switch CPU can be configured to save packets to a file by enabling the log-packets parameter. The file uses a libcap compatible format so you can use programs like TCPdump and Wireshark to read the file. You export the file to clients using SFTP.
Packet capture data is available with switch or fabric scope. The pcap files are stored over NFS in the following locations:
/net/<ServerSw_Name>//global/flow/<Flow_Name>/switch/<Switch_Name>/pcap
/net/<ServerSw_Name>//<_Name>/flow/<Flow_Name>/
switch/<Switch_Name>/pcap
/net/<ServerSw_Name>//global/flow/<Flow_Name>/fabric/pcap
/net/<ServerSw_Name>//<_Name>/flow/<Flow_Name>/
fabric/pcap
Snooping only works if you use the parameters, copy-to-cpu or to-cpu. The copy-to-cpu parameter ensures that the data plane forwards the packets and sends a copy to the CPU. Use this parameter if you want traffic to flow through the switch. The to-cpu parameter doesn’t forward packets and interrupts traffic on the switch. To snoop all application flow packets of protocol type TCP, enter the following CLI commands at the prompt:
CLI network-admin@switch > vflow-create name snoop_all scope local proto tcp action copy-to-cpu
Then use the following command to display the output:
CLI network-admin@switch > vflow-snoop
switch: pleiades24, flow: snoop_all, port: 65, size: 66, time: 20:07:15.03867188
smac: 64:0e:94:28:00:fa, dmac: 64:0e:94:2c:00:7a, etype: ip
sip: 192.168.2.51, dip: 192.168.2.31, proto: tcp
sport: 42120, dport: 33399
 
switch: pleiades24, flow: snoop_all, port: 65, size: 184, time: 20:07:15.03882961
smac: 64:0e:94:28:00:fa, dmac: 64:0e:94:2c:00:7a, etype: ip
sip: 192.168.2.51, dip: 192.168.2.31, proto: tcp
sport: 42120, dport: 33399
 
switch: pleiades24, flow: snoop_all, port: 43, size: 66, time: 20:07:15.03893740
smac: 64:0e:94:2c:00:7a, dmac: 64:0e:94:28:00:fa, etype: ip
sip: 192.168.2.31, dip: 192.168.2.51, proto: tcp
sport: 33399, dport: 42120
 
To restrict the flows captured to TCP port 22, SSH traffic, create the following vFlow:
CLI network-admin@switch > vflow-create name snoop_ssh scope local action copy-to-cpu src-port 22 proto tcp vflow-add-filter name snoop_ssh
Then use the vflow-snoop command to display the results:
 
switch: pleiades24, flow: snoop_ssh, port: 41, size: 230, time: 10:56:57.05785917 src-mac: 00:15:17:ea:f8:70, dst-mac: f4:6d:04:0e:77:60, etype: ip src-ip: 10.9.11.18, dst-ip: 10.9.10.65, proto: tcp src-port: 22, dst-port: 62356
switch: pleiades24, flow: snoop_ssh, port: 41, size: 118, time: 10:56:57.05922560 src-mac: 00:15:17:ea:f8:70, dst-mac: f4:6d:04:0e:77:60, etype: ip src-ip: 10.9.11.18, dst-ip: 10.9.10.65, proto: tcp src-port: 22, dst-port: 62356
 
The optional parameter vflow-add-filter restricts the output of the vflow-snoop command to the packets matching the snoop_ssh flow definition.
To capture traffic packets for a flow across the entire fabric, you create a flow with the scope of fabric. To copy the packets to a pcap file, add the log-packets option:
vflow-create name fab_snoop_all scope fabric action copy-to-cpu port 22 log-packets yes
If you enable log-packets, the separate pcap files for all switches are available on any switch. In addition a consolidated pcap file is available that aggregates the packets from all switches in the entire fabric.
Support for vFlows and IPv6 Addresses
To add support for IPv6 addresses, you must modify the vFlow table profile, using the command, vflow-table-profile-modify.
CLI network-admin@switch > vflow-table-profile-modify profile ipv6 hw-tbl switch-main percent 10
For the changes to take effect, you must reboot the switch. To ensure the availability of the profile changes, use the vflow-table-show command:
CLI network-admin@switch > vflow-table-show
switch name flow-max-per-group flow-used flow-tbl-slices capability flow-profile
 
------------ --------------------- ------------------ --------- --------------- -------------- ------------
 
ursa-onvl-11 Egress-Table-1-0 256 0 2 match-metadata system
 
ursa-onvl-11 Egress-Table-v6-1-0 256 0 1 none egress-v6
 
ursa-onvl-11 IPv6-Table-1-0 1536 0 1 none ipv6
 
ursa-onvl-11 System-L1-L4-Tun-1-0 1536 57 2 set-metadata system
 
ursa-onvl-11 System-VCAP-table-1-0 512 1 1 none system