In This Section: |
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:
The Peer Local AS feature lets you configure the connection to a remote peer with a Peer Local ASN, on a per-peer basis. The Peer Local ASN replaces the Local ASN in the BGP session. Only eBGP peers are supported. It is not necessary to configure the Peer Local ASN locally.
Inbound-Peer-Local
The router adds the configured Peer Local ASN to the AS path of the routes received from the peer. Routes installed from that peer will contain the Peer Local ASN as the first entry in the AS Path.
Outbound-Local
The router adds the Local ASN to the AS Path of the routes advertised to an eBGP peer. When enabled, the Local ASN is the second ASN in the AS Path of updates sent to eBGP peers. The Peer Local ASN is always the first ASN in the AS Path if this sub-feature is enabled or not.
Dual Peering
This option enables the connection to the Local ASN or the Peer Local ASN. There can be only one active connection. If you do not enable this option, it is only possible to connect to the Peer Local ASN.
The router first tries to connect to the local ASN. If the connection is created with the Local ASN, the BGP runs as if the peer Local ASN feature is not configured. If the connection with the Local ASN fails, the router tries to connect with the Peer Local ASN
Important - Do not use this feature with an AS that already has Peer Local AS with Dual-Peering enabled. This is because the two ASs then send AS numbers in OPEN messages in a manner that does not converge.
To prevent loops in BGP, routers examine the AS number in the AS Path. If a router sees its own AS number in the AS Path of the BGP packet, it drops the packet.
With AS Override, the router overrides the peer's AS number with the router's AS number in the outbound AS path. This helps multiple sites in the same AS accept the routes. If the Peer Local AS feature is enabled, the router uses the configured Peer Local AS to override the remote peer's AS number.
Equal-cost multi-path routing (ECMP) is a load-balancing routing strategy.
The BGP RFC does not support ECMP routes because BGP clearly sets the route selection criteria. To overcome this issue and install ECMP route through a BGP user, enable the ECMP option.
Note - BGP ECMP is not supported for routes that are received by a mix of IBGP and EBGP.
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:
|
These options work only with peers that support the same capabilities. Gaia systems can also peer with systems that do not support these options.