| Previous | Table of Contents | Next |
NOTIFICATION Message
From the preceding examination of the finite state machine, it should be apparent that many opportunities exist among the various states, for errors to be detected. A NOTIFICATION message is always sent whenever an error is detected, after which the peer connection is closed. Network administrators will need to evaluate these NOTIFICATION messages to determine the specific nature of errors that emerge in the routing protocol. Figure 4-15 illustrates the general message format.
)
Figure 4-15 NOTIFICATION message format.
The NOTIFICATION message is composed of the Error code (1-byte), Error subcode (1-byte), and a Data field (variable).
The Error code indicates the type of the notification, the Error subcode provides more specific information about the nature of the error, and the Data field contains data relevant to the error such as a bad header, an illegal AS number, and so on. Table 4-1 lists possible errors and their subcodes.
Troubleshooting:
Form and meaning of NOTIFICATION error messages
| Error Code | Error Subcode |
|---|---|
| 1—Message Header Error | 1—Connection Not Synchronized |
| 2—Bad Message Length | |
| 3—Bad Message Type | |
| 2—OPEN Message Error | 1—Unsupported Version Number |
| 2—Bad Peer AS | |
| 3—Bad BGP Identifier | |
| 4—Unsupported Optional Parameter | |
| 5—Authentication Failure | |
| 6—Unacceptable Hold Time | |
| 3—UPDATE Message Error | 1—Malformed Attribute List |
| 2—Unrecognized Well-Known Attribute | |
| 3—Missing Well-Known Attribute | |
| 4—Attribute Flags Error | |
| 5—Attribute Length Error | |
| 6—Invalid Origin Attribute | |
| 7—AS Routing Loop | |
| 8—Invalid NEXT_HOP Attribute | |
| 9—Optional Attribute Error | |
| 10—Invalid Network Field | |
| 11—Malformed AS_path | |
| 4—Hold Timer Expired | NOT applicable |
| 5—Finite State Machine Error (for errors detected by the FSM) | NOT applicable |
| 6—Cease (for fatal errors besides the ones already listed) | NOT applicable |
KEEPALIVE Message
KEEPALIVE messages are periodic messages exchanged between peers to determine whether peers are reachable. As discussed previously, the hold time is the maximum amount of time that may elapse between the receipt of successive KEEPALIVE or UPDATE messages. The KEEPALIVE messages are sent at a rate that ensures that the hold time will not expire (the session is considered alive). A recommended rate is one-third of the hold time interval. If the hold time interval is zero, periodic KEEPALIVE messages will not be sent. The KEEPALIVE message is a 19-byte BGP message header with no data following it.
UPDATE Message and Routing Information
Central to the BGP protocol is the concept of routing updates. Routing updates contain all the necessary information that BGP uses to construct a loop-free picture of the Internet. The following are the basic blocks of an UPDATE message:
- • Network Layer Reachability Information (NLRI)
- • Path attributes
- • Unreachable routes
- • Path attributes
Figure 4-16 illustrates these components in the context of an UPDATE message format.
)
Figure 4-16 BGP routing update.
The NLRI is an indication, in the form of an IP prefix route, of the networks being advertised. The path attribute list provides BGP with the capabilities of detecting routing loops and the flexibility to enforce local and global routing policies. An example of the BGP path attributes is the AS_path attribute, which is a sequence of AS numbers a route has traversed before reaching the BGP router.
AS3 in figure 4-17, for example, is receiving BGP updates from AS2 indicating that network 10.10.1.0/24 (NLRI) is reachable via two hops, first AS2 and then AS1. Based on this information, AS3 will be able to direct its traffic to 10.10.1.0/24.
)
Figure 4-17 BGP routing update example.
The third part of the UPDATE message, is a list of routes that have become unreachable—or in BGP terminology, WITHDRAWN. With the example illustrated in figure 4-17, if 10.10.1.0/24 is no longer reachable or experiences a change in its attribute information, BGP can withdraw the route that it advertised by sending an UPDATE message that lists the new network information or the network being unreachable.
Network Layer Reachability Information
BGP4 provides a new set of mechanisms for supporting classless interdomain routing (CIDR). As discussed in Chapter 3, "Handling IP Address Depletion," the concept of CIDR is a move from the traditional IP classes (A, B, C) toward a concept of IP prefixes. The IP prefix is an IP network address with an indication of the number of bits (left to right) that constitute the network number. The Network Layer Reachability Information (NLRI) is the mechanism by which BGP supports classless routing. The NLRI is the part of the BGP routing update that lists the set of destinations about which BGP is trying to inform its other BGP neighbors. The NLRI consists of multiple instances of the 2-tuples <length, prefix>, where length is the number of masking bits that a particular prefix has.
Figure 4-18 illustrates the NLRI <19, 198.24.160.0>. The prefix is 198.24.160.0, and the length is a 19-bit mask (counting from the far left of the prefix).
)
Figure 4-18 NLRI example.
| Previous | Table of Contents | Next |