etPass is a vendor-neutral network environment for
quarantining clients identified as being out of compliance with your
NetPass currently supports Cisco and Nortel switches. Those switches
must support VLAN trunking. Specific models approved (tested, known
to work) for use with
- 3500 series (3548XL, 3524XL, 3550-12G, 3550-24EMI)
- 6500 series
- Late model 350 (equivalent to the 450 without the cascade
NetPass will not work with earlier 350s that do not
support trunking of VLANs.
NetPass uses SNMP to control the switches. It should be possible to
develop an appropriate plugin for any switch that meets the
following feature requirements:
- SNMP Managable
- The switch must be managable via SNMP. For efficiency reasons,
SNMPv2, specifically, must be supported. If it is not support by
the switch, then processing of the SNMP commands is likely to
take too long - resulting in timeouts and delays and use
- 802.1q VLAN Tagging
- The switch must support 802.1q VLAN tagging. In addition, it
must permit trunking of VLANs to other switches. For example, the
original Nortel 350 switch supported tagging of ports into VLANs,
but only internally. The tags could not be propogated (trunked)
outside of the switch. For that reason, the original Nortel 350
can not be used with NetPass.
- MIB-II Linkup/Linkdown Traps
- Some of NetPass' functionality depends upon being able to
receive notification of client port state changes.
- Layer-2 Topology Aware
- Nortel calls this Autotopology and Cisco
uses CDP. This feature allows the switches to build a map of
how they are connected which, in turn, allows NetPass to more efficiently
locate the client's port. Note that this feature is typically
implemented in a proprietary way - meaning that if you use a mixture of Nortel and
Cisco switches, they won't be able to exchange layer-2 topology
information. It's possible to deploy NetPass in a mixed vendor
environment without significant performance degradation. The
actual befit of having the topology information depends upon the
architecture of your network.
In addition to the above, the switch should be able to process SNMP
requests in a timely manner. If the switch takes too long, is
underpowered, or simply can't handle multiple concurrent SNMP
queries, then timeouts and delays are likely to occur.
As of this
writing (Nov'04), Nortel 470's when deployed in a hybrid stack (a
mixture of 470s and 450s) are not capable of responding to the SNMP
queries rapidly enough. Standalone units and homogenous stacks of
470s or 450s don't experience this problem.