• Tap Aggregation – Filtering with Port ACLs

Print Friendly, PDF & Email


1) Introduction


This article details the filtering of traffic across the Tap Aggregator by using port ACL. The filters allow granular selection of Layer2, Layer3, and Layer4 traffic on a per-port basis.

The following other features might also be of interest, but are out of scope of this article:


2) Filtering Overview


The well known MAC and IP Access-List filtering is used to filter traffic in Tap Aggregation mode, just like it does in switching mode. The Layer2/3/4 ACLs can be applied

  • on Tap ports, ingress
  • on Tool ports, egress



# IP ACL – Filter IP traffic sourced from

switch(config)#ip access-list remove5network
switch(config-acl-remove5network)#deny ip any log
switch(config-acl-remove5network)#permit ip any any


# MAC ACL – Filter traffic with a VLAN tag of 200

switch(config)#mac access-list remove200
switch(config-mac-acl-remove200)#deny vlan 200 4095 any any
switch(config-mac-acl-remove200)#permit any any


# Apply the ACL filtering on the Tap port, ingress

switch(config-if-Et1)#ip access-group remove5network in 
switch(config-if-Et1)#mac access-group remove200 in


Note that both a MAC ACL and an IP ACL can be active and effective at the same time on an interface.

Some ACLs can also be applied egress, on the tap tool. Check the platform support in the feature matrix of the the release notes.


3) Multi-tier Filtering


The Arista EOS Tap Aggregation mode offers a multitude of flexible classification and filtering options; they can all be combined to work at the same time. This present article’s scope is ACL filtering, but to illustrate how and where it fits among the other DANZ Tap Aggregations features, the following details how those different features work together.


3.1 Classification and Filtering features


The following list the classification and filtering features available in DANZ Tap Aggregation mode (as of 4.14.1F, date of writing)


  • Port ACL
    • Ingress MAC ACL, including VLAN and Q-in-Q
    • Ingress IP ACL, including VLAN and Q-in-Q
    • Egress IP ACL, including VLAN and Q-in-Q
  • VLAN list
    • Ingress VLAN filter list
    • Egress VLAN filter list
  • Traffic Steering (Policy-based, per-flow), ingress
  • Identity tag, ingress
  • Native VLAN mapping, ingress
  • Tap port default group, ingress


All those features can work in combination.

Note: The scope of this document is Port ACL only.


3.2) Classification and Filtering Decision Tree


The below workflow diagram represent the filtering decision tree, to illustrate what takes priority on Port ACL.

The follow diagram presents the CLI configuration for such combination of multi-tier filtering.


The sections in green are those involving the Port ACLs.


Example of multi-tier filtering:






4.1) IP ACLs are Layer2, 3, and 4


While traditional IP access-lists filter at Layer3 and 4, some Arista platforms, along with the augmented DANZ capability, also support Layer2 VLAN filtering. For example, the following IP ACL filters on VLAN ID, IP subnets, and Layer4 port.

switch(config)#ip access-list myL234Acl
switch(config-acl-myL234Acl)#deny vlan 10 0x000 ip host any
switch(config-acl-myL234Acl)#deny vlan 11 0x000 tcp host eq 57 host 
switch(config-acl-myL234Acl)#permit ip any any


4.2) Q-in-Q and inner VLAN


By default, the vlan <VLAN ID> matches against the outermost 802.1Q header. In case of Q-in-Q, it would be the S-VLAN.

You have the option to match an inner VLAN (C-VLAN) with the keyword inner, as follows:

deny vlan inner 123 0x000 ip host any


4.3) VLAN mask


4.3.1) About ACL Masks


Notice in the previous example that the VLAN ID is follow by a mask. That mask is a wildcard mask (inverse), where:

  • 0 bits require an exact match
  • 1 bits match on any value

This is standard to IP ACL match definitions, where:

  • a host can be matched with “” (meaning “”)
  • a subnet can be matched with “ 0.0.255” (meaning “”), the last octet matching against 1111 1111.

VLAN masks work the same way:

  • A VLAN 1234 can be matched with “1234 0x000”


4.3.2) About Hexadecimals


Per the IEEE Ethernet 802.1Q standard, VLAN IDs are 12 bits long (0-4095 in value), which can be represented as 3 hexadecimals.

A a reminder, in hexadecimal (base 16), each for the 16 hex values (0-9,A-F) is represented by 4 bits : from 0000 (=0), 0001(=1), etc up to 1111 (=F).

Also remember that the hexadecimal values, is standardly represented after an “0x” prefix (in the literal term) to indicate that the values are not decimal but hexadecimal. For example, “FFF” is represented “0xFFF” in hexadecimal, otherwise “FFF” alone might be misinterpreted as ASCII (just alphanumerical characters).

The 12 bits VLAN ID mask is therefore easily represented as a hexadecimal, rather than a long binary chain.


