Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

☯ RIP Response messages sent in reply to an RIP Request are sent with a source port

of 521, and a destination port equal to whatever source port the RIP Request used.

☯ Unsolicited RIP Response messages (sent on a routine basis and not in response to a

request) are sent with both the source and destination ports set to 521.

RIPng Message Format

The message format for RIPng is similar to that of RIP-1 and RIP-2, except for the format of

the Route Table Entries; it is shown in Table 123 and Figure 178.

The maximum number of RTEs in RIPng is not restricted to 25 as it is in RIP-1 and RIP-2. It

is limited only by the maximum transmission unit (MTU) of the network over which the

message is being sent.

Table 123: RIPng Message Format

Field Name

Size

(bytes)

Description

Command 1

Command Type: Identifies the type of RIPng message being sent. A value

of 1 indicates an RIPng Request, while 2 means an RIPng Response.

Version 1

Version Number: Set to 1 (not 6, since this is the first version of the new

protocol RIPng.)

Must Be Zero 2 Reserved: Field reserved; value must be set to all zeroes.

Route Table

Entries (RTEs)

Variable

(RTE

)

y o

RIP

ng message cons

s o

a var

number of Route Table Entries (RTEs) that contain information about routes. Each

entry is 20 bytes long and has the following subfields:

Subfield

Name

Size

(bytes)

Description

IPv6 Prefix 16

IPv6 Prefix: The 128-bit IPv6 address of the network

whose information is contained in this RTE.

Route Tag 2

Route Tag: Additional information to be carried with

this route, as defined in RIP-2.

Prefix Len 1

Prefix Length: The number of bits of the IPv6 address

that is the network portion (the remainder being the

host portion). This is the number that normally would

appear after the “slash” when specifying an IPv6

network address, and is analogous to an IPv4 subnet

mask. See the description of IPv6 prefix notation for

more details.

Metric 1

Metric: The distance for the network indicated by the

IP address, as in RIP-1. Values of 1 to 15 indicate the

number of hops to reach the network (as described in

the general discussion of the RIP algorithm) while a

value of 16 represents “infinity” (an unreachable

destination).

Key Concept: RIPng is the version of RIP that was developed for use on IPv6 inter-

networks. It is technically a distinct protocol from RIP-1 and RIP-2 but is very similar

to both. It retains the enhancements to RIP made in RIP-2, making changes to these

features and to the RIP message format where needed for compatibility with IPv6.

When a Next Hop needs to be specified, a special RTE is included as I mentioned before.

This RTE is included before all the RTEs to which it applies. It has the same basic structure

as shown for regular RTEs in Table 123, with the IPv6 Prefix subfield containing the next

hop address, the Route Tag and Prefix Len fields set to 0, and the Metric field set to 255

(0xFF).

Figure 178: RIPng Message Format

RIPng retains the use of Route Table Entries (RTEs) from RIP-2, but their format has been changed to accom-

modate the much larger IPv6 address size. The limit of 25 entries per message has also been eliminated.

Command Type Version Number = 1 Must Be Zero

IPv6 Prefix

(128 bits)

Route Tag Prefix Length Metric

4 8 12 16 20 24 28 320

...

Route Table Entry (RTE) #2

Route Table Entry (RTE) #N

RTE #1

Open Shortest Path First (OSPF)

Interior routing protocols using a distance-vector routing algorithm, such as the Routing

Information Protocol (RIP), have a long history and work well in a small group of routers.

However, they also have some serious limitations in both scalability and performance that

makes them poorly-suited to larger autonomous systems or those with specific perfor-

mance issues. Many organizations that start out using RIP quickly found that its restrictions

and issues made it less than ideal.

To solve this problem, a new routing protocol was developed in the late 1980s that uses the

more capable (and more complex) link-state or shortest path first routing algorithm. This

protocol is called Open Shortest Path First (OSPF). It fixes many of the issues with RIP and

allows routes to be selected dynamically based on the current state of the network, not just

a static picture of how routers are connected. It also includes numerous advanced features,

including support for a hierarchical topology and automatic load sharing amongst routes.

On the downside, it is a complicated protocol, which means it is often not used unless it is

really needed. This makes it the complement of RIP and is the reason they both have a

place in the spectrum of TCP/IP routing protocols.

In this section I provide a condensed explanation of the concepts and operation behind

OSPF. As usual, I begin with an overview of the protocol, discussing how it was developed,

its versions and the standards that define them. I describe the concepts behind OSPF,

including basic topology and the link state database. I then discuss the more complex

optional hierarchical topology of routers, and the roles routers play when this topology is

used. I briefly explain the method used for determining routes in OSPF, and the general

operation and messaging used in the protocol, including a description of the five OSPF

message types. I conclude with an illustration of the formats used for OSPF messages.

Note: The difficult thing about networking is that so many protocols and technol-

ogies are so involved that each deserves its own book. This is certainly the case

with OSPF itself, which is sufficiently complex that the RFC defining OSPF Version

2 is over 240 pages long. Thus, as you have heard me say before, this section, despite

including six topics, can only be considered a high-level description of OSPF.

OSPF Overview, History, Standards and Versions

In the early days of TCP/IP, the Routing Information Protocol (RIP) became the standard

protocol for routing within an autonomous system (AS), almost by default. RIP had two big

things going for it: it was simple and easy to use, and it was included in the popular

Berkeley Standard Distribution (BSD) of UNIX starting in 1982. Most organizations using

TCP/IP started out with relatively small networks, and were able to use RIP with some

degree of success.

However, as we discussed in our look at RIP, that protocol has some serious technical

issues, and these are exacerbated when it is used on a larger AS. Many of its problems are

due to it being a distance-vector protocol—the algorithm itself simply limits the ability of RIP

to choose the best route and adapt to changing network conditions. Other problems with

RIP were based on its implementation, such as the selection of a value of 16 for “infinity”

that made it impossible to use RIP in a situation where more than 15 hops might occur

between devices. Problems such as the lack of classless addressing support were

addressed in Version 2 of RIP, but the basic difficulties with the protocol as a whole persist.

Development and Standardization of OSPF

The Internet Engineering Task Force (IETF) recognized that RIP by itself simply would not

meet the needs of all autonomous systems on the Internet. They formed a working group in

1988 to develop a new routing protocol based on the more capable link-state algorithm,

also called shortest path first (SPF). Research into this type of protocol had already begun

as early as the 1970s, with some of it conducted on the ARPAnet, the predecessor of the

Internet upon which much of TCP/IP was developed.

This new protocol was called Open Shortest Path First, or OSPF, and its name conveys two

of its most important characteristics. The first word refers to the fact that the protocol, like all

TCP/IP standards, was developed using the open and public RFC process, so it is not

proprietary and no license is required to use it. The SPF portion of the name refers to the

type of algorithm it uses, which is designed to allow routers to dynamically determine the

shortest path between any two networks.

The first version of OSPF was described in RFC 1131, published in October 1989. This was

quickly replaced by OSPF Version 2 in July 1991, described in RFC 1247. Since then there

have been several revisions to the OSPF Version 2 standard, in RFCs 1583, 2178, and

2328, with the last of these the current standard. OSPF Version 2 is the only version in use

today, so it is usually what is meant when people (including myself) refer to “OSPF”.

Overview of OSPF Operation

The fundamental concept behind OSPF is a data structure called the link-state database

(LSDB). Each router in an autonomous system maintains a copy of this database, which

contains information in the form of a directed graph that describes the current state of the

autonomous system. Each link to a network or another router is represented by an entry in

the database, and each has an associated cost (or metric). The metric can be made to

include many different aspects of route performance, not just a simple hop count as is used

in RIP.

Information about the autonomous system moves around the autonomous system in the

form of link-state advertisements (LSAs), messages that let each router tell the others what

it currently knows about the state of the AS. Over time, the information that each router has

about the autonomous system converges with that of the others, and they all have the same

