Modular Chassis vs Fixed Configuration Switches – Part 2 When/Where

Part 2 of my chassis vs fixed config switch showdown. In this post, I’ll provide some examples of where you might find both form factors deployed and some of the use cases for both. Click here for part 1 of this series.


Fixed Configuration

  • Campus

One of the more obvious places to find fixed configuration switches is in the campus network. This may include a campus of all sizes, from SMB to large enterprise. Here, the best bang for your buck lends itself to fixed-port switches since you typically will see “dumb switches” deployed in the access layer for port density and provide host connectivity to your network. Examples include lower-end Catalyst 2900 series and Catalyst 3600/3700 series switches.

Not only will you find these switches in the access of campus networks. Many smaller joints will use mid-range Catalyst 3750’s (for example) and stack them for distribution and/or core layer functions. Some of the advantages of using a switch stack for your core are distributed control plane across the stack, as well as port density for the rack space. If you’re connecting a bunch of dumb Layer 2 switches across your access, you can easily uplink them to slightly-beefier Layer 3 switches such as 3560’s and 3750’s arranged in a stack configuration. Of course, you are subject to hardware failures since these platforms do not have any redundancy built in to each member switch. However, for smaller organizations that just require the number of ports in a (relatively) small package, these do just fine.

  • Data Center

Fixed-port switches also find themselves in many “top-of-rack” (ToR) deployments. One only has to look as far as the Nexus 5000 Series, Juniper’s EX switching line, Brocade’s VDX line and countless other vendors. These switches typically have the 10 Gigabit density requires to connect large numbers of servers. Depending on your requirements, native Fibre Channel can also be used (in the case of Cisco Nexus 5500’s and Brocade VDX 6700’s) to provide FCoE connectivity down to servers. Rack space and port density again are factors when deploying these fixed configuration switches. In the case of data centers, the FCoE capabilities are also typically found on these platforms where they may not exist in chassis offerings.

  • ISP

One lesser-seen place to find fixed-port switches is in an ISP environment. Metro Ethernet comes to mind here. Providing Layer 2 VPN (L2VPN) services, ISP’s need equipment that can interface with the CPE and provide the connectivity up to the SP core. Cisco’s ME Series finds that place on this list, providing Q-in-Q/PBB as “dumb SP access”.

Modular Chassis

  • Campus

In the campus network, you’ll seen chassis’s in all places. On the one hand, with proper density and power requirements, you can easily deploy something like a Cisco Catalyst 4500E in a wiring closest for host connectivity. On the other hand, you would also see Catalyst 6500E’s in the campus core, providing high-speed switching with chassis-style redundancy to protect against single-device failures. Redundant power and supervisors help mitigate failures of one core device.

  • Data Center

In classical designs, the data center core is where you’d most likely see a chassis-based switch deployed. High-speed switching is the name of the game here, as well as resiliency against failures. Again, the redundant hardware found in chassis’s protect against failures in the data, control and management plane. Cisco Nexus 7000’s and Juniper’s high-end EX8200 platforms

In some designs, you may see a chassis switch deployed in an “End of Row” (EoR) fashion. This follows the design principles of the fixed-config ToR deployments, except here you could deploy a chassis switch to (again) improve redundancy. While definitely not required for all environments, if you couldn’t possibly allow a failure of your first switch that touches the end hosts, the extra redundancy (supervisors, power, switch fabrics, etc.) fit the bill.

  • ISP

Since I don’t work in the field of service providers, I’ll present what I feel are appropriate places to find a chassis-based switch. More than likely you’ll be using chassis-based routers here but I’ll include it for completeness. Cisco 6500/7600, ASR1000/9000’s, Juniper MX, all chassis offerings that you could see in an ISP’s network. This includes (but not limited to) ISP core for high-speed MPLS or IP switching/routing and PE deployments. This is where rich services provided by these offerings live, in order for service providers to be able to offer an array of MPLS-based services. This extends from L3VPNs to L2VPNs as well (either L3TPv3-based, EoMPLS-based or VPLS-based deployments). Being critical/core devices, I would imagine most service providers to require the level of fault-tolerance offered by a chassis-based system, especially with strict SLA’s with customers.


