In Windows it is possible to use the ping command in the CLI to find the point where fragmentation is needed. Simply, add the -f option to the ping command which sets the Do Not Fragment bit to 1. Then increase the payload size using the -l option in the same ping command until the pings start to fail. The ping response will show “Packet needs to be fragmented but DF set” message which indicates the point where fragmentation is required.

Using ping without options will use 74 bytes packets on the wire (14 byte Ethernet + 20 byte IP + 40 byte ICMP Payload). If specify ping options an extra 16 bytes is added to the IP header.

Increasing the ICMP payload size increases the packet size further and if the DF bit is set you will soon discover the point where fragmentation is required.

In a test I discovered that I could send 1456 bytes of ICMP payload resulting in a frame size of 1514 bytes without fragmentation. When I specified 1457 bytes the ICMP Requests were dropped and the message above was returned.

Fragmentation can lead to issues between client and server and sometimes segments arrive out of order causing issues with reordering or reassembly.

The MSS and MTU settings can be used on a WAN router to prevent fragmentation. The IP layer uses a Path MTU Discovery mechanism to discover the optimum MTU size for transmission. This requires the proper handling of ICMP messages between network devices. Alternatively, TCP MSS can be used to avoid fragmentation.

In XIQ-SE Network Devices can be configured using the Ports Tab and individual ports can have their configuration changed. How can you change the auto negotiation settings for a specific port?

In order to change the auto negotiation settings, first use the Column picker to select Auto Negotiate, Speed and Duplex so they appear as columns in the Ports Tab.

The Port Template needs to be changed to <Use Local Settings> so as an example, Auto can be turned off and the Speed set to 100 and Duplex Full.

When onboarding an AP 4000 into XIQ there was an error in discovering the country code or assigning the country code. The country code showed World SKU (998) instead of United Kingdom (826).

Data Sheet:

The AP4000 is the industry’s first Enterprise Universal and World SKU Wi-Fi 6E Wireless Access point. This innovation simplifies the sales ordering process and reinforces Extreme’s commitment to the journey to the “Infinite Enterprise”. The World SKU allows customers, partners, and distributors to order one model for any region, replacing the age-old problem of country specific SKUs. ExtremeCloud(tm) IQ geo-locates the Access Point and accurately provides it the corresponding set of channel and power specifications that the product can operate under in that country.

XIQ will discover the country code based on the public IP address so this should happen automatically. Where the CAPWAP traffic originates from I presume.

Anyway, to the solution. The Network Policy I had was configured with the four predefined NTP servers. The customer Firewall was not allowing these and they allow different addresses. Updated the NTP addresses under Additional Settings, pushed the config change to the AP and did a Discover Country Code action. Shortly afterwards the AP showed the correct county code in XIQ.

NTP is important for certificates and clocking so if the date and time is not correct and NTP servers are unreachable then this seemed to affect the ability to assign the correct country code to the Global AP. A Show Tech revealed the issue more clearly.

It may be best practice to disable low data rates for 2.4GHz 802.11b/g but where do you do it in XIQ?

Edit the 2.4GHz 802.11b/g data rates for each SSID. Click Additional Settings at the bottom of the Wireless Network. Click Customize for the Optional Settings. Under Radio Rates click on 802.11b/g. Make data rates 1 Mbps to 11 Mbps N/A. Change the 12 Mbps from Optional to Basic. Click Save Rate Settings. Click Save Optional Settings. Click Save.

A VOSS switch with EAPOL enabled will send RADIUS reachability packets every 180 seconds using RADIUS reachability mode use-radius. The Access-Request will contain the User Name Attribute with value reachme. If this username does not exist on the RADIUS server an Access-Reject (3) message is seen every time the Access-Request is sent.

In Extreme Access Control add the username reachme with password reachme in the Local  Password Repository and the Access-Request will return an Access-Accept message.

A new installation of Control will need at least one Authentication Rule setup under the Configuration>AAA>Default>Advanced AAA Configuration which will use the Local Authentication option for the Authentication Method.

I always change the Default setting from Basic to Advanced AAA Configuration to allow multiple Authentication Rules so can search Active Directory as well as Local.

If XIQ-SE is unable to discover a VOSS switch with SNMPv3 it is most likely caused by a mismatch in SNMP credentials. This could be to do with authpriv settings using incorrect authentication or privacy mode or the passwords don’t match.

There is another, not very obvious cause where the two double quotes are pasted as “bb” when adding a new group.

snmp-server group HOMELAB “” auth-priv read-view ALL write-view ALL notify-view ALL

The “” signify that the group belongs in the GRT VRF 0.

The show snmp-server group command will show “bb” under the Prefix column when it should be blank.

The solution here is to remove the group and user and manually type the commands in on the CLI instead of pasting and you will find the show snmp-server group output now excludes “bb” characters and XIQ-SE can discover the switch.

Had to convert some new Universal 5320 switches this week and came across a real time stealer.

The Universal hardware will boot with EXOS by default. During initial start up press space bar on the Boot Menu and scroll down to select Change the switch OS to VOSS and click Enter.

The version of VOSS software will be a pre-GA version and needs to be upgraded.

Problem I came across was as I attempted to add the software the switch would suddenly reboot and keep doing so every time I tried.

It felt like some kind of memory leak or watch dog timer failed and the switch died.

There are two ways I found to workaround this issue.

1) Factory default the switch before attempting the upgrade. This will start the switch in pre 8.2 configuration mode without the clever ZTP+ automation features such as searching for a nick-name server and mgmt DHCP client enabled. I figured this would prevent the CPU from going over 95% utilization which appeared to be related and this worked most of the time.

2) If step 1 fails, it is possible to use the VOSS: Rescue option on boot up. Insert a USB drive and specify the filename of the VOSS software ie 5320.8.8.1.0.voss.

The pre 8.2 default configuration will have ISIS and SPBM disabled.

Recently hit an issue between a Universal 5420 switch running EXOS in a stack connected to VSP 7432 switches. Normal practice to use different slots for the uplinks ie 1:52 and 2:52 in a LAG. I noticed 2:52 was not coming up.

On slot 1, the Master switch, Forward Error Correction was ON and this matched FEC settings on the VSP 7432 interfaces (100G channelized to 4 x 25 with breakout cable).

The default for EXOS should be that FEC is disabled. Disabling FEC on the VSP 7432 side brought the link up on 2:52. Disabled FEC on 1:52 allowed all ports to be active.

Bottom line, FEC must match both ends for the link to come up. I have raised a ticket as to why slot 1 would enable FEC on its ports but not on backup or standby switch ports.

Extend the Factory Default Premier Trial License

#EXOS 30.7 or Older
show memorycard
ls /usr/local/ext
download image memorycard <image>.xos

#EXOS 31.1 or Newer
show switch mounts
ls /usr/local/ext
download url file:///usr/local/ext/<image>.xos

Solution: Downloading image failed with – write error: No space left on device | Extreme Portal (force.com)