Management Options

• Block All—Prohibits forwarding multicast and broadcast traffic through tunnels.
• Allow All—Enables forwarding multicast and broadcast traffic through tunnels.

ExtremeCloud IQ devices can selectively block or allow broadcast and multicast traffic through GRE tunnels to reduce traffic congestion. You can filter using a blocked list that blocks the forwarding of all broadcast and multicast traffic through GRE tunnels (or blocks all except to a few select destinations) or using a allowed list that allows all broadcast and multicast traffic through GRE tunnels (or allows all except to a few destinations).

By default, devices do not enforce MAC or IP session limits per station. By default, devices do not enforce IP session limits per station.

This feature enables a device to monitor the TCP MSS (maximum segment size) option in TCP SYN and SYN-ACK messages for traffic that the device is going to pass through GRE tunnels (for Layer 3 roaming and static identity-based tunnels) and GRE-over-IPsec tunnels (for IPsec VPN tunnels). The device can then notify the sender to adjust the TCP MSS value if it exceeds a maximum threshold.

When establishing a TCP connection, neither end is aware of the packet processing done by network forwarding equipment in between. For example, if a device has to send traffic through an IPsec VPN tunnel, then it adds a GRE header, IPsec header, and possibly a UDP header for NAT-Traversal to each packet. Since the additional headers expand packet size, the device is forced to fragment them, which increases packet processing and slows down throughput. To avoid fragmentation, the device can adjust the MSS (maximum segment size) value inside the initial SYN packet to allow room for the additional headers.

The default thresholds are 1414 bytes for GRE tunnels and 1336 bytes for GRE-over-IPsec tunnels and are based on encapsulation overhead of the corresponding tunnel type and the maximum transmission unit (MTU) for the mgt0 interface, which is 1500 bytes by default. If you change the MTU and use "auto" for the TCP MSS option, the device automatically readjusts the TCP MSS thresholds.)

• Drop packets that are denied by IP or MAC firewall policies
• The first packets of the session destined for the Extreme Networks device itself

• Fragmented IP Packets
• All non-management traffic destined for the Extreme Networks device itself

By default, a device reserves 500 milliseconds of airtime per second for all VoIP calls. You can change the reserved airtime per second for VoIP from 100 to 1000 milliseconds per second.

By default, a device guarantees 20% of the reserved VoIP airtime for VoIP calls from roaming clients. You can change the percent of guaranteed airtime for roaming clients from 0% to 100%. Consider lowering the percent if VoIP users rarely roam, and raising the setting if roaming often occurs. Because VoIP traffic from a roaming client belongs to an existing session, the device to which the client roams always accepts it. If there is not enough airtime available in the guaranteed roaming reserve, the device deducts available airtime from the relevant user profile.

• Use DHCP option 55 contents: Select to use the DHCP option 55 parameter list.
• Use HTTP user agent IDs: Select to use the contents of the HTTP user agent ID within the HTTP headers.
• Use both detection methods (DHCP=primary method, HTTP=secondary method): Select to use both the DHCP option 55 parameter list and the HTTP user agent information to identify the client operating system. When you select this option, devices first check the contents of the DHCP option 55 parameter list. If it finds no match, then the device examines the HTTP header for the HTTP user agent ID to determine the operating system. If no match is found in either pass, then ExtremeCloud IQ displays unknown as the client OS.

Disabling the console port on a device that is deployed in a publicly accessibly location is a good security precaution. Disabling the console port means that all administrative access must flow over the network, and if there are any connectivity issues with the network or if the device is configured to use only DHCP to get an IP address and cannot get its network settings from a DHCP server, attempts to log in to the device fail.

Smart PoE lets an AP230, AP320 or AP340 adjust power consumption automatically based on the current power supply. The AP230 and AP320 support PoE on the ETH0 interface. The AP340 supports PoE on both its ETH0 or ETH1 interfaces, and can simultaneously draw power through either one or both. Using Smart PoE, an AP can detect if there are power injectors connected to one or both of its Ethernet ports and how many watts are available for each PoE channel. The AP uses this information to manage its internal use of power resources based on the currently available power level as follows:

• 20 W or higher: No adjustments are needed when the power level is 20 W or higher.
• 18 - 20 W: The device disables the ETH1 interface.
• 15 – 18 W: The device switches from 3x3 MIMO (Multiple In, Multiple Out) to 2x3.
• 13.6 - 15 W: In rare cases when the power drops between 13.6 and 15 W and further power conservation is necessary, the device reduces the speed on its active Ethernet interface from 10/100/1000 Mbps to 10/100 Mbps.
• 0 - 13.6 W: If there is a problem with the PoE switch or Ethernet cable and the power falls between 0 and 13.6 W, the device disables its wireless interfaces and returns its ETH0 and ETH1 interfaces to 10/100/1000 Mbps speeds.

By default, devices reject ICMP redirects because crafted ICMP redirect messages can be maliciously used to cause a victim host to send traffic to an attacker's host or even back to the victim itself, which is what occurs during a WinFreeze attack. However, if you believe that your network is safe from such threats and you want multiple routers on the local subnet to be able to update the routing table on devices, enable this option.

To use this setting, you must first define the iBeacon service in the associated network policy and then turn it on via the Device Management page.

• Local—Stores admin accounts locally on the APs.
• RADIUS—Stores admin accounts remotely on RADIUS authentication servers.
• Both—Stores admin accounts both locally and remotely.

If there is no central RADIUS server containing a user database, or if you prefer to keep the admin accounts locally on the AP, select Local. To use accounts located on an external RADIUS server and locally on the device, select Both. In this case, the device authenticates administrators by first checking accounts on the external RADIUS servers specified in the RADIUS profile, and then by checking accounts stored on the local database second.

• Delimiter—Choose the type of delimiter: Colon (:), Dash (-), or Dot (.).
• Style—Choose No delimiters, Two delimiters, or Five delimiters.
• Case Sensitivity—Choose between Lower Case and Upper Case.

Some servers only accept MAC addresses in a particular format. These parameters control MAC authentication for local users on an Extreme Networks RADIUS server. For example, if you set case sensitivity as lower case and store local users with upper case MAC addresses for their user names and passwords, MAC authentication checks fail.

By default, a device formats MAC addresses using lower case without any delimiter; for example: 0016cF8d55bc. You can reformat this address by making the following selections:

Colon, no delimiter, upper case: 0016CF8D55BC

Colon, two-delimiter, upper case: 0016:CF8D:55BC

Colon, five-delimiter, upper case: 00:16:CF:8D:55:BC

Dash, five-delimiter, upper case: 00-16-CF-8D-55-BC

Dot, five-delimiter, upper case: 00.16.CF.8D.55.BC