Journey to CCIE: March 2015

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.

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: ORIGIN AS_PATH NEXT_HOP MULTI-EXIT-DISC LOCAL-PREF ATOMIC-AGGREGATE AGGREGATOR COMMUNITY ORIGINATOR_ID CLUSTER_LIST The Path Attributes field contains three values: Attribute Type— Contains two subsections that describe each attribute type code (listed here) and the flags that apply to those attributes Attribute Length— Defines the length of the attribute Attribute Value— Contains the value belonging to the attribute type code
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: Well-known mandatory Well-known discretionary Optional transitive Optional nontransitive 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.

Journey to CCIE

Tuesday 31 March 2015

ACL

BGP Messages