1) Open Message : Used to open BGP Sessions
Parameters:
a) Version : Should be same
b) AS Number : Should be matched with configured remote-as number
c) Hold Time : The length of time a BGP speaker expects to wait before receiving either an UPDATE or KEEPALIVE message from its peer.
->if configured as 0 then keepalives are not considered.
->If both the values are different then the lowest will be considered as hold time.
->hold time should be 3 times of keep alive timer.
->Default 180
d) BGP ID: The BGP ID value must match the values configured by both the local and remote BGP peers for each BGP peer relationship, and the remote peer must be reachable by the local BGP peer or the session will not be opened.
e) Optional: Contains optional BGP parameters, such as the Marker field, which contains authentication information; if authentication is not configured, the Marker field will contain all 1s.
Parameters:
a) Version : Should be same
b) AS Number : Should be matched with configured remote-as number
c) Hold Time : The length of time a BGP speaker expects to wait before receiving either an UPDATE or KEEPALIVE message from its peer.
->if configured as 0 then keepalives are not considered.
->If both the values are different then the lowest will be considered as hold time.
->hold time should be 3 times of keep alive timer.
->Default 180
d) BGP ID: The BGP ID value must match the values configured by both the local and remote BGP peers for each BGP peer relationship, and the remote peer must be reachable by the local BGP peer or the session will not be opened.
e) Optional: Contains optional BGP parameters, such as the Marker field, which contains authentication information; if authentication is not configured, the Marker field will contain all 1s.
The optional Capabilities field contains information that allows for BGP feature negotiation; it is either supported or unsupported between BGP peers. If a Capability option is not supported, it will be ignored by the remote peer, and the session will be renegotiated without the capability.
BGP Capabilities Advertisement:
Using capabilities advertisement, peers can exchange capabilities and negotiate a session using the most agreed-upon features. If one of the peers does not support an optional parameter, it sends the advertiser a NOTIFICATION message with the error "Unsupported Optional Parameter." After receiving the NOTIFICATION message, the advertising peer resends the message without the unsupported parameter and so on, until both peers agree on a set of parameters
Capabilities Code
|
Description
|
0
|
Reserved
|
1
|
Multiprotocol extensions for BGP-4
|
2
|
ROUTE-REFRESH capability for BGP-4
|
3
|
Cooperative route filtering capability
|
4
|
Multiple routes to a destination capability
|
5–63
|
Unassigned
|
64
|
Graceful restart capability
|
65
|
Support for 4-octet AS number capability
|
66
|
Support for dynamic capability
|
128–255
|
Vendor specific
|
2) Update Message : Carries route updates for established BGP sessions
After a BGP session has been established, the peering routers begin to exchange routing information using UPDATE messages. UPDATE messages contain information about each route advertised to the peering router. In BGP routing, network prefixes are also referred to as Network Layer Reachability Information (NLRI).
Unfeasible Route Length
|
This field contains the total number of routes that are to be withdrawn from the BGP routing tables.
If this value is 0, no routes are to be withdrawn in this message.
|
Withdrawn Routes
|
The Withdrawn Routes field contains prefixes that are to be removed from the BGP tables. This information is stored in a [length, prefix] format. Each route that is to be removed from an established BGP session is sent to the neighboring router in this format.
|
Total Path Attribute Length
|
This field identifies the total length of the Path Attributes field (in octets).
|
Path Attributes
|
BGP path attributes (attribute type codes) are basically the metrics that are to be used by the decision process. There are 19 BGP path attributes defined by IANA, the top 10 of which are as follows:
The Path Attributes field contains three values:
|
Attribute Type (a subsection of the Path Attributes field)
|
The Attribute Type field contains two items: the Attribute Flags and the Attribute Type Code. Each of the attributes from the Attribute Type Code section of the Path Attributes field has an associated Attribute Type category, which defines how the attribute is to be forwarded by other BGP routers. There are four attribute types:
The Attribute Flags field is covered shortly.
|
NLRI
|
The NLRI field is the part of the UPDATE message field that contains paths that are to be advertised as reachable (network layer reachability information).
The NLRI field contains the prefixes for each of the paths to be advertised in a [length, prefix] format. This is the information that was taken from the local routers' Adj-RIB-Out database and will be added to the neighboring routers' Adj-RIB-In database.
|
After two BGP peers have formed an established BGP session, they can exchange routing information in the form of UPDATE messages. The UPDATE messages contain information about new routes that are to be added to the BGP table, routes that are no longer reachable (and are to be removed from the BGP table), and path attributes for the routes.
As shown in the preceding table, the Unfeasible Route Length field contains the number of routes that are to be removed from the BGP table. The Withdrawn Routes field contains the actual routes that are to be removed, in the [length, prefix] format. The Path Attributes field contains the attribute type codes for the paths sent in the update, and the Attribute Flags field specifies how attributes are to be handled by the routing process. And, finally, the NLRI field contains the new or changed routes that are being advertised.
In BGP, each routing update contains attributes that belong to all the NLRI paths in the message. The 10 basic attribute type codes and attribute values you will most likely encounter when working with BGP-4 in an IP environment are as follows:
- ORIGIN— Specifies the origin of the route: IGP, EGP, or Incomplete.
- AS_PATH— Contains a list of ASs that the route traversed in its path.
- NEXT_HOP— The next hop taken to reach the destination route.
- MULTI-EXIT-DISC— Multiple Exit Discriminator is a metric used to determine which path to take if there are multiple exit points to an AS.
- LOCAL-PREF— Indicates preference for one path over others within an AS.
- ATOMIC-AGGREGATE— Indicates that the local process chose a less-specific path to a destination over one that is more specific.
- AGGREGATOR— This attribute is used to indicate the IP address of a router that has aggregated a number of routes together.
- COMMUNITY— Specifies the local BGP COMMUNITY value; by default, all community-aware routers belong to the Internet community.
- ORIGINATOR_ID— Specifies a route reflection with a route reflector cluster.
- CLUSTER_LIST— Contains a reflection path that shows through which path a reflected route has passed.
Each of these attribute code types is accompanied by an attribute flag that specifies how the attribute is to be treated when it is processed by a peer router. Table 7-6 shows the four attribute flags and their associated flags; these are covered in detail later in this chapter.
Table 7-6. BGP Attribute Flags
Attribute Flag
|
Flag Name
|
Description
|
Highest bit
|
Optional bit
|
Defines whether an attribute is well known (0) or optional (1).
|
Second highest bit
|
Transitive bit
|
Defines whether an optional attribute is nontransitive (0) or transitive (1).
|
Third highest bit
|
Partial bit
|
Defines whether an optional transitive attribute is complete (0) or partial (1).
|
Fourth highest bit
|
Extended Length bit
|
Defines whether the attribute length is 1 octet (0) or 2 octets (1). This flag is only used (set to 1) when the attribute length is greater than 255 octets.
|
Example 7-2 shows a protocol analysis of an UPDATE message. Notice in the example that this message is a 68-byte BGP type 2 UPDATE message, with a Marker field of all 1s, indicating no authentication is taking place. This update does not contain any withdrawn routes, indicated by the 0 Unfeasible Routes Length. The first attribute in this message is the well-known transitive type 1 ORIGIN attribute value of 0-IGP, indicating that the message came from an I-BGP session. The next well-known transitive attribute is the type 2 AS_PATH attribute; this attribute lists the ASs through which the route has passed. The Path Segment Type field value of 2 (AS-SEQUENCE) means that this update contains an ordered list of autonomous systems. The Path Segment Length field value of 1 indicates that there is only one AS in the path, and the AS Identifier field value indicates that the packet originated from AS 2. The next well-known transitive attribute is the type 3 NEXT-HOP attribute that contains the next hop of 10.50.4.2. The final optional nontransitive attribute is the type 4 MED attribute. This attribute is used to determine which route to take if there are multiple exit points to an AS. The MED for this update is 0.
The next field in this update contains the NLRI information. The NLRI field contains new or changed routes that are being advertised in this message. This message contains routes to the networks 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24, 192.168.14.0/24, and 192.168.15.0/24. Each of these routes is presented in [prefix length, subnet mask, IP address] format.
Example 7-2. BGP UPDATE Message
Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary 13 [10.50.4.2] [10.50.4.1] 141 0:00:37.537 0.001.028 04/28/2002 03:14:50 PM BGP: type = Update DLC: ----- DLC Header ----- DLC: DLC: Frame 13 arrived at 15:14:50.4449; frame size is 141 (008D hex) bytes. DLC: Destination = Station 0004272281D8 DLC: Source = Station 000427228197 DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes IP: Type of service = C0 IP: 110. .... = internetwork control IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit IP: .... ...0 = CE bit - no congestion IP: Total length = 127 bytes IP: Identification = 3 IP: Flags = 0X IP: .0.. .... = might fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 1 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 9C50 (correct) IP: Source address = [10.50.4.2] IP: Destination address = [10.50.4.1] IP: No options IP: TCP: ----- TCP header ----- TCP: TCP: Source port = 179 (BGP) TCP: Destination port = 11002 TCP: Sequence number = 3816595210 TCP: Next expected Seq number= 3816595297 TCP: Acknowledgment number = 3817488925 TCP: Data offset = 20 bytes TCP: Flags = 18 TCP: ..0. .... = (No urgent pointer) TCP: ...1 .... = Acknowledgment TCP: .... 1... = Push TCP: .... .0.. = (No reset) TCP: .... ..0. = (No SYN) TCP: .... ...0 = (No FIN) TCP: Window = 16320 TCP: Checksum = 19F9 (correct) TCP: No TCP options TCP: [87 Bytes of data] TCP: BGP: ----- BGP Message ----- BGP: BGP: 16 byte Marker (all 1's) BGP: Length = 68 BGP: BGP type = 2 (Update) BGP: BGP: Unfeasible Routes Length = 0 BGP: No Withdrawn Routes in this Update BGP: Path Attribute Length = 25 bytes BGP: Attribute Flags = 4X BGP: 0... .... = Well-known BGP: .1.. .... = Transitive BGP: ..0. .... = Complete BGP: ...0 .... = 1 byte Length BGP: Attribute type code = 1 (Origin) BGP: Attribute Data Length = 1 BGP: Origin type = 0 (IGP) BGP: Attribute Flags = 4X BGP: 0... .... = Well-known BGP: .1.. .... = Transitive BGP: ..0. .... = Complete BGP: ...0 .... = 1 byte Length BGP: Attribute type code = 2 (AS Path) BGP: Attribute Data Length = 4 BGP: Path segment type = 2 (AS_SEQUENCE) BGP: Path segment length = 1 BGP: AS Identifier = 2 BGP: Attribute Flags = 4X BGP: 0... .... = Well-known BGP: .1.. .... = Transitive BGP: ..0. .... = Complete BGP: ...0 .... = 1 byte Length BGP: Attribute type code = 3 (Next Hop) BGP: Attribute Data Length = 4 BGP: Next Hop = [10.50.4.2] BGP: Attribute Flags = 8X BGP: 1... .... = Optional BGP: .0.. .... = Non-transitive BGP: ..0. .... = Complete BGP: ...0 .... = 1 byte Length BGP: Attribute type code = 4 (Multi Exit Disc) BGP: Attribute Data Length = 4 BGP: Multi Exit Disc Attribute = 0 BGP: BGP: Network Layer Reachability Information: BGP: IP Prefix Length = 24 bits, IP subnet mask [255.255.255.0] BGP: IP address [192.168.11.0] BGP: IP Prefix Length = 24 bits, IP subnet mask [255.255.255.0] BGP: IP address [192.168.12.0] BGP: IP Prefix Length = 24 bits, IP subnet mask [255.255.255.0] BGP: IP address [192.168.13.0] BGP: IP Prefix Length = 24 bits, IP subnet mask [255.255.255.0] BGP: IP address [192.168.14.0] BGP: IP Prefix Length = 24 bits, IP subnet mask [255.255.255.0] BGP: IP address [192.168.15.0] BGP: BGP: 16 byte Marker (all 1's) BGP: Length = 19 BGP: BGP type = 4 (KEEPALIVE) BGP: DLC: --- Frame too short ADDR HEX ASCII 0000: 00 04 27 22 81 d8 00 04 27 22 81 97 08 00 45 c0 | ..'"....'"....E. 0010: 00 7f 00 03 00 00 01 06 9c 50 0a 32 04 02 0a 32 | .........P.2...2 0020: 04 01 00 b3 2a fa e3 7c 9f 0a e3 8a 42 1d 50 18 | ....*..|....B.P. 0030: 3f c0 19 f9 00 00 ff ff ff ff ff ff ff ff ff ff | ?..รน............ 0040: ff ff ff ff ff ff 00 44 02 00 00 00 19 40 01 01 | .......D.....@.. 0050: 00 40 02 04 02 01 00 02 40 03 04 0a 32 04 02 80 | .@......@...2... 0060: 04 04 00 00 00 00 18 c0 a8 0b 18 c0 a8 0c 18 c0 | ................ 0070: a8 0d 18 c0 a8 0e 18 c0 a8 0f ff ff ff ff ff ff | ................ 0080: ff ff ff ff ff ff ff ff ff ff 00 13 04 | .............
In Figure 7-15, for example, Routers A and B have an established BGP session and are now exchanging routing information using UPDATE messages. Router A sends an update removing two routes: one to 50.1.1.0/24, and one to 50.2.2.0/24. This routing update also contains four new routes: 51.3.3.0/24, 51.4.4.0/24, 51.5.5.0/24, and 60.1.1.0/24. These routes are sent out as routes learned through E-BGP, but originating from an I-BGP session (indicated by the Type 1 IGP path attribute), with an AS path of AS 402, AS 10, and AS 30, with a next hop of 51.5.2.4. Router B receives the UPDATE message, removes the routes to 50.1.1.0/24 and 50.2.2.0/24 from its Adj-RIB-In table, and then adds the routes to the 51.3.3.0/24, 51.4.4.0/24, 51.5.5.0/24, and 60.1.1.0 networks to its Adj-RIB-In table to be processed by its BGP decision process.
Figure 7-15 Routers Exchanging BGP Updates
Router B then takes its routes from the local Adj-RIB-Out table, and sends an update to Router A containing new routes to networks 197.62.59.0/24, 197.63.59.0/24, and 197.64.59.0/24. The new routes all came from an E-BGP session, but originated from an I-BGP session, using an AS path of AS 917, AS 40, and AS 29, and have the next hop of 197.61.1.1. Router A takes these new routes and adds them to its Adj-RIB-In table to be processed by the BGP decision process, and then adds the best routes to its local BGP routing table Loc-RIB. Until there are any route changes, Routers A and B will not send any further routing updates; they will only send KEEPALIVE messages back and forth, notifying each other that the BGP session is still active.
3) Notification Message - Notifies a peer router of an error condition
used to indicate an error condition resulting in BGP session termination. NOTIFICATION messages are always immediately followed by session termination. Upon termination of a BGP connection, the TCP session between the BGP peers is torn down, all resources are released, "route withdrawal" messages are sent to peering BGP peers, and all BGP routes are removed from the table. A BGP session might terminate in an error condition for a number of reasons.
MessageNumber
|
Message Type
|
Description
|
1
|
Message Header Error
|
Indicates that an error was found processing a BGP message header. Message header errors include a subcode that indicates the reason for the error.
|
2
|
OPEN Message Error
|
Indicates a message found in an OPEN message. OPEN message errors include an error subcode that indicates the cause of the error.
|
3
|
UPDATE Message Error
|
Indicates a message found in an UPDATE message. UPDATE message errors are accompanied by an error subcode that indicates the cause of the error.
|
4
|
Hold Timer Expired
|
This error type indicates that the local system did not receive a KEEPALIVE or UPDATE message within the negotiated time interval.
|
5
|
Finite-State Machine Error
|
When an unexpected error occurs, a finite-state machine error is sent to the peering router, terminating the BGP session.
|
6
|
Cease
|
Indicates the immediately terminated BGP session.
|
MessageNumber
|
Message Type
|
Description
|
1
|
Message Header Error
|
Indicates that an error was found processing a BGP message header. Message header errors include a subcode that indicates the reason for the error.
|
2
|
OPEN Message Error
|
Indicates a message found in an OPEN message. OPEN message errors include an error subcode that indicates the cause of the error.
|
3
|
UPDATE Message Error
|
Indicates a message found in an UPDATE message. UPDATE message errors are accompanied by an error subcode that indicates the cause of the error.
|
4
|
Hold Timer Expired
|
This error type indicates that the local system did not receive a KEEPALIVE or UPDATE message within the negotiated time interval.
|
5
|
Finite-State Machine Error
|
When an unexpected error occurs, a finite-state machine error is sent to the peering router, terminating the BGP session.
|
6
|
Cease
|
Indicates the immediately terminated BGP session.
|
Each NOTIFICATION message contains three fields: Error Code, Error Subcode, and Data. The Error Code field specifies the type of NOTIFICATION error. The Error Subcode, if provided, gives a more detailed explanation of the error. One or more error subcodes might be included in a NOTIFICATION message. The Data field includes any diagnosis information that is related to the error. Not all NOTIFICATION messages include a value in the Data field.
When an error is found while processing a BGP header, a message header error NOTIFICATION message is generated. This message is generated in the event that a BGP header is received with an invalid Marker field, if the value of the length of a message header is greater or less than the required value, or if the type of the message header is unknown. Table 7-8 shows Message Header Error Notification subcodes and their descriptions.
Message Header Error NOTIFICATION Subcodes
Message Number
|
Message Subcode Type
|
Description
|
0
|
No error subcode
|
Null field.
|
1
|
Connection Not Synchronized
|
Indicates that the Marker field in a BGP message is not the expected value.
OPEN message— All 1s, unless TCP MD-5 authentication is in use
All others— Negotiated in OPEN messages
|
2
|
Bad Message Length
|
The length of a message header is greater or less than the required value. This message contains the bad value in the Data field.
OPEN— Minimum 29 octets, maximum 4096 octets
UPDATE— Minimum 23 octets, maximum 4096 octets
KEEPALIVE— No greater or less than 19 octets (the size of an empty BGP KEEPALIVE message)
|
3
|
Bad Message Type
|
Indicates that an unrecognized message type was received. The value of the Type field is included in the Data field of this message.
|
BGP OPEN message errors can be caused by failed or misconfigured TCP MD-5 authentication attempts, corrupt TCP packets, or other BGP configuration problems. OPEN message errors include a message subcode that describes the reason for the error message. Table 7-9 shows possible subcode messages and their descriptions.
OPEN Message Error NOTIFICATION Subcodes
Message Number
|
Message Subcode Type
|
Description
|
1
|
Unsupported Version
|
The BGP peer is using an unsupported BGP version. The Data field in this message includes the largest locally supported BGP version.
|
2
|
Bad Peer AS
|
The peering router's My AS value is not as expected. This error might be cause by a misconfiguration on one of the peering routers.
|
3
|
Bad BGP ID
|
The peering router's BGP ID value is not as expected. This error might be caused by a misconfiguration on either router. This value must be a valid IP address.
|
4
|
Unsupported Optional
|
The local router received an unsupported Optional value.
|
5
|
Authentication Failure
|
This message is generated upon BGP authentication failure.
|
6
|
Unacceptable Hold Time
|
The hold-timer value is not acceptable to the local system, any hold time might be rejected; hold timers must be negotiated on both BGP peers.
|
After the OPEN messages have been received and the routers have established a valid BGP session, they begin to send UPDATE messages. A number of different errors might occur when processing UPDATE messages. These errors are generally the result of a misconfiguration on one of the peer routers. Table 7-10 shows the various UPDATE message error NOTIFICATION messages and their descriptions.
UPDATE Message Error NOTIFICATION Subcodes
Message Number
|
Message Subcode Type
|
Description
|
1
|
Malformed Attribute List
|
The length of the Unfeasible Route Length and/or Total Attribute Length plus the fixed UPDATE header size (the fixed size of the UPDATE header [19] plus the size of the Total Path Attribute Length field [2] plus the Unfeasible Route Length field [2]) is too large.
This message might also be sent if the same attribute appears more than once in the same UPDATE message.
|
2
|
Unrecognized Well-Known Attribute
|
Indicates an unknown well-known mandatory attribute. The value of this attribute is included in the Data field of the message.
|
3
|
Missing Well-Known Attribute
|
Indicates that a well-known mandatory attribute is missing. The Data field includes the missing attribute.
|
4
|
Attribute Flag Error
|
The Attribute Flag field and Attribute Code field do not match. This might be a bad attribute, flag, code, or value. This information is included in the Data field for the message.
|
5
|
Attribute Length Error
|
The actual attribute length does not match the length specified by the Attribute Length field. The attribute data (attribute type, length, and value) is included in the Data field for the message.
|
6
|
Invalid Origin Attribute
|
The ORIGIN value is not defined or is unrecognized. The value of the ORIGIN field is included in the error message.
|
7
|
AS Routing Loop
|
The local AS number has been seen in an UPDATE message—an AS routing loop is assumed.
|
8
|
Invalid Next-Hop Attribute
|
The next-hop value is not a valid IP address; this is a syntax error. The value is included in the message.
|
9
|
Optional Attribute Error
|
Indicates an error in the value of a recognized optional attribute. The value of this error appears in the Data field of this message.
|
10
|
Invalid Network Field
|
Indicates a syntax error in the NLRI field for a message.
|
11
|
Malformed AS_PATH
|
The AS_PATH is syntactically incorrect.
|
If a BGP session has no errors, you will not see any NOTIFICATION messages unless an interface goes down or the BGP configuration has changed. After two BGP peers have formed a BGP session, they exchange KEEPALIVE messages to verify session BGP integrity. The next section discusses the BGP KEEPALIVE message type.
4) KeepAlive Message : Notifies a peer router of an error condition
The KEEPALIVE message contains no data; it is just a 19-byte BGP header.. KEEPALIVE messages are sent by the peering routers every 60 seconds, by default, to notify neighboring peers that the BGP connection is active.
5) Route-Refresh Message : An optional message (negotiated during capability advertisement) that is sent to request dynamic BGP route updates from the Adj-RIB-Out table of a remote BGP speaker
Prior to Cisco IOS Software Release 12.0(6)T, all BGP-speaking routers used to require a manual BGP session reset each time the local routing policy changed. This session reset allowed peers to apply new policies as the routers processed and received the incoming routing updates from their remote peers. In legacy versions of Cisco IOS software, this problem was solved, on a peer-by-peer basis, using BGP soft reconfiguration. After BGP soft reconfiguration has been configured on a legacy peer, that router stores the full, unmodified copy of the incoming Adj-RIB-In table that it received from each remote peer in memory. Although this feature promotes network stability by preventing BGP session interruptions, it also consumes large amounts of system resources. Soft configuration is triggered each time a soft-reconfiguration request is issued using the clear ip bgp {* | ip-address | peer-group} soft [in | out] command; the use of this command is covered later in Chapter 9, "Advanced BGP Configuration." When this command is issued, the local BGP peer acts as though it has just received a full routing update from the remote peer by refreshing routes stored in the Loc-RIB table using the Adj-RIB-In information stored in memory.
The BGP ROUTE-REFRESH capability, specified in RFC 2918, also referred to in Cisco IOS Software as the BGP soft reset enhancement, which is automatically enabled in later releases of Cisco IOS Software, is negotiated between BGP speakers during the capabilities exchange portion of BGP session initialization. This capability allows BGP peers to either request dynamic inbound updates or send outbound route updates to a peer without the soft reconfiguration. The IANA-assigned ROUTE-REFRESH capability (2) is contained in the Optional Capabilities field of the BGP OPEN messages. For ROUTE-REFRESH messages to be sent and understood, each of the peers negotiating a BGP session must support the capability. If a peer that does not understand this capability receives a ROUTE-REFRESH request message from a remote peer, that peer ignores the message, logging an "Unsupported OPEN Parameter" error, and continues on uninterrupted. When the ROUTE-REFRESH capability is not supported by both peers in a BGP peer relationship, neither of the peers will be able to use the capability, and either soft reconfiguration or manual session re-initialization has to take place to refresh the Adj-RIB-In table. If the ROUTE-REFRESH capability is successfully negotiated during session initialization, and a ROUTE-REFRESH request is, for some reason, unsuccessful, the session can still be manually cleared.
No comments:
Post a Comment