les than the other. This may or may not matter in your environment, but I like to have each side match exactly. It's always better to have too many ports, rather than too few, as long as the budget allows it. Rounding out the modules to 5 on each chassis brings you to 10 modules, totaling 480 ports. Now you have 480 ports available and a present requirement for 340. This allows for a growth factor of almost 30 percent. Chances are you've missed something (I always do), SO having room for more than 15 percent growth is not a bad thing. In cases like this, I make sure to reserve extra ports for expansion purposes. They always come in handy later. Chapter 35: Designing Networks Another requirement that engineers often forget is interswitch trunks. Switches in failover pairs need to be connected to each other, usually with multigigabit links. If you're using Firewall Services Modules, they should have dedicated trunks. ACE modules should also have their own trunks, as should RSPAN, if you'll be using it. If you assume a 2 Gbps EtherChannel for each of these trunks, you've just allocated 16 ports (8 on each side). I've worked on high-bandwidth networks where each of these trunks required 4 Gbps EtherChannels. A design like this would require 32 ports (16 on each side). That's almost an entire 48-port module just for interswitch communication! If you need 10-gigabit, remember that these ports can be expensive, and unless you're using Nexus switches, port density can be a problem. Watch out for 10 Gb needs. Modern blade server enclosures will burn two 10 Gb ports, SO depending on your environment, they can get used up quickly. Once you've determined how many ports you'll require, map out the devices you'll need and figure out which devices will serve which purposes. Here, I've decided that 6509-V-E switches will be used in the core, and 2921 routers will be used for Internet and backend connectivity to the corporate website, located in a collocation facility. Figure 35-1 shows my spreadsheet for this information. Interf