6.8.1. Preconfiguration Requirements

Before BGP can be implemented, the following entities must be configured:

6.8.2. BGP Hierarchy

BGP is configured in the config>router>bgp context. Three hierarchical levels are included in BGP configurations:

Commands and parameters configured at the global level are inherited by the group and neighbor levels, although parameters configured at the group and neighbor levels take precedence over global configurations.

6.8.3. Internal and External BGP Configurations

A BGP domain is composed of ASs that share network reachability information. Network reachability information is shared throughout the BGP domain by BGP speakers. BGP speakers can belong to the same or different AS. BGP supports two types of routing information exchanges.

6.8.4. BGP Route Reflectors

In a standard BGP configuration, all BGP speakers within an AS must have a full BGP mesh to ensure that all externally learned routes are redistributed through the entire AS. IBGP speakers do not readvertise routes learned from one IBGP peer to another IBGP peer. If a network grows, scaling issues could emerge because of the full mesh configuration requirement. Route reflection circumvents the full mesh requirement but still maintains the full distribution of external routing information within an AS.

Autonomous systems using route reflection arrange BGP routers into groups called clusters. Each cluster contains at least one route reflector that is responsible for redistributing route updates to all clients. Route reflector clients do not need to maintain a full peering mesh between each other. They only require a peering to the route reflectors in their cluster. The route reflectors must maintain a full peering mesh between all non-clients within the AS.

Each route reflector must be assigned a cluster ID and specify which neighbors are clients and which are non-clients to determine which neighbors should receive reflected routes and which should be treated as a standard IBGP peer. Additional configuration is not required for the route reflector except for the typical BGP neighbor parameters.

Figure 44 illustrates an autonomous system with clusters.

Figure 44:  Route Reflection Network Diagram Example 

The following configuration example shows the minimum BGP configuration for routers in Cluster 1.1.1.1, shown in Figure 44.

6.10.1. Creating an Autonomous System

Before BGP can be configured, the autonomous system must be configured. In BGP, routing reachability information is exchanged between autonomous systems (ASs). An AS is a group of networks that share routing information. The autonomous-system command associates an autonomous system number with the 7705 SAR being configured. A 7705 SAR can only belong to one AS. The autonomous-system command is configured in the config>router context.

Note: The 7705 SAR supports 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. This allows up to 4 294 967 295 unique AS numbers.

Use the following CLI syntax to associate a 7705 SAR with an autonomous system:

The following example displays autonomous system configuration command usage:

The following example displays the autonomous system configuration:

6.10.2. Configuring a Router ID

In BGP, routing information is exchanged between autonomous systems. The BGP router ID, expressed as an IP address, uniquely identifies the router. It can be set to be the same as the loopback address.

If a new or different router ID value is entered in the BGP context, the new router ID value is used instead of the router ID configured on the router level, system interface level, or inherited from the MAC address. The router-level router ID value remains intact.

A router ID can be derived by:

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is initialized or reinitialized, the new router ID is used. An interim period of time can occur when different protocols use different router IDs. To force the new router ID, issue the shutdown and no shutdown commands for each protocol that uses the router ID or restart the entire router.

Use the following CLI syntax to configure the router ID:

The following example displays router ID configuration command usage:

The following example displays the router ID configuration:

6.11.1. Configuring BGP

Once the BGP protocol instance is created, the no shutdown command is not required since BGP is administratively enabled upon creation. Minimally, to enable BGP on a router, you must associate an autonomous system number for the router, have a preconfigured router ID or system interface, create a peer group, neighbor, and associate a peer AS number. There are no default groups or neighbors. Each group and neighbor must be explicitly configured.

All parameters configured for BGP are applied to the group and are inherited by each peer, but a group parameter can be overridden on a specific basis. BGP command hierarchy consists of three levels:

For example:

Note: Careful planning is essential to implement commands that can affect the behavior of global, group, and neighbor levels. Because the BGP commands are hierarchical, analyze the values that can disable features on a particular level.

The following example displays the basic BGP configuration:

6.11.2. Configuring Group Attributes

A group is a collection of related BGP peers. The group name should be a descriptive name for the group. Follow your group naming and ID naming conventions for consistency and to help when troubleshooting faults. All parameters configured for a peer group are applied to the group and are inherited by each peer (neighbor), but a group parameter can be overridden on a specific neighbor-level basis. To configure BGP dynamic peers, see Configuring a BGP Peer Group with Dynamic Neighbors.

The following example displays group configuration command usage:

The following example displays the BGP group configuration:

6.11.3. Configuring Neighbor Attributes

After you create a group name and assign options, add neighbors within the same autonomous system to create IBGP connections. All parameters configured for the peer group level are applied to each neighbor, but a group parameter can be overridden on a specific neighbor basis.

The following example displays neighbor configuration command usage:

The following example displays neighbors configured in group “headquarters1”.

6.11.4. Configuring BGP Address Families

Routers advertise their BGP capabilities during session setup. The 7705 SAR supports several address families. One or more address families can be specified in a single command. To add an address family to the currently configured families, re-issue the command by including the current families in addition to any new family.

Use the following CLI syntax to configure BGP IPv6 parameters:

