Support Support Downloads Knowledge Base Apex Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[EX/QFX] Tunneling layer 2 control protocols without QinQ config on EX/QFX

1

0

Article ID: KB36842 KB Last Updated: 12 Aug 2021Version: 2.0
Summary:

This article describes the behavior of layer 2 control protocols (L2CP) on EX/QFX switches that run Junos OS Release 20.4 and later.

This applies to protocols that use a multicast MAC address as destination in the range 01:80:c2:00:00:00 through 01:80:c2:00:00:0f. Usually a QinQ configuration would be required to tunnel such traffic. However, in this article, we demonstrate how to tunnel tagged or untagged L2CP without using QinQ configuration.

Symptoms:

The default behavior in QFX and EX switches that are running Junos OS releases prior to 20.4 is to punt packets with a multicast destination MAC address in the range 01:80:c2:00:00:00 through 01:80:c2:00:00:0f to the CPU.

This behavior could not be changed and the same behavior exists in Junos OS Releases 20.4 and later. Whether the traffic is tagged or untagged, the layer 2 control frames are punted to the CPU and this is as expected.

Solution:

From Junos OS releases 20.4 onward, a firewall filter with action flood can be applied to switch the control packets instead of punting to the CPU. And you can confirm whether the packets are punted to the CPU by using the command monitor traffic interface as illustrated below:

#run monitor traffic interface ge-0/0/0 no-resolve layer2-headers extensive count 3 size 200   

        0a:01:02:03:04:05 > 01:80:c2:00:00:0f, ethertype 802.1Q (0x8100), length 124: vlan 1088, p 0, ethertype 0xffff, 
                         0440 ffff e0e6 fe4f 82a8 ecdf 4978 6960
                         0000 0000 1011 1213 ab5c a00b 004e 1a1b
                         1c1d 1e1f 2021 2223 2425 2627 2829 2a2b
                         2c2d 2e2f 3031 3233 3435 3637 3839 3a3b
                         3c3d 3e3f 4041 4243 4445 4647 4849 4a4b
                         4c4d 4e4f 5051 5253 5455 5657 5859 5a5b
                         5c5d 5e5f 6061 6263 6465 6667 78b5 0000
                         0000 81f3 6d60 bbfe 0e00 9200

In this case, the frames with the destination MAC address 01:80:c2:00:00:0f are destined to the CPU. If they had not been going to the CPU, the monitor traffic command would not have displayed them.

In order to change this behavior, that is to simply switch such packets at the Packet Forwarding Engine (PFE) and not punt them to the CPU, whether the L2CP packets are tagged or untagged, you can apply a firewall filter with the action flood as the following example illustrates:

root@host# show firewall family ethernet-switching | display set
set firewall family ethernet-switching filter TEST term 1 from destination-mac-address 01:80:c2:00:00:02/48
set firewall family ethernet-switching filter TEST term 2 then flood
set firewall family ethernet-switching filter TEST term 2 from destination-mac-address 01:80:c2:00:00:03/48
set firewall family ethernet-switching filter TEST term 2 then flood
set firewall family ethernet-switching filter TEST term 3 from destination-mac-address 01:80:c2:00:00:07/48
set firewall family ethernet-switching filter TEST term 3 then flood
set firewall family ethernet-switching filter TEST term 4 from destination-mac-address 01:80:c2:00:00:0e/48
set firewall family ethernet-switching filter TEST term 4 then flood
set firewall family ethernet-switching filter TEST term 5 from destination-mac-address 01:80:c2:00:00:0f/48
set firewall family ethernet-switching filter TEST term 5 then flood
set firewall family ethernet-switching filter TEST term ACCEPTALL then accept
 
{master:0}[edit]
root@host# show interfaces ge-0/0/0 | display set
set interfaces ge-0/0/0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members V1088
set interfaces ge-0/0/0 unit 0 family ethernet-switching filter input TEST

root@host# show interfaces ge-0/0/1 | display set
set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members V1088
set interfaces ge-0/0/1 unit 0 family ethernet-switching filter input TEST

In the above example, the action flood is applied to the specified MAC addresses with a default term to accept all other traffic. The trunk interfaces ge-0/0/0 and ge-0/0/1 on the switch are in the same VLAN - 1088. Any L2CP traffic that is received on the switch with the above specified destination MAC addresses will be switched between these two ports.

The same filter can also be used if the ports are access ports, that is if the L2CP traffic is untagged. If the monitor traffic interface command is executed after applying the firewall filter to the respective interfaces, no L2CP packets will be captured on the interfaces where the filter is applied. This indicates that the packets are not punted to the CPU but switched on the PFE itself.

You can also confirm this by using the monitor interface <interface#> command and tallying the input and output rate before and after the change. Note that you will see a slight increase in the output rate after the change. This output is easier to observe when there is no other traffic on the interfaces.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search