• Tap Aggregation – VLAN List Filtering

Print Friendly, PDF & Email


1) Introduction


A list of allowed VLANs simply specifies, under an interface in Tap Aggregation mode, which VLAN traffic is allowed. Removing VLANs from the allowed list means those VLANs would be blocked.

It allows filtering traffic in a flexible manner, directly from the interface command, without creating ACLs or steering policies.

This article details how to configure the VLAN list, and combine them to achieve multi-stage VLAN filtering.


2) Allowed VLAN List Definition


An allowed VLAN list is simply a definition of VLAN IDs. By default, all VLANs are allowed.

The below commands illustrate the default port configuration relating to tap mode. Notice than VLANs 1-4094 (all) are allowed.


switch(config)#show running-config all interfaces Ethernet 1 | include tap
  switchport tap native vlan 1
  no switchport tap identity
  switchport tap allowed vlan 1-4094
  no switchport tap truncation
  no switchport tap default group


The VLAN lists can be configured on tap ports and tool ports:

  • a VLAN list on a tap port would filter ingress traffic, at the point of entry
  • a VLAN list on a tool port would filter egress traffic, at the point of exit

By definition, an allowed VLAN list defines the VLANs that are allowed. To drop traffic from a VLAN, remove that VLAN from the allowed list. For example, if you are not interested in traffic carried on VLAN 100, that traffic can be dropped by configuring the allowed VLAN list. In this example, with remove VLAN ID 100. Only [1-99, 101-4094] remain allowed:


switch(config-if-Et49)#switchport tap allowed vlan remove 100 
switch#show run interface Ethernet2
  interface Ethernet2  
  switchport mode tap
  switchport tap allowed vlan 1-99,100-4094
  switchport tap default group ToolsA


The below figure represents a combination of multiple tap ports and tool ports. In this example, tap and tool ports are mapped by the ToolsA group, and VLAN filtering is applied ingress on tap ports with the allowed VLAN list:


Filtering VLAN 100 ingress on tap ports


Note, in the above figure, that all the tool ports are deprived of VLAN 100 traffic, because traffic was blocked at the source. Tool ports cannot selectively choose whether to send their attached analyzer VLAN 100 traffic or not.

To make the filtering decision on the tool ports, for more selective control, you may configure the allowed VLAN list on the tools ports. The configuration syntax is identical, whether made on tap or tool ports.

In the following example, the VLAN filtering is applied egress, on the tool port, by removing the VLAN 100 from the allowed VLAN list. For illustrating the potential advantage of filtering egress, the configuration is applied on Ethernet4 only, leaving Ethernet5 to its default (allow all). Notice how the two tool ports can now filter independently. Their respective analyzers can now receive a different set of interesting traffic.


Filtering VLAN 100 egress on a tool port


The use case for tools receiving different traffic is typically tools with different roles; for example:

  • One tool might be for live analysis and correlation, usually expensive and constrained throughput, this tool might need to be restricted to minimum interesting traffic
  • Another tool could be capturing raw packet (e.g. pcap) for ad-hoc needs (forensic, troubleshooting), in the form of easily scalable capture servers and scalable storage. It might be suitable for this tool (or farm of tools) to capture much more traffic.
  • Another tool (IDS / IPS / Firewall / DDoS protection), might look at yet another part of the traffic, with some potential overlap with the other tools.

The two precedent examples illustrate the flexibility of filtering, either ingress (tap port) or egress (tool port), for the specific VLANs of you choice.

Allowed VLAN list offers a quick and intuitive implementation method to filter VLANs, without the need to build port ACLs or steering policies. You might need to resort to those more advanced filtering features if you want to filter more than just VLANs.


3) Native VLAN


3.1) Port Origin Identity Tag


Native VLAN arriving on different tap ports could be mixed on egress, if the identity tag is not used. Identity tags differentiate traffic by applying an 802.1Q header with the ID specified. Traffic from VLAN 100, or native VLAN, would then not merge on the egress port.


Identity 802.1Q tag differentiate traffic by origin ID, on egress only


The origin identity 802.1Q header is applied on egress, which mean that internally the native VLAN traffic is still undifferentiated. Any manipulation of the allowed VLAN list would impact equally native traffic from all the tap ports.


3.2) Native VLAN Internal Mapping


To implement native VLAN differentiation internally, apply an internal VLAN ID to a tap port native VLAN traffic. For example:

switch(config)#interface Ethernet 1
switch(config-if-Et1)#switchport tap native vlan 3001
switch(config)#interface Ethernet 2
switch(config-if-Et1)#switchport tap native vlan 3002 


To illustrate that internal differentiation of native VLAN traffic, the below example implement egress filtering with VLAN list.

  • Ethernet 4 is dropping native traffic from Ethernet 1 (internally mapped to VLAN 3001)
  • Ethernet 5 is dropping native traffic from Ethernet 2 (internally mapped to VLAN 3002)


Internal differentiation of native VLAN, illustrated with egress VLAN list filtering

Note that on egress, the native VLAN traffic remain untagged. The native VLAN mapping is only for internal differentiation between the different possible origins.

If some origin differentiation is required beyond the Arista Tap Aggregator, after egress, then the port identity tag is required.


4) Multi-stage VLAN Filtering


4.1) Example

The following figure combines multiple filtering methods mentioned thus far:

  • Allowed VLAN list on a tap port
  • Allowed VLAN list on a tool port
  • Port identity tag
  • Native VLAN internal-only mapping


Multi-stage VLAN Filtering with VLAN List, port ID tag, native VLAN ID

Even elaborate, the multi-stage VLAN filtering based on allowed VLAN list is only capable of matching against the outermost 802.1Q header.

For more granular classification, port ACL (Layer2, 3 and 4, including LAN ID on IP ACL), and traffic steering (policy-based) can provide more advanced per-flow filtering.

The VLAN list can be combined with those more advanced filters. The following section clarify the processing priority for the different filtering options.


4.2) Classification and Filtering Decision Tree


The below workflow diagram represent the filtering decision tree, to illustrate what takes priority on port VLAN list.

vlanlist-Slide8-workflowFiltering Decision Tree



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


Example of multi-tier filtering



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

Join other followers: