Charles M. Kozierok The TCP-IP Guide

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

BGP Route Information Exchange: Update Messages

Once BGP speakers have made contact and a link has been established using Open

messages, the devices begin the actual process of exchanging routing information. Each

BGP router uses the BGP Decision Process to select certain routes to be advertised to its

peer. This information is then placed into BGP Update messages, which are sent to every

BGP device for which a session has been established. These messages are the way that

network reachability knowledge is propagated around the internetwork.

Each Update message contains either one or both of the following:

☯ Route Advertisement: The characteristics of a single route.

☯ Route Withdrawal: A list of networks that are no longer reachable.

Only one route can be advertised in an Update message, but several can be withdrawn.

This is because withdrawing a route is simple; it requires simply the address of the network

for which the route is being removed. In contrast, a route advertisement requires a fairly

complex set of path attributes to be described, which takes up a significant amount of

space. (Note that it is possible for an Update to only specify withdrawn routes and not

advertise a route at all.)

BGP Update Message Format

Because of the amount of information it contains, and the complexity of that information,

BGP Update messages use one of the most complicated structures in all of TCP/IP. The

basic structure of the message is described in Table 139, and illustrated in Figure 194. As

you can see in that table, several of the fields have their own substructure. The Attribute

Type subfield of the Path Attributes field has itself a complex substructure, which I have

shown separately in Table 140 to avoid overloading Table 139.

When you examine this format, you may find it confusing that there can be more than one

prefix in the NLRI field, given that I just said that an Update message advertises only one

route. There is in fact no inconsistency here. A single route may be associated with more

than one network; or, to put it another way, multiple networks may have the same path and

path attributes. In that case, specifying multiple network prefixes in the same Update is

more efficient than generating a new one for each network.

Table 139: BGP Update Message Format (Page 1 of 3)

Field Name

Size

(bytes)

Description

Marker 16

Marker: This large field at the start of each BGP message is used for

synchronization and authentication. See the discussion of the BGP general

message format for details.

Length 2

Length: The total length of the message in bytes, including the fields of the

header. Update messages are variable in length.

Type 1 Type: BGP message type, value is 2 for Update messages.

Unfeasible

Routes Length

Unfeasible Routes Length: The length of the Withdrawn Routes field, in

bytes. If 0, no routes are being withdrawn and the Withdrawn Routes field

is omitted.

Withdrawn

Routes

Variable

Total Path

Attribute Length

Total Path Attribute Length: The length of the Path Attributes field, in

bytes. If 0, indicates no route is being advertised in this message, so Path

Attributes and Network Layer Reachability Information are omitted.

Table 139: BGP Update Message Format (Page 2 of 3)

Field Name

Size

(bytes)

Description

Withd

rawn

es:

pec

ifi

e a

resses o

wor

or w

rou

are being withdrawn from use. Each address is specified using the

following substructure:

Subfield

Name

Size

(bytes)

Description

Length 1

Length: The number of bits in the IP address

Prefix subfield below that are significant.

Prefix Variable

Prefix: The IP address prefix of the network

whose route is being withdrawn. If the number of

bits in the prefix is not a multiple of 8, this field is

padded with zeroes so it falls on a byte boundary.

The length of this field is 1 byte if the preceding

Length field is 8 or less; 2 bytes if it is 9 to 16; 3

bytes if it is 17 to 24; and 4 bytes if 25 or greater.

Path Attributes Variable

Network Layer

Reachability

Information

Variable

Table 139: BGP Update Message Format (Page 3 of 3)

Field Name

Size

(bytes)

Description

Att

es:

escr

e pa

es o

e rou

e a

ver

Since some attributes require more information than others, attributes are

described using a flexible structure that minimizes message size compared

to using fixed fields that would often be empty. Unfortunately it also makes

the field structure confusing. ☺ Each attribute has the following subfields:

Subfield

Name

Size

(bytes)

Description

Attribute Type 2

Attribute Type: A two-byte subfield that defines

the type of attribute and describes it. This subfield

itself has a two-level substructure, so it won’t even

fit it here! See Table 140.

Attribute

Length

1 or 2

Attribute Length: The length of the attribute in

bytes. This field is normally one byte, allowing for

fields with a length up to 255 bytes. For longer

