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 Unified 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 
(block filtered traffic)

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, 
this action does not affect the traffic policy, but creates a copy of 
the policy to the 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 
the filter  

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 
port specified

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:


  1. 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


  1. 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


  1. 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



  1. 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



north
    keyboard_arrow_up
    keyboard_arrow_down
    description
    print
    feedback
    support
    business
    rss_feed
    south