4.3.3) VLAN Mask Examples


The following illustrate several examples of VLAN masks in hexadecimal, and details their meaning and use.


0x000 matches ONLY the specific value


vlan 10 0x000

This is equivalent, in binary to 0000 0000 1010 match 0000 0000 0000

Result: 0000 0000 1010 (only)

Only the VLAN ID 10 can match that ACL entry



0xFFF matches ANY value


vlan 10 0xFFF

This is equivalent, in binary to 0000 0000 1010 match xxxx xxxx xxxx xxxx

Result: xxxx xxxx xxxx xxxx (any)

Any VLAN ID (from 0 to 4095) would match that ACL entry


0x001 matches 2 VLAN values


vlan 10 0x001

This is equivalent, in binary to 0000 0000 1010 match 0000 0000 000X

Results: 0000 0000 1010, 0000 0000 1011 (the last bit can be either 0 or 1)

Both VLAN ID 10 and 11 would match that ACL entry.



0x00A matches discontiguous VLAN values


vlan 10 0x00A

Remember that 0xA (hexa) = 10 (decimal) = 1010 (binary). Also remember that it is a mask, not a range.

This is equivalent, in binary to 0000 0000 1010 match 0000 0000 X0X0


0000 0000 0000 = 0

0000 0000 0010 = 2

0000 0000 1000 = 8

0000 0000 1010 = 10

VLANs 0, 2, 8, and 10, would all four match that ACL entry.

VLANs 1, 3-7, 9, 11-4095 would not match the ACL entry.



How to match VLAN ranges ?

Similarly to subnet wildcard masks, you cannot specify a range with VLAN masks. For example, you cannot specify hosts from to with masks.

However, you can manually construct such range.

For example, how to match VLAN 10-20 (range of 10 VLANs) ? This is the same principle as if you wanted to match hosts to…

We want to match :

  • 0000 0000 1010  to  0000 0000 1011 (= 10 to 11) → vlan 10 0x001 (mask is 0000 0000 000x)
  • 0000 0000 1100  to  0000 0000 1111 (= 12 to 15) → vlan 12 0x003 (mask is 0000 0000 00xx)
  • 0000 0001 0000  to  0000 0000 0011 (= 16 to 19) → vlan 16 0x003 (mask is 0000 0000 00xx)
  • 0000 0001 0100                                    (= 20)          → vlan 20 0x000 (mask is 0000 0000 0000)


The range [10-20] must be composed of 4 entries. The below represent the most optimal configuration (fewest amount of line):

ip access-list permitVLAN10to20
  permit vlan 10 0x001 ip any any
  permit vlan 12 0x003 ip any any
  permit vlan 16 0x003 ip any any
  permit vlan 20 0x000 ip any any


If you do not have too many VLANs, you might find it easier and clearer to explicitly define each VLAN individually (mask 0x000 for each), especially if you are not comfortable with binary and hexadecimal, although it makes the configuration lengthier. The example below shows atomic definitions for a VLAN range of [10-20]:

ip access-list permitVLAN10to20
  permit vlan 10 0x000 ip any any
  permit vlan 11 0x000 ip any any
  permit vlan 12 0x000 ip any any
  permit vlan 13 0x000 ip any any
  permit vlan 14 0x000 ip any any
  permit vlan 15 0x000 ip any any
  permit vlan 16 0x000 ip any any
  permit vlan 17 0x000 ip any any
  permit vlan 18 0x000 ip any any
  permit vlan 19 0x000 ip any any
  permit vlan 20 0x000 ip any any


4.4) ACL programming mode

First, remember that you are taking filtering actions on a Tap Aggregator (NPB), rules are therefore not impacting the production traffic but only the tapped/SPAN/mirroring traffic captured. However that monitoring traffic might be critical to your business.

By default, ACL reprogramming might cause a short drop of traffic.

In Tap Aggregation mode, you should consider the trade off between allowing all traffic during ACL updates based on your tolerance for loss of interesting traffic.

  • Why dropping ? (default)
    • To not overload your tool ports, if you filter a large amount of traffic, and filters are implemented to reduce the amount of traffic.
    • To not receive unwanted traffic (may be undesired at the destination, potentially unsafe)
  • Why permitting ?
    • You know that you would not suffer congestion (cause of drops) or security issues towards the tools
    • Receiving the packets is absolutely primordial during ACL changes
  • Workaround: Change live ACLs only during maintenance windows

To allow the permit ACL update mode, configure:

switch(config)#hardware access-list update default-result permit


When enabled, all traffic will be permitted during ACL reprogram and guaranteed to egress the default group if configured.

When disabled traffic will egress default group during ACL update but may be dropped, depending on traffic load, number of ACLs and duration of the update process




Get every new post on this blog delivered to your Inbox.

Join other followers: