OnePolicy "deny all" blocks STP on EXOS, but not on EOS

[Erik_Auerswald]

Hi,

when replacing EOS based access switches (e.g. S-Series) with EXOS based switches with OnePolicy support (e.g. X460-G2 or X440-G2), there is a difference in behavior if a deny all policy is used. On EOS, STP BPDUs are not blocked, but on EXOS they are blocked by the OnePolicy.

I have encountered this with a customer using a deny all default OnePolicy to drop traffic from unauthenticated devices. After authentication, legitimate devices are assigned a OnePolicy to allow desired communication (and a VLAN is assigned using the RFC 3580 method as well).

While it is documented that deny all EXOS ACLs drop all Layer 2 protocols, I was not aware that this was carried over to OnePolicy (and I did not check the documentation).

Another problem is how to allow STP BPDUs in the default policy. I see two obvious methods to recognize them:

1. By the destination MAC address of 01:80:C2:00:00:00
2. By the LLC DSAP of 0x42 and SSAP of 0x42

The first method should be supported on X460-G2 switches (according to show policy capabilities), but not on e.g. X440-G2. The second method is not supported by either X440-G2 nor X460-G2. Since we had X440-G2 in the lab, we could not test the first method when I was on-site (for a different task that had priority).

Has anybody encountered this problem before? How was it solved?

[Note: OnePolicy was just called Policy on EOS, but EXOS knew policy (.pol) files (also known as ACLs) as well. EXOS ACLs are more powerful than EXOS OnePolicies.]

Thanks,
Erik

[Erik_Auerswald]

Hi all,

I have heard a disturbing rumour (I have not received a direct confirmation from an Extreme representative) from a reliable source that the S-Series and K-Series firmware will be (or has been already) changed to break the often used DenyAll default rule with policies applied after authenticating end systems, just as it is broken on EXOS (see the first post of this thread).

To add insult to injury this change is supposed to be implemented without any mention in the Release Notes, breaking existing networks if new firmware is installed, without any chance for a warning in advance. Installing new firmware is often required to stay in compliance with regulations and contracts, including receiving support from Extreme Networks.

I do not want to believe this, but there is a certain logic to this ("EOS" always used a couple of undocumented exceptions to not break networks with a policy that denies "all" frames, while EXOS requires the user to manually allow what is needed for the network to function, see e.g. the issue from the post above or the Example ACL Rule Entries from the documentation).

Can anybody confirm this, or has seen this with current S-Series or K-Series firmware already?

Best regards,
Erik

[Erik_Auerswald]

Hi Daniel,

thanks for the info, that was the reply I hoped to get. 🙂

Erik

[Daniel_Coughlin]

Erik,
I spoke with engineering about this rumor. They have not made changes to which protocols are still processed by EOS in the presence of a default drop rule in policy. They also stated that there is no plan to do so in the future.

[M_Nees]

Issue is still existing in EXOS 22.4:

https://gtacknowledge.extremenetworks.com/articles/Solution/802-1X-Authentication-Fails-after-Reject...