When working with devices from Enterasys Networks (Enterasys has been acquired by Extreme Networks in 2013), co-workers often complain(ed) that it is not easy to find information regarding a given problem. That complaint is (was) not totally unsubstantiated, because web search engines (used to) deliver abysmal performance in finding the freely available information. This page is an attempt to ameliorate this situation by collecting links to existing info as well as adding some of my own. Introduction of the HUB and GTAC Knowledge (see below) improved the situation over time.
The situation deteriorated since then. Extreme Networks discontinued the networking devices acquired from Enterasys Networks, and the number of users of those networking devices is shrinking. Thus the number of third party information resources is diminishing, too.
In October 2013, Enterasys started an online community called The Hub. This is (was) supposed to replace the Enterasys Knowledge Base after 2013-11-13. The HUB is indexed by search engines (or at least some instantiations of it were). It seems that articles from the former Knowledge Base are migrated to the HUB. Thus they become discoverable via, e.g., a DuckDuckGo search. Extreme Networks later created a new knowledgebase called GTAC Knowledge, containing articles about Enterasys (EOS) devices as well. This GTAC Knowledgebase is (was?) indexed by search engines. ☺ The GTAC Knowledgebase site has been retired, but the articles seem to have been moved to the Extreme Portal, accessible via the search feature. At least at the beginning of 2021 search engine search results still contain old GTAC Knowledge links, but those are not redirected to the articles. Instead one needs to manually enter (copy and paste) the article title into the portal's search box. The 2021 Knowledgebase uses article IDs as reference, but whenever a given article is updated, it gets a new ID, and the old article ID is removed. Similarly, The HUB is now (early 2022) in its (at least) third incarnation. While the move to the previous instantiation kept old articles, the latest move lost all that content, including knowledge base articles only moved to The HUB.
Thus links on this page may point to a page not found error instead of (an older version of) the article.
It seems as if Extreme Networks does not want to provide cool URIs.
The Knowledgebase has been retired and replaced by The Hub. There was an additional, newer knowledge base called GTAC Knowledge. This is indexed by search engines and contains lots of useful articles. The GTAC Knowledgebase site has been replaced by the search feature of the Extreme Portal.
Size of the installed RAM in N-Series (and other) switches can be queried with NetSight Console using the Storage Utilization FlexView (from the Resource Utilization folder). N-Series switches need 256MB RAM for Firmware 7 or NetFlow.
To have the same [BACKSPACE] key behaviour in both switch and router modes of an N-Series switch with firmware 6 and below, use the command:
N-Series(su)->set line-editor delete backspace default
On K-Series, N-Series with firmware 7, and S-Series switches you can
filter show output to lines including some fixed string using the
undocumented
|find
keyword.
K/N/S-Series(su)->show arp |find ? <search string> The string to search for in the outputYou cannot abbreviate the
|find
keyword. Neither manual nor
online help mention it. The CLI does not complete it. There is no space
in this 5 letter keyword. It may go away anytime, because it is no official
feature. You have been warned. ;-)
On the SecureStacks or rather A/B/C/D/G/I-Series switches, the
show vlan portinfo
command produces a very nice table
showing the VLANs configured on each port. This command
might
someday find its way into the K/N/S-Series firmware 7+, but it is not
there yet. Update: the show vlan portinfo
command
is supported in firmware 8 of the K/S-Series switches.
By setting the SNMP system location to an aptly constructed
string, you can create a foldable hierarchy in NetSight under
Grouped By -> Location. To do so, you separate
the parts of the hierarchy, e.g., site, building, and
room, with "/
":
Switch(su)->set system location "SITE / BUILDING / ROOM" Switch(su)->set system location "HQ/1/123"Spaces around the "
/
" are ignored.
If you need to convert an IPv4 address to a hexadecimal representation, e.g., to configure DHCP option 78 or DHCP option 43, you can use the printf utility on GNU/Linux or POSIX compatible UNIX systems:
$ printf -- '%02X%02X%02X%02X\n' 192 0 2 91 C000025B
If you need to convert an IPv4 address given as four hex values to the usual dotted-quad representation, e.g., to read the IPv4 address from an etsysMgmtAuthSuccessNotificiation trap, you can use the printf utility on GNU/Linux or POSIX compatible UNIX systems:
$ printf -- '%d.%d.%d.%d\n' 0xC0 0x00 0x02 0x5B 192.0.2.91
Quality of Service (QoS) configuration on Enterasys switches is usually done via policies. Some switches need a policy license to support this. Enterasys recommends using NetSight Policy Manager for policy-based QoS configuration.
The A2 switch as well as the B2, B3, and D2 without policy license support a
set diffserv
command set that enables a different, less flexible, QoS configuration
than the policy based method.
If you want to manually assign a policy to a port, you can use the
set policy port
command.
The A/B/C/D/G/I-Series switches provide a matching show policy
port
command to display policies assigned to a port and a
matching clear policy port
to remove a port policy.
(show policy port
has been added in firmare version 6.61.)
The K/N/S-Series switches implement set policy port
as a
macro, translating into an equivalent set policy rule
admin-profile
command. To display the policies assigned to a port,
use the show policy rule admin-profile
command.
To remove the policy from a port,
you can use either the documented, but long clear policy rule
admin-profile ...
command, or the undocumented set policy port
PORT 0
(this command is supposed to accept values of
1
and higher, but not 0
). You are on your own
if you use undocumented functionality, of course.
For additional info see the GTAC Knowledge articles How does an Admin-profile Policy Rule differ from a non-Admin Policy Rule? and Execution Sequence for EOS Policy Rules.
Saving the configuration of Enterasys switches differs depending on switch model and sometimes even firmware version.
write file
in privileged EXEC router mode.
save config
command saves all configuration changes. Stackable switches
(A/B/C-Series) provide the save config all
command to save the configuration to all switches in the stack.
set snmp persistmode manual
to deaktivate
automatic configuration saving. Use set snmp persistmode
auto
to activate automatic configuration saving.
Use the show snmp persistmode
command to check
this setting.
save config
CONFIGFILE
command is used to save configuration
changes. Make sure that the CONFIGFILE is the one used
during boot (show boot_file
).
The RADIUS Filter-ID is case-sensitive on A/B/C/D/G/I-Series
Switches. To assign a policy using a decorated Filter-ID,
its value must be
Enterasys:version=1:policy=POLICYNAME
(with a lower case p for the policy
keyword).
It will not work with an upper case P (Policy).
The K/N/S-Series switches accept an upper case P as well as the
documented lower case.
Do not use incompatible OSPF network types, e.g., in multi-vendor
environments. For example, on Cisco switches
(and routers) layer 3 (routed) Ethernet interfaces and SVIs can
be configured as point-to-point
(ip ospf network point-to-point
). N-Series switches
with firmware version 6 and below do not support this, the OSPF
network type is always broadcast. (K/N/S-Series firmware version
7 and up do support configuration of OSPF network type, supporting
point-to-point, so you can create this problem
in a pure Enterasys environment as well.)
An OSPF adjacency is established even with mismatched OSPF network types,
transitioning to FULL state with synchronized link state
databases, unless some other problem inhibits building the adjacency
(e.g., mismatched timers). But the network type affects the network graph
created by the OSPF process. In the case of one router advertising a link
as part of a broadcast network and the other advertising it as a
point-to-point network, these two routers will not be seen by OSPF
as attached to each other over this link. The result is that no routes
using this link will be installed in the routing table. This problem
is not shown by the output of show ip ospf database
(neither
on Enterasys nor Cisco switches).
I have written a sed
script
to hide passwords in, e.g., configuration files or the
show support
output. Tested with Solaris 10 sed and
GNU sed.
The current version is also available in my
single file tools
repository on
GitHub.
Hung telnet or SSH sessions on A/B/C/D/G/I-Series switches can be cleared via SNMP. The method was documented by HP for their ProCurve and SuperStack switches. The method works for Cisco switches as well, but did not work with an N-Series when we tested it. Sadly I did not preserve this information locally, and the old links no longer work. Not even the Wayback Machine can help here.
Enterasys switches create a so called Node Alias Table
which associates a layer 2 (MAC) address with higher layer info, e.g., an
IP address, and the port this was seen. Higher layer info includes DHCP,
OSPF, VRRP, HSRP, and more protocols.
The Node Alias Table can be read via SNMP (e.g., using NetSight).
K/N/S-Series switches provide a command line interface to this table
via the show nodealias
command.
The Node Alias Table is created on layer 2 switches as well, no layer 3
configuration is necessary for this feature.
On C/G-Series and K/N/S-Series switches with FW version 7 or newer, OSPF authentication is automatically enabled by configuring an authentication key on an interface:
ip ospf authentication-key PASSWORD
(simple password authentication)
or
ip ospf message-digest-key KEYID md5 KEY
(MD5 authentication)
An N-Series switch with FW version 6 needs an additional command in the router ospf section to activate authentication:
area AREAID authentication simple
(simple password authentication)
or
area AREAID authentication message-digest
(MD5 authentication)
This can be quite surprising when upgrading an N-Series from FW 6 to 7 with inactive OSPF authentication, but a configured authentication key.
Cisco IOS needs two commands to activate OSPF authentication, one to define the key, and an additional command to activate.
Note: Do not use simple password authentication, because the password is transmitted as plain text.
The LACP per port default setting changed from enabled on the B3 to disabled on the B5.
Central European Time (CET) can be configured on EOS as follows:
set timezone CET 1
Central European Time (CET) can be configured on 800-Series switches as follows:
config time_zone operator + hour 1 min 0
Central European Summertime (CEST) can be configured on EOS as follows:
set summertime recurring last Sunday March 02:00 last Sunday
October 03:00 60
set summertime enable CEST
Note that the label CEST can be selected arbitrarily, it serves documentary purposes only.
Central European Summertime (CEST) can be configured on 800-Series switches as follows:
config dst repeating s_week last s_day sun s_mth 3 s_time 2:0
e_week last e_day sun e_mth 10 e_time 3:0 offset 60
When using Rapid Spanning Tree Protocol (RSTP) in a mixed Enterasys and Extreme network you need to have at least one untagged VLAN on every port of the Extreme Networks EXOS switches where RSTP is to be used. This VLAN must be added to the RSTP stpd. This VLAN does not need to be used for any data and the Enterasys switches do not need an untagged VLAN on the inter switch links. Note that Extreme Networks switches block a port only for those VLANs (and ports) that have been added to an active stpd. If you use a new stpd for RSTP you need to configure the stpd encapsulation used.
Changing the default STP configuration to RSTP:
configure stpd s0 mode dot1w
set spantree version rstp
Adding a VLAN to use RSTP (needed on Extreme only):
enable stpd s0 auto-bind vlan NAME
Note that RSTP configuration on ExtremeXOS is quite involved. It uses a concept of one Carrier VLAN and additional Protected VLANs per stpd, which has to be configured manually. VLANs and/or ports not associated with an stpd do not participate in the spanning tree protocol. This is very different from most other vendors implementations I know. To configure a more or less standard compatible spanning tree on ExtremeXOS, MSTP should be used (see below).
Update: Later EXOS versions allow using RSTP with only tagged VLANs on an inter-switch link. I still prefer to use MSTP instead of RSTP on EXOS, especially since in those later EXOS versions VLANs can be associated to the CIST (instance 0).
When using Multiple Spanning Tree Protocol (MSTP) in a mixed Enterasys and Extreme network you need to create and use at least one MST instance besides instance 0, because Extreme switches cannot have any VLANs associated with the Common Spanning Tree only. Therefore you need to reconfigure your network if you use, e.g., instances 0 and 1 for MSTP and want to add an Extreme Networks switch. (Update: Later EXOS versions allow associating VLANs with the MST CIST (instance 0).)
Note that Extreme uses 3 as MST configuration revision
by default (instead of the usual 0 as used, e.g., by Enterasys
and almost everybody else).
The ExtremeXOS Command Reference advises against changing the MST
configuration revision number, so you might want to adjust it on the
Enterasys switches instead, just to be sure. In my tests the
configure mstp revision NUMBER
command worked
as expected.
ExtremeXOS allows changing the MSTP format selector from its standard value of 0. This does not conform to the MST standard and is not supported by any other MST implementation I know. You should never change the format selector to any other value than the default of 0.
I would suggest placing the root bridge(s) for CIST and all MST instances on Enterasys switch(es). Of all the different STP implementations I have worked with, the one from Enterasys time and again proved to be the most robust and compatible, gracefully handling implementation errors in other vendors' switches and saving the network.
If you are replacing your distribution or core switches with Extreme Networks devices consider using MLAG to connect Enterasys access switches redundantly via layer 2.
configure mstp region MYREGION
set spantree mstcfgid cfgname MYREGION rev 3
disable stpd s0
configure stpd s0 delete vlan Default ports all
disable stpd s0 auto-bind vlan Default
configure stpd s0 mode mstp cist
set spantree version mstp
create stpd s1
configure stpd s1 mode mstp msti 1
set spantree msti sid 1 create
enable stpd s1 auto-bind vlan Default
set spantree mstmap 1 sid 1
enable stpd s0
enable stpd s1
set spantree disable
command.
To enable use
set spantree enable
.set spantree stpmode none
command.
To enable use
set spantree stpmode ieee8021
.disable stp
command.
To enable use enable stp
.
The best way to integrate an ExtremeXOS switch into a network using standard compliant spanning tree (STP, RSTP, or MSTP) as found on ExtremeEOS switches seems to be a very basic MSTP configuration, resulting in RSTP-like behaviour:
configure stpd s0 delete vlan Default ports all
disable stpd s0 auto-bind vlan Default
configure stpd s0 mode mstp cist
create stpd s1
configure stpd s1 mode mstp msti 1
enable stpd s1 auto-bind vlan Default
enable stpd s0
enable stpd s1
Note that you need to add every created VLAN to MSTP instance 1
(s1
) to match standard compliant spanning tree
implementations. Newer ExtremeXOS versions allow the use of just
the CIST without needing a non-CIST instance to add ports, much
like the default behavior seen with almost all other MSTP
implementations.
You can take a look at a related thread on The Hub called How to configure XOS to use EOS default spanning tree configuration as well.
If you want to integrate ExtremeXOS (EXOS) switches into an existing Per VLAN Spanning Tree (PVST+) network, see my ExtremeXOS (EXOS) Interoperability with Cisco Rapid-PVST+ page.
To help migration from Enterasys A/B/C/D/G/I-Series to Extreme SummitStack switches, a configuration translation tool called E2X Translator (alternate URL) is in development. This tool is free software distributed under the CDDL.
With Extreme Networks acquiring Enterasys Networks, there will be no Enterasys Operating System (EOS, now called ExtremeEOS) based successor to SecureStacks and similar switches (A/B/C/D/G/I-Series). The SummitStack switches are positioned as the replacement product. One element to support the migration from EOS to XOS is the E2X translator tool. It can translate a subset of the SecureStack configuration to an equivalent SummitStack configuration. The code is published on GitHub under the Extreme Networks account. See the E2X Releases page for downloads.
The E2X translation tool assumes migrating from a SecureStack C5 to a SummitStack X460. Since the C-Series provides a superset of the SecureStack switch features it can be used for migrating from, e.g., a B-Series or other similar switches as well.
Additional information could be found on the GTAC Knowledge site, e.g., in the articles Is There a Way to Convert an EOS Configuration to XOS? and How to Convert EOS Configurations to EXOS using e2x.py.
There were best practice articles for EOS switches at GTAC Knowledge: EOS: Basic Switch Layer 2 Configuration Best Practices and minimum feature recommendations and a Security Checklist For S-Series, K-Series, N-Series and Securestack
Oracle RAC clusters can send ARP responses with a sender hardware address 00:00:00:00:00:00 in failover situations. Since this MAC address is never learned by the switch, all frames sent to the cluster are flooded (unknown unicast flooding). Unknown unicast flooding is done in software on Enterays N/K/S-Series switches. This can lead to a maxed out CPU and thus interfere with normal network operation. See my page on testing unknown unicast rate limiting for further info and a possible mitigation technique.
The strange ARP reply is logged by Enterasys S-Series (and similar) switches as follows:
RtrArpProc[6]1.2.3.4 on vlan.0.123 responds to ARP requests
using a Sender Hardware Address [00-00-00-00-00-00] that does not
match the L2 source address [12-34-56-78-90-ab]. Additionally the
Sender Hardware Address does not exist in the Filter Database. This
is often caused by Network Load Balanced Servers without a
corresponding switch configuration. Please consult the release notes
or configuration guide to properly configure a static multicast
Filter Database Entry for: 00-00-00-00-00-00 on vlan.0.123
To gracefully handle this cluster failover feature, a static MAC entry for 00:00:00:00:00:00 can be added to the switch, pointing to every port used by the Oracle cluster. If the cluster is connected to ports ge.1-4.10 in VLAN 123, that would be done using:
set mac unicast-as-multicast enable
set mac multicast 00-00-00-00-00-00 123 ge.1-4.10
This will result in a warning message by the switch (Warning: Unicast address converted to multicast 01-00-00-00-00-00). The configuration will show the command with the multicast MAC address 01-00-00-00-00-00. The command can be entered with the multicast address as well, with the same result without a warning.
The set mac unicast-as-multicast enable
command changes
how the switch looks up unicast destination MAC addresses. If the
unicast destination is not found in the FDB (also known as MAC address
table or CAM table), the switch will look for the corresponding
multicast MAC address in the FDB. If an entry is found, it is used
to forward the unicast frame, possibly to multiple ports. Otherwise
the unicast frame is flooded as a regular unknown unicast.
Sending an ARP reply with all-zero sender hardware address reminds of the UNARP mechanism introduced in the experimental RFC 1868. This experimental RFC specifies use of a zero Hardware Address Length, omitting both Sender (called Source in RFC 1868) and Target Hardware addresses from the UNARP packet, instead of sending a normal ARP reply with a 6 byte Sender Hardware Address set to 00-00-00-00-00-00. If so, the receiving system should remove the ARP entry for the IP address from the UNARP reply. The expected result would be an ICMP Host Unreachable error message for attempts to reach the (cluster) IP address invalidated via UNARP. This little known experimental RFC is not widely implemented on networking gear, its use would be quite suprising. (Nowadays, experimental RFCs are time limited with an intent to evaluate the results of the experiment.)
The all-zero MAC address is an invalid source address, which is generally not learned by switches. Thus using a destination MAC address of 00-00-00-00-00-00 results in unknown unicast flooding, which can be abused as a kind of broadcast. One forum post I found mentioned that Sun might have used the all-zero MAC as broadcast MAC address. This could be abused to stop sending data to only a cluster node that stops handling the traffic, and send it to all cluster nodes instead (which should include the new active node) in order to speed up failover inside the cluster.
I have not (yet) found an official explanation of this (UN?)ARP reply sent by Oracle RAC, especially regarding the expected results.
The all-zero MAC address is legitimately used for hardware without a burned in address, whose MAC address needs to be initialized by firmware or software before use. Some USB network adapters are examples of this use. But this all-zero MAC address is intended to be replaced by driver software with a unique non-zero MAC address before use on a network. (This does not always happen, and rumor has it that those addresses have be ssen in real-life networks.)
For a similar, i.e., unknown unicast flooding, problem with normal (non-failover) Microsoft NLB operation see the GTAC Knowledge article EOS: How to configure multicast mac to stop flooding of NLB server traffic via slow path.
Note that ExtremeXOS switches ignore the sender hardware address field of ARP replies by default. They use the sender address of the Ethernet frame containing the ARP packet instead. This breaks many virtual addressing mechanisms in subtle ways, but prevents UNARP-like behavior from causing unknown unicast flooding.
On K/S-Series switches with firmware version 8, an SVI can be
enabled/disabled by both the
set port {enable|disable} vlan.0.X
and
[no] shutdown
commands.
On Enterasys layer 3 switches (B/C/G/K/N/S-Series),
Switched Virtual Interfaces are disabled by default.
The default shutdown
command is not shown in the
configuration. Enabled interfaces show no shutdown
in the
configuration.
This is surprising for people knowing Cisco IOS, because SVIs are enabled
(no shutdown
) by default on Cisco layer 3 switches, and
disabled interfaces are easily identified by showing
shutdown
in the configuration.
On Enterasys layer 3 switches (B/C/G/K/N/S-Series),
loopback interfaces are disabled by default.
The default shutdown
command is not shown in the
configuration. Enabled interfaces show no shutdown
in the
configuration.
This is surprising for people knowing Cisco IOS, because loopback
interfaces are enabled
(no shutdown
) by default on Cisco layer 3 switches and
routers, and disabled interfaces are easily identified by showing
shutdown
in the configuration.
When migrating from N-Series FW 6 to FW 7 or later, e.g., to S-Series, an ACL inbound on the management SVI might create problems.
With FW 6, the switch IP address is usually used for management. If the management workstations or servers are located in a different VLAN, access to the switch management VLAN is restricted by ACLs on the SVI used as gateway. The inbound ACL on that SVI sees traffic originating in the switch management VLAN only. Thus it can be very restrictive.
With FW 7 and later, every N/K/S-Series will have an SVI in the management VLAN. Usually there are at least two N/K/S-Series switches with SVIs in the switch management VLAN to provide redundancy. One of those usually is the active router (VRRP master) and forwards management traffic to the other switches. The management traffic enters the switch acting as active gateway either via a transfer VLAN to another layer 3 switch, or from the management server resp. workstation VLAN SVI. This is the same situation as with FW 6, the switch management SVI's inbound ACL is not consulted. But management traffic to the backup layer 3 switch will enter that switch on the switch management SVI, and thus the inbound ACL there is used. This may result in dropping legit management traffic from a management server, if the migrated ACL allows just traffic coming from switches and denies any other traffic.
I have seen this problem after a migration from N-Series to S-Series, where the RADIUS replies were denied by the inbound ACL on the management interface. As a result no user could authenticate to use the network.
This potential problem is not mentioned in the Transitioning to Firmware v7.0 document.
The RADIUS / NAC solution Extreme Control (formerly known as Enterasys NAC, then as Extreme NAC) uses default settings that can result in failed authentication, i.e., denied network access, if a single packet from the RADIUS server to the switch acting as network access server (NAS) is lost. Intermittent failed authentication can also have sporadic reauthentication failures as a result.
The problem is a mismatch of the RADIUS retransmission cache timer (5 seconds) and the NAS timeout configured by Extreme Control on the NAS switches (15 seconds). With this configuration, the first re-transmitted packet will arrive long after the cache entry has expired, resulting in an Access-Reject RADIUS message if Extreme NAC expects the next message during EAP authentication. MAC authentication is not affected by these default settings, because every Access-Request can be handled independently in this case.
The duration for which an entry in the retransmission cache is held can be configured by defining the undocumented property RADIUS_CLEANUP_DELAY. This sets the cleanup_delay option of FreeRADIUS (used inside Extreme Control to implement the RADIUS protocol). Increasing this value should be combined with adjusting the maximum number of cache sessions by defining the undocumented property RADIUS_MAX_REQUESTS, setting the corresponding option max_requests of FreeRADIUS. The RADIUS timeout and number of retransmit attemps of the switches (NAS) need to be configured accordingly, to ensure that no retransmitted packet arrives at the Extreme Control server after the respective retransmit cache entry has expired.
Network fail-over times for the different redundancy mechanisms (BGP, OSPF, VRRP/HSRP, STP, load balancers, etc.) need to be considered when tuning the various retransmission settings.
This kind of problem would not have happened if RADIUS were using TCP (as TACACS+ does). TCP dynamically adjusts to the network conditions and keeps sessions alive during short-term connectivity problems. The reliable data delivery provided by TCP is needed for a successful multi-step 802.1X authentication process anyway. Additionally, the data sent during 802.1X authentication is much bigger than what fits into one standard Ethernet frame. DNS provides a nice example of a protocol that switches to TCP if it needs to transmit more data than fits into one DNS packet. While RADIUS has a reputation for being robust, 802.1X over RADIUS is brittle and requires a lot of fine-tuning to work really well.
Extreme Control's extra functionality, e.g., host fingerprinting to determine the operating system used by an end system, or MAC to IP mapping, relies on receiving every packet. This cannot be guaranteed in an IP based network, especially if WAN links are involved. IP networks must lose some packets to work correctly, see my On Bufferbloat page for more information.
ACL configuration on 800-Series switches uses a two step process:
Create an ACL profile defining the fields to use
inside the ACL using create access_profile
.
Create the individual ACL rules using the fields defined in the
ACL profile using config access_profile
. The
individual rules are applied to ports or a VLAN in this step.
While you need to add default masks to the fields of the ACL profile, you can (and probably should) specify the masks used in every rule.
create access_profile profile_id 1 profile_name EXAMPLE ip source_ip_mask 255.255.255.0 destination_ip_mask 255.255.255.0 config access_profile profile_id 1 add access_id auto_assign ip source_ip 192.0.2.128 mask 255.255.255.128 destination_ip 192.0.2.0 mask 255.255.255.192 vlan_based vlan_id 1002 permit config access_profile profile_id 1 add access_id auto_assign ip source_ip 192.0.2.0 mask 255.255.255.192 destination_ip 192.0.2.128 mask 255.255.255.128 vlan_based vlan_id 1002 permit config access_profile profile_id 1 add access_id auto_assign ip source_ip 0.0.0.0 mask 0.0.0.0 destination_ip 0.0.0.0 mask 0.0.0.0 vlan_based vlan_id 1002 deny
SNMP access to a switch can be checked using
snmpget
from
Net-SNMP
by querying the system name using the
OID .1.3.6.1.2.1.1.5.0
(SNMPv2-MIB::sysName.0
).
Alternatively, the system description can be queried using the OID
.1.3.6.1.2.1.1.1.0
(SNMPv2-MIB::sysDescr.0
).
Another interesting OID to check is the system uptime, which can be
queried using the OID
.1.3.6.1.2.1.1.3.0
(SNMPv2-MIB::sysUpTime.0
).
snmpget -v1 -c COMMUNITY SWITCH_IP
.1.3.6.1.2.1.1.5.0
snmpget -v2c -c COMMUNITY SWITCH_IP
.1.3.6.1.2.1.1.5.0
snmpget -v3 -l authPriv -a SHA -x AES -u SNMP_USER
-A AUTH_PASSWORD -X PRIV_PASSWORD
SWITCH_IP .1.3.6.1.2.1.1.5.0
SNMP version 3 should be used if possible.
End-to-end IPv4 MTU size which can be used for
path MTU discovery (PMTUD) can be tested using the
ping
program. To do so, the size of the IP packet needs to correspond to the
MTU value, and the don't fragment (DF) bit needs to be set.
An IPv4 packet of exactly MTU size will be transported over the path,
while an IPv4 packet just one byte larger will not. For too large a
packet that may not be fragmented, an ICMP type 3 code 4 (datagram is
too big) error message is generated.
Different ping implementations use different ways to specify the packet size. The IPv4 header size (20 bytes (more with options)) and the ICMP header size (8 bytes) need to be taken into account when calculating the complete packet size from the ICMP data size.
The end-to-end MTU can be reduced by tunneling or overlay mechanisms. It can be increased by allowing jumbo frames on the network devices. Some tunneling implementations transparently fragment too big frames or packets, others do not, and some allow configuration. After implementing, changing, or buying (renting) a tunneled connection, its characteristics need to be tested, including the provided MTU. A simple but useful test is to check whether 1500 byte IP packets can be sent without fragmentation.
ping -s 1472 -Mdo HOST
ping -l 1472 -f HOST
ping start-size 1472 dont-fragment HOST
ping HOST size 1500 df-bit
ping HOST size 1500 df-bit
ping size=1500 HOST do-not-fragment
ping size 1472 do-not-fragment yes host HOST
vmkping -d -s 1472 HOST
ping -d -s 1472 HOST
ping -D -s 1472 HOST
ping -f -s 1472 HOST
Some ping implementations do not allow to control the DF bit, but only the packet size. This cannot be used used to test the MTU directly. One could use a packet capture to find out whether the packets have been fragmented.
If an overlay network does not provide fragmentation, just setting the packet size suffices to test the end-to-end MTU. This is the usual case for VXLAN overlay networks.
Extreme EOS and the Enterasys XSR do not allow control over the DF bit for the ping command. The SecureStacks resp. A/B/C/D/G/I-Series and 800-Series switches do not even allow to specify the packet size for ping.
ping -s 1472 HOST
ping HOST size 1500
Some systems implement a mechanism to automatically try different packet sizes with ping (sometimes called a ping sweep, but that can refer to sweeping a range of IP addresses, too). This can be used to determine the exact MTU on a path.
ping
command without any arguments and answer
both prompts Extended commands [n]: and
Sweep range of sizes [n]: with y, then specify
the start (Sweep min size [36]:) and end
(Sweep max size [18024]:) sizes.
While IOS XR allows a ping sweep using arguments
to the ping
command, it does not allow to specify
the start and end sizes, always sweeping from 36B to 18024B packets
in 1B increments (which is not really useful).ping [vr VR] dont-fragment start-size START
end-size END HOST
ping -D -g START -G END -h INCR
HOST
ping -f -range min START max END HOST
I have written a shell script called pmtud for GNU/Linux systems to perform path MTU discovery using ping.
If you use IPv6 addresses with ping, you do not need to specify that the DF bit needs to be set, because routers are not allowed to fragment IPv6 packets. The IPv6 header does not have a DF bit, actually. You may still need to tell the implementation that you do not want the sending host to fragment the packet. Sometimes there is no possibility to do this, or it does not work, and you cannot use ping to determine the IPv6 path MTU. This did happen to me when I tried the default ping of some GNU/Linux distribution (this was fixed in a later version), and I experienced it with Huawei VRP as well. YMMV.
To show port status and description on an 800-Series switch you can use:
show ports [PORTSTRING] description
To power cycle a PoE device connected to an 800-Series switch you need to disable PoE for the port. The device is still powered if you just disable the port. To reset the PoE powered device connected to port 2 of an 800-Series switch use the following two commands:
config poe ports 2 state disable
config poe ports 2 state enable
The configuration of an 800-Series switch can be saved to a
TFTP server using the command
upload cfg_toTFTP SERVER_IP dest_file FILENAME
.
The file name should have the extension .cfg
.
Sometimes it is necessary to perform remote configuration changes
that have the potential to disrupt the management
connection. On S-Series and similar switches the
configuration restore point feature can be used together
with a timed reboot as a safety net, similar to using
reload in
on Cisco IOS or reboot time
on EXOS.
Because Extreme (formerly Enterasys) EOS automatically saves every
configuration command immediatly on S-Series and similar switches, the
timed reboot (reset in
) alone does not suffice.
Set up a configuration restore-point and schedule a reboot in 10 minutes to automatically recover from a configuration error:
set config restore-point KnownGood
show config restore-point
(note the Index)
configure restore-point Index
reset in 0:10
Then perform the risky changes, verify they worked, and cancel both the scheduled reboot and the configuration restore point:
reset cancel
configure restore-point Index none
Caution! The above description is based on EOS documentation, but I have not yet tried it out!
EOS switches by default accept any tagged frame entering a
port.
This can result in high CPU load if one side of a trunk is
configured with
VLANs not configured (and not needed) on the other side with many
unknown unicast
frames inside one or more of those VLANs. The receiving switch
may be overloaded, which may result in dropped frames that actually
have to traverse the overloaded switch. In this case it helps to
enable the so called Ingress Filter for the trunk
with the command set port ingress-filter PORT-STRING
enable
. The result is that only tagged frames with a VLAN tag
active in egress direction for the port (use show port egress
PORT_STRING
to display) is accepted. This filter
acts early enough to avoid high CPU for unknown unicast frames in
filtered out VLANs.
Another potential problem with disabled Ingress Filter is
a unidirectional loop. A port that is not in any VLAN egress
list, i.e., the output of show port egress
is empty, but
that has a disabled Ingress Filter, still accepts any tagged frames
ingressing the port. Thus it does not break any forwarding loop that
includes this port in ingress direction, it only breaks a forwarding
loop that includes it in egress direction (because of the empty egress
list for this port).
(I have encountered the above problems in production networks.)
Most other switch vendors allow only the behavior of activating the Ingress Filter. Thus I would strongly recommend to always enable the Ingress Filter for all ports of EOS switches, unless there really is an actual need to disable it.
The Denial of Service (DoS) control settings on
A/B/C/D/G/I-Series switches (also known as SecureStacks) can
have unintended side effects. For example, using set
dos-control udpport
drops VoIP traffic of at least some
Unify IP phones, because that traffic uses identical source and
destination ports. I have experienced this with a C5.
As documented in the CLI Reference, DoS control adds global drop rules in order to protect the network, i.e., the devices connected to (or through) the switch. This feature is not just protecting the switch itself, i.e., it is not host DoS protection.
Back to my homepage.