attributes, the Extended Length flag is set (see

Table 140), indicating that this Attribute Length

field is two bytes, for attributes up to 65,535 bytes.

Attribute Value Variable

Attribute Value: The value of the attribute. The

size and meaning of this field depends on the type

of path attribute. For example, for an Origin

attribute it is a single integer value indicating the

origin of the route; for an AS_Path attribute this

field contains a variable-length list of the auton-

omous systems in the path to the network.

wor

ayer

eac

bilit

orma

(NLRI)

ns a

address prefixes for the route being advertised. Each address is specified

using the same general structure as that used for Withdrawn Routes:

Unlike most of the other fields in the Update message, the length of the

NLRI field is not explicitly stated. It is computed from the overall message

Length field, less the lengths of the other fields that are explicitly specified.

Subfield

Name

Size

(bytes)

Description

Length 1

Length: The number of bits in the Prefix field

below that are significant.

Prefix Variable

Prefix: The IP address prefix of the network

whose route is being advertised. If the number of

bits in the prefix is not a multiple of 8, this field is

padded with zeroes so it falls on a byte boundary.

The length of this field is 1 byte if the preceding

Length field is 8 or less; 2 bytes if it is 9 to 16; 3

bytes if it is 17 to 24; and 4 bytes if 25 or greater.

Table 140: Details of BGP Update Message Attribute Type Subfield

Sub-subfield

Name

Size

(bytes)

Description

Attribute Flags 1

Attribute Type

Code

Att

ags:

ags

escr

e na

ure o

e a

e an

how to process it (you may need to refer to the path attributes description to

make sense of these flags):

Sub-Sub-

Subfield

Name

Size

(bytes)

Description

Optional

1/8

(1 bit)

Optional Bit: Set to 1 for optional attributes; 0 for

well-known attributes.

Transitive

1/8

(1 bit)

Transitive Bit: Set to 1 for optional transitive

attributes; 0 for optional non-transitive attributes.

Always set to 1 for well-known attributes.

Partial

1/8

(1 bit)

Partial Bit: When 1, indicates that information

about an optional transitive attribute is “partial”.

This means that since it was optional and

transitive, one or more of the routers that passed

the path along did not implement that attribute but

was forced to pass it along, so information about it

