Implementing the vFlow Policies
Netvisor ONE allows you to apply multiple policies in parallel or in series to a particular traffic flow by providing the vFlow construct with two main attributes to control the sequential order of execution relative to other vFlows such as the hardware table and precedence.
The following command keywords enable this functionality:
- table-name − hardware vflow table name
- precedence − processing priority value
Hardware Table
Netvisor ONE provides multiple filter tables along the internal flow hardware data path. However, by default, the vFlow is installed in the ingress filter table, but allows you to optionally implement the vFlow in any other available table, although flow filtering, manipulation, and redirection capabilities may become limited. Figure 10-3 describes the available hardware tables with the corresponding vFlow table names and how the tables are concatenated, allowing both cascading and parallel execution policies.
Figure 10-3: Concatenation of vFlow Hardware Tables
Additionally, Figure 3 highlights the data-path forwarding stage for each filter table, where some tables are always enabled (displayed in white), while some tables require manual enabling (displayed in grey) such as the Application, QoS, PBR, and IPv6 tables. Use the table-name keyword to install or program the vFlow in the specified hardware table.
Table 10-1: Hardware Filter Tables with Descriptions
Hardware Filter Tables |
Description |
System-VCAP |
Where the system VCAP policies are defined at the pre-ingress stage |
System-L1-L4 |
Where the system ingress traffic filtering policies are defined for L2, L3, and L4 packet parameters at the ingress or ICAP table. All system rules are defined in ICAP |
Egress-Table |
Where the system egress policies are defined at the egress or ECAP table. Supports drop and forward actions. |
Application Table |
Where the user application level policies are defined. |
QoS Table |
Where the ACL policies are defined |
PBR Table |
Where the policy based routing policies are defined. For details, see the Configuring Policy-Based Routing section. |
IPv6 Table |
Where IPv6 policies are defined |
You can view the configurable hardware tables by using the command:
CLI (network-admin@leaf-1) > vflow-table-profile-show
profile hw-tbl enable flow-capacity flow-slices-needed flow-slices-used comment
----------- ----------- ------- ------------- ----------------- ---------------- ------------------
system switch-main enable 768 2 3 System-L1-L4-flows
application switch-main disable 0 1 0 User-Application
qos switch-main disable 0 1 0 QoS
ipv6 switch-main disable 0 1 0 IPv6
pbr switch-main enable 0 0 0 PBR
Note: The capacity and availability of the hardware tables vary between switch models.
The optional tables (in grey in Figure 10-3) are disabled by default. You can enable optional tables with the vflow-table-profile-modify command. For example, enable the qos table using the command:
CLI (network-admin@leaf-1) > vflow-table-profile-modify profile qos enable hw-tbl switch-main
You must reboot the switch or restart the nvOSd service for the settings to take effect. When you enable optional hardware tables, Netvisor ONE allocates a minimum number of entries in the order of 256 vFlow objects (the number of vflow objects varies based on the platform and the type of the table). For maximum vFlow scalability, enable hardware tables only when necessary. You can monitor the resource consumption of active hardware tables with the following command:
CLI (network-admin@leaf-1) > vflow-table-show
name flow-max-per-group flow-used flow-tbl-slices metadata flow-profile
--------------------- ------------------ --------- --------------- --------- ------------
Egress-Table-1-0 512 0 1 match system
System-L1-L4-Tun-1-0 2048 49 2 set,match system
System-VCAP-table-1-0 512 0 1 set 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. Use the keyword precedence to enforce the evaluation order as Netvisor ONE executes vFlows with higher precedence value first. See a sample configuration below:
Figure 10-4 displays the precedence or evaluation order for different vFlow objects. When a flow matches two or more vFlows with the same precedence, the corresponding vFlow actions are merged and executed together. 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. You cannot configure the evaluation order or precedence value beyond 15.
Figure 10-4: Evaluation Order for vFlow Objects with Different Precedence
When you create multiple vflow objects within the same hardware table without specifying the precedence value (default value being 2), Netvisor displays an error message about the vFlow conflicts. For example,
- Create a vFlow:
CLI (network-admin@Leaf1) > vflow-create name example_vflow1 scope fabric bw flow-class meter bw-max 2g
- Create a second vFlow:
CLI (network-admin@Leaf1) > vflow-create name example_vflow2 scope fabric bw flow-class meter bw-max 5g src-ip 192.168.20.1
vflow-create: Flow conflicts with Flow example_vflow1, ID68: specify fields to make flows mutually exclusive or change the flow precedence
The error message is generated because the vFlow configurations conflict with each other. To differentiate between the two vflows, assign a different precedence to example_vflow2:
CLI (network-admin@Leaf1) > vflow-create name example_vflow2 scope fabric bw flow-class meter bw-max 5g src-ip 192.168.20.1 precedence 5
Managing Traffic Classes with vFlow
The vFlow classes indicate the priority assigned to a packet within a switch for internal processing and prioritization and specifies a service type: traffic metering or traffic shaping, bandwidth guarantee. Netvisor ONE supports two types of vFlow classes:
- System Flow Classes
- Metered flow class, where the traffic is not allowed to exceed a set rate.
- Guaranteed bandwidth flow class, where the vFlow object guarantees a certain bandwidth and the switch priority is 9.
- Lossless flow class, where drop action is unavailable and the switch priority is 10.
- User Defined Flow Classes
- Flow classes created by users with priorities between 1 and 8
- Used for traffic metering
- Used for traffic shaping and bandwidth guarantee