Revision | Date | Changes |
---|---|---|
1.0 | December 16th, 2020 | Initial Release |
The CVE-ID tracking this issue: CVE-2020-26568
CVSSv3.1 Base Score: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)
This advisory documents the impact of a vulnerability in Arista’s EOS for device configurations leveraging VxLAN Routing and VRFs. To evaluate if a VxLAN enabled device is vulnerable, please see the “Symptoms” section below for details.
On impacted devices, malformed packets could be incorrectly forwarded across VRF boundaries when non-default VRFs are configured. This issue affects UDP traffic, and will fail to complete the three-way handshake for TCP traffic.
Please note that this advisory does not refer to the crossing of VRF boundaries as a result of the configuration of inter-VRF routing (which would be the expected behavior).
This issue was discovered internally and Arista is not aware of any malicious uses of this issue in customer networks.
Affected Software
Affected Platforms
This vulnerability is applicable to systems with both non-default VRFs and VxLAN configured. The exploitation of this vulnerability would result in packets crossing VRF boundaries in one direction.:
To confirm if the vulnerability is applicable, the following checks can be performed by logging into the device in question. :
Example:
Switch#show vrf
Maximum number of vrfs allowed: 1023
VRF RD Protocols State Interfaces
------------- --------------- --------------- ----------------- --------------------------
default ipv4,ipv6 v4:routing, Vlan1, Ethernet8/1,
v6:routing Ethernet9/1, Loopback0,
test1 100:1 ipv4,ipv6 v4:routing, Vlan10, Ethernet3/1,
v6:routing Ethernet7/1, Loopback1
test2 200:1 ipv4,ipv6 v4:routing, Vlan20, Ethernet4/1,
v6:routing Ethernet8/1, Loopback2
Example:
Switch#show running-config section vxlan
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 10 vni 100
vxlan vrf test1 vni 1001
There is no mitigation available to address this vulnerability. For the final resolution, please refer to the next section which lists the details of the remediated software versions.
This vulnerability is being tracked by BUG 485689. The recommended resolution is to upgrade to a remediated EOS version during a maintenance window.
The vulnerability is fixed in the following EOS versions:
Post upgrade impact on select platforms:
This section of the advisory applies to the following list of platforms:
For customers whose network design leverages VxLAN decapsulation on an interface that carries traffic for multiple VRFs, the following additional steps may be required post EOS upgrade.
Once an upgrade to a release with the fix has been completed, the following warnings may be logged under “show logging all”:
**%VXLAN-4-DECAPSULATION_DISABLED:** VXLAN decapsulation has been disabled on
Ethernet48 because it carries both default VRF and non-default VRF traffic
**%VXLAN-4-DECAPSULATION_DISABLED:** VXLAN decapsulation has been disabled on Ethernet48 because it carries non-default VRF traffic
To allow VXLAN decapsulation on interfaces that carry both default VRF and non-default VRF traffic issue the command: 'vxlan decapsulation filter interface multiple-vrf disabled'.
To entirely disable VRF-based VXLAN decapsulation filtering on this switch/router, configure 'vxlan decapsulation filter disabled'.
If the above warnings have been observed, it indicates that VxLAN decapsulation has been disabled on the listed interfaces (for example, in the above case VxLAN decapsulation has been disabled on ethernet48).
These warnings and the associated action of disabling VxLAN decapsulation can be expected post an upgrade. The next step would be to confirm if one of interfaces included in these warnings is a “core-facing interface”. A core-facing interface is the physical port on which the switch receives VxLAN encapsulated traffic from remote VTEPs. Please note that the core-facing interface is not determined on the basis of any configuration, rather it is the result of the network design.
A core-facing interface is typically the uplink to a Spine in a Leaf-Spine topology. In order to enable VxLAN decapsulation on a core-facing interface, the following configuration can be applied under the “interface vxlan 1” configuration context.
Please note that the application of the configuration below will revert the default behavior for the interfaces specified in the “interface list”. This configuration only needs to be applied if VxLAN decapsulation has been disabled on the core-facing interfaces (or any physical interface on which it is expected to receive and decapsulate VxLAN traffic). This configuration can be disregarded if it is not expected to receive and decapsulate VxLAN traffic on a physical interface that carries traffic for multiple VRFs.
vxlan decapsulation filter interface multiple-vrf disabled []
Example:
**(config-if-Vx1)# vxlan decapsulation filter interface multiple-vrf disabled Ethernet48**
If there are multiple core-facing interfaces (i.e. multiple uplinks to the spine), all relevant interfaces will need to be specified.
Example:
**(config-if-Vx1)# vxlan decapsulation filter interface multiple-vrf disabled Ethernet48 Ethernet49 **
If you require further assistance, or if you have any further questions regarding this security notice, please contact the Arista Networks Technical Assistance Center (TAC) by one of the following methods:
By email: This email address is being protected from spambots. You need JavaScript enabled to view it.
By telephone: 408-547-5502
866-476-0000