BGP4/BGP+
Border Gateway Protocol Version 4 (BGP-4) is the principal protocol used in the Internet backbone and in networks for large organizations. The BGP4 specification (RFC 1771) details the messages exchanged by BGP routers, as well as their meaning and usage. BGP4 - Inter-Domain Routing in the Internet, by John W. Stewart III is a descriptive reference on this protocol.
Internal Versus External BGP
The BGP4 protocol is used according to two sets of rules, depending on whether or not the two communicating BGP routers are within the same Autonomous System (AS). An AS is a collection of routers that implement the same routing policy and are typically administered by a single group of administrators. ASs connected to the Internet are assigned Autonomous System Numbers (ASNs) that are key to inter-domain routing. When BGP is used between two ASs, the protocol is referred to as EBGP (External BGP); when BGP is used within an AS it is referred to as IBGP (Internal BGP). The following figure depicts the differences in topology between EBGP versus IBGP.
Figure: External BGP Versus Internal BGP
In the figure above, AS1, AS2, and AS3 are distinct Autonomous Systems. The Rns are routers in the various ASs. Routers on the links between ASs `speak' EBGP, while the routers within AS3 `speak' IBGP.
IBGP Extensions
In the original BGP4 specification (RFC 1771), all IBGP routers within an AS are required to establish a full mesh with each other. This leads to a lack of scalability which is solved by the introduction of two additional concepts: route Reflection and Confederations.
In route reflection, some routers in an AS are assigned the task of re-distributing internal routes to other internal AS routers. To prevent looping within an AS that uses route reflection, two concepts are important: the originator-id and cluster-list attributesThe originator-id is the identification of the router that originated a particular route. Routers within an AS propagate this information and refuse to send a route back to its originator. Even the use of route reflectors and originator-ids can lead to scalability problems in an AS. The cluster-list concept helps this problem. A cluster consists of a reflecting router and its clients. A Cluster ID is the IP address of the reflecting router if there is one, or a configured number otherwise. A cluster-list is a constructed list, consisting of the cluster IDs of all of the clusters that a route has passed through. Each router refuses to send a route back to a cluster that has seen the route already.
In a confederation, an AS is divided into multiple sub-confederation subsets. Each sub-confederation is defined in terms of its own ASN and a list of routers. Routers within a sub-confederation are expected to fully mesh using IGP. Sub-confederations within a confederation speak a variant of EGP, called EIGP. Additional path attributes are used with a confederation to indicate paths that should not be propagated outside the confederation.
Communities
In deployment of BGP4 into a growing Internet environment, it became necessary to deal with certain routes in different manners not related to the strict routing of packets. The community attribute was invented to allow a route to be `tagged' with multiple numbers, called communities. This is also referred to sometimes as route coloring.
BGP Router Test Configuration
The Ixia Protocol server implements an environment in which the Ixia hardware simulates multiple routers which speak IBGP and/or EBGP with one or more DUT routers. For example, in the External BGP Versus Internal BGP figure, the Ixia hardware emulates R1, R3, and R5 while the DUTs are R2 and R4. The following figure depicts the same setup based on the location of the simulated or actual router:
Figure: BGP Interconnection Environment
All of the routers are logically connected through appropriate networking hardware. The Ixia hardware is used to simulate three of the routers in two different ASs communicating with two routers being tested.
A single router emulated by the Ixia hardware is specified by a single IP address, and a number of emulated routers may be specified by a range of IP addresses. Each DUT router is identified by its IP address.
Messages may be sent between the emulated routers and the DUT routers when a connection is made and one of the two endpoints sends an OPEN message. Where the emulated routers and the DUT routers send their OPEN messages simultaneously, standard collision handling is applied. Thereafter, the emulated routers send a number of UPDATE messages to the DUT routers. The UPDATE messages contain a number of network address ranges (route ranges), also known as ranges of prefixes. The ranges of generated network addresses is illustrated in the following figure.
Figure: Generation of Network Addresses in BGP UPDATE Messages
A designated number of network addresses are generated with network Mask Width with the From through To values. The following table shows some examples of generated addresses. Network Addresses are generated by starting with the First Route and From mask width up to, but not including 224.0.0.0. (127.*.*.* is also skipped). If the requested number of network addresses has not been generated before 224.0.0.0 is reached, then the next mask length is used with the First Route to generate network addresses.
First Route | Mask Width From | Mask Width To | Iterator Step | Number of Routes | Generated BGP Routes (Network Addresses) |
---|---|---|---|---|---|
192.168.36.0 |
24 |
26 |
1 |
(14,378,756 Max.) |
192.168.36.0/24 192.168.37.0/24 192.168.38.0/24 ... 223.255.255.0/24 (224.0.0.0+ skipped) 192.168.36.0/25 192.168.36.128/25 192.168.37.0/25 ... 223.255.255.128/25 (224.0.0.0+ skipped) 192.168.36.0/26 192.168.36.64/26 192.168.36.128/26 ... 223.255.255.192/26 |
204.197.56.0 |
24 |
24 |
10 |
4 |
204.197.56.0/24204.197.66.0/ 24204.197.76.0/24204.197.86.0/24 |
All of the generated network addresses are associated with a set of attributes that describes routing to these generated network addresses and associated features.
Only one route can be added per UPDATE message, but a variable number of withdrawn routes may be packed into each UPDATE message. The packing is randomly chosen across a range of a number of routes. The time interval between UPDATE messages is configurable, in units of milliseconds.
A BGP4 network condition called `flapping' can be emulated by the protocol server on an Ixia port. In the Link flapping emulation, a peer BGP router appears to be going offline and online repeatedly, which is accomplished on the Ixia port by alternate disconnects and reconnects of the TCP/IP stack. In the Route flapping emulation, BGP routes are repeatedly withdrawn, and then re-advertised, in UPDATE messages.
BGP L3 VPNs
L3 Virtual Private Networks (VPNs) over an IP backbone (at Layer 3 of the OSI model), may be provided to the customers of a Service Provider (SP), providing connectivity between two or more sites owned by the customer. L3 VPNs are independent of the Layer 2 protocol. While MPLS handles the packet forwarding in the backbone/core, the BGP protocol provides a means of advertising external routes/network addresses across that backbone between sites. IETF Internet Draft `draft-ietf-ppvpn-rfc2547bis-01.txt,' the proposed successor to RFC 2547, covers the VPN architecture designed for use by private service providers. A simplified example of a BGP L3 VPN topology is shown in the following figure.
Figure: Simplified BGP L3 VPN Diagram
The term site refers to a customer/client site, which consists of a group of inter-connected IP devices, usually in one geographic location. A Customer Edge (CE) device, typically a router, connects the site, through a data link connection, to a Provider Edge (PE) router an entry point to the service provider's backbone. The PE-to-CE routing protocols may be static routing, or a dynamic protocol such as eBGP or RIPv2.
Provider (P) network core routers, `transparently' carry the IP traffic across the internal core between CE routers. CEs and Ps are not `VPN-aware' devices. CE devices are considered as belonging to a only one site, but that site may belong to multiple VPNs. A VPN Routing and Forwarding table (VRF) on a PE consists of an IP routing table, a forwarding table, and other information on the set of interfaces in the VPN. The VRF generally describes a VPN site's routing information, and a PE may maintain multiple VRFs, one for each connected customer site. See L3 VPN VRFs for additional information on VRFs.
Layer 3 VPN sites are identified by a Route Target (RT). A route target is based on the mechanism proposed in the IETF draft for the `BGP Extended Communities Attribute.' An 8-byte route target is common to all route ranges that belong to a single L3 site. Route targets are defined for individual VPN route ranges. The formats for Route Targets (RTs) are shown in the following figure.
Figure: Route Target Formats (BGP Extended Community Types)
BGP VPN-IPv4 Address Formats
Globally unique 12-byte VPN-IPv4 prefixes are created by a PE router. This includes configuration of the 8-byte VPN Route Distinguishers (RDs). It should be noted that BGP IPv4 routes and VPN -IPv4 routes are considered noncomparable; VPN-IPV4 addresses can be used only within the VPN service provider network.The route distinguishers are used by PE routers to associate routes with the path to a particular CE site router in a VPN. Each route can only have one RD. The formats of the RDs are shown in the following figure.
Figure: VPN-IPv4 Address Formats (with Route Distinguishers)
L3 VPN VRFs
For Layer 3 Virtual Private Network (L3 VPN) configurations, the Provider Edge (PE) routers maintain routing tables for each VPN that they participate in, termed VPN Routing and Forwarding tables (VRFs). The VRFs are populated with routes received from both the directly attached and remote Customer Edge (CE) routers. Each entry in the VRF is called a VPN Forwarding Instance (VPI). VRFs and CEs are not required to be configured on a one-to-one basis, although this is the typical situation. An example of the possible relationships between VRFs and CEs is shown in the following figure.
Figure: L3 VPN VRF Example