Extreme Campus Controller policy rules for DHCP and linux

[Jan_Reister]

I have an ECC policy role which works fine for almost all devices, except few linux device which can’t get an IP address via DHCP.

The role has a default deny policy, then:

L2 rules: none

L3 rules: allow DHCP client and server, allow http,https…

Windows, iOS and most linux clients get an IP address, some linux cients fail at DHCP.

If I change the default policy to allow, the problematic clients get an IP and succeed.

If I leave a default deny policy, and add a L2 role of allow all, the problematic clients get an IP and work.

If I leave a default deny policy, and add a L3 role of allow all, the problematic linux clients fail at dhcp.

I have excluded 802.11 issues as the client associates, does 802.1x EAP, does 4-way handshake, sends encrypted data frames (dhcp).

I am aware of Understanding the Policy Rules Direction, and this is the L3 rule configuration for DHCP:

allow DHCP Client: from user=src, to user=dst

allow DHCP Server: from user=dst, to user=src

For the time being I’m using a workaround to make roles work for everybody, but I need a solution for enforcing granular rules.

Do you have any idea what could possibly cause the problem?

Have you ever met special linux clients with weird DHCP habits?

[Jan_Reister · Accepted solution]

A L2 rule allowing L2 broadcast solved the issue for the rare linux clients that failed DHCP. We will probably open a case on this matter.

[Jan_Reister]

Hello Stephan,

the dhcp pcaps are almost identical, the only difference is the problematic linux client sets a no fragmentation flag. This should not be an issue in our environment, but I’ll investigate further.

Jan

[StephanH]

Hello Jan,

did you create a Wireshark trace from one of the not working clients when it works (as for example when the Allow All rule is active), for example on you DHCP server? If not, create one and compare it with a client that always works.

This way you should be able to detect any deviations.