may be missing (not supplied by the routers that

didn't recognize it but just passed it along). If 0,

means information is complete. This bit has

meaning only for optional transitive attributes; for

well-known or non-transitive attributes it is 0.

Extended

Length

1/8

(1 bit)

Extended Length Bit: Set to 1 for long attributes,

to indicate that the Attribute Length field is two

bytes in size. Normally 0, meaning the Attribute

Length field is a single byte.

Reserved

4/8

(4 bits)

Reserved: Set to zero and ignored.

Att

ype

num

tifi

e a

ype.

urren

values are:

Value Attribute Type

1 Origin

2 AS_Path

3 Next_Hop

4 Multi_Exit_Disc (MED)

5 Local_Pref

6 Atomic_Aggregate

7 Aggregator

Figure 194: BGP Update Message Format

This diagram shows the complete BGP Update message format, including a set of withdrawn routes, path

attributes and NLRI entries. The exploded view shows the substructure of the Attribute Type subfield of Path

Attributes, as described in Table 140.

Marker

(128 bits)

Length Type = 2

Withdrawn Route #1

Length

Withdrawn Route #1 Prefix

Withdrawn Route #N

Length

Withdrawn Route #N Prefix

Total Path Attribute Length Attribute Type #1

Attribute Length #1 Attribute Value #1

Attribute Type #N Attribute Length #N

4 8 12 16 20 24 28 320

Unfeasible Routes

Length (1 of 2)

Unfeasible Routes

Length (2 of 2)

... ...

...

480

Attribute Flags

Attribute Type Code

Optional

Bit

Trans-

itive Bit

Par tial

Bit

Extended

Length Bit

Reserved

1612

Attribute Value #N

Network Layer Reachability

Information #1 Prefix

NLRI #1 Length

NLRI #N Length

Network Layer Reachability

Information #N Prefix

Withdrawn Routes

Path Attributes

Network Layer

Reachability Information

Key Concept: The most important message type in BGP is the Update message,

which is used to send detailed information about routes between BGP devices. It

uses a complex structure that allows a BGP speaker to efficiently specify new routes,

update existing ones, and withdraw routes that are no longer valid. Each message may

include the full description of one existing route, and may also withdraw from use a list of

multiple routes.

BGP Connectivity Maintenance: Keepalive Messages

Once a BGP connection is established using Open messages, BGP peers will initially use

Update messages to send each other a large amount of routing information. They will then

settle into a routine, where the BGP session is maintained, but Update messages are sent

only when needed. Since these updates correspond to route changes, and route changes

are normally infrequent, this means many seconds may elapse between receipt of consec-

utive Update messages.

The BGP Hold Timer and Keepalive Message Interval

While a BGP peer is waiting to hear the next Update message, it remains sort of like a

person who has been put “on hold” on the telephone. Now, seconds may not seem like

much to us, but to a computer they are a very long time. Like you, a BGP speaker that is put

on hold for too long might become impatient, and start to wonder if maybe the other guy

hung up on them. Computers don't get offended at being put on hold, but they might wonder

if perhaps a problem arose that led to the connection being interrupted.

To keep track of how long it has been on hold, each BGP device maintains a special hold

timer. This hold timer is set to an initial value each time its peer sends a BGP message. It

then counts down until the next message is received, when it is reset. If the hold timer ever

expires, the connection is assumed to have been interrupted and the BGP session is

terminated.

The length of the hold timer is negotiated as part of session setup using Open messages. It

must be at least three seconds long, or may be negotiated as a value of zero. If zero, the

hold timer is not used; this means the devices are “infinitely patient” and don't care how

much time elapses between messages.

To ensure that the timer doesn't expire even when no Updates need to be sent for a long

while, each peer periodically sends a BGP Keepalive message. The name says it all: the

message just keeps the BGP connection alive. The rate at which Keepalive messages is

sent is implementation-dependent, but the standard recommends that they be sent with an

interval of one-third the value of the hold timer. So if the hold timer has a value of three

seconds, each peer sends a Keepalive every second (unless it needs to send some other

message type in that second). To prevent excess bandwidth use, Keepalives must be sent

no more often than once per second, so that is the minimum interval even if the hold timer is

shorter than three seconds.

BGP Keepalive Message Format

The point of a Keepalive message is the message itself; there's no data to be communi-

cated. In fact, we want to keep the message short and sweet. Thus, it is really a “dummy”

message containing only a BGP header—a nice change after that incredibly long Update

message format! The format of the Keepalive message can be found in Table 141 and

Figure 195.

There is also one other, special use of Keepalive messages: as acknowledgment of receipt

of a valid Open message during initial BGP session setup.

Key Concept: BGP Keepalive messages are sent periodically during idle periods

when no real information needs to be sent between connected BGP speakers. They

serve only to keep the session alive, and thus contain only a BGP header and no

data.

Table 141: BGP Keepalive Message Format

Field Name

Size

(bytes)

Description

Marker 16

Marker: This large field at the start of each BGP message is used for

synchronization and authentication. See the discussion of the BGP general

message format for details.

Length 2

Length: The total length of the message in bytes, including the fields of the

header. Keepalive messages are fixed in length at 19 bytes.

Type 1 Type: BGP message type, value is 4 for Keepalive messages.

Figure 195: BGP Keepalive Message Format

Marker

(128 bits)

Length = 19

Type = 4

4 8 12 16 20 24 28 320

BGP Error Reporting: Notification Messages

Once established, a BGP session will remain open for a considerable period of time,

allowing routing information to be exchanged between devices on a regular basis. During

the course of operation, certain error conditions may crop up that may interfere with normal

communication between BGP peers. Some of these are serious enough that the BGP

session must be terminated. When this occurs, the device detecting the error will inform its

peer of the nature of the problem by sending it a BGP Notification message, and then close

the connection.

Of course, having someone tell you “I found an error, so I quit” is not of much value.

Therefore, the BGP Notification message contains a number of fields that provide infor-

mation about the nature of the error that caused the message to be sent. This includes a set

of primary error codes, as well as subcodes within some of these error codes. Depending

on the nature of the error, an additional data field may also be included to aid in diagnosing

the problem.

In addition to the use of Notification messages to convey the occurrence of an error, this

message type is also used for other purposes. For example, one may be sent if two devices

cannot agree on how to negotiate a session, which isn't, strictly speaking, an error. A Notifi-

cation message is also used to allow a device to tear down a BGP session for reasons

having nothing to do with an error.

BGP Notification Message Format

The format for the BGP Notification messages is detailed in Table 142 and Figure 196.

Table 142: BGP Notification Message Format

Field Name

Size

(bytes)

Description

Marker 16

Marker: This large field at the start of each BGP message is used for

synchronization and authentication. See the discussion of the BGP general

message format for details.

Length 2

Length: The total length of the message in bytes, including the fields of the

header. Notification messages are variable in length.

Type 1 Type: BGP message type, value is 3 for Notification messages.

Error Code 1

Error Code: Specifies the general class of the error. Table 143 shows the

possible error types with a brief description of each.

Error Subcode 1

Error Subcode: This field provides more specific indication of the cause of

the error for three of the Error Code values. The possible values of this field

for each Error Code value are shown in Table 144.

Data Variable

Data: This field contains additional information to help diagnose the error;

its meaning is dependent on the type of error specified in the Error Code

and Error Subcode fields. In most cases, this field is filled in with whatever

bad value caused the error to occur. For example, for “Message Header

Error / Bad Message Type”, the value of the bad Type field is placed here.

BGP Notification Message Error Codes and Error Subcodes

Table 143 and Table 144 show the values permitted for the Error Code and Error Subcode

fields, respectively, and thus provide a good summary of the types of errors that Notification

messages can report (as well as demonstrating the other non-error uses of the message

type).

Figure 196: BGP Notification Message Format

Table 143: BGP Notification Message Error Codes (Page 1 of 2)

Error

Code

Value

Code Name Description

Message Header

Error

A problem was detected either with the contents or length of the BGP

header. The Error Subcode provides more details on the nature of the

problem.

Open Message

Error

A problem was found in the body of an Open message. The Error Subtype

field describes the problem in more detail. Note that authentication failures

or inability to agree on a parameter such as hold time are included here.

Update Message

Error

A problem was found in the body of an Update message. Again, the Error

Subtype provides more information. Many of the problems that fall under

this code are related to issues detected in the routing data or path

attributes sent in the Update message, so these messages provide

feedback about such problems to the device sending the erroneous data.

Hold Timer

Expired

A message was not received before the hold time expired. See the

description of the Keepalive message for details on this timer.

Marker

(128 bits)

Length Type = 3 Error Code

Error Subcode

4 8 12 16 20 24 28 320

Data

Finite State

Machine Error

The BGP finite state machine refers to the mechanism by which the BGP

software on a peer moves from one operating state to another based on

events (see the TCP finite state machine description for some background

on this concept). If an event occurs that is unexpected for the state the

peer is currently in, it will generate this error.

6 Cease

Used when a BGP device wants to break the connection to a peer for a

reason not related to any of the error conditions described by the other

codes.

Table 144: BGP Notification Message Error Subcodes (Page 1 of 2)

Error

Type

Error

Subcode

Value

Subcode Name Description

Message

Header

Error

(Error

Code 1)

Connection Not

Synchronized

The expected value in the Marker field was not found,

indicating that the connection has become unsynchro-

nized. See the description of the Marker field.

2 Bad Message Length

The message was less than 19 bytes, greater than 4096

bytes, or not consistent with what was expected for the

message type.

3 Bad Message Type The Type field of the message contains an invalid value.

Open

Message

Error

(Error

Code 2)

Unsupported Version

Number

The device does not “speak” the version number its peer

is trying to use.

2 Bad Peer AS

The router doesn't recognize the peer's autonomous

system number or is not willing to communicate with it.

3 Bad BGP Identifier The BGP Identifier field is invalid.

Unsupported Optional

Parameter

The Open message contains an optional parameter that

the recipient of the message doesn't understand.

5 Authentication Failure

The data in the Authentication Information optional

parameter could not be authenticated.

Unacceptable Hold

Time

The router refuses to open a session because the

proposed hold time its peer specified in its Open

message is unacceptable.

Table 143: BGP Notification Message Error Codes (Page 2 of 2)

Error

Code

Value

Code Name Description