data. When changes occur to the internetwork, routers send updates to ensure that all the

routers are kept up-to-date.

To determine actual routes, each router uses its link-state database to construct a shortest-

path tree. This tree shows the links from the router to each other router and network, and

allows the lowest-cost route to any location to be determined. As new information about the

state of the internetwork arrives, this tree can be recalculated, so the best route is dynami-

cally adjusted based on network conditions. When more than one route with an equal cost

exists, traffic can be shared amongst the routes.

OSPF Features and Drawbacks

In addition to these obvious benefits of the link-state algorithm, OSPF includes several

other features of value especially to larger organizations. It supports authentication for

security, and all three major types of IP addressing (classful, subnetted classful and

classless). For very large autonomous systems, OSPF also allows routers to be grouped,

and arranged into a hierarchical topology. This allows for better organization and improved

performance through reduced link-state advertisement traffic.

Naturally, the superior functionality and many features of OSPF do not come without a cost.

In this case, the primary cost is that of complexity. Where RIP is a simple and easy-to-use

protocol, OSPF requires more work and more expertise to properly configure and maintain.

This means that even though OSPF is widely considered better than RIP technically, it's not

for everyone. The obvious role for OSPF is as a routing protocol for larger or higher-perfor-

mance autonomous systems, leaving RIP to cover the smaller and simpler internetworks.

Key Concept: Open Shortest Path First (OSPF) was developed in the late 1980s to

provide a more capable interior routing protocol for larger or more complex auton-

omous systems that were not being served well by RIP. It uses the dynamic shortest

path first or link state routing algorithm, with each router maintaining a database containing

information about the state and topology of the internetwork. As changes to the inter-

network occur, routers send out updated state information, which allows each router to

dynamically calculate the best route to any network at any point in time. OSPF is a

complement to RIP in that RIP is simple but limited, where OSPF is more capable but more

complicated.

OSPF Basic Topology and the Link State Database (LSDB)

OSPF is designed to facilitate routing in both smaller and larger autonomous systems

(ASes). To this end, the protocol supports two topologies. When there is only a small

number of routers, the entire AS is managed as a single entity. This doesn't have a specific

name, but I call it OSPF basic topology to convey the simple nature of the topology, and to

contrast it with the hierarchical topology we will explore in the topic following this one.

When OSPF basic topology is used, all the routers in the AS function as peers. Each router

communicates routing information with each other one, and each maintains a copy of the

key OSPF data structure: the link-state database (LSDB). The LSDB is essentially a

computerized representation of the topology of the autonomous system. It is the method by

which routers “see” the state of the links in the autonomous system—thus the name link-

state database (and for that matter, the name of the entire class of link-state algorithms of

which OSPF is a part.)

The LSDB is a bit hard to visualize, but is best viewed as a set of data that is equivalent to a

graphical picture showing the topology of an autonomous system. In such a diagram, we

typically show routers and networks as nodes, and connections between routers and

networks as lines that connect them. The OSPF LSDB takes that information and puts it

into a table, to allow a router to maintain a virtual picture of all the connections between

routers and networks in the AS.

The LSDB therefore indicates which routers can directly reach which other routers, and also

which networks each can reach. Furthermore, it stores for each of these links a cost to

reach the network. This cost is an arbitrary metric that can be set up based on any criteria

important to the administrator. OSPF is not restricted to the overly-simple hop-count metric

used in RIP.

OSPF Basic Topology and LSDB Example

For example, let's consider the same autonomous system we looked at in our examination

of the RIP route determination algorithm. This internetwork has four individual networks,

connected as follows:

☯ Router A (RA) connects Network 1 (N1) to Network 2 (N2).

☯ Routers B (RB) and C (RC) connect Network 2 to Network 3 (N3).

☯ Router D (RD) connects Network 3 to Network 4 (N4).

To make this example more interesting, I am also going to add a direct link between RB and

RC; the resulting AS is shown in Figure 179. The LSDB for this autonomous system would

look something like Table 124.

