ed in crossover mode Watch out for older FEXs. The Nexus 2148 FEX does not allow Ether- Channel bundles to be formed within a single FEX. The drawback to the crossover design is that each upstream switch will think that the FEX is an extension of its fabric, and in fact, it is. It becomes very easy to configure the same physical FEX differently on each upstream switch, which can be catastrophic, not to mention hard to troubleshoot. If such a design is warranted in your environment, I strongly urge you to use the Nexus config-sync feature outlined later in this chapter. Keep in mind that config-sync is available only on NX-OS version 5.0(2) and later. Remember, FEXs do no switching of their own. All switching is done by the upstream switches-in this example, a pair of Nexus 5000s. Even if two hosts connected to the same FEX need to communicate, the frames will traverse the uplink, be switched on the 5000, and be sent back down the uplink to the FEX. Instead of thinking of FEXs as switches, it would be better to think of them as modules in a chassis switch. Once consider a 5K the supervisor and the FEXs to be modules, the passthru design makes a lot more sense. You wouldn't cross-connect each blade on a chassis switch to the supervisor of the other switch in a pair, would you? You cannot attach a switch to a FEX. All FEX ports are configured with BPDU Guard, which cannot be disabled. You can, however, connect a switch to the Nexus 5000, as shown in Figure 18-16. OK, SO you can connect a switch to a FEX, but to do SO you must prevent that switch from sending BPDUs. I'll spare you the "that's a bad idea" speech. Configuring the FEXs is pretty straightforward, SO long as you understand how they work. First, you must enable the FEX feature: NX-5K-1 1(config)# feature fex Nexus Design Features Figure 18-16. Switch connectivity with FEXs Describing FEXs After the FEX feature has been enabled, each FEX must then be described in the 5K. The FEXs are assigned numbers in the range of 100-199. The number is locally signif- ic