Forwarding Action in vFlow Filters
The forwarding action defines the switch behavior for traffic that matches with the vFlow filter. Depending on the use case, the possible actions for the traffic flow include:
- Dropping of filtered traffic
- Regular or customized forwarding of filtered traffic
- Redirection or replication of filtered traffic to a switch processor, a physical port, or to an IP address destination.
Access Control
To provide security access control policies that operate on high-speed distributed networks, the switch, which employs 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 blacklist or whitelist approach can be implemented consistently across the entire network using fabric-wide vFlow policies.
Netvisor ONE provides several vFlow actions for securing the network traffic with Access Control Lists (ACL) as described in the table :
Table 12-2: vFlow Actions Supported in Netvisor ONE
Action |
Description |
action none |
Traffic is forwarded (permit filtered traffic) This is the default action. |
action drop |
Traffic matching the filter is removed from traffic path |
action to-port |
Traffic matching the filter is forwarded to specified ports |
action to-cpu |
Traffic matching the filter is sent to CPU only |
action trap |
Traffic matching the filter is trapped to CPU |
action copy-to-cpu |
Traffic matching the filter is forwarded normally and copied to CPU, |
action copy-to-port |
Traffic matching the filter is forwarded normally and copied to port |
action check |
Traffic matching the filter is verified |
action setvlan |
VLAN ID is set for the traffic matching the filter |
action add-outer-vlan |
New outer VLAN tag is added to the traffic matching the filter |
action set tpid |
Traffic matching the filter is tagged with the provided TPID |
action to-port-set-vlan |
Traffic matching the filter is sent to provided port on specified VLAN |
action tunnel-pkt |
Tunnel frame is added for incoming traffic |
action set-tunnel-id |
Tunnel ID is set for the traffic matching the filter |
action to-span |
Traffic matching the filter is forwarded to the span ports |
action cpu-rx |
Stress test for cpu-rx |
action cpu-rx-tx |
Stress test for cpu-rx-tx |
action set-metadata |
Metadata is set for the traffic matching the filter |
action set-dscp |
DSCP value is set for the traffic matching the filter |
action decap |
Decap is set for the traffic matching the filter |
action set-dmac |
Destination MAC is set for traffic matching the filter |
action to-next-hop-ip |
The next hop IP address for traffic redirection |
action set-dmac-to-port |
Destination MAC is set and it is forwarded to port specified |
action to-ports-and-cpu |
Traffic matching the filter is forwarded to ports and CPU |
action set-vlan-pri |
Set VLAN priority for traffic matching the filter |
action tcp-seq-offset |
TCP sequence offset is set for traffic matching the filter |
action tcp-ack-offset |
TCP acknowledgment offset is set for traffic matching |
action l3-to-cpu-switch |
Redirects Layer3 packets to CPU |
action set-smac |
Source MAC is set for the traffic matching the filter |
action drop-cancel-trap |
Traffic matching the flow is dropped and not trapped |
action to-ecmp-group |
ECMP group for traffic redirection |
action redirect-to-vrouter |
Redirect packets to vrouter |
set-dscp |
DSCP value is set for the traffic matching the filter |
decap |
Decap is set for the traffic matching the filter |
set-dmac |
Destination MAC is set for traffic matching the filter |
to-next-hop-ip |
The next hop IP address for traffic redirection |
set-dmac-to-port |
Destination MAC is set and it is forwarded to |
to-ports-and-cpu |
Traffic matching the filter is forwarded to ports and CPU |
set-vlan-pri |
Set VLAN priority for traffic matching the filter |
tcp-seq-offset |
TCP sequence offset is set for traffic matching the filter |
tcp-ack-offset |
TCP ack offset is set for traffic matching the filter |
l3-to-cpu-switch |
Redirects l3 packets to CPU |
set-smac |
Source MAC is set for the traffic matching the filter |
drop-cancel-trap |
Traffic matching the flow is dropped and not trapped |
to-ecmp-group |
ECMP group for traffic redirection |
redirect-to-vrouter |
Redirect packets to vrouter |
Typically the action resolution process gathers the actions from each slice match and decides on a collective action. However, when there is an action conflict, the collective action is not possible and the drop action takes higher priority. With the implementation of virtual slide mapping feature, action resolution is handled by the precedence or priority value.
Understanding Blacklist Policy
You can implement access control policies using a blacklist approach, that is, approving all traffic by default and explicitly restricting certain traffic categories.
Figure 12-7 - Blacklist Topology Example
For example, as shown in Figure 12-7, you want to block HTTP traffic ingressing the switches in VLAN 10 going from the black host to the white host, while permitting all other traffic. Use the following parameters to configure a vFlow for this purpose:
- vFlow name: ACL01
- Filter: VLAN 10
- TCP port: 80
- Source IP address: 10.0.30.10
- Destination IP address: 192.168.0.40
- Forwarding 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 ACL scalability, the blacklist policy can be also implemented using the System-VCAP table (see Figure 12-8) and provide additional capacity based on the switch models. In this approach, Netvisor ONE drops the blacklisted traffic at the pre-ingress stage without utilizing the resources in the default ingress table.
Figure 12-8: Scaling the Blacklist ACLs using a Pre-Ingress Filter
Understanding Whitelist Policy
Contrary to the blacklist policy, the Whitelist model explicitly defines network traffic that is allowed and uses a default permit policy. Figure12- 9 illustrates an example where 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 the host below (10.0.31.4) acts as a responder.
Figure 12-9: Whitelist Topology Example
To implement this policy, create four fabric-scoped vFlow objects, with the last one (vFlow ACL04) having the least (default) precedence and by using the following parameters:
- vFlow ACL01
- Filter: VLAN 10
- Source IP address: 10.0.30.10
- 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.30.10 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.144 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 ACL04
- Filter: VLAN 10
- Forwarding Action: drop
- Precedence: 2 (default)
CLI (network-admin@switch) > vflow-create name ACL04 scope fabric vlan 10 action drop
For maximum ACL scalability, you can implement the whitelist policy using the System-VCAP table and provide additional capacity for vFlow objects based on the switch models.
In this approach, Netvisor ONE examines Whitelisted traffic and labels 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. You can also build the same Whitelist policy using both System-VCAP and the default System-L1-L4 tables as shown in Figure 12-10.
Figure 12-10: Scaling Whitelist ACLs Using a Pre-ingress Filter