Figure 179: Example OSPF Autonomous System

This is the same AS that we looked at in RIP (as shown in Figure 172), but with the addition of a link between

the two routers RB and RC.

Network 1

Network 2 Network 3 Network 4

In practice, each of the bullets (“☯“) in Table 124 would be replaced by a metric value

indicating the cost to send a datagram from the particular router to another router or

network. Note that the chart is symmetric, since if RB can reach RC, RC can reach RB.

However, the costs do not have to be symmetric. It is possible for RB to have a metric that

is higher for it to send to RC than for RC to send to RB.

Note also that there is no cost to reach a router from a network. This ensures that only one

cost is “charged” for a router to send to another router over a network—the cost to reach the

network from the router. This makes sense, since each router is a member of the network

upon which it is connected.

LSDB Information Storage and Propagation

An important point to remember about the LSDB is that even though each router maintains

it, the database isn't constructed from the perspective of the individual router. A router's

LSDB represents the topology of the entire AS, including links between routers that may be

rather distant from it. So, for example, RA would keep the entire database in its storage

area, including information about RC and RD, to which it does not connect directly.

Since in basic topology all the routers are peers and maintain information for the entire AS,

they in theory should have the exact same LSDB contents. When a router is first turned on

it may in fact have different LSDB information than its neighbors, but this will be corrected

through the exchange of update messages containing link-state advertisements (LSAs).

Eventually all routers should converge to the same information. We will see how this works

in the topic on OSPF messaging.

OSPF, as an interior routing protocol, is of course used only within the autonomous system.

In most cases the AS will be connected to other ASes through one or more of its routers.

The routers that connect the AS to other ASes are often called boundary routers. These

Table 124: Example OSPF Link State Database (LSDB)

To Router /

Network

From Router From Network

RA RB RC RD N1 N2 N3 N4

RA 00

☯

0 0

☯

RD 0 0

☯

☯ ☯ ☯

☯☯☯

☯

devices will use OSPF to communicate within the AS, and an exterior routing protocol

(typically BGP) to talk to routers outside the AS. The name boundary router refers to the

fact that these devices are usually located on the periphery of the AS.

Key Concept: In basic OSPF topology, each of the routers running OSPF is

considered a peer of the others. Each maintains a link-state database (LSDB) that

contains information about the topology of the entire autonomous system. Each link

between a router and network or between two routers is represented by an entry in the

LSDB that indicates the cost to send data over the link. The LSDB is updated regularly

through the exchange of OSPF link-state advertisements (LSAs).

OSPF Hierarchical Topology, Areas and Router Roles

When the number of routers in an autonomous system (AS) is relatively small, using the

basic topology described in the previous topic works well. Each router maintains a common

picture of the network topology in the form of an identical link-state database (LSDB). The

routers communicate as peers using link-state advertisements (LSAs). While changes in

the AS may cause a router to temporarily have different information than its peers, routine

exchanges of data will keep all the LSDBs synchronized and up-to-date, and not that much

information needs to be sent around because the AS is small.

This simpler topology does scale reasonably well, and can support many smaller and even

moderate-sized autonomous systems. However, as the number of routers increases, the

amount of communication required to update LSDBs increases as well. In a very large inter-

network with dozens or even hundreds of routers, having all the routers be OSPF peers

using basic topology can result in performance degradation. This problem occurs due both

to the amount of routing information that needs to be passed around, and also the need for

each router to maintain a large LSDB containing every router and network in the entire AS.

OSPF Hierarchical Topology and Areas

To provide better support for these larger internetworks, OSPF supports the use of a more

advanced, hierarchical topology. In this technique, the autonomous system is no longer

considered a single, flat structure of interconnected routers all of which are peers. Instead,

a two-level hierarchical topology is constructed. The autonomous system is divided into

constructs called areas, each of which contains a number of contiguous routers and

networks. These areas are numbered, and managed independently by the routers within

them, so each area is almost as if it were an autonomous system unto itself. The areas are

