|
SYSTEM ADMINISTRATOR GUIDE 18/1543-CRA 119 1170/1-V1 Uen E | |
Copyright
© Ericsson AB 2009 -2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademark List
| SmartEdge | is a registered trademark of Telefonaktiebolaget LM Ericsson. | |
| NetOp | is a trademark of Telefonaktiebolaget LM Ericsson. |
This document provides an overview of the Border Gateway Protocol (BGP) and describes the tasks and commands used to configure, monitor, troubleshoot, and administer BGP features through the SmartEdge® router.
BGP is an Exterior Gateway Protocol (EGP) based on distance-vector algorithms, and uses the Transmission Control Protocol (TCP) as its transport protocol. BGP is a protocol between two BGP nodes, or BGP speakers. First, the TCP connection is established and then the two BGP speakers exchange dynamic routing information over the connection. The exchange of messages is a BGP session between BGP peers.
The SmartEdge router supports multiple BGP features, including those specified in the folloswing IETF drafts and RFCs:
T. Bates, R. Chandra, E. Chen, RFC 2796, BGP Route Reflection - An Alternative to Full Mesh IBGP, April 2000
P. Traina, D. McPherson, J. Scudder, RFC 3065, Autonomous System Confederations for BGP, February 2001
R. Chandra, P. Traina, T. Li, RFC 1997, BGP Communities Attribute, August 1996
A. Heffernan, RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option, August 1998
C. Villamizar, R. Chandra, R. Govindan, RFC 2439, BGP Route Flap Damping, November 1998
R. Chandra, J. Scudder, RFC 2842, Capabilities Advertisement with BGP-4, May 2000
T. Bates, R. Chandra, D. Katz, Y. Rekhter, RFC 2858, Multiprotocol Extensions for BGP-4, June 2000
E. Chen, RFC 2918, Route Refresh Capability for BGP-4, September 2000
E. Chen, Y. Rekhter, RFC 5291, Outbound Route Filtering Capability for BGP-4, August 2008
E. Chen, S. Sangli, RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4, August 2008
S. Sangli, Y. Rekhter, R. Fernando, J. Scudder, E. Chen, RFC 4274, Graceful Restart Mechanism for BGP, January 2007
Q. Vohra, E. Chen, Internet Draft, BGP Support For Four-Octet AS Number Space, draft-ietf-idr-as4bytes-03.txt, May 2001
The following additional features are also supported:
In-depth information on how BGP is structured, and how it operates, is described the sections that follow.
Routers that belong to the same AS and exchange BGP updates are running iBGP, and routers that belong to different autonomous systems and exchange BGP updates are running eBGP.
Figure 1 illustrates the concept of autonomous systems and iBGP versus eBGP.
Typically, iBGP speakers must be fully meshed. Any BGP speaker that receives messages from an external router must advertise the routes it receives to all BGP speakers in its autonomous system. However, if a route reflector is configured, although it must have connections to all other BGP speakers in the AS, not all other BGP speakers must be fully meshed. When a BGP speaker in the AS receives messages from an external router, it is sufficient to advertise these routes only to the route reflector, which then readvertises the bestpath of each route to all other BGP speakers in the AS.
Internal peers of the route reflector are divided into two groups: client peers and nonclient peers. A route reflector reflects routes between these two groups. The route reflector and its client peers form a cluster. Nonclient peers must be fully meshed with each other. Client peers are not required to be fully meshed and do not communicate with BGP speakers outside their cluster. If it is required, peer client-to-peer client route reflection can be disabled.
When the route reflector receives an advertised route:
Figure 2 shows an example of iBGP networking using route reflection.
Another way to reduce iBGP mesh is to divide an autonomous system into subautonomous systems grouped by a routing domain identifier. The AS and its subautonomous systems are part of the same confederation. Externally, the confederation looks like a single AS. Each subautonomous system is fully meshed within itself and has a few connections to other subautonomous systems in the confederation.
Neighbors from other subautonomous systems are treated as special eBGP peers. Even though peers in different subautonomous systems engage in eBGP sessions, they exchange routing information as if they were iBGP peers. Specifically, the next-hop, the Multi-Exit Discriminator (MED), and local preference information is preserved, so that a single Interior Gateway Protocol (IGP) is used for all of the subautonomous systems; see Figure 3.
BGP4 supports Classless InterDomain Routing (CIDR). With CIDR, routers use the network prefix to determine the dividing point between the network number and the host number. For example, the range of addresses 128.186.1.0 to 128.186.1.255 can be represented as the network prefix 128.186.1.0/24; the 24 indicates that all addresses in the segment agree in their first 24 bits.
In addition, CIDR does not require a network to be of standard size, as is the case in classful addressing, which provides 8-bit (Class A), 16-bit (Class B), and 24-bit (Class C) network deployment. This flexibility in CIDR enables the creation of arbitrarily sized networks.
Of particular importance is CIDR’s ability to lend itself to the concept of route aggregation. The Internet is divided into addressing domains. Within a domain, detailed information is available about all of the networks that reside in the domain. Outside of an addressing domain, however, only the common network prefix is advertised. By allowing a single routing table entry to specify a route to many individual network addresses, aggregation minimizes the size of the routing table. A router cannot aggregate an address if it does not have a more specific route of that address in the BGP routing table. More-specific routes can be injected in the BGP routing table by incoming updates from other autonomous systems.
The SmartEdge router performs BGP best-path calculations periodically by scanning the RIB for changes in next hops. For intermittent next-hop moves, the SmartEdge router runs the best-path calculation immediately upon notification by the RIB and updates the RIB with the new next hop. In addition, this feature improves convergence time for BGP by triggering immediate best-path calculation for next-hop withdrawals. A back-off mechanism prevents unnecessary churn during network instability.
Use the following commands in IPv4 BGP address family configuration mode to configure next-hop-triggered BGP best-path calculation:
The following commands show information related to BGP next-hop scanning:
By default, BGP multipath capabilities are disabled, which means BGP installs a single path in the RIB for each destination. If that path fails and no other path has installed a path for that prefix, traffic destined for that path is lost until the path is available again.
When BGP multipath is enabled with the multi-paths command, BGP installs multiple best equal-cost paths in the routing table for load-balancing traffic to BGP destinations. With multipath, the paths can be:
Multiprotocol BGP (MP-BGP) makes use of multiprotocol extensions to BGP4, as defined in RFC 2283, Multiprotocol Extensions for BGP-4, that allow other protocols to use BGP to exchange protocol-specific information.
One of the main advantages of MP-BGP is the ability to use BGP’s scalability and policy control, to easily configure routers to peer with other interdomain routers, exchange multicast source route information, and configure multicast routing policies using familiar BGP commands. MP-BGP also carries two sets of routes: one set for unicast routing and one set for multicast routing, allowing you to configure separate routing policies for unicast and multicast routes.
Before Release 2.5, whenever there was a change in an inbound or outbound routing policy, such as a prefix-list, as-path-list, or route-map, for a BGP peer, the clear bgp neighbor ip-addr soft [in | out] command had to be manually issued to make the policy change effective. Currently, routing policy changes automatically take effect, and issuing the clear bgp neighbor ip-addr soft [in | out] command to update routing policies can cause updates to be unnecessarily sent, so it is not recommended.
To aggregate multiple policy changes, the operating system performs the necessary action 15 seconds after a policy change.
| Caution! | ||
|
Risk of dropped connection. If the remote peer does not support
the BGP Route Refresh Capability, an inbound policy change for the
peer results in an automatic hard reset of the session. To reduce
the risk, ensure that the remote peer supports the BGP Route Refresh
Capability.
| ||
The non-intrusive Message Digest 5 (MD5) password change feature for BGP allows you to change the password for a BGP peer without resetting the BGP session. The sections that follow describe in detail how the non-intrusive MD5 password change feature is implemented.
When an old MD5 password is replaced by a new one in a BGP peer configuration, both passwords are allowed to coexist for authentication until the old password expires. To facilitate a smooth transition from the old to new password, a new configuration can be used to specify the time interval during which the old MD5 password coexists with the new one.
For a TCP connection that is already established, or is in one of the closing states when an existing password is replaced by a new MD5 password, both password strings coexist for authentication during the specified time interval before the old MD5 password expires. The old MD5 password continues to be used for authentication until either the password expires, or the remote TCP for the peer uses a new MD5 password.
For a TCP connection that is not yet established, when the old password is replaced, the local TCP immediately uses the new MD5 password.
This feature does not apply when configuring a new MD5 password for a peer while there is no existing password already configured for the peer. The BGP peer session is reset after the new MD5 password is configured.
This feature does not apply when explicitly deleting a MD5 password from the BGP peer configuration.
When the current active MD5 password is deleted from the configuration, the old password (if existing) and the current password are both immediately deleted, and the BGP session with the peer is reset.
A BGP speaker can use its local routing policy to filter out unwanted routes received from peers of the speaker. However, filtering uses resources on both the sender and receiver, which must generate and process BGP updates for the unwanted routes. To preserve resources in your network, you can use BGP prefix-based outbound route filtering (ORF) to prevent the generation and processing of these BGP updates.
With BGP prefix-based ORF, a BGP speaker sends a set of outbound route filters to a BGP peer. The peer applies these filters in addition to any locally configured outbound filters. These filters prevent unnecessary outbound routing updates from being sent to the speaker.
To configure ORF on your system:
Graceful restart is enabled on all BGP routing instances. When configured as a BGP speaker, the router:
The BGP speaker advertises these graceful restart capabilities to the peers.
Keep the following in mind when configuring graceful restart for a BGP routing instance:
Figure 4 illustrates an example of how routes are maintained in an iBGP system. This example shows a system of four iBGP peers, where router A is the helper router. If router D fails, router A retains the address families and routes from router D only if routers B and C are configured with the same routing capabilities as router D. For example, if router D is configured with IPv4 unicast address family capabilities, router A retains those IPv4 unicast routes only if routers B and C are also configured with IPv4 unicast address family capabilities. If router D is configured with IPv4 unicast and IPv6 unicast capabilities, but routers B and C are configured only with IPv4 unicast address family capabilities, Router A retains only the IPv4 unicast address families and routers when router D fails.
The BGP fast-reset feature enables fast resetting of a BGP peer session when the links used to reach a neighbor go down.
When fast-reset is disabled, the BGP session is not reset immediately when the link used to reach that peer goes down. Instead, the BGP sessions remain connected to the peer until the configured BGP holdtime timer (set with the timers command in BGP router configuration mode) expires. If no packets are received from a peer within the configured hold time, the BGP session is reset.
When fast-reset is enabled, the configured hold time is ignored, and BGP drops its session with a peer immediately if the link to that peer goes down. When you enable BGP fast-reset on peers, packet loss is minimized during link failures.
Fast-reset is supported on directly connected and multihop BGP sessions.
For directly connected eBGP peers, use the fast-reset command in BGP router configuration mode to specify time (in seconds) that must pass before the BGP routing process drops sessions of directly connected external peers when the link used to reach them goes down. In this case, the fast-reset configuration applies to all eBGP peers that are directly connected to the local system.
For iBGP or multihop eBGP sessions, a peer is reachable through a number of interfaces. To configure fast-reset for iBGP or multihop eBGP sessions:
Consider the following when configuring BGP fast-reset on a multihop BGP session:
The SmartEdge router supports a configurable Minimum Route Advertisement Interval (MRAI) (using the advertisement-interval command). The MRAI starts when an UPDATE message is sent to a BGP neighbor or peer group. After sending an UPDATE message to the specified BGP peers, the router waits for the specified MRAI before sending the next UPDATE message. If a route change occurs and the MRAI has passed since the last UPDATE message was sent, the router immediately sends an UPDATE message to the peer. If a route change occurs and the MRAI has not passed since the last UPDATE message was sent to the peer, the router waits the specified MRAI before sending a new UPDATE message.
Figure 5 illustrates an example of how MRAI sends UPDATE messages to BGP peers.
If the MRAI in Figure 5 is set to 20 seconds:
To configure BGP, perform the tasks described in the sections that follow.
A BGP routing instance enables the SmartEdge router to be a BGP speaker. In addition, many BGP parameters that can affect the global routing process can be configured within a BGP routing instance.
To configure a BGP routing instance and other instance attributes, perform the tasks described in the sections that follow.
To configure a BGP routing instance, perform the tasks described in Table 1.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Create a BGP routing instance using an autonomous system number (ASN) and enter BGP router configuration mode. |
Enter this command in context configuration mode. | |
|
Allow the comparison of the Multi-Exit Discriminator (MED) for paths from BGP neighbors in the same autonomous system. |
By default, the comparison of the MED is enabled for paths from BGP neighbors in the same autonomous system. For iBGP paths, the MED is always 0. | |
|
Disable (or reenable, if disabled) the verification of the first AS number in a received AS path from an eBGP peer. |
By default, a BGP router compares the remote AS number of an eBGP peer with the first AS number in the paths received from that peer. If those AS numbers do not match, the BGP router:
Use the no enforce first-as command to disable this feature. | |
|
Specify a period of time that must pass before the BGP routing process drops sessions of directly connected external peers once the link used to reach them goes down. |
By default, BGP sessions remain connected after the outbound interface goes down. BGP sessions are dropped after the BGP hold time value, set with the timers command in BGP router configuration mode, is exceeded. | |
|
Configure the local preference attribute for the BGP routes. |
The local preference value is applied to BGP routes that do not have the local-preference attribute assigned to them. | |
|
Log BGP neighbor resets. |
— | |
|
Enable multipath capabilities on a system, so that mutilple paths to the same destination are installed in the routing table. |
Although multiple paths are installed, only one path (the best path available) is advertised. | |
|
Configure a fixed BGP router ID. |
By default, the BGP router ID is the IP address of a loopback interface if one is configured. If a loopback interface is not configured, the interface with the highest IP address is used as the router ID. Peering sessions are reset when the router ID is changed. If a context does not contain any IPv4 address configuration and BGP is being used, you must configure the router-id command in the context or routing protocol instance level. If you configure a context with only IPv6 addresses and no IPv4 addresses and run BGP in that context, BGP does not establish a relationship with any neighbors if the router-id command is not configured. | |
|
Configure the time interval, in seconds, during which an old MD5 password can coexist with a new MD5 password for authentication. |
Configuring the password timer interval affects only the BGP peers which have existing MD5 passwords replaced after this configuration is committed. | |
|
Modify keepalive and holdtime timers for all BGP neighbors. |
By default, the keepalive timer is set to 60 seconds and the holdtime value is set to 180 seconds. | |
|
Configure IPv4 multicast or unicast address family attributes. |
— |
For the complete list of tasks used to configure IPv4 address family attributes, see Configure IPv4 UNI or NNI Address Family Attributes for a BGP Routing Instance. |
|
Configure IPv6 unicast address family attributes. |
— |
For the complete list of tasks used to configure IPv6 address family attributes, see Configure IPv6 Address Family Attributes for a BGP Routing Instance. |
|
Configure the BGP graceful restart characteristics. |
— |
For the complete list of tasks used to configure BGP graceful restart, see Configure Graceful Restart Characteristics for a BGP Routing Instance. |
|
Configure BGP Route Reflection. |
— |
For the complete list of tasks used to configure BGP route reflection, see Configure BGP Route Reflection. |
|
Configure BGP confederations. |
— |
For the complete list of tasks used to configure BGP confederations, see Configuring BGP Attribute-Based Accounting in Configuring Routing Policies. |
To configure the IPv4 address family attributes for a BGP routing instance, perform the tasks described in Table 2.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Specify the use of standard IP Version 4 (IPv4) multicast or unicast address prefixes for the BGP routing instance, and access BGP address family configuration mode. |
Enter this command in BGP router configuration mode. Include the multicast keyword to specify a multicast address prefix, or the unicast keyword to specify a unicast address prefix. | |
|
Create an aggregate entry in the BGP database for the BGP address family. |
— | |
|
Enable eBGP route dampening for the specified BGP address family. |
— | |
|
Configure the administrative distance values for a BGP address family. |
When installing and advertising the best path, the BGP best-path algorithm uses the administrative distance value in instances where multiple paths are available. If the distance of a path is greater than the maximum allowable distance out of the distances configured for iBGP, eBGP, and local, BGP removes that path from the list of best-path candidates. If only one path is up, BGP installs that path and ignores the distance value. | |
|
Enable route-flap statistics accounting for the BGP address family. |
— | |
|
Originate BGP routes that are advertised to peers. |
— | |
|
Redistribute routes learned through other protocols into the BGP routing process. |
Be aware that the redistribute (BGP) command is available in BGP address family configuration mode for unicast address prefixes only. See Example: Configure BGP Route Redistribution and Aggregation for an example of how to configure route redistribution and aggregation for a BGP instance. | |
|
Assign a traffic index to routes installed for a BGP address family. |
Traffic index counters are maintained on interfaces with traffic index accounting enabled. For more information about BGP attribute-based accounting, see the Configuring BGP Attribute-Based Accounting section in Configuring Routing Policies. | |
|
Enable the triggering of immediate BGP best-path calculation on notification of a next-hop withdrawal by the RIB, and configure next-hop scan parameters. |
The nexthop triggered command is available in unicast IPv4 mode only. |
To configure the IPv6 address family attributes for a BGP routing instance, perform the tasks described in Table 3.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Specify the use of standard IP Version 6 (IPv6) unicast address prefixes for the BGP routing instance, and access BGP address family configuration mode. |
Enter this command in BGP router configuration mode. | |
|
Create an aggregate entry in the BGP database for the BGP address family. |
— | |
|
Enable eBGP route dampening for the specified BGP address family. |
— | |
|
Configure the administrative distance values for a BGP address family. |
When installing and advertising the best path, the BGP best-path algorithm uses the administrative distance value in instances where multiple paths are available. If the distance of a path is greater than the maximum allowable distance out of the distances configured for iBGP, eBGP, and local, BGP removes that path from the list of best-path candidates. If only one path is up, BGP installs that path and ignores the distance value. | |
|
Enable route-flap statistics accounting for the BGP address family. |
— | |
|
Originate BGP routes that are advertised to peers. |
— | |
|
Enable the triggering of immediate BGP best-path calculation on notification of a next-hop withdrawal by the RIB, and configure next-hop scan parameters. |
— | |
|
Redistribute routes learned through other protocols into the BGP routing process. |
See Example: Configure BGP Route Redistribution and Aggregation for an example of how to configure route redistribution and aggregation for a BGP instance. | |
|
Assign a traffic index to routes installed for a BGP address family. |
Traffic index counters are maintained on interfaces with traffic index accounting enabled. For more information about BGP attribute-based accounting, see Configuring BGP Attribute-Based Accounting in Configuring Routing Policies. |
Graceful restart is always enabled in all BGP routing instances, and is supported for both IPv4 and IPv6 address families. You cannot disable BGP graceful restart on a BGP neighbor, but you can configure some characteristics.
To configure the graceful restart characteristics for a BGP routing instance, perform the tasks described in Table 4. Enter all commands in BGP router configuration mode.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Set the maximum amount of time that it will take for a local BGP peer to come up after it has been reset. |
— | |
|
Set the maximum amount of time the local BGP speaker retains routes it has previously received from a remote peer once that remote peer restarts the connection. |
Any routes that have not been updated by the remote peer are deleted by the local peer after the local peer receives the end-of-RIB marker from the remote peer, or after the timer expires. | |
|
Set the maximum delay time for the BGP routing process after a reset has occurred before performing initial best path calculations. |
Use this feature when all peers do not support a graceful restart, or when a peer may not send an end-of-RIB marker. |
If a BGP route reflector is configured, while it must have connections to all other BGP speakers in the AS, not all other BGP speakers must be fully meshed. When a BGP speaker in the AS receives messages from an external router, it is sufficient to advertise these routes only to the router reflector, which then readvertises the routes to all other BGP speakers in the AS.
To configure BGP route reflection, perform the tasks described in Table 5. Enter all commands in BGP router configuration mode.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Enable client-to-client reflection. |
By default, routes are reflected between clients of a route reflector. | |
|
Disable client-to-client reflection. |
Disable client-to-client reflection when you do not want routes that have been learned from one client to be reflected to other clients; for example, when clients are fully meshed. | |
|
Assign a separate cluster ID to each route reflector. |
Use this command when there is more than one route reflector in a cluster. |
To reduce iBGP mesh, you can divide an autonomous system into subautonomous systems grouped by a routing domain identifier. The AS and its subautonomous systems are part of a BGP confederation. Externally, the confederation looks like a single autonomous system.
To configure a BGP confederation, perform the tasks described in Table 6. Enter all commands in BGP router configuration mode.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Configure a BGP confederation. |
— | |
|
Configure the subautonomous systems that belong to the BGP confederation. |
— |
BGP speakers (BGP-enabled routers) that exchange inter-AS routing information are called BGP neighbors. BGP supports two kinds of neighbors: internal and external. Internal neighbors are in the same AS; external neighbors are in different autonomous systems. External neighbors must be adjacent to each other and share the same subnet, while internal neighbors may be located anywhere inside the same autonomous system.
To enable BGP speakers to effectively communicate with each other, each BGP speaker must be configured with information about its BGP neighbors.
The sections that follow describe how to configure a BGP neighbor and other neighbor attributes.
To configure a BGP neighbor, perform the tasks described in Table 7.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Enter BGP router configuration mode. |
Enter this command in context configuration mode. | |
|
Create a BGP neighbor and access BGP neighbor configuration mode. |
Enter this command in BGP router configuration mode. To configure an external GRP (eBGP) neighbor, include the external keyword in the neighbor command string. To configure an internal GRP (iBGP) neighbor, include the internal keyword in the neighbor command string. | |
|
Advertise to a peer that this BGP speaker is willing to accept address prefix-based route filtering from the peer. |
Because ORF capabilities are communicated between BGP speakers during BGP connection establishment, the accept filter prefix-list command does not take effect until the BGP connection is reset. | |
|
Modify the MRAI (minimal interval at which BGP routing updates are sent to the specified neighbor). |
Range is from 0 to 600. For external BGP (eBGP), the default value is 30. For internal BGP (iBGP), the default value is 5. | |
|
Enable Bidirectional Forwarding Detection (BFD) for an eBGP neighbor. |
BFD is a simple Hello protocol that provides the ability to detect communication failures in less than one second. When BFD detects a communication failure to the eBGP neighbor, the neighbor is reset. BFD can be enabled only for eBGP neighbors; enabling BFD for an iBGP neighbor generates an error message. For more information about BFD, see Configuring BFD. | |
|
Associate a description with the neighbor. |
— | |
|
Configure the maximum number of hops used to reach an eBGP neighbor when the neighbor is not directly connected. |
This command must be enabled for BGP connections to be established with neighbors that are not directly connected. | |
|
Enable the BGP time-to-live (TTL) security check in the kernel for the BGP neighbor. |
For the BGP TTL security check to function correctly, it must be enabled on both ends of an eBGP session. Enabling only one end causes the eBGP session to drop. | |
|
Configure the ASN that the BGP routing process uses to peer with the specified eBGP neighbor. |
— | |
|
Advertise the local peer address as the next-hop address. |
By default, when a BGP neighbor receives BGP routes from an eBGP neighbor, routes are sent to iBGP neighbors without changing the next-hop address. | |
|
Configure an encrypted MD5 password for the BGP neighbor. |
— | |
|
Apply the attributes of a configured BGP peer group to one or more BGP neighbors. |
You can assign a neighbor can be assigned to a peer group only if the neighbor and the peer group is of the same type—external or internal BGP. If a neighbor belongs to a particular peer group, you cannot configure it to belong to another peer group. You must first explicitly delete the previous peer group membership before reconfiguring the peer membership. Attributes are inherited from the peer group to which a neighbor is assigned. The following BGP neighbor configuration mode commands represent attributes that you cannot customize per neighbor when the neighbor is assigned to a peer group: advertisement-interval, ebgp-multihop, local-as, send community, and timers. Attributes inherited from a peer group that you can customize per neighbor include those set by the following commands: description, password, send prefix, shutdown, and update-source. | |
|
Configure the ASN of the eBGP neighbor. |
— | |
|
Send the community attribute to the specified eBGP neighbor. |
— | |
|
Advertise to a BGP peer that this BGP speaker would like to send prefixed-based filtering to the peer. |
Because ORF capabilities are communicated between BGP speakers during BGP connection establishment, the send filter prefix-list command does not take effect until the BGP connection is reset. | |
|
Administratively shut down a BGP session with the specified neighbor. |
This command temporarily shuts down a BGP session without removing a BGP neighbor from the configuration. | |
|
Modify keepalive and holdtime timers for a specific neighbor. |
Values set for a BGP neighbor override the values set for the BGP routing instance. | |
|
Specify the IP address of the interface used for BGP peering. |
— | |
|
Configure IPv4 multicast or unicast address family attributes. |
— |
For the complete list of tasks used to configure IPv4 address family attributes, see Configure IPv4 Address Family Attributes for a BGP Neighbor. |
|
Configure IPv6 unicast address family attributes. |
— |
For the complete list of tasks used to configure IPv6 address family attributes, see Configure IPv6 Address Family Attributes for a BGP Neighbor. |
|
Configure the graceful restart characteristics. |
— |
For the complete list of tasks used to configure BGP graceful restart, see Configure Graceful Restart Characteristics for a BGP Neighbor. |
|
Configure the interval that must pass before the BGP routing process triggers fast-reset after all of the links in a BGP fast-reset interface list go down, and access BGP neighbor fast-reset configuration mode, where you can add up to ten links to a BGP fast-reset interface list. |
BGP fast-reset occurs only when all interfaces in the BGP fast-reset interface list go down. If only one interface in a group goes down, an alternative path becomes active, and so on. | |
|
Add an interface to the BGP fast-reset interface list. |
Repeat this step to add additional interfaces to the BGP fast-reset interface list. You can add up to 10 interfaces to a list. |
To configure the IPv4 address family attributes for a BGP neighbor, perform the tasks described in Table 8.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Specify the use of standard IP Version 4 (IPv4) multicast or unicast address prefixes for the neighbors in the BGP address family, and to access BGP neighbor address family configuration mode. |
Enter this command in BGP neighbor configuration mode. | |
|
Filter BGP routing updates from or to the specified BGP neighbor address family. |
— | |
|
Advertise the default route of the specified address family, even when the default route is not installed in the BGP routing table, to a BGP neighbor. |
— | |
|
Specify how the BGP routing process responds when the maximum number of prefixes sent by the BGP neighbor for the specified address family is exceeded. |
— | |
|
Apply the attributes of a configured BGP peer group to one or more BGP neighbor address families. |
A BGP neighbor address family can belong to more than one peer group and you can modify it to belong to a different peer group without having to delete the previous peer group association first. Attributes are inherited from the peer group to which a BGP neighbor address family is assigned. The following commands in BGP neighbor address family configuration mode represent attributes that you cannot customize per address family once it is assigned to a peer group: as-path-list out, prefix-list out, remove-private-as, and route-map out. Attributes inherited from a peer group that you can customize per neighbor address family include those set by the following commands: as-path-list in, default-originate, maximum-prefix, prefix-list in, and route-map in. | |
|
Filter BGP routes from or to the specified neighbor address family. |
— | |
|
Remove ASNs from routes advertised to the specified BGP neighbor address family. |
— | |
|
Apply a route map that modifies BGP attributes or filters BGP routes received from or sent to the BGP neighbor. |
— | |
|
Configure an iBGP neighbor as a route reflector client for a BGP address family. |
— | |
|
Enable a BGP router to send MPLS labels with BGP IPv4 routes to a peer BGP router. |
The send label command is available for BGP routers configured with IPv4 unicast address prefixes only; it is not available for routers configured with multicast IPv4 address prefixes. |
To configure the IPv6 address family attributes for a BGP neighbor, perform the tasks described in Table 9.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Specify the use of standard IPv6 unicast address prefixes for the neighbors in the BGP address family, and to access BGP neighbor address family configuration mode. |
Enter this command in BGP neighbor configuration mode. | |
|
Filter BGP routing updates from or to the specified BGP neighbor address family. |
— | |
|
Advertise the default route of the specified address family, even when the default route is not installed in the BGP routing table, to a BGP neighbor. |
— | |
|
Specify how the BGP routing process responds when the maximum number of prefixes sent by the BGP neighbor for the specified address family is exceeded. |
— | |
|
Apply the attributes of a configured BGP peer group to one or more BGP neighbor address families. |
A BGP neighbor address family can belong to more than one peer group and you can modify it to belong to a different peer group without having to delete the previous peer group association first. Attributes are inherited from the peer group to which a BGP neighbor address family is assigned. The following commands in BGP neighbor address family configuration mode represent attributes that you cannot customize per address family once it is assigned to a peer group: as-path-list out, prefix-list out,remove-private-as, and route-map out. Attributes inherited from a peer group that you can customize per neighbor address family include those set by the following commands: as-path-list in, default-originate, maximum-prefix, prefix-list in, androute-map in. | |
|
Filter BGP routes from or to the specified neighbor address family. |
— | |
|
Remove ASNs from routes advertised to the specified BGP neighbor address family. |
— | |
|
Apply a route map that modifies BGP attributes or filters BGP routes received from or sent to the BGP neighbor. |
— | |
|
Configure an iBGP neighbor as a route reflector client for a BGP address family. |
— | |
|
Enable a BGP router to send MPLS labels with BGP IPv6 routes to a peer BGP router. |
You must configure this command on both the local router and the peer router in order for the routers to send IPv6 unicast routes with MPLS labels. Before you use the send label command to enable the sending of IPv6 packets over an IPv4 core, you must enable MPLS on the core. |
Graceful restart is always enabled all BGP routing instances, and is supported for both IPv4 and IPv6 address families. You cannot disable BGP graceful restart on a BGP neighbor, but you can configure certain characteristics.
To configure the graceful restart characteristics for a BGP neighbor, perform the tasks described in Table 10.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Set the maximum amount of time after the local BGP speaker has been reset before it attempts to reconnect with the remote peer. |
— | |
|
Set the maximum amount of time the local BGP speaker retains routes it has previously received from a remote peer once that remote peer restarts the connection. |
Any routes that have not been updated by the remote peer are deleted by the local peer after the local peer receives the end-of-RIB marker from the remote peer, or after the timer expires. | |
|
Force a BGP neighbor to retain routes from an iBGP peer once the peer has restarted. |
By default, routes are not retained for an iBGP peer after the peer restarts unless all iBGP peers support a graceful restart; however, in some network topologies, it may be desirable and feasible to retain the routes for an iBGP peer, even if not all iBGP peers support a graceful restart. |
To enable IPv6 over an IPv4 MPLS core, perform the tasks described in Table 11.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Access global configuration mode. |
Enter this command in global exec mode. | |
|
Enter context configuration mode. |
context local |
Enter this command in global configuration mode. |
|
Enter router configuration mode for the specified BGP routing instance. |
Enter this command in context configuration mode. | |
|
Specify the use of IP Version 6 (IPv6) unicast address prefixes for the Border Gateway Protocol (BGP) routing instance and enter BGP address family configuration mode. |
Enter this command in BGP router configuration mode. | |
|
Exit BGP address family configuration mode and enter BGP router configuration mode. |
Enter this command in BGP address family configuration mode. | |
|
Enter BGP neighbor configuration mode for the specified neighbor. |
Enter this command in BGP router configuration mode. | |
|
Specify the use of IPv6 unicast address prefixes for the specified BGP neighbor, and enter BGP neighbor address family configuration mode. |
Enter this command in BGP neighbor configuration mode. | |
|
Enable the transport of labeled IPv6 routes over the MPLS IPv4 core. |
Enter this command in BGP neighbor address family configuration mode. |
BGP peer groups are helpful in cases where many BGP neighbors are configured with the same update policies. Grouping a large number of neighbors into one or more peer groups simplifies modifications to a configuration and makes the BGP update calculation process more efficient. A BGP peer group can be an eBGP or as an iBGP peer group.
To configure a BGP peer group and other peer group attributes, perform the tasks described in the sections that follow.
To configure a BGP peer group, perform the tasks described in Table 12.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Configure a BGP peer group, and enter BGP peer group configuration mode. |
Enter this command in BGP router configuration mode. | |
|
Modify the minimal interval at which BGP routing updates are sent to the specified BGP peer group. |
Range is from 0 to 600. For external BGP (eBGP), the default value is 30. For internal BGP (iBGP), the default value is 5. | |
|
Associate a description with the peer group. |
— | |
|
Configure the maximum number of hops used to reach an eBGP neighbor when the BGP peer group is not directly connected. |
This command must be enabled for BGP connections to be established with neighbors that are not directly connected. | |
|
Enable the BGP TTL security check in the kernel for the BGP peer group. |
For the BGP TTL security check to function correctly, it must be enabled on both ends of an eBGP session. Enabling only one end causes the eBGP session to drop. | |
|
Advertise the local peer address as the next-hop address. |
— | |
|
Configure an encrypted MD5 password for the BGP peer group. |
— | |
|
Send the community attribute to the specified BGP peer group. |
— | |
|
Enable a flapping peer to be temporarily suppressed for a configurable amount of time. |
This command is per peer and peer-group based. If the peer is member of a peer group, the command is inherited from the peer-group and can be customized in the peer configuration. The main benefit of this feature is to avoid flapping peers from using system resources, and also to reduce routing churn induced by a flapping peer. | |
|
Administratively shut down a BGP session with the specified peer group. |
This command temporarily shuts down a BGP session without removing a BGP peer group from the configuration. | |
|
Modify keepalive and holdtime timers for a peer group. |
— | |
|
Specify the IP address of the interface used for BGP peering. |
By default, when a BGP peer group receives BGP routes from an eBGP peer group, routes are sent to iBGP neighbors without changing the next-hop address. | |
|
Configure IPv4 multicast or unicast address family attributes. |
For the complete list of tasks used to configure IPv4 address family attributes, see Configure IPv4 Address Family Attributes for a BGP Peer Group. | |
|
Configure IPv6 unicast address family attributes. |
For the complete list of tasks used to configure IPv6 address family attributes, see Configure IPv6 Address Family Attributes for a BGP Peer Group. | |
To configure IPv4 address family attributes for a BGP peer group, perform the tasks described in Table 13. Enter all commands in BGP peer group address family configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Specify the use of standard IPv4 multicast or unicast address prefixes for peer groups in the BGP peer groups address family, and enter BGP peer group address family configuration mode. |
Enter this command in BGP peer group configuration mode. | |
|
Filter BGP routing updates from or to the specified BGP neighbor address family. |
— | |
|
Advertise the default route of the specified address family, even when the default route is not installed in the BGP routing table, to a BGP neighbor. |
— | |
|
Specify how the BGP address family responds when the maximum number of prefixes sent by the BGP peer group for the specified address family is exceeded. |
— | |
|
Filter BGP routes from the peer group for the specified address family. |
— | |
|
Remove ASNs from routes advertised to the specified BGP peer group address family. |
— | |
|
Apply a route map that modifies BGP attributes or filters BGP routes received from or sent to the specified peer group address family. |
— | |
|
Configure an iBGP peer group as a route reflector client for a BGP address family. |
— |
To configure IPv6 address family attributes for a BGP peer group, perform the tasks described in Table 14. Enter all commands in BGP peer group address family configuration mode, unless otherwise noted.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Specify the use of standard IPv6 unicast address prefixes for peer groups in the BGP peer groups address family, and enter BGP peer group address family configuration mode. |
Enter this command in BGP peer group configuration mode. | |
|
Filter BGP routing updates from or to the specified BGP neighbor address family. |
— | |
|
Advertise the default route of the specified address family, even when the default route is not installed in the BGP routing table, to a BGP neighbor. |
— | |
|
Specify how the BGP address family responds when the maximum number of prefixes sent by the BGP peer group for the specified address family is exceeded. |
— | |
|
Filter BGP routes from the peer group for the specified address family. |
— | |
|
Remove ASNs from routes advertised to the specified BGP peer group address family. |
— | |
|
Apply a route map that modifies BGP attributes or filters BGP routes received from or sent to the specified peer group address family. |
— | |
|
Configure an iBGP peer group as a route reflector client for a BGP address family. |
— |
A BGP neighbor, or BGP neighbor address family, can inherit attributes from the peer group to which a neighbor is assigned. The following BGP neighbor configuration mode commands represent attributes that cannot be customized per neighbor when the neighbor is assigned to a peer group: advertisement-interval, ebgp-multihop, local-as, send community, and timers. Attributes inherited from a peer group that can be customized per neighbor include those set by the following commands: description, password, send prefix, shutdown, and update-source.
To apply peer group attributes, perform the tasks described in Table 15.
|
Task |
Root Command |
Notes |
|---|---|---|
|
Apply peer group attributes to a BGP neighbor. |
Enter this command in BGP neighbor configuration mode. | |
|
Apply peer group attributes to a BGP neighbor address family. |
Enter this command in BGP peer group configuration mode. |
To enable BGP prefix-based ORF, perform the tasks described in Table 16.
|
# |
Task |
Root Command |
Notes |
|---|---|---|---|
|
Configure an IP-prefix list with ORF filters: | |||
|
1. |
Access global configuration mode. |
Enter this command in global exec mode. | |
|
2. |
Enter context configuration mode. |
Enter this command in global configuration mode. | |
|
3. |
Create an IP prefix list and access IP prefix list configuration mode. |
When the prefix list is applied to a BGP neighbor, that neighbor takes on the filters specified by the IP prefix list. | |
|
4. |
Create a filter. |
seq |
The sequence number determines the order in which the filter is applied. You can configure a filter that permits or denies BGP updates from a specified IP whose prefix length is equal to, greater than, or less than the specified prefix length. |
|
5. |
Repeat Step 1 through Step 4 to add more filters to an IP prefix list.
| ||
|
Apply the prefix list to a BGP neighbor: | |||
|
6. |
Access global configuration mode. |
Enter this command in global exec mode. | |
|
7. |
Enter context configuration mode. |
Enter this command in global configuration mode. | |
|
8. |
Access router configuration mode for the specified BGP routing instance. |
— | |
|
9. |
Enter BGP neighbor configuration mode for the specified neighbor. |
— | |
|
10. |
Advertise to a BGP peer that this BGP speaker can send prefixed-based filtering to the peer. |
Because ORF capabilities are communicated between BGP speakers during BGP connection establishment, the send filter prefix-list command does not take effect until the BGP connection is reset. | |
|
11. |
Access BGP neighbor address family configuration mode. |
address-family ipv4 (Multicast and Unicast) or or |
|
|
12. |
Apply the IP prefix list you configured in Steps 1 through 5 to the neighbor address family. |
prefix-list pl-name in |
|
|
Configure the receiving BGP peer (another BGP speaker) to accept ORFs received from the sending BGP speaker: | |||
|
13. |
Access global configuration mode. |
Enter this command in global exec mode. | |
|
14. |
Enter context configuration mode. |
Enter this command in global configuration mode. | |
|
15. |
Access router configuration mode for a BGP routing instance. |
— | |
|
16. |
Advertise to a peer that this BGP speaker is willing to accept address prefix-based route filtering from the peer. |
Because ORF capabilities are communicated between BGP speakers during BGP connection establishment, the accept filter prefix-list command does not take effect until the BGP connection is reset. | |
To manage BGP functions, perform the appropriate tasks described in Table 17. Enter the show commands in any mode; enter the clear and debug commands in exec mode.
|
Task |
Root Command |
|---|---|
|
Apply new BGP routing policies or reset BGP connections globally without dropping connections. |
|
|
Apply new routing policies for eBGP neighbors or to reset eBGP connections. |
|
|
Clear BGP route-flap statistics. |
|
|
Apply new BGP routing policies to connections using multicast address prefixes or to reset BGP IPv4 address connections. |
|
|
Apply new BGP routing policies to connections using unicast address prefixes or to reset BGP IPv4 address connections. |
|
|
Clear BGP message statistics. |
|
|
Apply new BGP neighbor routing policies or reset BGP neighbor connections. |
|
|
Apply new BGP peer group routing policies or to reset BGP peer group connections. |
|
|
Enable the generation of BGP general-event messages. |
|
|
Enable the generation of debug messages for BGP passive open connections. |
|
|
Enable the generation of debug messages for BGP nonupdate events. |
|
|
Enable the generation of debug messages for BGP routing policies. |
|
|
Enable the generation of debug messages for interaction between BGP and the Routing Information Base (RIB). |
|
|
Enable the generation of debug messages for BGP session states and timers. |
|
|
Enable the generation of debug messages for BGP update events. |
|
|
Display BGP attribute information, including AS path, community, next-hop address, and route reflector attributes. |
|
|
Display malformed BGP messages for the purpose of troubleshooting. |
|
|
Display BGP neighbor status, configuration, and statistical information. |
|
|
Display BGP neighbor flap statistics. |
|
|
Display BGP notification messages. |
|
|
Display BGP peer group information, including peer group membership and session status. |
|
|
Display BGP neighbor reset information for troubleshooting purposes. |
|
|
Display information about all BGP routes, or for a subset of routes. |
|
|
Display community information for BGP routes. |
|
|
Display BGP route-flap statistics. |
|
|
Display BGP routes sourced from more than one AS. |
|
|
Display information about BGP multicast or unicast IP Version 4 (IPv4) address prefix-based routes. |
|
|
Display information about BGP unicast IP Version 6 (IPv6) address prefix-based routes. |
|
|
Display MPLS labels associated with BGP routes. |
|
|
Display information about routes to or from BGP neighbors. |
|
|
Display BGP communities that match an AS path string. |
|
|
Display BGP routes sourced from the local AS. |
|
|
Display a summary report of BGP routes in the routing table. |
|
|
Display a summary of BGP status and statistical information. |
|
|
Display the current BGP configuration information for the current context. |
| Caution! | ||
|
Risk of dropped connection. A hard reset can impact network connectivity.
When using any clear bgp command, the soft keyword for inbound only takes effect if the BGP neighbor supports
the refresh capability. The soft keyword for outbound
is a local matter, and does not require the capability. To see if
a BGP neighbor supports the refresh capability, use the show
bgp neighbor summary command (in exec mode). Specify the soft keyword if you do not want the BGP neighbor connection
dropped. To reduce the risk, only use a hard reset as a last resort.
| ||
The sections that follow provide BGP configuration examples for basic BGP, next-hop triggered BGP best-path calculation, iMP-BGP peers, iMP-BGP peer groups, eMP-BGP peers, eMP-BGP peer groups, and IPv6 over an IPv4 core.
The following example show the minimum commands needed to configure BGP:
[local]Router_A#config [local]Router_A(config)#context local [local]Router_A(config-ctx)#router bgp 64001 [local]Router_A(config-bgp)#router-id 1.1.1.71 [local]Router_A(config-bgp)#address-family ipv4 unicast [local]Router_A(config-bgp-af)#redistribute static [local]Router_A(config-bgp-af)#exit [local]Router_A(config-bgp)#peer-group iBGP internal [local]Router_A(config-bgp-peer-group)#next-hop-self [local]Redback(config-bgp-peer-group)#update-source loopback0 [local]Redback(config-bgp-peer-group)#address-family ipv4 unicast [local]Redback(config-bgp-peer-af)#exit [local]Redback(config-bgp-peer-group)#exit [local]Redback(config-bgp)#peer-group customer-routes external [local]Redback(config-bgp-peer-group)#address-family ipv4 unicast [local]Redback(config-bgp-peer-af)#route-map rmap1 out [local]Redback(config-bgp-peer-af)#exit [local]Redback(config-bgp-peer-group)#exit [local]Redback(config-bgp)#neighbor 1.1.1.1 internal [local]Redback(config-bgp-neighbor)#peer-group ibgp [local]Redback(config-bgp-neighbor)#exit [local]Redback(config-bgp)#neighbor 2.2.2.2 external [local]Redback(config-bgp-neighbor)#remote-as 200 [local]Redback(config-bgp-neighbor)#peer-group customer-routes [local]Redback(config-bgp-neighbor)#address-family ipv4 unicast [local]Redback(config-bgp-peer-af)#prefix-list bar in [local]Redback(config-bgp-peer-af)#route-map foo2 in [local]Redback(config-bgp-peer-af)#exit [local]Redback(config-bgp-neighbor)#exit [local]Redback(config-bgp)#neighbor 3.3.3.3 external [local]Redback(config-bgp-neighbor)#remote-as 300 [local]Redback(config-bgp-neighbor)#address-family ipv4 unicast [local]Redback(config-bgp-peer-af)#prefix-list bar in [local]Redback(config-bgp-peer-af)#route-map foo3 out
The following example shows how to enable and then configure next-hop triggered BGP best-path calculation:
[local]Router_A#config [local]Router_A(config)#context local [local]Router_A(config-ctx)#router bgp 64001 [local]Router_A(config-bgp)#address-family ipv4 unicast [local]Router_A(config-bgp-af)#nexthop triggered [local]Router_A(config-bgp-af)#nexthop triggered delay 30 [local]Router_A(config-bgp-af)#nexthop triggered holdtime 2 backoff 10 [local]Router_A(config-bgp-af)#commit
The following example configures two iMP-BGP peers. Figure 6 shows the network topology for the configuration.
The configuration for Router_A is as follows:
[local]Router_A#config [local]Router_A(config)#context local [local]Router_A(config-ctx)#interface lo1 loopback [local]Router_A(config-if)#ip address 10.200.1.1/32 [local]Router_A(config-if)#exit [local]Router_A(config-ctx)#router bgp 100 [local]Router_A(config-bgp)#router-id 10.200.1.1 [local]Router_A(config-bgp)#neighbor 10.200.1.2 internal [local]Router_A(config-bgp-neighbor)#update-source lo1 [local]Router_A(config-bgp-neighbor)#address-family ipv4 multicast [local]Router_A(config-bgp-peer-af)#exit [local]Router_A(config-bgp-neighbor)#exit [local]Router_A(config-bgp)#exit [local]Router_A(config-ctx)#ip route 10.200.1.2/32 102.1.1.2
The configuration for Router B is as follows:
[local]Router_B#config [local]Router_B(config)#context local [local]Router_B(config-ctx)#interface lo1 loopback [local]Router_B(config-if)#ip address 10.200.1.2/32 [local]Router_B(config-if)#exit [local]Router_B(config-ctx)#router bgp 100 [local]Router_B(config-bgp)#router-id 10.200.1.2 [local]Router_B(config-bgp)#neighbor 10.200.1.1 internal [local]Router_B(config-bgp-neighbor)#update-source lo1 [local]Router_B(config-bgp-neighbor)#address-family ipv4 multicast [local]Router_B(config-bgp-peer-af)#exit [local]Router_B(config-bgp-neighbor)#exit [local]Router_B(config-bgp)#exit [local]Router_B(config-ctx)#ip route 10.200.1.1/32 102.1.1.1
The following example configures an iMP-BGP peer group for two iMP-BGP peers. Figure 7 shows the network topology for the configuration.
The configuration for Router_A is as follows:
[local]Router_A#config [local]Router_A(config)#context local [local]Router_A(config-ctx)#interface lo1 loopback [local]Router_A(config-if)#ip address 10.200.1.1/32 [local]Router_A(config-if)#exit [local]Router_A(config-ctx)#router bgp 100 [local]Router_A(config-bgp)#router-id 10.200.1.1 [local]Router_A(config-bgp)#address-family ipv4 multicast [local]Router_A(config-bgp-af)#exit [local]Router_A(config-bgp)#peer-group iMBGP internal [local]Router_A(config-bgp-peer-group)#update-source lo1 [local]Router_A(config-bgp-peer-group)#address-family ipv4 multicast [local]Router_A(config-bgp-peer-af)#exit [local]Router_B(config-bgp-peer-group)#exit [local]Router_A(config-bgp)#neighbor 10.200.1.2 internal [local]Router_A(config-bgp-neighbor)#peer-group iMBGP
The configuration for Router_B is as follows:
[local]Router_B#config [local]Router_B(config)#context local [local]Router_B(config-ctx)#interface lo1 loopback [local]Router_B(config-if)#ip address 10.200.1.2/32 [local]Router_B(config-if)#exit [local]Router_B(config-ctx)#router bgp 100 [local]Router_B(config-bgp)#router-id 10.200.1.2 [local]Router_B(config-bgp)#address-family ipv4 multicast [local]Router_B(config-bgp-af)#exit [local]Router_B(config-bgp)#peer-group iMBGP internal [local]Router_B(config-bgp-peer-group)#update-source lo1 [local]Router_B(config-bgp-peer-group)#address-family ipv4 multicast [local]Router_B(config-bgp-peer-af)#exit [local]Router_B(config-bgp-peer-group)#exit [local]Router_B(config-bgp)#neighbor 10.200.1.1 internal [local]Router_B(config-bgp-neighbor)#peer-group iMBGP
The following example configures two eMP-BGP peers. Figure 8 shows the network topology for the configuration.
The configuration for Router_B is as follows:
[local]Router_B#config [local]Router_B(config)#context local [local]Router_B(config-ctx)#interface lo1 loopback [local]Router_B(config-if)#ip address 10.200.1.2/32 [local]Router_B(config-if)#exit [local]Router_B(config-ctx)#router bgp 100 [local]Router_B(config-bgp)#router-id 10.200.1.2 [local]Router_B(config-bgp)#neighbor 10.200.1.3 external [local]Router_B(config-bgp-neighbor)#remote-as 200 [local]Router_B(config-bgp-neighbor)#ebgp-multihop 10 [local]Router_B(config-bgp-neighbor)#update-source lo1 [local]Router_B(config-bgp-neighbor)#address-family ipv4 multicast
The configuration for Router_C is as follows:
[local]Router_C#config [local]Router_C(config)#context local [local]Router_C(config-ctx)#interface lo1 loopback [local]Router_C(config-if)#ip address 10.200.1.3/32 [local]Router_C(config-if)#exit [local]Router_C(config-ctx)#router bgp 100 [local]Router_C(config-bgp)#router-id 10.200.1.2 [local]Router_C(config-bgp)#neighbor 10.200.1.1 internal [local]Router_C(config-bgp-neighbor)#remote-as 100 [local]Router_C(config-bgp-neighbor)#ebgp-multihop 10 [local]Router_C(config-bgp-neighbor)#update-source lo1 [local]Router_C(config-bgp-neighbor)#address-family ipv4 multicast
The following example configures an eMP-BGP peer group for two eMP-BGP peers. Figure 9 shows the network topology for the configuration.
The configuration for Router_B is as follows:
[local]Router_B#config [local]Router_B(config)#context local [local]Router_B(config-ctx)#interface lo1 loopback [local]Router_B(config-if)#ip address 10.200.1.2/32 [local]Router_B(config-if)#exit [local]Router_B(config-ctx)#router bgp 100 [local]Router_B(config-bgp)#router-id 10.200.1.2 [local]Router_B(config-bgp)#address-family ipv4 multicast [local]Router_B(config-bgp-af)#exit [local]Router_B(config-bgp)#peer-group eMBGP external [local]Router_B(config-bgp-peer-group)#ebgp-multihop 10 [local]Router_B(config-bgp-peer-group)#update-source lo1 [local]Router_B(config-bgp-peer-group)#address-family ipv4 multicast [local]Router_B(config-bgp-peer-af)#exit [local]Router_B(config-bgp-peer-group)#neighbor 10.200.1.3 external [local]Router_B(config-bgp-neighbor)#remote-as 200 [local]Router_B(config-bgp-neighbor)#peer-group eMBGP
The configuration for Router_C is as follows:
[local]Router_C#config [local]Router_C(config)#context local [local]Router_C(config-ctx)#interface lo1 loopback [local]Router_C(config-if)#ip address 10.200.1.3/32 [local]Router_C(config-if)#exit [local]Router_C(config-ctx)#router bgp 200 [local]Router_C(config-bgp)#router-id 10.200.1.3 [local]Router_C(config-bgp)#address-family ipv4 multicast [local]Router_C(config-bgp-af)#exit [local]Router_C(config-bgp)#peer-group eMBGP external [local]Router_C(config-bgp-peer-group)#ebgp-multihop 10 [local]Router_C(config-bgp-peer-group)#update-source lo1 [local]Router_C(config-bgp-peer-group)#address-family ipv4 multicast [local]Router_C(config-bgp-peer-af)#exit [local]Router_C(config-bgp-peer-group)#neighbor 10.200.1.2 external [local]Router_C(config-bgp-neighbor)#remote-as 100 [local]Router_C(config-bgp-neighbor)#peer-group eMBGP
The following example shows how to enable IPv6 over an MPLS IPv4 core in the SmartEdge router. Perform this configuration on a PE router that has at least one IPv4 session with a PE neighbor and one IPv6 session with a CE neighbor:
[local]Router_C#config context local [local]Router_A(config-ctx)#router bgp 100 [local]Router_C(config-bgp)#address-family ipv6 unicast [local]Router_C(config-bgp-af)#exit [local]Router_C(config-bgp)#neighbor 10.200.1.3 internal [local]Router_C(config-bgp-neighbor)#address-family ipv6 unicast [local]Router_C(config-bgp-peer-af)#send label [local]Router_C(config-bgp-peer-af)#commit
The following example shows how to configure BGP ORF between a BGP speaker (IP address 192.168.255.120) and its BGP peer (IP address 192.168.255.110):
The following example creates an IP prefix list called ORF-test that has three filters:
[local]Redback#configure [local]Redback(config)#context local [local]Redback(config-ctx)#ip prefix-list ORF-test [local]Redback(config-prefix-list)#seq 10 permit 192.168.128.0/24 ge 24 [local]Redback(config-prefix-list)#seq 15 permit 192.168.127.0/24 le 18 [local]Redback(config-prefix-list)#seq 20 deny any
The following example advertises to a BGP neighbor that this BGP speaker can send prefixed-based filtering to the peer, and applies the IP prefix list ORF-test to the BGP peer:
[local]Redback#configure [local]Redback(config)#context local [local]Redback(config-ctx)#router bgp 999 [local]Redback(config-bgp)#neighbor 192.168.255.110 external [local]Redback(config-bgp-neighbor)#address-family ipv4 unicast [local]Redback(config-bgp-peer-af)#prefix-list ORF-test in
The following example configures the BGP peer (whose IP address is 192.168.255.110) to accept ORFs received from the sending BGP speaker (whose IP address is 192.168.255.120):
[local]Redback#configure [local]Redback(config)#context local [local]Redback(config-ctx)#router bgp 100 [local]Redback(config-bgp)#neighbor 192.168.255.120 external [local]Redback(config-bgp-neighbor)#accept filter prefix-list
The following example configures route redistribution and aggregation for a BGP routing instance. First, configure a list of aggregate IP prefixes:
[local]Router(config-ctx)#ipv6 prefix-list test1-aggregate [local]Router(config-ipv6-prefix-list)#seq 10 permit 4001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 20 permit 5001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 30 permit 6001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 40 permit 7001:101:101:106::/64 ge 64 [local]Router(config-ipv6-prefix-list)#seq 50 permit 2001:101:101::/48 ge 48
Next, configure route map test1 that aggregates the IPv6 prefixes in the aggregate prefix list called test1-aggregate:
[local]Router(config-ctx)#route-map test1 permit 10 [local]Router(config-route-map)#match ipv6 address prefix-list test1-aggregate [local]Router(config-route-map)#set ipv6 aggregate test1-aggregate
Specify that routes selected for redistribution are summarized only if they contain any of the prefixes specified in IPv6 prefix list test1:
[local]Redback(config-ctx)#router bgp 1 [local]Redback(config-bgp)#address-family ipv6 unicast [local]Redback(config-bgp-af)#redistribute static route-map test1
Configure the static routes. In this example, the routes match aggregate prefix 2001:101:101::/48:
[local]Redback(config-ctx)#ipv6 route 2001:101:101:303::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:304::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:305::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:306::/64 80::2 [local]Redback(config-ctx)#ipv6 route 2001:101:101:307::/64 80::2
