Additional Campus Design Recommendations

Additional Campus Design Recommendations

This section addresses a variety of other tips and best practices that do not fit in the previous sections or important points that deserve emphasis.

Access Layer Recommendations

When designing the IDF/access layer sections of the network, be sure to at least consider using the following features if NFFC/RSFC support is available in these devices:

• Protocol Filtering (see Chapter 11)

• IGMP Snooping (see Chapter 12)

• QoS classification

Distribution Layer Recommendations

The recommendation here is simple and has been clearly discussed earlier in the chapter. However, it is important enough to repeat: Always try to form a Layer 3 barrier in the MDF/distribution layer devices.

Core Layer Recommendations

The primary thing to keep in mind is the point discussed in the Spanning Tree and VLAN sections: Keep the core loop free when using a Layer 2 core.

Watch Out for Discontiguous Subnets

Carefully scrutinize your designs for possible discontiguous subnets. One of the most common and subtle causes of this situation is created in scenarios such as that shown in Figure 15-17.

Figure 15-17. Discontiguous Subnets

The link between Cat-A and Cat-B has failed, partitioning the 10.0.1.0 subnet into two halves. However, because neither router is aware of the failure, they are both trying to forward all traffic destined to this subnet out their upper interface. Therefore, Router-A will not be able to reach Host-B and Router-B will not be able to communicate with Host-A.

In general, there are two simple and effective ways to fix this problem:

• Utilize a mixture of Layer 2 and Layer 3 (such as with "routing switches"/MLS)

• Place only a single Layer 2 switch between routers (as well as between the "switching router" forms of Layer 3 switches)

Under the first approach, MLS is used to create a Layer 2 environment that, because it is redundant, remains contiguous even after the failure of any single link. Figure 15-18 illustrates this approach.

Figure 15-18. Avoiding Discontiguous Subnets With A Routing Switch (MLS)

Figure 15-18 shows a logical representation of MLS devices where the Layer 2 and Layer 3 components are drawn separately in order to highlight the redundant Layer 2 configuration.

Note

The design in Figure 15-18 could also be implemented using switching router technology such as the Catalyst 8500s by utilizing bridging/IRB.

The second solution to the discontiguous subnet problem is to always use a single Layer 2 switch between routers, as shown in Figure 15-19.

Figure 15-19. Avoiding Discontiguous Subnets By Using a Single Layer 2 Switch

Because this eliminates the "chain" of Layer 2 switches shown in Figure 15-17, it allows any single link to fail without partitioning the subnet.

VTP

In some situations, the VLAN Trunking Protocol (VTP) can be useful for automatically distributing the list of VLANs to every switch in the campus. However, it is important to realize that this can automatically lead to campus-wide VLANs. Moreover, as discussed in Chapter 12, VTP can create significant network outages when it corrupts the global VLAN list.

When using VTP in large networks, consider overriding the default behavior using one of two techniques:

• VTP transparent mode

• Multiple VTP domains

First, many large networks essentially disable VTP by using the transparent mode of the protocol (there is no set vtp disable command). When using VTP transparent mode, you have absolute control over which VLANs are configured on each switch. This can allow you to prune back VLANs where they are not required to optimize your network.

Second, when organizations do decide to utilize VTP server and client mode, it is often beneficial to use a separate VTP domain name for each distribution block. This provides several benefits:

• It breaks the default behavior of spreading every VLAN to every switch (in other words, campus-wide VLANs).

• It constrains VTP problems to a single building.

• It allows the VTP protocol to better mirror the multilayer model.

• It can reduce Spanning Tree overhead.

Passwords

Because the XDI/CatOS-interface Catalysts (currently this includes 4000s, 5000s, and some 6000 configurations) automatically allow access by default, be sure to set user and privilege mode passwords. In addition, be certain to change the default SNMP community strings (unlike the routers, SNMP is enabled by default on XDI/CatOS-interface Catalysts).

Port Configurations

When configuring ports, especially important trunk links, hard-code as many parameters as possible. For example, relying on 10/100 speed and duplex negotiation protocols has been shown to occasionally fail. In addition, the state (on or off) and type (isl or 802.1Q) of your Ethernet trunks should be hard-coded.

Tip

One exception to this rule concerns the use of PAgP, the Port Aggregation Protocol used to negotiate EtherChannel links. If PagP is hard-coded to the on state, this prevents the Catalyst from performing some value-added processing that can help in certain situations such as Spanning Tree failover.