You will often want to apply the same policies to most or all of the peers of a particular BGP speaker. Update policies are usually defined by route maps, filter lists, and distribution lists. You can reduce the configuration effort by defining a peer group made up of these peers.
A peer group is defined relative to a particular BGP speaker. Figure 11 shows two peer groups, eastcoast and leftcoast. Each of these peer groups is defined for router Chicago, the hub router. Routers Boston, NY, and Miami have no knowledge of being members of Router Chicago’s eastcoast peer group. Similarly, routers SanFran, LA, and SanDiego have no knowledge of being members of router Chicago’s leftcoast peer group.
The following commands configure the eastcoast peer group on router Chicago:
- host1(config)#router bgp 23
- host1(config)#route-map wtset permit 10
- host1(config-route-map)#set weight 25
- host1(config-route-map)#exit
- host1(config-router)#neighbor eastcoast peer-group
- host1(config-router)#neighbor eastcoast route-map
wtset in
- host1(config-router)#neighbor 10.6.6.2 remote-as
12
- host1(config-router)#neighbor 10.6.6.2 peer-group
eastcoast
- host1(config-router)#neighbor 10.7.3.2 remote-as
12
- host1(config-router)#neighbor 10.7.3.2 peer-group
eastcoast
- host1(config-router)#neighbor 10.4.4.2 remote-as
12
- host1(config-router)#neighbor 10.4.4.2 peer-group
eastcoast
The following commands configure the leftcoast peer group on router Chicago:
- host1(config-router)#neighbor leftcoast peer-group
- host1(config-router)#neighbor 10.3.3.2 remote-as
78
- host1(config-router)#neighbor 10.3.3.2 peer-group
leftcoast
- host1(config-router)#neighbor 10.3.2.2 remote-as
2143
- host1(config-router)#neighbor 10.3.2.2 peer-group
leftcoast
- host1(config-router)#neighbor 10.3.1.2 remote-as
136
- host1(config-router)#neighbor 10.3.1.2 peer-group
leftcoast
The multiprotocol extensions to BGP enable the exchange of information within different types of address families. By default, peers and peer groups exist in the unicast IPv4 address family and exchange unicast IPv4 addresses. For information on configuring and activating BGP peer groups within address families, see Configuring the Address Family.
Figure 11: BGP Peer Groups
neighbor peer-group
For information about the inheritance of configuration values by peer groups and peers, see Inheritance of Configuration Values.
Each peer group must have a peer type before any BGP sessions for members of that peer group are allowed to come up and before the Adj-RIBs-Out table of that peer group can be filled. You can use the neighbor peer-type command to explicitly configure a peer type for a peer group.
Alternatively, you can implicitly configure the peer type of a peer group by either of the following methods:
In both of these implicit cases, the remote AS is combined with the local AS, the configured confederation ID, and the configured confederation peers to determine the peer type of the peer group.
neighbor peer-type
- host1(config-router)#neighbor promispeers
peer-type internal
You can associate a description with a BGP neighbor or a peer group. This is a convenient way to store minimal pertinent information about the neighbor.
neighbor description
- host1(config-router)#neighbor 10.11.0.5 description
bostonmetropeer
You can force BGP to log a message whenever a peer enters or leaves the Established state.
bgp log-neighbor-changes
- host1:3(config)#bgp log destination console
severity notice
- host1:3(config)#router bgp 100
- host1:3(config-router)#bgp log-neighbor-changes
- NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,4.4.4.4):
peer 4.4.4.4 in core leaves established state
- NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,5.5.5.5):
peer 5.5.5.5 in core leaves established state
- NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,6.6.6.6):
peer 6.6.6.6 in core leaves established state
- NOTICE 04/30/2001 21:06:22 bgpNeighborChanges (3,13.13.13.1):
peer 13.13.13.1 in core leaves established state
- NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,4.4.4.4):
peer 4.4.4.4 in core enters established state
- NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,5.5.5.5):
peer 5.5.5.5 in core enters established state
- NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,6.6.6.6):
peer 6.6.6.6 in core enters established state
- NOTICE 04/30/2001 21:06:31 bgpNeighborChanges (3,13.13.13.1):
peer 13.13.13.1 in core enters established state
By default, BGP uses the IP address of the outgoing interface toward the peer as the source IP address for the TCP connection over which the BGP session runs. If the outgoing interface goes down, the BGP session is dropped because the IP source address is no longer valid. This is appropriate behavior for EBGP sessions because the EBGP peers typically can reach each other only by virtue of being connected to a common subnet.
For IBGP sessions, however, you typically want BGP sessions to be automatically rerouted around interfaces that are down. You can issue the neighbor update-source command to accomplish this. This command instructs BGP to use the IP address of a specified interface as the source address of the underlying TCP connection. Typically, a loopback interface is used because it is inherently stable.
For example, you can specify that BGP use loopback interface 2 as the source for messages that it sends to peer 192.50.30.1:
- host1(config)#neighbor 192.50.30.1 update-source
loopback 2
neighbor update-source
The source address that you specify with the neighbor update-source command is also used by BGP as the default value for the next hop address advertised for IPv4 or IPv6 prefixes.
The source addresses and next hop address that result from using the neighbor update-source command vary depending on the configuration of the command. Table 14 lists the results for different configurations.
Table 14: Source Addresses and Default Next Hop Addresses for Various Configurations
You can override a native IPv6 next-hop address with either the neighbor update-source command or an outbound route map.
When you specify an interface with the neighbor update-source command, the IPv4-mapped IPv6 address of the interface is used instead of the native IPv6 address for the next hop.
- host1(config)#interface loopback 0
- host1(config-if)#ip address 10.1.1.1/32
- host1(config-if)#exit
- host1(config)#router bgp 100
- host1(config-router)#neighbor 2::2 update-source
loopback 0
In this example, the IPv4-mapped IPv6 address of the loopback 0 interface is the next-hop address sent when IPv6 prefixes are advertised. However, if loopback 0 has an IPv6 address, then that address is used as the default next hop for advertising IPv6 prefixes.
Normally, EBGP speakers are directly connected. When you cannot connect EBGP speakers directly, you can use the neighbor ebgp-multihop command to specify that the neighbor is more than one hop away. You generally need static routes to configure multihop connections. By default, the one-hop limitation per EBGP peers is enforced by the time-to-live attribute. You can override this default limit by using the ttl variable to specify the maximum number of hops to the peer.
In Figure 12, router Boston and router LA are connected together through router NY, rather than by a direct connection. Routers Boston and LA are configured as external peers with the neighbor ebgp-multihop command because no direct connection exists between them. Because router NY is not a BGP speaker, static routes are configured on routers Boston and LA. The configuration for router NY is not shown, because it does not involve BGP.
Figure 12: Using EBGP-Multihop
The following commands achieve the BGP configuration.
To configure router Boston:
- host1(config)#ip route 10.7.4.0 255.255.255.0
10.1.10.2
- host1(config)#router bgp 100
- host1(config-router)#neighbor 10.7.4.3 remote-as
300
- host1(config-router)#neighbor 10.7.4.3 ebgp-multihop
To configure router LA:
- host2(config)#ip route 10.1.10.0 255.255.255.0
10.7.4.4
- host2(config)#router bgp 300
- host2(config-router)#neighbor 10.1.10.1 remote-as
100
- host2(config-router)#neighbor 10.1.10.1 ebgp-multihop
neighbor ebgp-multihop
IBGP peers are multihop by default. However, you can use the neighbor ibgp-single-hop command to enable single-hop connections for IBGP peers.
neighbor ibgp-singlehop
- host1(config-router)#neighbor 192.168.32.15
ibgp-singlehop
As the routing table increases in size, the processor and memory resources required to process routing information increases. Some peers send so much routing information that a BGP speaker can be overwhelmed by the updates. You can use the neighbor maximum-prefix command to limit how many prefixes can be received from a neighbor.
The router resets the BGP connection when the specified maximum is exceeded. You can use the warning-only keyword to log a warning rather than reset the connection. You can also configure the router so that a warning is logged when a specified percentage of the maximum is exceeded.
In the following example, the router is configured to reset the BGP connection when it receives more than 1,000 prefixes from its neighbor at 2.2.2.2:
- host1(config)#router bgp 100
- host1(config-router)#neighbor 2.2.2.2 maximum-prefix
1000
neighbor maximum-prefix
You might choose to conserve AS numbers by assigning private AS numbers to some customers. You can assign private AS numbers from the range 64,512 to 65,535. However, when BGP advertises prefixes to other ISPs, it is undesirable to include the private AS numbers in the path. Configure the external neighbors to drop the numbers with the neighbor remove-private-as command.
neighbor remove-private-as
- host1(config-router)#neighbor 10.10.128.52
remove-private-as
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
You can use the bgp maxas-limit command to prevent the forwarding of routes having AS paths longer than a specified limit.
bgp maxas-limit
- host1(config-router)#bgp maxas-limit 42
To apply the new behavior to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
If you use the fields as-path option with the show ip bgp command, the display indicates routes whose AS path exceeds the limit. The following display illustrates the result of setting the AS path length limit to 5:
host1:3# show ip bgp fields intro best peer loc-pref as-path Local router ID 13.13.13.3, local AS 200 10 paths, 5 distinct prefixes (520 bytes used) 6 paths selected for route table installation 14 path attribute entries (1943 bytes used) Status codes: > best Prefix Peer LocPrf AS-path 10.23.40.1/32 192.168.13.1 200 100 211 32 15 67 44 (too long) > 10.23.40.1/32 172.123.23.2 100 100 211 > 10.23.40.2/32 192.168.13.1 200 100 211 32 15 67 10.23.40.2/32 172.123.23.2 100 100 211 32 > 10.23.40.3/32 192.168.13.1 100 211 32 15 10.23.40.3/32 172.123.23.2 100 211 32 15 10.23.40.4/32 192.168.13.1 100 100 211 32 > 10.23.40.4/32 172.123.23.2 200 100 211 32 15 67 > 10.23.40.5/32 192.168.13.1 100 100 211 10.23.40.5/32 172.123.23.2 200 100 211 32 15 67 44 (too long)
You can use the neighbor password command to enable MD5 authentication on a TCP connection between two BGP peers. Enabling MD5 authentication causes each segment sent on the TCP connection between them to be verified.
You must configure MD5 authentication with the same password on both BGP peers; otherwise, the router does not make the connection between the BGP peers.
The MD5 authentication feature uses the MD5 algorithm. When you specify this command, the router generates and checks the MD5 digest on every segment sent on the TCP connection.
In the following example, the password is set to “ opensesame” :
- host1(config)#router bgp 100
- host1(config-router)#neighbor 2.2.2.2 password
opensesame
The show ip bgp neighbors command does not reveal the password, but does indicate whether MD5 authentication is configured for the session. The output of the show configuration command varies as follows:
neighbor password
You can use the neighbor maximum-update-size command to set the maximum size of update messages transmitted to a BGP peer.
For example, to set the maximum update size to 2,000 octets:
- host1(config)#router bgp 100
- host1(config-router)#neighbor 10.12.2.5 maximum-update-size
2000
neighbor maximum-update-size
You can use the bgp fast-external-fallover command to specify that in the event of the failure of a link to any adjacent external peer, the BGP session is immediately and automatically brought down rather than waiting for the TCP connection to fail or for the hold timer to expire.
bgp fast-external-fallover
BGP uses a keepalive timer to control the interval at which keepalive messages are sent. A hold-time timer controls how long BGP waits for a keepalive message before declaring a peer not available.
BGP negotiates the hold time with each neighbor when establishing the BGP connection. The peers use the lower of the two configured hold times. BGP sets the keepalive timer based on this negotiated hold time and the configured keepalive time.
neighbor timers
- host1(config-router)#neighbor 192.168.21.5
timers 90 240
timers bgp
- host1(config-router)#timers bgp 75 300
To force sessions that are already established to use the new timer values, you must use the clear ip bgp command to perform a hard clear.
By default, all routes redistributed into BGP from an IGP are automatically summarized to their natural network masks.
auto-summary
You can administratively shut down particular BGP neighbors or peer groups without removing their configuration from BGP by using the neighbor shutdown command.
You can also administratively shut down BGP globally by using the bgp shutdown command.
bgp shutdown
- host1(config-router)#bgp shutdown
neighbor shutdown
You can specify how you want BGP to behave when it is running out of memory in an overload condition. You can have BGP either shut itself down or continue running; in the latter case, BGP performance might be altered because of the lack of resources.
overload shutdown
- host1(config-router)#overload shutdown
The following partial outputs show how the BGP state is indicated by the show ip bgp summary command:
host1#show ip bgp summary Local router ID 10.1.0.1, local AS 1 Administrative state is Start Operational state is Overload Shutdown in overload state is disabled Default local preference is 100 ... host1#show ip bgp summary Local router ID 10.1.0.1, local AS 1 Administrative state is Start Operational state is Down due to transition from Overload state Shutdown in overload state is enabled Default local preference is 100 ...
By default, a BGP speaker does not store a copy of each route it sends to a BGP peer in the Adj-RIBs-Out table for that peer. However, you can force BGP to store a copy of routes in the Adj-RIBs-Out table for a particular peer or peer group by enabling that Adj-RIBs-Out table (“ enabling rib-out” ) with the no neighbor rib-out disable command. Alternatively, you can use the no rib-out disable command to affect all BGP peers. The details of route storage vary between peers and peer groups.
For peers, BGP stores a single bit with each route in the table to indicate whether it has previously advertised the route to the peer, enabling the avoidance of spurious withdrawals. The full set of attributes for each route is not stored in the peer Adj-RIBs-Out table.
After enabling rib-out for a peer, you can issue the show ip bgp neighbors advertised-routes command to display the routes that have been advertised to the peer. The attributes displayed for the routes are those from the local routing table, not those that were advertised. In other words, BGP stores the attributes prior to the application of any outbound policy.
For peer groups, BGP stores the full set of attributes associated with the route after the application of any outbound policy; that is, it stores the attributes as they will be advertised. BGP does not store a bit to track whether a route was advertised to the peer group. Storing the full attribute set for each peer group route is memory intensive but acceptable for peer groups, because the number of peer groups is relatively small. An advantage of enabling rib-out for peer groups is that convergence is accelerated because the attributes for each route are already determined for all routes to be advertised to the peer group. BGP has to apply outbound policy only once for each route rather than once for each peer for each route.
After enabling rib-out for a peer group, you can issue the show ip bgp advertised-routes command to display the routes that will be advertised to the peer group and the attributes (after the application of any outbound policy) that will be advertised with the routes.
When you have enabled rib-out for individual peers or a peer group, before sending an advertisement or withdrawal the router compares the route it is about to send with the last route sent for the same prefix (and stored in the Adj-RIBs-Out table for the peer or peer group) and sends the update message only if the new information is different from the old.
The comparison prevents the sending of unnecessary withdrawals for both peers and peer groups, because the BGP speaker will not send a withdrawal if the table indicates it has not previously advertised that route to the peer. However, because the route attributes are no longer stored with the routes in peer Adj-RIBs-Out tables, BGP cannot compare them with the attributes in the new update message. Consequently, BGP cannot determine whether the update contains new attributes or the same attributes as those previously advertised, and might send superfluous advertisements to peers. This circumstance does not happen for peer groups, because their Adj-RIBs-Out tables store the full attribute set.
After you change the outbound policy for a peer or peer group, the policy changes do not take effect until you issue either a hard clear or an outbound soft clear. (See Resetting a BGP Connection for information about performing clears with the clear ip bgp command.) The clear action causes BGP to reapply the outbound policy of the peer or peer group to each route in the BGP routing table. BGP then stores the results in the Adj-RIBs-Out table for that peer or peer group. The BGP session with each peer or peer group member takes the routes from the appropriate Adj-RIBs-Out table and sends them in update messages to the peer or peer group member.
 |
