Frame Relay

Frame Relay is a popular WAN protocol because it makes it easy to construct reliable and inexpensive networks. Its main advantage over simple point-to-point serial links is the ability to connect one site to many remote sites through a single physical circuit. Frame Relay uses virtual circuits to connect any physical circuit in a cloud to any other physical circuit. Many virtual circuits can coexist on a single physical interface.

This section will offer only a quick refresher of how Frame Relay works. If you are unfamiliar with Frame Relay, we recommend reading the more detailed description of the protocol and its features that are found in T1: A Survival Guide (O'Reilly).

The Frame Relay standard allows for both Switched (SVC) and Permanent (PVC) Virtual Circuits, although support for SVCs in Frame Relay switching equipment continues to be relatively rare. Most fixed Frame Relay WANs use PVCs rather than SVCs. This allows you to configure the routers to look like a set of point-to-point physical connections. SVCs, on the other hand, provide a mechanism for the network to dynamically make connections between any two physical circuits as they are needed. In general, SVCs are more complicated to configure and manage. Most network engineers prefer to use PVCs unless the carrier offers significant cost benefits for using SVCs. SVCs tend to be most practical when the site-to-site traffic is relatively light and intermittent.

Each virtual circuit is identified by a Data Link Connection Identifier (DLCI), which is simply a number between 0 and 1023. In fact, Cisco routers can only use DLCI numbers in the range 16 through 1007 to carry user data.

If the router at Site A wants to send a packet to Site B, it simply specifies the appropriate DLCI number for the virtual circuit that connects to Site B in the Frame Relay header. Although a physical circuit can have many virtual circuits, each connecting to a different remote circuit, there is no ambiguity about where the network should send each individual packet.

It's important to remember, though, that the DLCI number only has local significance. That is, the DLCI number doesn't uniquely identify the whole virtual circuit, just the connection from the local physical circuit to the Frame Relay switch at the Telco central office. The DLCI number associated with this virtual circuit can change several times before it reaches the remote physical circuit.

We like to use this fact to our advantage when constructing a Frame Relay network. Instead of thinking of the DLCI number as a virtual circuit identifier, we use it to uniquely label each physical circuit. Suppose, for example, that Site A has virtual circuits to both Sites B and C. Then we would use the same DLCI number at both Sites B and C to label the virtual circuits that terminate at Site A. This is just one of many possible DLCI numbering schemes, but we prefer it because it makes troubleshooting easier. Unfortunately, while this scheme works well in hub-and-spoke network topologies, it tends to become unworkable in meshed or partially meshed networks.

OSPF

Open Shortest Path First (OSPF) is a popular routing protocol for IP networks for several key reasons. It is classless, offering full CIDR and VLSM support, it scales well, converges quickly, and guarantees loop free routing. It also supports address summarization and the tagging of external routes, similar to EIGRP. For networks that require additional security, you can configure OSPF routers to authenticate with one another to ensure that unauthorized devices can't affect routing tables.

Perhaps the most important reasons for OSPF's popularity are that it is both an open standard and a mature protocol. Virtually every vendor of routing hardware and software supports it. This makes it the routing protocol of choice in multivendor enterprise networks. It is also frequently found in ISP networks for the same reasons.

But, for all of these benefits, OSPF is also considerably more complicated to set up than EIGRP or RIP. Unlike EIGRP, which can be readily retrofitted into almost any existing network, your network has to be designed with OSPF in mind if you want it to scale well. For more information on OSPF network design, refer to Designing Large-Scale LANs (O'Reilly). You can find more information about the protocol itself in IP Routing (O'Reilly). The remainder of this section is intended only to serve as a reminder to readers who are already familiar with OSPF.

OSPF is currently in its second version, which is documented in RFC 2328. It uses a large, dimensionless metric on every link (also equivalently called a "cost"), with a maximum value of 65,535. It is important to remember that OSPF doesn't add these metrics the same way that RIP and EIGRP do. In those protocols, each router updates the total metric as it passes the route on to the next router. However, in OSPF, the routers distribute the individual link costs to one another. The maximum cost for an individual link, then, is 65,535, but the RFC does not specify a maximum total path cost. Any given path through an OSPF network can include many high-cost links, but still be usable. This is quite different from RIP, for example, where a few high-cost links along a path can make the entire path unusable.

This 16-bit OSPF per-link metric, while significantly larger than the simple hop-count metric used in RIP, is much smaller than EIGRP's 32-bit metric. So many of the metric manipulation techniques we discussed for EIGRP in Chapter 7 do not work in OSPF. The smaller metric sometimes means that you have to exercise care in how you define the costs of each link. We discuss this issue in more detail in Recipe 8.3.

Like EIGRP, OSPF routers only start to exchange routing information after they have established a neighbor relationship. However, unlike EIGRP, OSPF routers don't actually exchange routing tables directly. Instead, they exchange Link State Advertisements (LSAs), which describe the states of different network links. Each router then obtains an accurate image of the current topology of the network, which it uses to build its routing tables. If you group the routers into areas, as we will discuss in a moment, every router in each area sees the same LSA information, which guarantees that all of the routing tables are compatible with one another.

The OSPF protocol operates directly at the IP layer using IP protocol number 89, without an intervening transport layer protocol such as UDP or TCP. Devices exchange OSPF information using multicast packets that are confined to the local segment. OSPF actually uses two different multicast IP addresses: all OSPF routers use 224.0.0.5, and Designated Routers (DRs) use 224.0.0.6.

A DR is basically a master router for a network segment. This is only relevant when there are several OSPF routers on a multiple access medium, such as an Ethernet segment. In this case, to avoid the scaling problems of establishing a mesh of neighbor relationships between all of the routers on the segment, one router becomes the DR for the segment. Then all of the other routers talk to the DR. Each segment also elects a Backup Designated Router (BDR) in case the DR fails.

One of the most important features of OSPF is the concept of an area. This is also partly what makes OSPF more difficult to configure. An OSPF network can be broken up into areas that are connected by Area Border Routers (ABRs). Routing information can then be summarized at the ABR before being passed along to the next area. This means that routers in one area don't need to worry about the LSA information from routers in other areas, which drastically improves network stability and convergence times. It also reduces the memory and CPU required to support OSPF on the routers.

For OSPF to work well, you need to allocate your IP addresses appropriately among the areas. In particular, you want to be able to summarize the routes for an area when you pass this information along to the next area. The summarization doesn't need to reduce perfectly to a single route for each area, but the fewer LSAs you need to pass between areas, the better OSPF will scale.

Each area has a 32-bit identifier number, which is often represented in dotted decimal notation, similar to IP addresses. Every OSPF network should have an Area 0 (or 0.0.0.0), and every ABR must be a member of Area 0. This enforces a hierarchical design model for OSPF networks. The one exception to this rule happens in a network with only one area. In this case you can actually give this area any number, but we don't recommend doing so because it could cause serious problems if you ever need to partition the network into areas later. The only time this becomes relevant is when a network failure isolates one area from the rest of the network. In this case, the isolated area can continue working as normal internally.

You can get around this strict design requirement of having all areas connected only through Area 0 by using OSPF virtual links. These are essentially little more than IP tunnels. You can use virtual links to ensure that every ABR connects to Area 0, even if one or more of them are not physically connected to Area 0. However, we should stress that we do not recommend using virtual links except as a temporary measure—perhaps while migrating your network to a new architecture or while merging two networks.

Cisco SWAN Components

There are four components to the Cisco SWAN framework—access points; management and security servers; WLAN
client devices; and infrastructure devices.
• Cisco Aironet® Series WLAN access points running Cisco IOS® Software—Cisco Aironet access points are
required. These access points offer secure, manageable, and reliable wireless connectivity with exceptional range
and performance, as well as integrated radio frequency (RF) management.
• Management and security servers—The CiscoWorksWireless LAN Solution Engine (WLSE) and an IEEE 802.1X
authentication server, such as Cisco Secure Access Control Server (ACS), are required to manage and secure
the wireless network. These products simplify the deployment and management of the WLAN infrastructure
and implement an enterprise-class security solution.
• WLAN client devices—Wi-Fi Certified or IEEE 802.11 clients are required. Using Cisco Aironet or Cisco
Compatible client devices provides additional benefits, including advanced enterprise-class security, extended
air RF radio management, and enhanced interoperability.
• Infrastructure devices—As Cisco incorporates wireless capabilities into its switches and routers, customers
receive a unified network system that extends to wireless traffic all of the enterprise-class scalability, security,
reliability, and simplified manageability of the wired infrastructure. The result of this wired and wireless
integration is a lower overall total cost of ownership since existing routers and switches are used for WLAN
support, obviating the need for unfamiliar and unproven WLAN point products.

Network Address Translation (NAT)

Network Address Translation (NAT) was first described in RFC 1631 in 1994. The authors of that document were trying to solve the imminent problem of running out of IPv4 addresses. They proposed a simple but brilliant solution: allow devices on the inside of a network to use the standard pool of unregistered IP addresses currently defined in RFC 1918. The router or firewall at the boundary between the internal private network and the external public network could then use software to rewrite the internal IP addresses of every packet, replacing them with valid registered addresses.

There are four kinds of addresses: inside local, inside global, outside local, and outside global. Inside and outside are relative terms if you're just connecting two private networks. But if you are connecting a private network to the public Internet, the Internet is considered the outside. A local address is generally the private address, while the global address is the globally unique public address.

To help make these terms more clear, suppose you are connecting a network that uses RFC 1918 private addresses to the public Internet. Inside your network you have private addresses, such as 192.168.1.0/24. These are the inside local addresses. NAT will translate these addresses to globally unique registered addresses, which are also the inside global addresses. The addresses on the public Internet are outside global addresses. These external network addresses are all registered in this case, so there is no need to translate them. If translation was needed, an outside global address would be changed to an outside local address.

To put this another way, the address that internal devices use to communicate with other internal devices is the inside local address. The address that internal devices uses to communicate with external devices is the outside local address. The address that external devices uses to communicate with internal devices is the inside global address. Finally, external devices communicate with one another using outside global addresses.

NAT makes it possible to have a huge internal network with thousands of local addresses represented by a handful (or perhaps even just one) global address. This is why NAT is often credited with alleviating the address shortage problem. But it solves this problem only if most people who use it have more local than global addresses.

In practice, NAT offers a huge range of possibilities. You can map local addresses uniquely to individual global addresses. You can share one global address among several local addresses. You can allocate global addresses from a pool as they are requested, or have a single global address and map all local addresses to this one address. You can even define a combination of these different alternatives.

When a device sends a packet out from the private to the public network, the translator replaces the local source address with a registered address, then routes the packet. For an inbound packet, the translator replaces the global address with the local address and routes the packet into the internal network. The translator has a much more difficult job with inbound packets than outbound, because it has to figure out which internal device to send the packet to. Since many internal devices may be using the same global address, the translator has to keep a state table of all of the devices that send or receive packets to or from the external network.

Suppose, for example, that two internal users are both using HTTP to view information on the public network. The translator must be able to determine which packets are intended for which internal device. It's not sufficient to simply look at the external device's IP address—both of these users could be looking at the same web page. They would both wind up with severely scrambled screens if the translator couldn't tell which packets to send to which internal user.

This particular example is made somewhat easier by the fact that HTTP uses TCP. Because TCP is a connection-based protocol, well-defined TCP session initiation and termination helps the translator to sort out the inbound flows. In this case, Cisco's NAT implementation uses Port Address Translation (PAT), which means that the router rewrites the source port numbers, and uses the new values as tags to distinguish between the two flows. Because UDP also uses port numbers, the same PAT technique also works here, although the router doesn't keep the translation table entries active for the same length of time.

ICMP, on the other hand, is considerably more difficult for NAT to keep straight. For example, if two internal users both ping the same external site at the same time, the translator has to assume that it will receive the responses in the same order that they were sent. Fortunately, this rarely causes real problems in production networks. But it is worth remembering that, whether it can use PAT or not, NAT requires the router to keep track of a lot of state information that routers don't usually care about.

Further, because IP addresses and port numbers are included in both IP and TCP checksums, the translator must recalculate these checksum values for every packet. So NAT always consumes more CPU and memory on the router or firewall that it runs on. This resource usage increases rapidly with both the number of packets and the number of different flows.

The other important thing to remember about NAT is that some protocols include IP address information in the payload of the packet, as well as in the IP header. For example, the ubiquitous FTP protocol has a PORT command that contains an IP address encoded in ASCII. In this case, the FTP protocol is well understood and NAT implementations can look out for the PORT command. But in other, less popular protocols, strange problems can occur. And, if a server happens to run FTP on a nonstandard TCP port, you must tell NAT about the change so that it can rewrite the payload addresses.

SNMP also includes IP addresses in packet payloads. For example, IP address information is part of the standard interface MIB because the address is an important piece of information about the interface. However, rewriting addresses in the payloads of SNMP packets is a much more difficult problem than finding the IP address for FTP, because the address could be anywhere in the payload. It is also possible for the addresses in the payload to refer to different interfaces than the address in the header. And, to make the problem even more difficult, there is no common standard format for IP addresses in SNMP packets. They are sometimes transmitted as dotted decimal ASCII strings, as packed hex bytes, or in a variety of other formats depending on the specific MIB. Consequently, Cisco routers do not attempt to rewrite IP addresses in the payloads of SNMP packets.

We have also seen custom-built applications that make life very hard for NAT by encoding IP addresses and port numbers in the data segment of a packet, then using this information to attempt new connections. It can be very hard to get NAT to work in cases like this. Often the only workaround is to encapsulate the ill-behaved application in a tunnel.

Simple Network Management Protocol

Since its introduction in 1988, the Simple Network Management Protocol (SNMP) has become the most popular network management protocol for TCP/IP based networks. The IETF created SNMP to allow remote management of IP based devices using a standardized set of operations. It is now widely supported by servers, printers, hubs, switches, modems, UPS systems, and (of course) Cisco routers. The SNMP set of standards define much more than a communication protocol used for management traffic. The standards also define how management data should be accessed and stored, as well as the entire distributed framework of SNMP agents and servers. The IETF has officially recognized SNMP as a fully standard part of the IP protocol suite. The original SNMP definition is documented in RFC 1157.

In 1993, SNMP Version 2 (SNMPv2) was created to address a number of functional deficiencies that were apparent in the original protocol. The added and improved features included better error handling, larger data counters (64-bit), improved efficiency (get-bulk transfers), confirmed event notifications (informs), and most notably, security enhancements. Unfortunately, SNMPv2 did not become widely accepted because the IETF was unable to come to a consensus on the SNMP security features. So, a revised edition of SNMPv2 was released in 1996, which included all of the proposed enhancements except for the security facility. It is discussed in RFCs 1905, 1906, and 1907. The IETF refers to this new version as SNMPv2c and it uses the same insecure security model as SNMPv1. This model relies on passwords called community strings that are sent over the network as clear-text. SNMPv2c never enjoyed widespread success throughout the IP community. Consequently, most organizations continue to use SNMPv1 except when they need to access the occasional large counter variable. The IETF recently announced that SNMPv3 would be the new standard, with SNMPv1, SNMPv2, and SNMPv2c being considered purely historical.

Cisco's IOS supported SNMPv2 until Version 11.2(6)F, when Cisco began supporting SNMPv2c. Cisco continues to support SNMPv2c in every IOS version beginning with 11.2(6)F. In addition, every version of IOS has supported SNMPv1 since the earliest releases. The compromise that became SNMPv2c left the management protocol without satisfactory security features. So, in 1998, the IETF began working on SNMPv3, which is defined in RFCs 2571-2575. Essentially, SNMPv3 is a set of security enhancements to be used in conjunction with SNMPv2c. This means that SNMPv3 is not a stand-alone management protocol and does not replace SNMPv2c or SNMPv1.

SNMPv3 provides a secure method for accessing devices using authentication, message integrity, and encryption of SNMP packets throughout the network. We have included a recipe describing how to use the SNMPv3 security enhancements (see Recipe 17.21). Table 17-1 lists the three supported versions of SNMP and highlights their security capabilities.

SNMP Management Model

SNMP defines two main types of entities, managers and agents. A manager is a server that runs network management software that is responsible for a particular network. These servers are commonly referred to as Network Management Stations (NMS). There are several excellent commercial NMS platforms on the market. Throughout this book we will refer to the freely distributed NET-SNMP system as a reference NMS. An agent is an embedded piece of software that resides on a remote device that you wish to manage. In fact, almost every IP-capable device provides some sort of built-in SNMP agent. The agent has two main functions. First, the agent must listen for incoming SNMP requests from the NMS and respond appropriately. And second, the agent must monitor internal events and create SNMP traps to alert the NMS that something has happened. This chapter will focus mainly on how to configure the router's agent.

The NMS is usually configured to poll all of the key devices in the network periodically using SNMP Get requests. These are UDP packets sent to the agent on the well-known SNMP port 161. The SNMP Get request prompts the remote device to respond with one or more pieces of relevant operating information. However, because there could be hundreds or thousands of remote devices, it is often not practical to poll a particular remote device more often than once every few minutes (and in many networks you are lucky if you can poll each device more than a few times per hour). On a schedule like this, a remote device may suffer a serious problem that goes undetected—it's possible to crash and reboot in between polls from the NMS. So, on the next poll, the NMS will see everything operating normally and never know that it completely missed a catastrophe.

Therefore, an SNMP agent also has the ability to send information using an SNMP trap without having to wait for a poll. A trap is an unsolicited piece of information, usually representing a problem situation (although some traps are more informational in nature). Traps are UDP packets sent from the agent to the NMS on the other well-known SNMP port number, 162. There are many different types of traps that an agent can send, depending on what type of equipment it manages. Some traps represent non-critical issues. It is often up to the network administrator to decide which types of traps will be useful. The NMS does not acknowledge traps, and since traps are often sent to report network problems, it is not uncommon for trap reports to get lost and never make it to the NMS. In many cases, this is acceptable because the trap represents a transient transmission problem that the NMS will discover by other means if this trap is not delivered. However, critical information can sometimes be lost when a trap is not delivered.

To address this shortcoming, SNMPv2c and SNMPv3 include another type of packet called an SNMP inform. This is nearly identical to a standard trap, except that the SNMP agent will wait for an acknowledgement. If the agent does not receive an acknowledgement within a certain amount of time, it will attempt to retransmit the inform. SNMP informs are not common today because SNMPv2c was never widely adopted. However, SNMPv3 also includes informs. Since SNMPv3 promises to become the mainstream SNMP protocol, it seems inevitable that enhancements such as SNMP informs will start to be more common.

Dymic Host Configuration Protocol

Dynamic Host Configuration Protocol (DHCP) is often used on networks to allow end devices to automatically retrieve their network configuration when they first connect to the network. It basically expands on the earlier Bootstrap Protocol (BOOTP) and uses the same UDP ports, numbers 67 and 68. The protocol itself is defined in RFC 2131, and the configuration options are defined in RFC 2132.

The most common application for DHCP is to automatically set up IP addresses, netmasks, and default gateways for end devices. However, the protocol can also configure many other options, such as DNS servers, domain names, time zones, NTP servers, and many others. Some software vendors have even added their own configuration options to automatically set up key applications on end devices.

DHCP makes it possible to give a minimal common configuration to all user workstations. You can simply plug the device into the network at any point, and DHCP will take care of getting an IP address that will work at that location. This minimizes errors due to manual configuration, centralizes control over configuration information, and greatly reduces technician costs because anybody can connect a device to the network.

There are three distinct element types in a DHCP network. There must be a client and a server. If these two elements are not on the same Layer 2 network, there also must be a proxy, which usually runs on the router. The proxy is needed because the client device initially doesn't know its own IP address, so it must send out a Layer 2 broadcast to find a server that has this information. The router must relay these broadcasts to the DHCP server, then forward the responses back to the correct Layer 2 address so that the right end device gets the right configuration information.

Historically, the router's only role in BOOTP or DHCP was this proxy function. However, Cisco has recently added both DHCP client and server functionality. This chapter will show configuration examples for all three of these functions, but many of the recipes will focus on complex server configurations.

A DHCP exchange starts with a client device, such as an end user workstation. Typically, this device will boot and connect to the network with no preconfigured network information. It doesn't know its IP address, the address of its router, its subnet, or netmask. It doesn't even know the address of the server that will provide these pieces of information. The only thing it can do is send out a UDP broadcast packet looking for a server.

Most DHCP networks of any size include two or more DHCP servers for redundancy. The end devices typically just need to talk to a DHCP server at startup time, but they will not work at all without it. So redundancy is important. This also means that it is not unusual for an end device to see several responses to a DHCP request. It will generally just use the first response. However, this also underscores the importance of ensuring that all of the DHCP servers distribute the same information. Their databases of end device configuration parameters must be synchronized.

The end device requests configuration information from one of the servers. It must specify exactly what options it requires. The server does not need to respond to all of the requested options, but it cannot offer additional unrequested information to the client, even if it has additional information in its database. This is an important detail to remember—it can be very confusing when an end device has some manually configured options that are not replaced by the information on the server.

Since duplicate IP addresses can cause serious problems on a network, most DHCP servers track address conflicts. They do this by attempting to ping each IP address before telling an end device that it is safe to use the address. Many DHCP clients will also double-check that the address is not already in use by sending an ARP request before using it. However, neither of these checks is mandatory, and some DHCP clients and servers do not check before using an address.

One of the important features of DHCP is the ability to allocate IP addresses for a configurable period of time, called the lease period. If a client device wants to keep its IP address for longer than this period, it must renew the lease before it expires. Clients are free to renew their leases as often as they like.

The server can allocate IP addresses from a pool on a first-come, first-served basis, or it can associate IP addresses with end device MAC addresses to ensure that a particular client always receives the same address.

What is WDS?

WDS is a collection of Cisco IOS Software features that enhance WLAN client mobility and simplify WLAN deployment and management. A WDS device can be a Cisco Aironet Series access point Cisco router or Cisco Catalyst switch.

All access points in a subnet are detect and securely register, via IEEE 802.1X, with the WDS. The WDS aggregates client and access point RF(Radio Frequency) measurements for RE-managed services such as rogue access point detection, interference detection and assisted site serveys.The currently supported WDS feature set includes fast secure roaming, radio management aggregation, and client tracking. Before the operation of any other WDS-based features. it must establish relationships between the APs that participate in WDS and the device that is configured as the WDS. One of the main purposes of WDS is to cache the user credentails as soon as the authentication server authenticates the client for the first time. On subsequent attempts, WDS authenticates the client on the basis of the cached information.

Advertises WDS capability and participates in an election of the best WDS device for WLAN. Set up one device as the main WDS candidate and one or more additional devices as backup WDS candidates. If the main WDS device goes offline, one of the backup WDS devices takes the place of the main device. Authenticates all APs in the subnetwork and establishes a secure communication channel with each of the APs. Collects radio data from APs in the subnetwork, aggregates the data, and forwards the data to the Wireless LAN Solution Engine (WLSE) device on network. Registers all client devices in the subnetwork, establishes session keys for the client devices, and caches the client security credentials. When a client roams to another AP, the WDS device forwards the client security credentials to the new AP. A single WDS AP can supports a maximum 60 infrastructure APs.

The WDS and the infrastructure APs communicate over a multicast protocol called the Wireless LAN Context Control Protocol (WLCCP). These multicast messages cannot be routed. Therefore, a WDS and the associated infrastructure APs must be in the same IP subnetwork and on the same LAN segment. Between the WDS and the Wireless LAN Solution Engine (WLSE), WLCCP uses Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) on port 2887. When the WDS and WLSE are on different subnetworks, packet translation with a protocol like Networks Address Translation(NAT) cannot occur.

A WDS-enabled AP also acts as an aggregator for radio frequency(RF) statistics from the other APs. The WDS-enabled AP passes along these statistics to the Wireless LAN Solution Engine (WLSE) in order to highlight rogue APs. The monitor of RF allows the WLSE to create a map of wireless coverage. The WLSE also uses current APs in order to carry out side surveys and identify areas with no coverage. There is no limit to the number of WDS backup candidates. The backup candidates still function as APs that report to the WDS master. In addition, only the primary WDS AP establishes WLSE security keys and registers with the WLSE in order to interact with the WLSE. Only if the primary WDS fails, the backup WDS takes up the role of an active WDS AP and goes on to register with the WLSE and establish security keys. As long as the primary WDS is active, the primary WDS functions as a normal AP that reports to the WDS master.