BGP

Overview

BGP is an inter-AS routing protocol. An AS is a network or a group of devices logically organized and controlled by a common network administration. BGP enables devices to exchange network reachability information. AS paths are the routes to each destination. There are two types of BGP: IBGP and EBGP.

• IBGP is used to communicate with peer devices in the same AS. Routes received from a device in the same AS are not advertised to other devices in the same AS but can be advertised to an EBGP peer.

• EBGP is used to communicate with peers in a different AS. Routes received from a device in a different AS can be advertised to both EBGP and IBGP peers.

See Inter-AS connections in VPRN service management for more information about connecting ASs in a VPRN.

You can use the NFM-P to enable BGP on the device and perform the following functions:

• set the AS values for the routing instance

• create confederations of group-managed devices

• create BGP peer groups

• create neighbors (peers) within the BGP peer groups

The NFM-P supports the configuration of IPv6 addresses for BGP peering on the base routing instance of supporting devices.

The base BGP routing instance and the policy statement support MVPN IPv6 on supporting devices.

The NFM-P supports IPv4 and IPv6 routes with and without implementation labels. The base router maintains separate BGP RIBs for each of the following types of routes: IPv4, label-IPv4, IPv6 and label-IPv6. Each VPRN maintains separate BGP RIBs for each of the following types of routes: IPv4, label-IPv4 (if CSC is enabled), IPv6 and label-IPv6.

A device can only belong to one AS. After the neighbor relationship is established between devices, they exchange BGP open messages, which contain information such as AS numbers, BGP versions, router IDs, hold-time values, and keepalive messages. This information determines the status of the BGP session. Peer relationships are defined by configuring the IP addresses of the devices that are peers of the local BGP system.

The following figure shows a simple BGP example using groups, subconfederations, and confederations.

Figure 28-1: BGP example

In a standard BGP configuration, all BGP-enabled devices within an AS have a full mesh of BGP peerings to ensure all externally learned routes are redistributed through the entire AS. This is needed because IBGP does not re-advertise routes learned from one IBGP peer to another IBGP peer. However, as more devices are added, scaling the IBGP mesh can become an issue. You can use the following subdividing methods to solve this scaling issue:

• BGP confederations: subdivides a large AS into smaller ASs yet still advertise as a single AS to external peers. The intent is to reduce IBGP mesh size.

• Subconfederations: further subdivide ASs; within each smaller AS, or confederation, IBGP is still used, however EBGP is used between subconfederations. This means less meshing between peers is required.

• Route reflector: ASs are divided into groups called clusters. Each cluster contains at least one route reflector. The route reflector redistributes routing updates to all devices in its cluster. Because the route reflector provides all the routing updates, the other devices in the cluster do not maintain a BGP mesh.

• BGP Optimal Route Reflection (BGP-ORR): BGP-ORR uses IGP on a route reflector to advertise the best path to the BGP-ORR client groups.

  Client groups sharing the same or similar IGP topology can be grouped as one BGP peer group, with BGP-ORR enabled. You can configure one of the client NEs as the primary NE for BGP-ORR so that the IGP metric from that NE is used to select the best path and advertise it to the clients in the same BGP peer group. Optionally, you can also select other NEs as secondary or tertiary backup NEs, to be used when the primary NE goes down or is unreachable.

By default, BGP routers will advertise only the best path to other BGP peers. When the best path fails or a better path is discovered, the old routing information is overwritten. If BGP PIC Add-Path is enabled, peers will advertise multiple paths for the same destination, all of which will be retained in their routing tables. In the event of a failure or path withdrawal message, the router is able to update its forwarding entry for that destination without having to receive new path advertisements. This results in faster convergence after path failure.

MP-BGP

MP-BGP is an extension to BGP that allows different types of addresses (known as address families) to be distributed in parallel. Standard BGP only supports IPv4 Unicast addresses; MP-BGP supports both IPv4 and IPv6 addresses and supports Unicast and Multicast variants of each. MP-BGP allows information about the topology of IP multicast-capable routers to be exchanged separately from the topology of normal IPv4 Unicast routers. The routes associated with multicast routing are used by PIM to build multicast data distribution trees.

BGP distributes IP routing information between networks. The distribution of IP routing information between VPRNs requires MP-BGP. MP-BGP addressing uses an 8-byte RD with a 4-byte or 16-byte IP address, depending on whether IPv4 or IPv6 is used. The requirements for MP-BGP configuration are the following.

• MP-BGP must be enabled on the participating PE devices.

• All PE devices must be configured as BGP peers.

When PE devices learn routing information from the CE devices in a VPRN configuration, the routing information is shared using MP-BGP. The RD is used to associate the new routing information with a VPRN instance.

The PE devices distribute the route information to the other CE devices in the VPRN. Each learned route is assigned an MPLS label that is distributed to the devices.

When customer packets arrive at a PE device, the packets are encapsulated with the MPLS label that corresponds to the learned route for the packet destination.

The MP-BGP multicast extension can be applied to build separate routing tables for multicast paths. IGPs such as OSPF and IS-IS can import multicast and Unicast routing information to the multicast and Unicast routing tables. The multicast routing information can subsequently be used by PIM to perform RPF lookups.

BGP SIDR prefix origin validation

BGP SIDR prefix origin validation can help prevent BGP prefix spoofing. BGP speakers access cryptographically secured information about the AS numbers that are authorized to originate routes for different prefixes.

If a BGP speaker that supports SIDR prefix origin validation receives a route from an EBGP peer and the origin AS of the route is incorrect for the advertised prefix, the route is considered invalid and may be given a lower preference or not propagated further. When a device is configured with RPKI router sessions, the device stores the information it receives from cache servers in a local database called the origin validation database. The entries in this database are called VRP (Validated ROA Payload) entries.

See To configure BGP SIDR prefix origin validation for information about configuring BGP SIDR prefix origin validation.