interconnected so that routing information can be shared between areas, across the entire

AS.

The easiest way to understand this hierarchical topology is to consider each area like a

“sub-autonomous system” within the autonomous system as a whole. The routers within

any area maintain a link-state database containing information about the routers and

networks within that area. Routers within more than one area maintain LSDBs about each

area they are a part of, and also link the areas together to share routing information

between them.

Key Concept: To allow better control and management over larger internetworks,

OSPF allows a large autonomous system to be structured into a hierarchical form.

Contiguous routers and networks are grouped into areas that connect together using

a logical backbone. These areas act as the equivalent of smaller autonomous systems

within the larger AS, yielding the same benefits of localized control and traffic management

that autonomous systems provide for a large internetwork between organizations.

Router Roles in OSPF Hierarchical Topology

The topology described above is hierarchical because the routers in the AS are no longer

all peers in a single group. The two-level hierarchy consists of the lower level containing

individual areas, and the higher level that connects them together, which is called the

backbone and is designated as “Area 0”. The routers are no longer all peers, but in fact play

different roles depending on where they are located and how they are connected. There are

three different labels applied to routers in this configuration:

☯ Internal Routers: These are routers that are only connected to other routers or

networks within a single area. They maintain an LSDB for only that area, and really

have no knowledge of the topology of other areas.

☯ Area Border Routers: These are routers that connect to routers or networks in more

than one area. They maintain an LSDB for each area of which they are a part. They

also participate in the backbone.

☯ Backbone Routers: These are routers that are part of the OSPF backbone. By

definition, this includes all area border routers, since those routers pass routing infor-

mation between areas. However, a backbone router may also be a router that

connects only to other backbone (or area border) routers, and is therefore not part of

any area (other than Area 0).

To summarize: an area border router is always also a backbone router, but a backbone

router is not necessarily an area border router.

Note: The classifications above are independent of the designation of a router as

being a boundary router or not, as described in the previous topic. A boundary

router is one that talks to routers or networks outside the AS. Now a boundary

router will also often be an area border router or a backbone router, but this is not neces-

sarily the case—a boundary router could be an internal router in one area.

Okay, I bet you are now wondering… what is the point of all this? Well, the point is exactly

the same as the point of using autonomous system architecture in the first place. The

topology of each area matters only to the devices in that area. This means that changes in

that topology only need to be propagated within the area. It also means that internal routers

within Area 1 don't need to know about anything that goes on within Area 2, and don't need

to maintain information about any area other than their own. Only the backbone routers

(which include at least one area border router within each area) need to know the details of

the entire autonomous system. These backbone routers condense information about the

areas so that only a “summary” of each area's topology needs to be advertised on the

backbone.

Routing in a hierarchical topology AS is performed in one of two ways, depending on the

location of the devices. If the source and destination are in the same area, then routing

occurs only over networks and routers in that area. If they are in a different area, then the

datagram is routed from the source to an area border router in the source's area, over the

backbone to an area border router in the destination's area, and then finally, delivered to the

destination. Again, this is analogous to how routing works between ASes in the big-picture

internetwork.

OSPF Hierarchical Topology Example

I'm sure this all made perfect sense the first time you read it. Uh-huh. ☺ Let's take an

example to help make things more concrete. We can use the autonomous system in the

preceding topic. This AS is really small enough that it's unlikely one would use hierarchical

topology, but it will suffice for sake of illustration. Let's divide this AS into two areas, as

follows (see Figure 180):

☯ Area 1: This area would contain N1, RA, N2, RB and RC.

☯ Area 2: This area would contain RB, RC, N3, RD and N4.

Figure 180: Example OSPF Hierarchical Topology Autonomous System

This is the same AS we saw in Figure 179 but arranged into OSPF hierarchical topology. The AS has been

split evenly into Area 1 and Area 2. Area 0 contains RB and RC, which are area border routers for both Area 1

and Area 2 in this very simple example AS.

Area 0

Area 2Area 1

Network 1

Network 2 Network 3 Network 4