Note: You cannot change outbound policy for an individual peer group member. You can change outbound policy only for a peer group as a whole or for peers that are not members of a peer group. |
neighbor rib-out disable
- host1(config-router)#no neighbor 10.15.24.5
rib-out disable
rib-out disable
- host1(config)#rib-out disable
The BGP multiprotocol extensions specify that BGP can exchange information within different types of address families. The JUNOSe BGP implementation defines the following different types of address families:
Any command issued outside the context of an address family applies to the unicast IPv4 address family by default.
To limit the exchange of routes to those from within the address family and to set other desired BGP parameters:
- host1(config)#router bgp 100
- host1(config-router)#neighbor 10.10.2.2 remote-as
100
- host1(config-router)#neighbor 10.10.3.3 remote-as
100
- host1(config-router)#neighbor ibgp peer-group
- host1(config-router)#address-family vpn4 unicast
- host1(config-router-af)#neighbor ibgp activate
- host1(config-router-af)#neighbor 10.10.2.2
peer-group ibgp
- host1(config-router-af)#neighbor 10.10.3.3
peer-group ibgp
- host1:vr1(config-router-af)#exit-address-family
address-family
- host1:vr1(config-router)#address-family ipv4
multicast
- host1:vr1(config-router)#address-family ipv4
unicast
- host1:vr1(config-router)#address-family ipv4
unicast vrf vr2
- host1:vr1(config-router)#address-family vpn4
unicast
- host1:vr1(config-router)#address-family ipv6
unicast
bgp default ipv4-unicast
- host1:vr1(config-router)#bgp default ipv4-unicast
exit-address-family
- host1:vr1(config-router-af)#exit-address-family
neighbor activate
If dynamic capability negotiation was negotiated with the peer, BGP sends a capability message to the peer to advertise or withdraw the multiprotocol capability for the address family in which this command is issued. If a neighbor is activated, BGP also sends the full contents of the BGP routing table of the newly activated address family.
- host1:vr1(config-router-af)#neighbor 192.168.1.158
activate
If you have configured some or all neighbors to be in the multicast or VPN-IPv4 address families, you can quickly configure all neighbors to be part of the IPv4 unicast address family by issuing the bgp default ipv4-unicast command.
You can use the neighbor lenient command to enable the BGP speaker to attempt to recover from malformed packet errors and finite state machine errors generated by a peer. If BGP can recover from the error, it logs a warning message and attempts to maintain the session with the peer. The normal, nonlenient behavior is for the BGP speaker to send a notification message to the peer generating the error and to terminate the session. By default, lenient behavior is disabled.
neighbor lenient
- host1(router-config)#neighbor 10.12.45.23
lenient
You can use the neighbor allow command to enable a peer group to accept incoming BGP connections from any remote address that matches an access list. Such a peer group is known as a promiscuous peer group; the member peers are sometimes referred to as promiscuous peers.
Promiscuous peers are useful when the remote address of the peer is not known ahead of time. An example is in B-RAS applications, in which interfaces for subscribers are created dynamically and the remote address of the subscriber is assigned dynamically from a local pool or by using RADIUS or some other method.
BGP automatically creates a dynamic peer when a peer group member accepts the incoming BGP connection. Dynamic peers are passive, meaning that when they are not in the established state, they will accept inbound connections but they will not initiate outbound connections. You cannot configure any attributes for the dynamic peers. You cannot remove a dynamic peer with the no neighbor ip-address command.
When a dynamic peer goes from the established state to the idle state for any reason, BGP removes the dynamic peer only if it does not go back to the established state within 1 minute. This delay enables you to see the dynamic peer in show command output; for example, you might want to see the reason for the last reset or how many times the session flapped.
While a dynamic peer is not in the established state, the show ip bgp neighbor command displays the number of seconds remaining until the dynamic peer will be removed.
If you have configured the neighbor allow command for multiple peer groups, when an incoming BGP connection matches the access list of more than one of these peer groups, the dynamic peer is created only in the first peer group. (BGP orders peer groups alphabetically by name.)
When the BGP speaker receives an open message from a dynamic peer, the remote AS number must match one of the following criteria; the connection is closed if it does not:
If a peer group has been configured with a peer type but not a remote AS, then the remote AS for dynamic peers is not known until an open message has been received from the peer. Until then, show commands display the remote AS as “ ?” or “ unknown.”
Static peers that you configure with the neighbor remote-as or neighbor peer-group commands take precedence over the dynamic peers created as a result of the neighbor allow command. If the remote address of an incoming BGP connection matches both a static peer and the access list, the static peer is used and no dynamic peer is created. If you configure a new static peer while a dynamic peer for the same remote address already exists, BGP automatically removes the dynamic peer.
You can optionally specify the maximum number of dynamic peers that BGP can create for the peer group. There is no default maximum. In the absence of a specified maximum, the number of dynamic peers allowed is determined by the available memory and CPU. Dynamic peers consume about the same resources as static peers.
When the maximum number of dynamic peers has been created for a peer group, BGP rejects all subsequent connection attempts for that group. This behavior means that you can specify a maximum to help protect against denial-of-service attacks that attempt to create many dynamic peers to overwhelm your router resources.
BGP generates a log message whenever a dynamic peer is created, rejected because the maximum has been reached, or removed. BGP maintains counters for each peer group for the current number of dynamic peers, the highest number of concurrent dynamic peers ever reached, and the number of times a dynamic peer was rejected because the maximum was reached.
Because dynamic peers always fully inherit their configuration from a peer group, any features that are available for peers but not for peer group members are not supported for the dynamic peers. Currently, only ORFs are not supported for peer group members and therefore are not supported for dynamic peers.
clear bgp ipv6 dynamic-peers
clear ip bgp dynamic-peers
- host1#clear ip bgp 192.168.1.158 vrf boston5
dynamic-peers
neighbor allow
- host1(config-router)#neighbor promispeers
allow remotelist1 max-peers 1023
You can configure BGP to be passive regarding specific peers, meaning that the BGP speaker will accept inbound BGP connections from the peers but will never initiate an outbound BGP connection to the peers. This passive status conserves CPU and TCP connection resources when the neighbor does not exist.
For example, suppose you preprovision a router before installation with a large number of customer circuits to minimize the configuration changes you might have to make to the router. Any peers that do not exist will consume resources as BGP repeatedly attempts to establish a session with them.
If instead you initially configure the router as passive for those peers, BGP will not attempt to establish sessions to those peers but will wait until these remote peers initiate a session, thus conserving CPU resources.
If you configure both sides of a BGP session as passive, then the session can never come up because neither side can initiate the connection.
neighbor passive
- host1(config-router)#neighbor 10.12.3.5 passive
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |