- 1) Introduction
- 2) Filtering Overview
- 3) Multi-tier Filtering
- 4) VLAN ID in IP ACL
- 4.1) IP ACLs are Layer2, 3, and 4
- 4.2) Q-in-Q and inner VLAN
- 4.3) VLAN mask
- 4.4) ACL programming mode
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 192.168.5.0/24
switch(config)#ip access-list remove5network switch(config-acl-remove5network)#deny ip any 192.168.5.0/24 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) VLAN ID in IP ACL
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 126.96.36.199 any switch(config-acl-myL234Acl)#deny vlan 11 0x000 tcp host 10.0.0.1 eq 57 host 188.8.131.52 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 184.108.40.206 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 220.127.116.11 can be matched with “18.104.22.168 0.0.0.0” (meaning “22.214.171.124/32”)
- a subnet 126.96.36.199 can be matched with “188.8.131.52 0.0.255” (meaning “184.108.40.206/24”), 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 10.0.0.10 to 10.0.0.20 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 10.0.0.10 to 10.0.0.20…
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