And there you have it. Hopefully, I’ve given you a good overview of the what, where, when, and why of fixed configuration and modular chassis switches. Given the state of things with our vendors, you can typically find any and all form factors provided by each and hopefully will choose the fit platform to fit the requirements of your environment. Cisco, Juniper, Brocade and HP are the first names that I can think of. There are other players as well including Arista, BNT, Dell, Huawei, Alcatel-Lucent, and a slew of others might fit specific markets and environments but may not cover the broad spectrum required for every network. As always, do your research and you’ll find what you need just fine.


Any corrections or feedback, you know what to do! Thanks for reading.

Configuration differences in multi-vendor networks

One of the challenges working in a multi-vendor environment is trying to keep track of all the configuration differences. Having all the guides handy helps when you have to look-up a command or two, but actually having a whole end-to-end configuration for a vendor you don’t normally work with can be challenging.

I spent this week training a new employee on both Brocade FastIron/NetIron and BNT isCLI, so I got a chance to refresh my non-Cisco vendor configuration. It can get pretty insane having to jump between the different OS’s so I’ll be making periodic posts (such as this one) for both my own reference and to give some exposure to the various CLI’s that aren’t as widespread as Cisco IOS.

Brocade (formerly Foundry Networks) kit looks pretty innocent at first and is very IOS-like:

No password has been assigned yet...
FastIron#conf t
FastIron(config)#enable super-user-password br0cade
FastIron(config)#int ethernet 1/1/1

…However, Brocade FastIron has a different way of configuring your basic Layer 2 settings:

Unrecognized command
FastIron(config)#vlan 100
tagged                     802.1Q tagged port
FastIron(config-vlan-100)#tagged eth 1/1/1
Added tagged port(s) ethe 1/1/1 to port-vlan 100.

This is the equivalent to Cisco’s switchport mode trunk switchport trunk allowed vlan 1,100.
In my opinion, Brocade has a much more sane way of configuring your L2. You can also use a range of ports (tagged eth 1/1/1 to 1/1/48 eth...) and doesn’t suffer the drawback of having to go into each interface to assign a VLAN. To configure “access switchport”, you add ports to the VLAN as “untagged”.

Some other Layer 2 features in Brocade:

Rapid Spanning Tree
FastIron(config-vlan)#spanning-tree 802-1w
FastIron(config-vlan)#spanning-tree 802-1w priority 4096
FastIron(config-vlan)#spanning-tree 802-1w admin-pt2pt-mac

Voice VLANs
FastIron(config)#vlan 110 name voice
FastIron(config-vlan-110)#tagged eth 1/1/20
Added tagged port(s) ethe 1/1/20 to port-vlan 110.
FastIron(config-vlan-110)#vlan 120 name data
FastIron(config-vlan-120)#tagged eth 1/1/20
Added tagged port(s) ethe 1/1/20 to port-vlan 120.
FastIron(config-vlan-120)#int eth 1/1/20
FastIron(config-if-e1000-1/1/20)#dual-mode 120

Virtual Router Interface (SVI)
FastIron(config)#vlan 100
FastIron(config-vlan-100)#router-interface ve 1
FastIron(config-vlan-100)#int ve 1
FastIron(config-vif-1)#ip address

As you can see, the FastIron CLI (also applies to NetIron) is very much IOS-like, so the learning curve between IOS and Brocade is pretty minimal. Some others include being able to use any “show” command in any of the CLI hierarchy and use of “enable”/”disable” commands to bring interfaces down or up (instead of your “shut”/”no shut”).

Since this post is looking a bit long in the tooth, I’ll leave the BNT configs for next time. 🙂

Docs used: Brocade FastIron 07.3.00 Configuration Guide