BGP Sessions (Internal and External)

Introduction

BGP supports these session types between neighbors:

  • Internal (iBGP) - Runs between routers in the same autonomous system.

  • External (eBGP) - Runs between routers in different autonomous systems.

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.

Preventing Private AS Numbers from Propagating

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 GaiaClosed Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. 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:

  • If the AS_PATH includes both public and private AS numbers, the private AS numbers are not removed.

  • If the AS_PATH contains the AS number of the destination peer, private AS numbers are not removed.

  • If the AS_PATH includes confederations and all the AS numbers in the AS_PATH are private, all the private AS numbers are removed.

BGP Route Refresh

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.

These options work only with peers that support the same capabilities.

Gaia systems can also peer with systems that do not support these options.