Versatile Routing and Services with BGP

Understanding and Implementing BGP in SR-OS

Colin Bookham

• Publisher: Wiley
• Year: 2014
• ISBN:
  9781118875629
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Redes de computadoras

Design a robust BGP control plane within a secure, scalable network for smoother services

A robust Border Gateway Protocol setup is vital to ensuring reliable connectivity, an essential capability for any organization. The Internet has become a necessary, always-on service in homes and businesses, and BGP is the protocol that keeps communication flowing. But BGP also has become crucial to delivery of intra-domain business services. But the network is only as reliable as BGP, so service enablement depends upon making BGP more stable, reliable, and service-rich.

Alcatel-Lucent Service Router Operating System is engineered to bear the load of the most demanding networks. The system features support for Symmetric Multiprocessing and unprecedented depth of advanced routing features, all within a single OS that's supported across the entire Alcatel-Lucent IP/MPLS router portfolio. Versatile Routing and Services with BGP provides guidance toward implementation of BGP within SR-OS, and details the use and control of each feature. The book provides in-depth coverage of topics such as:

• BGP/MPLS IP-VPN, VPLS, VPWS
• Labeled Unicast IPv4, reconvergence, and multicast
• Security, graceful restart and error handling
• IPv6 PE (6PE) and IPv6 extensions to BGP/MPLS IP-VPN
• A look at forthcoming features such as Ethernet VPN

Basic BGP competency is assumed, but the book is accessible even to those with zero familiarity with Alcatel-Lucent's SR-OS. It underscores the idea that BGP is more than just service enablement, and can also be used for infrastructure layer transport - but both layers must be solid, scalable, and able to quickly reconverge. Versatile Routing and Services with BGP demonstrates the creation of a robust BGP control plane within a, secure network, allowing the delivery of flawless, uninterrupted service.

Chapter 1

Getting Started

Although this book does not discuss the operation of BGP as a path-vector protocol, it's worth a quick recap on how a BGP speaker processes and stores routes in the Routing Information Bases (RIBs). The RIB within a BGP speaker is made up of three distinct parts: the Adj-RIB-In, the Loc-RIB, and the Adj-RIB-Out. The Adj-RIB-In stores routing information learned from inbound UPDATE messages advertised by peers to the local router. The routes in the Adj-RIB-In represent routes that are available to the path decision process. The Loc-RIB contains routing information the local router selected after applying policy to the routing information contained in the Adj-RIB-In. These are the routes that will be used by the local router. The Adj-RIB-Out stores information the local router selected for advertisement to its peers. This information is carried in UPDATE messages sourced by this router when advertising to peers. In summary, the Adj-RIB-In contains unprocessed routing information advertised by peers to the local router, the Loc-RIB contains the routes that have been selected by the local BGP speaker's best-path decision process, and the Adj-RIB-Out contains the routes for advertisement to peers in UPDATE messages. I'll use this terminology throughout the book, and may interchangeably use Adj-RIB-In or simply RIB-In, and Adj-RIB-Out or simply RIB-Out.

Enabling BGP in its most basic form is a very simple exercise. All you need is an IP interface toward a BGP peer and some minimal BGP configuration. For conciseness, Output 1-1 does not show the IP interface configuration. For exchange of IPv4 reachability, the only parameters required are an Autonomous System (AS) number defined within the global router context (or Virtual Private Routed Network [VPRN] context), an IP address for the peer, and a peer AS number. The IP address and peer AS number are entered in a BGP group context, often referred to as a peer group. Peer groups allow you to group together a set of peers that have a common administrative configuration, and are discussed further in Chapter 10.

---

Output 1-1: Basic BGP Configuration

 router autonomous-system 64496 bgp group “EBGP” neighbor 192.168.0.2 peer-as 64510 exit exit no shutdown exit exit

---

Session Negotiation and Capabilities

A Finite State Machine (FSM) is maintained for each BGP peer, and there are six possible states in the FSM. Initially, the FSM for the BGP peer is in the Idle state. In this state, the router listens for a TCP connection initiated by the remote peer or initiates the TCP connection itself. The second state is the Connect state, where the FSM is waiting for the TCP three-way handshake to be completed. If the TCP connection is not successfully established, the state is changed to Active and a further attempt is made to establish the TCP connection to the remote peer. (If the connection continues to fail, the FSM reverts to the Idle state.) If the TCP connection is successfully established, the FSM completes the BGP initialization, generates an OPEN message toward the peer, and changes its state to OpenSent. If an OPEN message is also received from the remote peer and the parameters contained in the OPEN message are acceptable, the router generates a KEEPALIVE message and changes its state to OpenConfirm. If the parameters of the OPEN message are not acceptable, a NOTIFICATION message is sent with the appropriate error code, and the state is reverted to Idle. While in the OpenConfirm state, if the router receives a KEEPALIVE message from the remote peer, it moves to the Established state. In the Established state, peers can send UPDATE messages to exchange routing information.

The OPEN message sent by each peer contains its AS number, Hold Time, BGP identifier, and some optional parameters. The notable optional parameter is the Capabilities parameter. The Capabilities parameter is defined in RFC 5942 and allows BGP speakers to exchange capability sets in the OPEN exchange. If both peers advertise a given capability, the peers can use that advertised capability on the peering. If either peer did not advertise the capability, it cannot be used.

