|
|
|
In This Section: |
Border Gateway Protocol (BGP) is an inter-AS protocol, meaning that it can be deployed within and between autonomous systems (AS). An autonomous system is a set of routers under a single technical administration. An AS uses an interior gateway protocol and common metrics to route packets within an AS; it uses an exterior routing protocol to route packets to other ASs.
|
Note - This implementation supports BGP version 4, with Multiprotocol Extensions. |
|---|
BGP sends update messages that consist of network number-AS path pairs. The AS path contains the string of ASs through which the specified network can be reached. An AS path has some structure in order to represent the results of aggregating dissimilar routes. These update messages are sent over TCP transport mechanism to ensure reliable delivery. BGP contrasts with IGPs, which build their own reliability on top of a datagram service.
As a path-vector routing protocol, BGP limits the distribution of router reachability information to its peer or neighbor routers.
You can run BGP over a route-based VPN by enabling BGP on a virtual tunnel interface (VTI).
Gaia implements BGP-4 with support for multiprotocol extensions and the exchange of IPv6 address prefixes, as described in RFCs 2545, 2858, and 3392.
You must use an IPv4 address for the router ID (BGP identifier). After the BGP session is up, prefixes can be advertised and withdrawn by sending normal UPDATE messages that include either or both of the new multiprotocol attributes MP_REACH_NLRI (used to advertise reachability of routes) and MP_UNREACH_NLRI (used to withdraw routes).
The new attributes are backward compatible. If two routers have a BGP session and only one supports the multiprotocol attributes, they can still exchange unicast IPv4 routes even though they cannot exchange IPv6 routes.
Notes:
Configuring IPv6 BGP (BGP-4 Multiprotocol Extensions)
On each peer, configure the type of routes (Multiprotocol capability) to exchange between peers. Select one of these:
To establish BGP peering, the BGP routers must share a capability.
If your system is exchanging IPv4 routes over IPv6 or vice versa, use Gaia Clish routemap commands to set nexthop to match the family of the routes being exchanged. If they do not match, the routes will not be active.
Note - To configure routing policies for BGP-4 Multiprotocol Extensions, use Gaia Clish routemap commands. Do not use the route redistribution and inbound filters in the <_r_gaia> Portal.
BGP supports these session types between neighbors:
When you send routes to an external peer, the local AS number is prepended to the AS path. Routes received from an internal neighbor have the same AS path that the route had when it was received from an external peer.
BGP sessions might include a single metric (Multi-Exit Discriminator or MED) in the path attributes. Smaller values are preferred. These values are used to break ties between routes with equal preference from the same neighbor AS.
Internal BGP sessions carry at least one metric in the path attributes that BGP calls the local preference. The size of the metric is identical to the MED. Use of these metrics depends on the type of internal protocol processing.
For BGP implementation, external peers are directly attached to a shared subnet and advertise next hops that are host addresses on the subnet. If you enable the multihop option in the BGP peer template during configuration, this constraint is relaxed.
Internal groups determine the immediate next hops for routes. The next hop received with a route from a peer is used as a forwarding address and to look up an immediate next hop in IGP routes. Internal groups support distant peers, but need to know the IGP whose routes they are using to determine immediate next hops.
Where possible, for internal BGP group types, a single outgoing message is built for all group peers based on the common policy. A copy of the message is sent to every peer in the group, with appropriate adjustments to the next hop field to each peer. This minimizes the computational load needed to run large numbers of peers in these types of groups.
An ISP can assign private AS numbers (64512 to 65535) to a customer in order to conserve globally unique AS numbers. When an ISP does so, a BGP update from a customer network to the ISP has the private AS number in its AS_PATH attribute. When the ISP propagates its network information to other ISPs, the private AS number would normally be included. To avoid this, you can configure Gaia to remove the private AS number from BGP update messages to external peers.
To configure Gaia to remove private AS numbers from BGP updates, enable the Remove Private AS option on the configuration page for an external peer.
If you enable this option, private AS numbers are removed from BGP updates according to the following rules:
Gaia supports the ability to dynamically request BGP route updates from peers and to respond to requests for BGP route updates. For example, if you change the inbound routing policy, you can request that a peer readvertise its previously advertised routes so that the routes can be checked against the new policy. This feature is often referred to as a soft reset because it provides the ability to refresh routes received from a peer without tearing down the established session.
To configure BGP route updates in the:
set bgp external remote-as as_number peer ip_address send-route-refreshset bgp internal peer ip_address send-route-refresh These options work only with peers that support the same capabilities. Gaia systems can also peer with systems that do not support these options.
A path attribute is a list of AS numbers that a route has traversed to reach a destination. BGP uses path attributes to provide more information about each route and to help prevent routing loops in an arbitrary topology. You can also use path attributes to determine administrative preferences.
BGP collapses routes with similar path attributes into a single update for advertisement. Routes that are received in a single update are readvertised in a single update. The churn caused by the loss of a neighbor is minimized, and the initial advertisement sent during peer establishment is maximally compressed.
BGP does not read information that the kernel forms message by message. Instead, it fills the input buffer. BGP processes all complete messages in the buffer before reading again. BGP also performs multiple reads to clear all incoming data queued on the socket.
Note - This feature might cause a busy peer connection to block other protocols for prolonged intervals.
Path attributes:
Attribute |
Description |
|---|---|
AS_PATH |
Identifies the autonomous systems through which routing information carried in an UPDATE message passed. Components of this list can be AS_SETs or AS_SEQUENCES. |
NEXT_HOP |
Defines the IP address of the border router that should be used as the next hop to the destinations listed in the UPDATE message. |
MULTI_EXIT_DISC |
Discriminates among multiple exit or entry points to the same neighboring autonomous system. Used only on external links. |
LOCAL_PREF |
Determines which external route should be taken and is included in all IBGP UPDATE messages. The assigned BGP speaker sends this message to BGP speakers within its own autonomous system but not to neighboring autonomous systems. Higher values of a LOCAL_PREF are preferred. |
ATOMIC_AGGREGATE |
Specifies to a BGP speaker that a less specific route was chosen over a more specific route. The BGP speaker attaches the ATOMIC_AGGREGATE attribute to the route when it reproduces it to other BGP speakers. The BGP speaker that receives this route cannot remove the ATOMIC_AGGREGATE attribute or make any Network Layer Reachability Information (NLRI) of the route more specific. This attribute is used only for debugging purposes. |
All unreachable messages are collected into a single message and are sent before reachable routes during a flash update. For these unreachable announcements, the next hop is set to the local address on the connection, no metric is sent, and the path origin is set to incomplete. On external connections, the AS path in unreachable announcements is set to the local AS. On internal connections, the AS path length is set to zero.
Routing information shared between peers in BGP has two formats: announcements and withdrawals. A route announcement indicates that a router either learned of a new network attachment or made a policy decision to prefer another route to a network destination. Route withdrawals are sent when a router makes a new local decision that a network is no longer reachable.
Multi-exit Discriminator (MED) values are used to help external neighbors decide which of the available entry points into an AS are preferred. A lower MED value is preferred over a higher MED value and breaks the tie between two or more preferred paths.
Note - A BGP session does not accept MEDs from an external peer unless the Accept MED field is set for an external peer.
All transit ASs must be able to carry traffic that originates from locations outside of that AS, is destined to locations outside of that AS, or both. This requires a certain degree of interaction and coordination between BGP and the Interior Gateway Protocol (IGP) that the particular AS uses. In general, traffic that originates outside of a given AS passes through both interior Gateways (Gateways that support the IGP only) and border Gateways (Gateways that support both the IGP and BGP). All interior Gateways receive information about external routes from one or more of the border Gateways of the AS that uses the IGP.
Depending on the mechanism used to propagate BGP information within a given AS, take special care to ensure consistency between BGP and the IGP, since changes in state are likely to propagate at different rates across the AS. A time window might occur between the moment when some border gateway (A) receives new BGP routing information (which was originated from another border gateway (B) within the same AS) and the moment the IGP within this AS can route transit traffic to the border gateway (B). During that time window, either incorrect routing or black holes can occur.
To minimize such routing problems, border gateway (A) should not advertise to any of its external peers a route to some set of exterior destinations associated with a given address prefix using border gateway (B) until all the interior Gateways within the AS are ready to route traffic destined to these destinations by using the correct exit border gateway (B). Interior routing should converge on the proper exit gateway before advertising routes that use the exit gateway to external peers.
If all routers in an AS are BGP speakers, no interaction is necessary between BGP and an IGP. In such cases, all routers in the AS already have full knowledge of all BGP routes. The IGP is then only used for routing within the AS, and no BGP routes are imported into the IGP. The user can perform a recursive lookup in the routing table. The first lookup uses a BGP route to establish the exit router, while the second lookup determines the IGP path to the exit router.
BGP routes can be filtered, or redistributed by AS number or AS path regular expression, or both.
BGP stores rejected routes in the routing table with a negative preference. A negative preference prevents a route from becoming active and prevents it from being installed in the forwarding table or being redistributed to other protocols. This behavior eliminates the need to break and re-establish a session upon reconfiguration if importation policy is changed.
When you import from BGP you can add or modify the local preference, rank and nexthop. The local preference parameter assigns a BGP local preference to the imported route. The local preference is a 32-bit unsigned value, with larger values preferred. This is the preferred way to bias a routing subsystem preference for BGP routes.
Redistributing to BGP is controlled by an AS. The same policy is applied to all firewalls in the AS. BGP metrics are 16-bit, unsigned quantities; that is, they range from 0 to 65535 inclusive, with zero being the most attractive. While BGP version 4 supports 32-bit unsigned quantities, routed does not.
|
Note - To define a redistribution policy, use Advanced Routing > Route Distribution in the Portal, or routemaps in the CLI. |
|---|
BGP communities allow you to group a set of IP addresses and apply routing decisions based on the identity of the group or community.
To implement this feature, map a set of communities to certain BGP local preference values. Then you can apply a uniform BGP configuration to the community as a whole as opposed to each router within the community. The routers in the community can capture routes that match their community values.
Use community attributes to can configure your BGP speaker to set, append, or modify the community of a route that controls which routing information is accepted, preferred, or distributed to other neighbors. The following table displays some special community attributes that a BGP speaker can apply.
Community attribute |
Description |
|---|---|
|
Not advertised outside a BGP confederation boundary. A stand-alone autonomous system that is not part of a confederation should be considered a confederation itself. |
|
Not advertised to other BGP peers. |
|
Not advertised to external BGP peers. This includes peers in other members’ autonomous systems inside a BGP confederation. |
For more about communities, see RFCs 1997 and 1998.
By default, all BGP peers in an Autonomous System (AS) are in a full mesh. However, if an AS has many BGP peers, the BGP configuration and hardware deployment is not easy.
To simplify configuration and deployment and avoid having to connect the peers in a full mesh, it is possible to configure:
The route reflector and its clients are known as a route reflection cluster. The route reflector sends the routes received from its peers to its clients.
In the example network, AS1 has five BGP-enabled Check Point routers. One of the routers is a route reflector for two clients.
Number |
Description |
Number |
Description |
|---|---|---|---|
1 |
Non-client |
5 |
Cluster |
2 |
IBGP |
6 |
AS1 |
3 |
Route Reflector |
7 |
EBGP |
4 |
Client |
8 |
AS676 |
It is possible to define more than one route reflector in the AS to avoid having a single point of failure. We recommend that you not use multiple redundant reflectors unnecessarily because it increases the memory required to keep routes on the peers of redundant reflectors.
To learn more about route reflection, see RFC 2796.
An alternative to route reflection is BGP confederations. As with route reflectors, you can partition BGP speakers into clusters where each cluster is typically a topologically close set of routers. With confederations, this is accomplished by subdividing the autonomous system into multiple, smaller ASs that communicate among themselves. The internal topology is hidden from the outside world, which perceives the confederation to be one large AS.
Each distinct sub-AS within a confederation is referred to as a routing domain (RD). Routing domains are identified by using a routing domain identifier (RDI). The RDI has the same syntax as an AS number, but as it is not visible outside of the confederation, it does not need to be globally unique, although it does need to be unique within the confederation. Many confederations find it convenient to select their RDIs from the reserved AS space (ASs 64512 through 65535 (see RFC 1930). RDIs are used as the ASs in BGP sessions between peers within the confederation.
The confederation as a whole, is referred to by a confederation identifier. This identifier is used as the AS in external BGP sessions. As far as the outside world is concerned, the confederation ID is the AS number of the single, large AS. For this reason, the confederation ID must be a globally unique, normally assigned AS number.
|
Note - Do not nest confederations. |
For further details, refer to the confederations specification document (RFC 1965).