In the display example below, the mvpn-ipv4 address family is added to the BGP group to communicate auto-discovery routes and C-multicast signaling.

6.11.5. Configuring Route Reflection

Route reflection can be implemented in autonomous systems with a large internal BGP mesh to reduce the number of IBGP sessions required. One or more routers can be selected to act as focal points for internal BGP sessions. Several BGP speaking routers can peer with a route reflector. A route reflector forms peer connections to other route reflectors. A router assumes the role as a route reflector by configuring the cluster cluster-id command. No other command is required unless you want to disable reflection to specific peers.

If you configure the cluster command at the global level, then all subordinate groups and neighbors are members of the cluster. The route reflector cluster ID is expressed in dotted- decimal notation. The ID should be a significant topology-specific value. No other command is required unless you want to disable reflection to specific peers.

If a route reflector client is fully meshed, the disable-client-reflect command can be enabled to stop the route reflector from reflecting redundant route updates to a client.

The following example displays route reflection configuration command usage:

The following example displays a route reflection configuration:

6.11.6. Configuring a BGP Peer Group with Dynamic Neighbors

The dynamic-neighbor command allows any router within the configured IP prefix range to establish BGP peering sessions with other routers in the prefix range without any manual intervention.

A BGP neighbor session is considered dynamic if its setup is triggered by an incoming TCP connection that does not match the IP address of any static (configured) neighbor. A dynamic BGP session is always associated with one BGP group, as is the case for statically configured peers.

For a base router BGP group to have dynamic sessions, one or more prefix command entries must be added under the config>router>bgp>group>dynamic-neighbor context. There is no limit on the number of prefix entries per group or overall.

The CLI blocks completely overlapping prefix entries in the same routing instance (that is, entries with the same address and same prefix length). Partially overlapping entries are allowed; for example, 10.0.0.0/8 and 10.10.0.0/16.

For a dynamic session to come up, its source IP address must match at least one prefix entry. The dynamic session is associated with the entry—and consequently, the group—having the longest prefix match for the IP address. When a dynamic session has been set up, changes to the neighbor may occur and are handled as follows:

Static sessions always take precedence regardless of any longest-prefix match with a dynamic neighbor prefix entry.

The number of dynamic BGP peers can be limited at the BGP global and BGP group levels using the dynamic-neighbor-limit command, which limits the number of dynamic sessions allowed by the router and the group, respectively. If an incoming connection for a new dynamic session exceeds the BGP global or BGP group limit, the connection attempt is rejected and a notification message is issued.

The following example displays the dynamic-neighbor command usage:

The following example displays a dynamic neighbor configuration:

6.12.1. Modifying an AS Number

You can modify an AS number on a 7705 SAR but the new AS number will not be used until the BGP instance is restarted either by administratively disabling or enabling the BGP instance, or by rebooting the system with the new configuration.

Since the AS number is defined in the config>router context, not in the BGP configuration context, the BGP instance is not aware of the change. Re-examine the plan detailing the autonomous systems, the 7705 SARs belonging to each group, group names, and peering connections.

Note: Changing an AS number on a 7705 SAR could cause configuration inconsistencies if associated peer-as values are not also modified as required. At the group and neighbor levels, BGP will re-establish the peer relationships with all peers in the group with the new AS number.

Use the following CLI syntax to change an autonomous system number:

6.12.2. Modifying the BGP Router ID

Changing the router ID number in the BGP context causes the new value to overwrite the router ID configured on the router level, system interface level, or the value inherited from the MAC address.

Note: Changing the router ID on a router could cause configuration inconsistencies if associated values are not also modified.

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is initialized or reinitialized, the new router ID is used.

To force the new router ID for BGP, issue the shutdown and no shutdown commands or restart the router.

This example displays the BGP configuration with the BGP router ID specified:

6.12.3. Modifying the Router-Level Router ID

Changing the router ID number in the config>router context causes the new value to overwrite the router ID configured on the protocol level, system interface level, or the value inherited from the MAC address.

Note: Changing the router ID on a router could cause configuration inconsistencies if associated values are not also modified.

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is initialized or reinitialized, the new router ID is used. An interim period of time can occur when different protocols use different router IDs. To force the new router ID, issue the shutdown and no shutdown commands for each protocol that uses the router ID or restart the entire router.

Use the following CLI syntax to change a router ID:

The following example displays the router ID configuration:

6.12.4. Deleting a Neighbor

In order to delete a neighbor, you must shut down the neighbor before issuing the no neighbor ip-addr command.

Use the following CLI syntax to delete a neighbor:

The following example displays the “headquarters1” configuration with the neighbor 10.0.0.103 removed.

6.12.5. Deleting Groups

In order to delete a group, the neighbor configurations must be shut down first. After each neighbor is shut down, you must shut down the group before issuing the no group name command.

Use the following CLI syntax to shut down a peer and neighbor and then delete a group:

If you try to delete the group without shutting it down first, the following message appears:

6.12.6. Editing BGP Parameters

You can change existing BGP parameters in the CLI. The changes are applied immediately.

Refer to BGP Components for a complete list of BGP parameters.