Tuesday, August 28, 2007

Basic Ethernet Switch Replacement Requirements

I mentioned in the last TCP/IP Meeting that we have started to look for replacements for our aging Ethernet switches for the TNS LAN Service. We sent out a Request for Information (RFI) asking what devices could satisfy the following requirements. We sent the RFI to the nine vendors that Gartner placed in the Magic Quadrant for Campus LAN, which is an interesting read. They are (alphabetically):

Here is the text of the RFI as we sent it out.

Background

The purpose of this document is to outline the requirements of new devices to replace our existing Basic Ethernet Switch family. Currently there are many such devices spread across our Statewide Campus Network in the form of HP ProCurve 4000M (J4121A) and 3Com 4400 and 4900 family devices (3C17203, 3C17204, 3C17205, 3C17210, 3C17700, and 3C17701).

Currently, the Basic Ethernet Switch provides 10/100 and 100/1000 copper user ports and connects the Penn State Integrated Backbone via 100BASE-FX or 1000BASE-LX. We aggregate switches within a telecommunications room using 100BASE-TX or 1000BASE-T to provide the required number of user ports. We also connect switches between telecommunications rooms within a building using 100BASE-FX or 1000BASE-LX.

Taking into account potential future growth, upgrades in services, and the need for additional user bandwidth, the new Basic Ethernet Switch must meet the following listed requirements.

The general requirements below apply to all applications for the Basic Ethernet Switch. Afterwards, specific application requirements are given for specific applications of the switch.

General Requirements

Availability and Suitability
  • AS1. Currently shipping to customers
  • AS2. All of the following features currently available in shipping product
  • AS3. Does not require the use of proprietary mechanisms, where an IEEE, IETF, or Internet RFC standards based mechanism is currently available
Configuration and Management
  • CM1. Stores configuration settings in non-volatile memory
  • CM2. Allows transfer of configuration settings to another device
  • CM3. Can use ASCII file to transfer the configuration settings
  • CM4. Can reload an edited ASCII configuration file to make configuration changes
  • CM5. Manageable locally using console access
  • CM6. Manageable remotely using SSHv2, SNMP, or HTTPS
  • CM7. Provides configurable security methods for all management methods
  • CM9. Provides an interface for SNMP management, version 2c or higher
  • CM10. Uses standard MIB, or proprietary MIB is provided
  • CM11. Allows configuration of all settings without using proprietary software
  • CM12. Provides mechanism to upgrade firmware
  • CM13. Uses IGMP to control multicast traffic
Monitoring
  • MN1. Generates SNMP traps
  • MN2. Generate syslog messages
  • MN3. Date and time stamps syslog messages
  • MN4. Uses either NTP or SNTP to set and maintain time
  • MN5. Supports network monitoring via RMON
  • MN6. Can mirror a port to another
  • MN7. Propagates framing errors to the mirror port
  • MN8. Mirrors port traffic at line rate
  • MN9. Differentiates between mirror port inflows and outflows
  • MN10. Alerts the monitoring port or log record if mirror packets are dropped
Security
  • SC1. Does not forward unicast packets not destined for an individual port
  • SC2. Does not forward packets to a port before learning the MAC address of the attached device
  • SC3. Can remotely disable and enable individual ports
  • SC4. Can continue to operate when ports are placed in the loopback condition (pin 1 to pin 3 and pin 2 to pin 6)
  • SC5. Does not degrade to hub operation under ARP flood
Other Standards
  • OS1. Supports IEEE 802.1Q VLANs
  • OS2. Supports at least 8 VLANs per port
  • OS3. Supports IEEE 802.1AB Link Layer Discovery Protocol
Interface Options and Specifications
  • IO1. Passes IPv4 unicast packets at full line rate
  • IO2. Passes IPv4 multicast packets at full line rate
  • IO3. Passes IPv6 unicast packets at full line rate
  • IO4. Passes IPv6 multicast packets at full line rate
  • IO5. Passes frames as small as 64 bytes at full line rate
  • IO6. Passes all frames without loss
  • IO7. Supports STP
  • IO6. Ports auto-negotiate
  • IO7. Individual ports settable to 10 Mbps half duplex
  • IO8. Individual ports settable to 100 Mbps full duplex
  • IO9. Individual ports settable to 1000 Mbps full duplex
  • IO10. Provides a backplane that is non-blocking at full port capacity and with port-level interconnects running at full line rate.
  • IO11. Passes jumbo frames as large as 9200 bytes at full line rate
Physical Characteristics
  • PC1. A 19” rack-mountable version is available
  • PC2. Port connectors provided on the front panel
Environmental
  • EN1. Operates in temperatures between 32 and 120°F 104°F
  • EN2. Operates in humidity up to 90% non-condensing humidity
Failure Rates
  • FR1. Has an MTBF no less than 100,000 hours

Specific Application Requirements

Administrative Edge Switch

The Administrative Edge switch provides network connectivity for trusted users. These networks may also support associated file servers, printers, or other network devices.

  • AE1. Provides at least 32 10/100/1000BASE-T ports
  • AE2. Provides at least 2 100BASE-FX ports
  • AE3. Provides at least 2 1000BASE-LX ports