The Capabilities parameter is encoded as a code, a length, and a value. The output in Debug 1-1 is taken from an OPEN negotiation between an SR-OS router and a test device. The SR-OS router sends its OPEN message with capability codes indicating support for IPv4 unicast Multi-Protocol (MP)-BGP, Route-Refresh, and 4-byte ASN support. The capability code for MP-BGP encodes a value (0x0 0x1 0x0 0x1) that represents an Address Family Identify (AFI) of IPv4 (0x0 0x01) and a Subsequent Address Family Identifier (SAFI) of unicast (0x0 0x1) indicating support only for IPv4 unicast MP-BGP. (The use of the AFI and SAFI for Multi-Protocol BGP is discussed in further detail later in this chapter.) The capability code for 4-Octet ASN also encodes a value indicating its 4-byte Autonomous System number. In this case the SR-OS router only has a 2-byte Autonomous System number; therefore, it is converted into a 4-byte Autonomous System number by setting the two high-order octets of the 4-octet field set to zero.

Figure 1-1 Finite State Machine

Conversely, the test device peer sends its OPEN message indicating support for IPv4 unicast MP-BGP, IPv6 unicast MP-BGP, and Route Refresh. In this OPEN message the capability code for MP-BGP appears twice; each occurrence contains a different capability value. The first occurrence indicates support for IPv4 unicast. The second occurrence, with value (0x0 0x2 0x0 0x1), represents an AFI of IPv6 (0x0 0x2) and a SAFI of unicast (0x0 0x1).

---

Debug 1-1: OPEN message with Capabilities Negotiation

135 2013/04/18 14:47:00.98 BST MINOR: DEBUG #2001 Base BGP "BGP: OPEN Peer 1: 192.168.0.2 - Send (Active) BGP OPEN: Version 4 AS Num 64496: Holdtime 90: BGP_ID 192.0.2.46: Opt Length 16 Opt Para: Type CAPABILITY: Length = 14: Data: Cap_Code MP-BGP: Length 4 Bytes: 0x0 0x1 0x0 0x1 Cap_Code ROUTE-REFRESH: Length 0 Cap_Code 4-OCTET-ASN: Length 4 Bytes: 0x0 0x0 0x11 0xed " 137 2013/04/18 14:47:00.97 BST MINOR: DEBUG #2001 Base BGP "BGP: OPEN Peer 1: 192.168.0.2 - Received BGP OPEN: Version 4 AS Num 64510: Holdtime 30: BGP_ID 192.168.0.2: Opt Length 16 Opt Para: Type CAPABILITY: Length = 14: Data: Cap_Code MP-BGP: Length 4 Bytes: 0x0 0x1 0x0 0x1 Cap_Code MP-BGP: Length 4 Bytes: 0x0 0x2 0x0 0x1 Cap_Code ROUTE-REFRESH: Length 0 "

---

This asymmetric capability negotiation is acceptable from the perspective of the peering session, providing that the only optional capabilities used are IPv4 MP-BGP and Route-Refresh. If, for example, the peer advertises an IPv6 prefix using MP-BGP, this results in a NOTIFICATION message being sent. The integrity of the peering session thereafter is dependent on supported and configured error handling capabilities. Standard capabilities' codes are maintained by the Internet Assigned Numbers Authority (IANA) at www.iana.org/assignments/capability-codes/capability-codes.xml but vendor-specific capability codes are in widespread use. During capability exchange these should be ignored by a BGP speaker if not recognized.

---

Output 1-2: Local/Remote Capabilities

*A:R1# show router bgp neighbor 192.168.0.2 | match expression “Local|Remote” Local AS : 64496 Local Port : 179 Local Address : 192.168.0.1 Local Family : IPv4 Remote Family : IPv4 IPv6 Local Capability : RtRefresh MPBGP 4byte ASN Remote Capability : RtRefresh MPBGP Local AddPath Capabi*: Disabled Remote AddPath Capab*: Send - None

---

The Hold Times negotiated in the OPEN exchange do not have to be the same for the BGP session to be established. The BGP speaker calculates the active Hold Time value by using the smaller of its configured value and the value received in the OPEN message. In the OPEN exchange shown in Debug 1-1, SR-OS uses the default Hold Time of 90 seconds while the peer advertises a Hold Time of 30 seconds. This exchange results in both peers using a Hold Time of 30 seconds, with KEEPALIVE messages exchanged every (30/3) 10 seconds.

As previously described, when a BGP speaker has sent an OPEN message it moves to the OpenSent state, and when it has received a corresponding OPEN message from its peer it moves to OpenConfirm state. If the BGP speaker is happy with the contents of the received OPEN message, it responds with a KEEPALIVE message. When each BGP speaker has sent and received an OPEN message and KEEPALIVE message, they move to the ESTABLISHED state and can then exchange reachability information.

UPDATE Messages

This book does not explicitly detail all BGP message formats, but it's useful to review the basic BGP UPDATE format so you can understand the differences between it and the general format of Multi-Protocol BGP UPDATE messages. The Withdrawn Routes field contains a list of IP prefixes in the form <length, prefix> that are being withdrawn from service. The Network Layer Reachability Information (NLRI) field contains a list of IP prefixes, again in the form <length, prefix>, that can be reached from a given BGP speaker (subject to policy).

---

Debug 1-2: Active Hold Time

*A:R1# show router bgp neighbor 192.168.0.2 | match "Hold Time" Hold Time : 90 Keep Alive : 30 Min Hold Time : 0 Active Hold Time : 30 Active Keep Alive : 10 

---

Figure 1-2 UPDATE Message Format

The Path attributes field contains a sequence of attributes associated with an NLRI and each attribute can be placed into one of four categories: well-known mandatory, well-known discretionary, optional transitive, and optional non-transitive. Non-transitive simply refers to the fact that this attribute may be advertised into an AS but may not leave that AS.

Mandatory attributes must be present in the UPDATE message if NLRI is pre...