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.
วันจันทร์ที่ 26 พฤศจิกายน พ.ศ. 2550
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.
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.
สมัครสมาชิก:
บทความ (Atom)