Administrative Aggregation Switch

The Administrative Aggregation switch is used to aggregate Administrative Edge switches within or between telecommunication rooms.

  • AA1. Provides at least 6 100BASE-FX ports
  • AA2. Provides at least 6 1000BASE-LX ports
  • AA3. Provides at least 1 10GBASE-LR port
VoIP Edge Switch

The VoIP Edge Switch provides network connectivity for VoIP handsets on our dedicated VoIP network.

  • VE1. Provides at least 24 10/100BASE-T ports
  • VE2. Provides at least 2 100BASE-FX ports
  • VE3. Provides at least 2 1000BASE-LX ports
  • VE4. Blocks forwarding of Cisco Discovery Protocol (CDP) packets
  • VE5. Provides both IEEE 802.3af and Cisco Inline Power (CIP) to each port based on the requirements of the detected media endpoint
  • VE6. Allows an endpoint MAC address to be associated with each port such that only traffic from that device is accepted
  • VE7. Supports TIA-1057 Link Layer Discovery Protocol for Media Endpoint Devices
VoIP Aggregation Switch

The VoIP Aggregation Switch is used to aggregate VoIP Edge networks between buildings.

  • VA1. Provides at least 16 100BASE-FX ports
  • VA2. Provides at least 16 1000BASE-LX ports
VCoIP Edge Switch

The VCoIP Edge Switch provides network connectivity for videoconferencing devices connected to our dedicated VCoIP network.

  • VC1. Provides at least 4 100BASE-TX ports
  • VC2. Provides at least 1 1000BASE-LX port
Residence Hall Edge Switch

The Residence Hall Edge Switch provides network connectivity to students in residence halls.

  • RE1. Provides at least 32 10/100BASE-T ports
  • RE2. Allows an endpoint MAC address to be associated with each port such that only traffic from that device is accepted
  • RE3. Allows an endpoint IP address to be associated with each port such that only traffic from that device is accepted
  • RE4. Provides at least 1 100BASE-FX port
  • RE5. Provides at least 1 1000BASE-LX port
Wireless Edge Switch

The Wireless Edge Switch provides network connectivity for wireless access point devices on our dedicated wireless network.

  • WE1. Provides at least 24 100BASE-TX ports
  • WE2. Provides at least 1 100BASE-FX port
  • WE3. Provides at least 1 1000BASE-LX port
  • WE4. Provides IEEE 802.3af power

Labels:

posted by Mark (the Brush Valley Brewer) @ 8/28/2007 08:31:00 AM  5 Comments

5 Comments:

At 11/13/2007 11:08:00 AM , Anonymous Derek Morr said...

I'm curious about the level of IPv6 support in the TNS switch requirements you posted in your blog.

For example, should requirement CM6 (manage remotely over SSH, SNMP or HTTPS) be interpreted as requiring IPv6 support for SSH, SNMP or HTTPS?

Likewise, what about CM13 (use IGMP)? IPv6 folds multicast group management into ICMPv6.

Should requirements MN1 (SNMP) and MN4 ( (S)NTP ) be interpreted as requiring SNMP- and (S)NTP-over-IPv6?

Also, what about RE3 (restricting a port to an IP address)? Does this include an IPv6 address? How will this restriction handle a host with privacy addresses (RFC 4941) enabled? Of course, it's not clear if or how privacy addressses are compatible with AD-20.

 
At 11/13/2007 11:25:00 AM , Blogger Mark Linton said...

Awesome questions! Disappointing answers, but great questions.

Few vendors currently provide access to the management functions of their devices through IPv6, though this is primarily our motivator in asking about IPv6 support. After all, at the Ethernet layer, IPv6 is backwards compatible with IPv4 so "passing" IPv6 is a no-brainer.

We have pointed out to vendors who use open-source TCP stacks on their linux based platforms that they must actually go out of their way to prevent their devices from being manageable over IPv6. I imagine that they have simply not exposed a user interface for configuring the management address. Hopefully some enlightened vendor will finally get it and provide that one extra command to enable IPv6 management. The one that is first will get a lot of business.

 
At 11/15/2007 11:54:00 AM , Anonymous Derek Morr said...

You might want to ask vendors about their support for IPv6 Ready certification. I haven't see any switched on their lists, but that might change if customers start asking for certification.

 
At 7/17/2008 03:25:00 PM , Anonymous Derek Morr said...

I know it's too late for this to be useful, but I'll ask anyway. Should the security requirements be amended to include to block specific services, e.g. bogus DHCP advertisements? Or for IPv6, bogus Router Advertisements? I believe Cisco provides this in their Advanced IP Services stack.

 
At 7/19/2008 07:34:00 AM , Blogger Mark Linton said...

Interesting suggestions, Derek. Although we didn't ask for it, as you observe, many modern switches include these abilities. In fact we are currently playing with some of these advanced features in the lab. We are looking at the ability to prevent a user from serving DHCP, eliminating an avenue to man-in-the-middle attacks. We are looking at ways to prevent ARP cache poisoning attacks. We hope to implement these security enhancements where appropriate, soon.

 

Post a Comment

<< Home