• Switch Management Concepts
  • This chapter discusses many of the features used to manage the switch, and explains many concepts and important points regarding these features. Configuring the Switch to implement these concepts is discussed in detail in the next chapters.

    1. Local Console Management
    2. Local console management involves the administration of the Switch via a direct connection to the RS-232 DCE console port. This is an Out-Of-Band connection, meaning that it is on a different circuit than normal network communications, and thus works even when the network is down.

      The local console management connection involves a terminal or PC running terminal emulation software to operate the Switch’s built-in console program (see Chapter 6, “Using the Console Interface”). Using the console program, a network administrator can manage, control and monitor the many functions of the Switch.

      Hardware components in the Switch allow it to be an active part of a manageable network. These components include a CPU, memory for data storage, other related hardware, and SNMP agent firmware. Activities on the Switch can be monitored with these components, while the Switch can be manipulated to carry out specific tasks.

      1. Diagnostic (Console) Port (RS-232 DCE)

    Out-of-band management requires connecting a terminal, such as a VT-100 or a PC running terminal emulation program (such as HyperTerminal, which is automatically installed with Microsoft Windows) a to the RS-232 DCE console port of the Switch. Switch management using the RS-232 DCE console port is called Local Console Management to differentiate it from management done via management platforms, such as D-View, HP OpenView, etc.

    The console port is set for the following configuration:

    Make sure the terminal or PC you are using to make this connection is configured to match these settings.

    If you are having problems making this connection on a PC, make sure the emulation is set to VT-100 or ANSI. If you still don’t see anything, try hitting <Ctrl> + r to refresh the screen.

      1. IP Addresses and SNMP Community Names
      2. Each Switch has its own IP Address, which is used for communication with an SNMP network manager or other TCP/IP application (for example BOOTP, TFTP). You can change the default Switch IP Address to meet the specification of your networking address scheme.

        In addition, you can also set an IP Address for a gateway router. This becomes necessary when the network management station is located on a different IP network as the Switch, making it necessary for management packets to go through a router to reach the network manager, and vice-versa.

        For security, you can set in the Switch a list of IP Addresses of the network managers that you allow to manage the Switch. You can also change the default Community Name in the Switch and set access rights of these Community Names.

      3. Traps

    Traps are messages that alert you of events that occur on the Switch. The events can be as serious as a reboot (someone accidentally turned OFF the Switch), or less serious like a port status change. The Switch generates traps and sends them to the network manager (trap managers). The following lists the types of events that can take place on the Switch.

    You can also specify which network managers may receive traps from the Switch by setting a list of IP Addresses of the authorized network managers.

    Trap managers are special users of the network who are given certain rights and access in overseeing the maintenance of the network. Trap managers will receive traps sent from the Switch; they must immediately take certain actions to avoid future failure or breakdown of the network.

    The following are trap types a trap manager will receive:

      1. MIBs
      2. Management information and counters are stored in the Switch in the Management Information Base (MIB). The Switch uses the standard MIB-II Management Information Base module. Consequently, values for MIB objects can be retrieved from any SNMP-based network manager software. In addition to the standard MIB-II, the Switch also supports its own proprietary enterprise MIB as an extended Management Information Base. These MIBs may also be retrieved by specifying the MIB’s Object-Identity (OID) at the network manager. MIB values can be either read-only or read-write.

        Read-only MIBs variables can be either constants that are programmed into the Switch, or variables that change while the Switch is in operation. Examples of read-only constants are the number of ports and types of ports. Examples of read-only variables are the statistics counters such as the number of errors that have occurred, or how many kilobytes of data have been received and forwarded through a port.

        Read-write MIBs are variables usually related to user-customized configurations. Examples of these are the Switch’s IP Address, Spanning Tree Algorithm parameters, and port status.

        If you use a third-party vendors’ SNMP software to manage the Switch, a diskette listing the Switch’s propriety enterprise MIBs can be obtained by request. If your software provides functions to browse or modify MIBs, you can also get the MIB values and change them (if the MIBs’ attributes permit the write operation). This process however can be quite involved, since you must know the MIB OIDs and retrieve them one by one.

      3. Packet Forwarding
      4. The Switch learns the network configuration and uses this information to forward packets. This reduces the traffic congestion on the network, because packets, instead of being transmitted to all segments, are transmitted to the destination only. Example: if Port 1 receives a packet destined for a station on Port 2, the Switch transmits that packet through Port 2 only, and transmits nothing through the other ports.

        1. Aging Time
        2. The Aging Time is a parameter that affects the auto-learn process of the Switch in terms of the network configuration. Dynamic Entries, which make up the auto-learned-node address, are aged out of the address table according to the Aging Time that you set.

          The Aging Time can be from 10 seconds to 9999 seconds. A very long Aging Time can result with the out-of-date Dynamic Entries that may cause incorrect packet filtering/forwarding decisions.

          On the other hand, if the Aging Time is too short, many entries may be aged out soon, resulting in a high percentage of received packets whose source addresses cannot be found in the address table, in which case the Switch will broadcast the packet to all ports, negating many of the benefits of having a switch.

        3. Filtering Database

    A switch uses a filtering database to segment the network and control communications between segments. It also filters packets off the network for intrusion control (MAC Address filtering).

    For port filtering, each port on the switch is a unique collision domain and the switch filters (discards) packets whose destination lies on the same port as where it originated. This keeps local packets from disrupting communications on other parts of the network.

    For intrusion control, whenever a switch encounters a packet originating from or destined to a MAC address defined by the user, the switch will discard the packet.

    Filtering includes:

    1. Dynamic filtering Automatic learning and aging of MAC addresses and their location on the network. Filtering occurs to keep local traffic confined to its segment.
    2. MAC address filtering The manual entry of specific MAC addresses to be filtered from the network.
    3. Filtering done by the Spanning Tree Protocol Can filter packets based on topology, making sure that signal loops don’t occur.
    4. Filtering done for VLAN integrity. Packets from a member of a VLAN (VLAN 2, for example) destined for a device on another VLAN (VLAN 3) will be filtered.
      1. Spanning Tree Algorithm

    The Spanning Tree Algorithm (STA) in the Switch allows you to create alternative paths (with multiple switches or other types of bridges) in your network. These backup paths are idle until the Switch determines that a problem has developed in the primary paths. When a primary path is lost, the switch providing the alternative path will automatically go into service with no operator intervention. This automatic network reconfiguration provides maximum uptime to network users. The concept of the Spanning Tree Algorithm is a complicated and complex subject and must be fully researched and understood. Please read the following before making any changes.

        1. STA Operation Levels
        2. STA operates on two levels: the bridge level and the port level. On the bridge level, STA calculates the Bridge Identifier for each Switch, then sets the Root Bridge and the Designated Bridges. On the port level, STA sets the Root Port and Designated Ports. Details are as follows:

          1. On the Bridge Level
          1. On the Port Level
        1. User-Changeable STA Parameters

    The factory default setting should cover the majority of installations. However, it is advisable to keep the default settings as set at the factory, unless it is absolutely necessary. The user changeable parameters in the Switch are as follows:

    Note: The Hello Time cannot be longer than the Max. Age. Otherwise, a configuration error will occur.

    Observe the following formulas when you set the above parameters:

    1. Max. Age = 2 x (Forward Delay - 1 second)
    2. Max. Age = 2 x (Hello Time + 1 second)
        1. Illustration of STA

    A simple illustration of three Bridges (or the Switch) connected in a loop is depicted in Figure 5-1. In this example, you can anticipate some major network problems if the STA assistance is not applied. For instance, if Bridge 1 broadcasts a packet to Bridge 2, Bridge 2 will broadcast it to Bridge 3, and Bridge 3 will broadcast it to Bridge 1 and so on. The broadcast packet will be passed indefinitely in a loop, causing a serious network failure.

    To alleviate network loop problems, STA can be applied as shown in Figure 5-2. In this example, STA breaks the loop by blocking the connection between Bridge 1 and 2. The decision to block a particular connection is based on the STA calculation of the most current Bridge and Port settings. Now, if Bridge 1 broadcasts a packet to Bridge 3, then Bridge 3 will broadcast it to Bridge 2 and the broadcast will end there.

    STA setup can be somewhat complex. Therefore, you are advised to keep the default factory settings and STA will automatically assign root bridges/ports and block loop connections. However, if you need to customize the STA parameters, refer to Table 5-1.


    1. Figure 5-1. Before Applying the STA Rules


    1. Figure 5-2. After Applying the STA Rules

    STA parameters




    Bridge Priority

    lower the #, higher the priority

    Increases chance of becoming the Root Bridge

    Avoid, if the switch is used in workgroup level of a large network

    Hello Time

    1 - 10 sec.

    No effect, if not Root Bridge

    Never set greater than Max. Age Time

    Max. Age Time

    6 - 40 sec.

    Compete for Root Bridge, if BPDU is not received

    Avoid low number for unnecessary reset of Root Bridge

    Forward Delay

    4 - 30 sec.

    High # delays the change in state

    Max. Age £ 2 x (Forward Delay - 1) Max. Age ³ 2 x (Hello Time + 1)

    Port Level STA parameters

    Enable / Disable

    Enable / Disable

    Enable or disable this LAN segment

    Disable a port for security or problem isolation

    Port Priority

    lower the #, higher the priority

    Increases chance of become Root Port


    1. Table 5-1. User-selective STA parameters
      1. Port Trunking

    Port trunking is used to combine a number of ports together to make a single high-bandwidth data pipeline. The participating parts are called members of a trunk group, with one port designated as the anchor of the group. Since all members of the trunk group must be configured to operate in the same manner, all settings changes made to the anchor port are applied to all members of the trunk group. Thus, when configuring the ports in a trunk group, you only need to configure the anchor port.

    The Switch supports 3 trunk groups, which may include from 2 to 8 switch ports each, except for the third trunk group which consists of the 2 ports of the Slot 1, 100BASE-TX or 100BASE-FX front-panel module. The anchor port for the first group is preset as port 5, the anchor port for the second group is port 13 and the anchor port for the third group is the first port (1x) on the 2-port module.

    1. Figure 5-3. Port trunking example

    The switch treats all ports in a trunk group as a single port. As such, trunk ports will not be blocked by Spanning Tree (unless a redundant link with higher STP priority is present).

    Data transmitted to a specific host (destination address) will always be transmitted over the same port in a trunk group. This allows packets in a data stream to arrive in the same order they were sent. A trunk connection can be made with any other switch that maintains host-to-host data streams over a single trunk port. A trunk connection cannot be made with switches that perform load-balancing on a per-packet basis.

      1. VLAN
      2. VLANs are a collection of switch ports grouped together in a secure, autonomous broadcast and multicast domain. VLANs allow a network to be segmented in order to reduce the size of broadcast domains. All Ethernet packets (unicast, broadcast, multicast, unknown, etc.) entering a VLAN will only be forwarded to the ports that are members of that VLAN.

        Another benefit of VLANs is that you can change the network topology without physically moving stations or changing cable connections. Stations can be “moved” simply by changing VLAN settings from one VLAN (the sales VLAN, for example) to another VLAN (the marketing VLAN). This allows VLANs to accommodate network moves, changes, and additions with the utmost flexibility.

        VLANs can also provide a level of security to your network. Port-based VLANs allow you to configure ports to not send or receive packets outside of the VLAN.

        The untagging feature of IEEE 802.1Q VLANs allow VLANs to work with legacy switches and NICs that don’t recognize VLAN tags in packet headers. The tagging feature allows VLANs to span multiple 802.1Q-compliant switches through a single physical connection and allows Spanning Tree to be enabled on all ports and work normally.

        1. IEEE 802.1Q VLANs
        2. The Switch supports up to 96 IEEE 802.1Q (port-based) VLANs. Port-based VLANs limit traffic that flows into and out of switch ports. Thus, all devices connected to a port are members of the VLAN(s) the port belongs to, whether there is a single computer directly connected to a switch, or an entire department.

          On port-based VLANs, NICs do not need to be able to identify 802.1Q tags in packet headers. NICs send and receive normal Ethernet packets. If the packet’s destination lies on the same segment, communications take place using normal Ethernet protocols. Even though this is always the case, when the destination for a packet lies on another switch port, VLAN considerations come into play to decide if the packet gets dropped by the switch or delivered.

          There are two key components to understanding IEEE 802.1Q VLANs; Port VLAN ID numbers (PVID) and VLAN ID numbers (VID). Both variables are assigned to a switch port, but there are important differences between them. A user can only assign one PVID to each switch port. The PVID defines which VLAN a switch will forward packets from the connected segment on, when packets need to be forwarded to another switch port or somewhere else on the network. On the other hand, a user can define a port as a member of multiple VLANs (VIDs), allowing the segment connected to it to receive packets from many VLANs on the network. These two variables control a port’s ability to transmit and receive VLAN traffic, and the difference between them provides network segmentation, while still allowing resources to be shared across more than one VLAN.

          1. VLAN Segmentation
          2. Take for example a packet that is transmitted by a machine on Port 1 that is a member of VLAN 2 and has the Port VLAN ID number 2 (PVID=2). If the destination lies on another port (found through a normal forwarding table lookup), the switch then looks to see if the other port (Port 10) is a member of VLAN 2 (and can therefore receive VLAN 2 packets). If port 10 is not a member of VLAN 2, then the packet will be dropped by the switch and will not reach it’s destination. If Port 10 is a member of VLAN 2, the packet will go through. This selective forwarding feature based on VLAN criteria is how VLANs segment networks. The key point being that Port 1 will only transmit on VLAN 2, because it’s Port VLAN ID number is 2 (PVID=2).

          3. Sharing Resources Across VLANs

    Network resources such as printers and servers however, can be shared across VLANs. This is achieved by setting up overlapping VLANs as shown in the diagram below.

    1. Figure 5-4. Example of typical VLAN configuration

    In the above example, there are three different VLANs and each port can transmit packets on one of them according to their Port VLAN ID (PVID). However, a port can receive packets on all VLANs (VID) that it belongs to. The assignments are as follows:

    Transmit on VLAN #


    Member of VLAN #





    Port 1





    Port 2



    Port 3



    Port 7






    Port 11





    Port 12



    1. Table 5-2. Example of possible VLAN assignments

    The server attached to Port 7 is shared by VLAN 1 and VLAN 2 because Port 7 is a member of both VLANs (it is listed as a member of VID 1 and 2). Since it can receive packets from both VLANs, all ports can successfully send packets to it to be printed. Ports 1, 2 and 3 send these packets on VLAN 1 (their PVID=1), and Ports 11 and 11 send these packets on VLAN 2 (PVID=2). The third VLAN (PVID=3) is used by the server to transmit files that had been requested on VLAN 1 or 2 back to the computers. All computers that use the server will receive transmissions from it since they are all located on ports which are members of VLAN 3 (VID=3).

          1. VLANs Spanning Multiple Switches

    VLANs can span multiple switches as well as your entire network. Two considerations to keep in mind while building VLANs of this sort are whether the switches are IEEE 802.1Q-compliant and whether VLAN packets should be tagged or untagged.

    Definitions of relevant terms are as follows:

            1. VLANs Over 802.1Q-compliant Switches

    When switches maintaining the same VLANs are 802.1Q-compliant, it is possible to use tagging. Tagging puts 802.1Q VLAN information into each packet header, enabling other 802.1Q-compliant switches that receive the packet to know how to treat it. Upon receiving a tagged packet, an 802.1Q-compliant switch can use the information in the packet header to maintain the integrity of VLANs, carry out priority forwarding, etc.

    Data transmissions between 802.1Q-compliant switches take place as shown below.

    Figure 5-5. Data transmissions between 802.1Q-compliant Switches

    In the above example, step 4 is the key element. Because the packet has 802.1Q VLAN data encoded in its header, the ingress port can make VLAN-based decisions about its delivery: whether server #2 is attached to a port that is a member of VLAN 2 and, thus, should the packet be delivered; the queuing priority to give to the packet, etc. It can also perform these functions for VLAN 1 packets as well, and, in fact, for any tagged packet it receives regardless of the VLAN number.

    If the ingress port in step 4 were connected to a non-802.1Q-compliant device and was thus receiving untagged packets, it would tag its own PVID onto the packet and use this information to make forwarding decisions. As a result, the packets coming from the non-compliant device would automatically be placed on the ingress ports VLAN and could only communicate with other ports that are members of this VLAN.

      1. Broadcast Management
      2. Broadcast transmissions, packets sent to every devices on the LAN, are a vital part of any network. However, they can often cause problems on the network and even network failure. For this reason the Switch has a number of tools for managing broadcast packets on your network.

        1. Broadcast Storms
        2. Broadcast storms are a common problem on today’s networks. Basically, they consist of broadcast packets that flood and/or are looped on a network causing noticeable performance degradation and in extreme cases, network failure. Some of the causes of broadcast storms are network loops, malfunctioning NICs, bad cable connections, and applications or protocols that generate broadcast traffic.

          Broadcast storms can originate from any number of sources, and once they are started, they can be self-perpetuating, and can even multiply the number of broadcast packets on the network over time. In the best case, network utilization will be high and bandwidth limited until the hop counts for all broadcast packets have expired, whereupon the packets will be discarded and the network will return to normal. In the worst case, they will multiply, eventually using up all the network bandwidth (although network applications will usually crash long before this happens), and cause a network meltdown.

          Broadcast storms have long been a concern for network administrators with routers traditionally being used to prevent their occurrence, and if that failed, limit their scope. However, switches are now able to limit broadcast domains better and cheaper than routers. Also, many switches have broadcast sensors and filters built into each port to further control broadcast storms—such as the Switch you have purchased.

        3. Port-based Broadcast Packet Filter
        4. The Switch is equipped with sensors that count the number of broadcast frames arriving at each port. When a certain level (rising threshold) is reached, the sensors can initiate a broadcast filter (rising action) which drops all broadcast packets arriving at the affected port. This effectively partitions the broadcast packets from the rest of the network, thereby limiting the effects of a broadcast storm. The port-based Broadcast Storm Filter settings can be set by the user. Please refer to the Configure Ports section of this manual for more detailed explanations regarding port-based Broadcast Storm filter settings.

        5. MAC-based Broadcast Packet Filter

    Broadcast domains can also be managed on the MAC level. In this case, broadcast domains can be defined to include specific devices (MAC addresses). To do this, simply enter the MAC addresses of the computers and peripherals you wish to include in the broadcast domain(s). Any unknown or broadcast packets generated within the Mac-based broadcast domain will only be sent to the other members. Other parts of the network are effectively shielded. Configuring MAC-based broadcast domains is done in the VLANs and MAC-based Broadcast Domains submenus of the Console or Web-based management programs.