This chapter provides information on configuring BGP.
Topics in this chapter include:
Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol. An autonomous system (AS) is a network or a group of routers logically organized and controlled by a common network administration. BGP enables routers to exchange network reachability information, including information about other ASs that traffic must traverse to reach other routers in other ASs. In order to implement BGP, the AS number must be specified in the config>router context. A 7705 SAR OS BGP configuration must contain at least one group (a collection of related BGP peers) and include information about at least one neighbor (peer).
AS paths are the routes to each destination. Other attributes, such as the path’s origin, the system’s route preference, aggregation, route reflection, and communities included in the AS path are called path attributes. When BGP interprets routing and topology information, loops can be detected and eliminated. Route preference for routes learned from the configured peers can be enabled among groups of routes to enforce administrative preferences and routing policy decisions.
This section contains information on the following topics:
There are two types of BGP peers: internal BGP (IBGP) peers and external BGP (EBGP) peers (see Figure 16).
Autonomous systems use BGP to share routing information — such as routes to each destination and information about the route or AS path — with other ASs. Routing tables contain lists of known routers, reachable addresses, and associated path cost metrics to each router. BGP uses the information and path attributes to compile a network topology.
Four message types are used by BGP to negotiate parameters, exchange routing information and indicate errors. They are:
Add-paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. BGP add-paths provides a number of potential benefits, including reduced routing churn, faster convergence, and better load sharing. Refer to draft-ietf-idr-add-paths-04.txt, Advertisement of Multiple Paths in BGP for details of the add-paths capabilities advertisement.
This section also contains information on the following topics:
In order for router A to receive multiple paths per NLRI from peer B for a particular address family, they must advertise their BGP capabilities during session setup. Peer router B advertises that it wants to send multiple paths for an address family and router A indicates that it is able to receive multiple paths for the address family.
When the add-paths receive capability for an address family has been negotiated with a peer router, all advertisements and withdrawals of NLRI within that address family by that peer will include a path identifier. Path identifiers have no significance to the receiving peer. If the combination of NLRI and path identifier in an advertisement from a peer is unique and does not match an existing route in the RIB-IN from that peer, then the route is added to the RIB-IN. If the combination of NLRI and path identifier in a received advertisement is the same as an existing route in the RIB-IN from the peer, then the new route replaces the existing one. If the combination of NLRI and path identifier in a received withdrawal matches an existing route in the RIB-IN from the peer, then that route is removed from the RIB-IN. An UPDATE message carrying an IPv4 NLRI with a path identifier is shown in Figure 17.
Add-paths are only supported on the base router BGP instance and the EBGP and IBGP sessions it forms with other add-path-capable peers. The ability to send and receive multiple paths per prefix to and from an add-paths peer is configurable per family. The following families support BGP add-path:
The RIB-IN may have multiple paths for a prefix (for example, prefix D). The path selection mode refers to the algorithm used to decide which of these paths to advertise to an add-paths peer. In the current implementation, the 7705 SAR supports only one path selection algorithm, the Add-N algorithm described in draft-ietf-idr-add-paths-guidelines-00.txt, Best Practices for Advertisement of Multiple Paths in BGP. The Add-N algorithm selects the N best overall paths for each prefix, regardless of path type (internal vs. external), degree of difference between the paths or use in forwarding. If this set of N best overall paths includes multiple paths with the same BGP NEXT_HOP, only the best route with a particular NEXT_HOP is advertised and the others are suppressed.
In the 7705 SAR implementation, N is configurable, per address-family, at the BGP global, group and neighbor levels; N has a minimum value of 1 and a maximum value of 16. For a peer belonging to a group, the path selection parameters are first based on the neighbor configuration for the peer, then the group configuration, then the BGP global configuration.
When add-path is enabled for the VPN-IPv4 address family in the base router BGP context, only VPN-IP routes in the base router BGP RIB-IN are considered for advertisement to add-path peers. If a VPRN best route to a destination is a BGP-VPN route imported from the base router and its next-best route is a CE-learned BGP route that would be accepted by the VPRN VRF export policy, this next-best route is not advertised, regardless of the base router’s add-Path configuration.
BGP and VRF export policies are applied after path selection is performed. If add-paths is configured to send up to N paths to a peer and an export policy prevents some number (X) of the N best paths for prefix D from being advertised to the peer, then only the remaining (N minus X) best paths are sent.
Add-paths allows non-best paths to be advertised to a peer, but it still complies with basic BGP advertisement rules such as the IBGP split horizon rule: a route learned from an IBGP neighbor cannot be readvertised to another IBGP neighbor unless the router is configured as a route reflector.
If add-paths is configured to send up to N paths to a peer and some number (X) of the N best paths for D cannot be advertised to the peer due to route advertisement rules, then only the remaining (N minus X) routes are advertised.
Split horizon refers to the action taken by a router to avoid advertising a route back to the peer from which it was received or to another non-client peer for IBGP. By default, the 7705 SAR applies split-horizon behavior only to routes received from IBGP non-client peers. This split-horizon functionality, which cannot be disabled, prevents routing loops by disabling the advertisement of routes learned from a non-client IBGP peer back to the sending peer or any other non-client peer.
To apply split-horizon behavior to routes learned from RR clients, peers or EBGP peers, the split-horizon command must be configured in the appropriate contexts; it is supported at the global BGP, group and neighbor levels. When split horizon is enabled on these types of sessions, it only prevents the advertisement of a route back to its originating peer; for example, the 7705 SAR does not prevent the advertisement of a route learned from one EBGP peer back to a different EBGP peer in the same neighbor AS.
ORF is a mechanism that allows one router, the ORF-sending router, to signal to a peer, the ORF-receiving router, a set of route filtering rules (ORF entries) that the ORF-receiving router should apply to its route advertisements towards the ORF-sending router. The ORF entries are encoded in Route Refresh messages.
The use of ORF for a session must be negotiated — both routers must advertise the ORF capability in their Open messages. The ORF capability describes the address families that support ORF, and for each address family, the ORF types that are supported and the ability to send/receive each type. The 7705 SAR supports ORF type 3, ORF based on extended communities, for the following address families:
The send and receive capability for ORF is configurable with the send-orf and accept-orf commands, and the setting applies to all supported address families.
ORF type 3 allows a PE router that imports VPN routes with a particular set of route target extended communities to indicate to a peer (for example a route reflector) that it only wants to receive VPN routes that contain one or more of these extended communities. To inform a peer to add or remove a route target extended community, the PE router sends a Route Refresh message to the peer containing an ORF type 3 entry that instructs the peer to either add or remove a permit entry for the 8-byte extended community value.
The type 3 ORF entries that are sent to a peer can be generated dynamically (if no route target extended communities are specified with the send-orf command) or specified statically. Dynamically generated ORF entries are based on the route targets that are imported by all locally configured VPRNs.
A router that has installed ORF entries received from a peer can still apply BGP export policies to the session. BGP export policies overrule ORF entries. If the evaluation of a BGP export policy results in a reject action for a VPN route that matches a permit ORF entry, the route is not advertised.
ORF filtering is efficient; a large number of VPN routes can be filtered faster than using a conventional BGP export policy. In addition to ORF, users can also use BGP Route Target Constrained Route Distribution for dynamic filtering based on route target extended communities. RTC, as discussed below, offers some advantages over ORF.
BGP route target constrained route distribution allows a router to advertise a route target constraint (RTC) route to its peers. A peer receiving an RTC route does not advertise VPN routes back to the router unless they contain a route target extended community that matches one of the received RTC routes. For detailed information on RTC, refer to the 7705 SAR OS Services Guide, “Route Target Constraint”.
RTC routes are carried using MP-BGP with an AFI value of 1 and SAFI value of 132. The NLRI of an RTC route encodes an Origin AS and a route target extended community using prefix-type encoding with the host bits after the prefix length set to zero.
In order for two routers to exchange route target membership NLRI, they must advertise the corresponding AFI and SAFI to each other during capability negotiation. The use of MP-BGP means route target membership NLRI are propagated, loop-free, within an autonomous system and between autonomous systems, using well-known BGP route selection and advertisement rules.
If there are multiple RTC routes for the same NLRI, the BGP decision process selects one as the best path. The propagation of the best path installs RIB-Out filter rules as it travels from one router to the next, which creates an optimal VPN route distribution tree rooted at the source of the RTC route.
Route target constrained route distribution and outbound route filtering (ORF) both allow routers to advertise which route target extended communities they want to receive in VPN routes from peers. RTC, however, is more widely supported, is simpler to configure, and its distribution scope is not limited to a direct peer.
ORF and RTC are mutually exclusive for a particular BGP session. The CLI does not attempt to block the configuration of both ORF and RTC, but if both capabilities are enabled for a session, the ORF capability will not be included in the OPEN message sent to the peer.
The capability to exchange RTC routes is advertised when the route-target keyword is added to the family command. RTC is supported for EBGP and IBGP sessions on the base router instance.
When RTC has been negotiated with one or more peers, the 7705 SAR automatically originates and advertises to these peers one RTC route with a prefix length of 96 (the origin AS and route target extended community are fully specified) for every route target imported by a locally configured VPRN or BGP-based Layer 2 VPN, including MVPN-specific route targets.
A router may be configured to send the default RTC route to a group or neighbor with the default-route-target CLI command. This causes the router to generate and send a special RTC route with a prefix length of 0:0:0/0. Sending the default RTC route to a peer conveys a request to receive all VPN routes from that peer. The default RTC route is typically advertised by a route reflector to PE clients. Advertising the default RTC route to a peer does not suppress other more specific RTC routes from being sent to that peer. A received default RTC route is never propagated to other routers.
The advertisement of RTC routes by a route reflector follows special rules as described in RFC 4684. These rules are needed to ensure that RTC routes for the same NLRI that are originated by different PE routers in the same AS are properly distributed within the AS.
When a BGP session comes up and RTC is enabled for the session (both peers advertised the MP-BGP capability), routers delay sending any VPN-IPv4 and VPN-IPv6 routes until either the session has been up for 60 s or the end-of-RIB marker is received for the RTC address family. When the VPN-IPv4 and VPN-IPv6 routes are sent, they are filtered to include only those with a route target extended community that matches an RTC route from the peer.
VPN-IP routes matching an RTC route originated in the local AS are advertised to any IBGP peer that advertises a valid path for the RTC NLRI. Route distribution is not limited only to the IBGP peer advertising the best path. VPN-IP routes matching an RTC route that originated outside the local AS are only advertised to the EBGP or IBGP peer that advertises the best path.
The 7705 SAR does not support an equivalent of BGP Multipath for RTC routes. There is no way to distribute VPN routes across more than one set of inter-AS paths that are nearly equal.
Received RTC routes have no effect on the advertisement on MVPN-IPv4 routes.
To enable BGP routing, participating routers must have BGP enabled and be assigned to an autonomous system, and the neighbor (peer) relationships must be specified. A router can belong to only one AS. TCP connections must be established in order for neighbors to exchange routing information and updates. Neighbors exchange BGP Open messages that include information such as AS numbers, BGP versions, router IDs, and hold-time values. Keepalive messages determine if a connection is established and operational. The hold-time value specifies the maximum time BGP will wait between successive messages (either Keepalive or Update) from its peer, before closing the connection.
In BGP, peers are arranged into groups. A group must contain at least one neighbor. A neighbor must belong to a group. Groups allow multiple peers to share similar configuration attributes.
Although neighbors do not have to belong to the same AS, they must be able to communicate with each other. If TCP connections are not established between two neighbors, the BGP peering session will not be established and updates will not be exchanged.
Peer relationships are defined by configuring the IP address of the routers that are peers of the local BGP domain. When neighbor and peer relationships are configured, the BGP peers exchange Update messages to advertise network reachability information.
BGP parameters are initially applied at the global level. These parameters are inherited by the group and neighbor (peer) levels. Parameters can be modified and overridden on a level-specific basis. BGP command hierarchy consists of three levels:
Many of the hierarchical BGP commands can be modified at different levels. The most specific value is used. That is, a BGP group-specific command takes precedence over a global BGP command. A neighbor-specific command takes precedence over a global BGP and group-specific command; for example, if you modify a BGP neighbor-level command default, the new value takes precedence over group- and global-level settings.
Caution: Take care how you use command settings at a lower level that can disable features at a higher level. For example, if the damping command is used to enable damping at the global level and you want it disabled only for a specified neighbor, use the no damping command at the neighbor level only; do not use it the global level also, since this will disable damping for all neighbors within the BGP global instance. |
In a standard BGP configuration, all BGP speakers within an AS must have full BGP mesh to ensure that all externally learned routes are redistributed through the entire AS. IBGP speakers do not readvertise routes learned from one IBGP peer to another IBGP peer. If a network grows, scaling issues could emerge because of the full mesh configuration requirement. Instead of peering with all other IBGP routers in the network, each IBGP router only peers with a router configured as a route reflector.
Route reflection circumvents the full mesh requirement but maintains the full distribution of external routing information within an AS. Route reflection is effective in large networks because it is manageable, scalable, and easy to implement. Route reflection is implemented in autonomous systems with a large internal BGP mesh in order to reduce the number of IBGP sessions required within an AS.
A large AS can be subdivided into smaller ASs, called clusters. Each cluster contains at least one route reflector, which is responsible for redistributing route updates to all clients. Route reflector clients do not need to maintain a full peering mesh between each other. They only require a peering to the route reflectors in their cluster. The route reflectors must maintain a full peering mesh between all non-clients within the AS.
Each route reflector must be assigned a cluster ID and specify which neighbors are clients and which are non-clients to determine which neighbors should receive reflected routes and which should be treated as a standard IBGP peer. Additional configuration is not required for the route reflector, aside from the typical BGP neighbor parameters.
BGP speakers within the AS that are not peers with the route reflector are called non-clients. Non-clients are peers to a route reflector but do not understand the route reflector attributes. Several BGP-speaking routers can peer with a route reflector. A route reflector forms peer connections to other route reflectors.
Figure 18 displays a simple configuration with several IBGP 7705 SAR nodes.
When SR-A receives a route from SR-1 (an external neighbor), it must advertise route information to SAR-01, SAR-02, SAR-03, SAR-04, and SAR-05. To prevent loops, IBGP learned routes are not readvertised to other IBGP peers.
When route reflectors are configured, the routers within a cluster do not need to be fully meshed. Figure 18 depicts a fully meshed network and Figure 19 depicts the same network but with route reflectors configured to minimize the IBGP mesh between SR-A, SAR-01, SAR-02, and SAR-03. SR-A, configured as the route reflector, is responsible for redistributing route updates to clients SAR-01, SAR-02, and SAR-03. IBGP peering between SAR-01, SAR-02 and SAR-03 is not necessary because even IBGP learned routes are reflected to the route reflector’s clients.
In Figure 19, SAR-04 and SAR-05 are shown as non-clients of the route reflector. As a result, a full mesh of IBGP peerings must be maintained between SR-A, SAR-04, and SAR-05.
BGP speakers within an AS that are not configured as reflectors are considered to be client peers. Non-client peers are other routers in the AS. A route reflector enables communication between the clients and non-client peers. Route reflector-to-client peer configurations do not need to be fully meshed, but non-client peers need to be fully meshed within an AS.
A grouping, called a cluster, is composed of a route reflector and its client peers. A cluster ID identifies the grouping unless specific BGP peerings are configured. A cluster’s clients do not share information messages with other peers outside the cluster. Multiple route reflectors can be configured within a cluster for redundancy. A router assumes the role as a route reflector by configuring the cluster cluster-id command. No other command is required unless you want to disable reflection to specific clients.
When a route reflector receives an advertised route, depending on the sender and neighbors (peers), it selects the best path. Routes received from an EBGP peer are advertised unmodified (to retain next-hop information) to all clients and non-client peers in the AS. Routes received from a non-client peer are advertised to all clients in the AS. Routes received from a client are advertised to all clients and non-client peers.
Fast external failover on a group and neighbor basis is supported. For EBGP neighbors, fast external failover controls whether the router drops an EBGP session immediately upon an interface-down event, or whether the BGP session is kept up until the hold-time expires.
When fast external failover is disabled, the EBGP session stays up until the hold-time expires or the interface comes back up again. If the BGP routes become unreachable as a result of the interface going down, they are immediately withdrawn from other peers.
BGP Fast Reroute (FRR) creates an alternate path to support fast rerouting of BGP traffic around failed or unreachable next hops. When BGP FRR is enabled, the system switches to a precalculated alternate path as soon as a failure is detected.
BGP Prefix-Independent Convergence (PIC) is supported on the 7705 SAR and is automatically enabled when a BGP backup path is enabled. With BGP FRR and PIC, alternate paths are precalculated and the FIB is updated with all alternate next hops. When a prefix has a backup path, and its primary paths fail, the affected traffic is rapidly diverted to the backup path without waiting for control plane reconvergence to occur. When many prefixes share the same primary paths, and in some cases also share the same backup path, the time to switch traffic to the backup path can be very fast and is independent of the number of prefixes.
BGP FRR can be enabled in the BGP context or in the VPRN context. For information about BGP FRR for VPRNs, refer to the 7705 SAR OS Services Guide, “BGP Fast Reroute with Prefix-Independent Convergence in a VPRN”.
Note:
|
When BGP FRR is enabled, the control plane attempts to find an eligible backup path for every received IPv4 or IPv6 prefix. In most cases, the backup path is the single best path remaining after the 7705 SAR removes the primary ECMP paths and any paths with the same BGP next hops.
The following scenarios affect backup path selection.
Table 54 lists the supported BGP FRR scenarios.
Ingress Packet | Primary Route | Backup Route | PIC |
IPv4 (ingress PE) | IPv4 route with next hop A resolved by an IPv4 route | IPv4 route with next hop B resolved by an IPv4 route | Yes |
IPv4 (ingress PE) | VPN-IPv4 route with next hop A resolved by a GRE, LDP, RSVP, or BGP tunnel | VPN-IPv4 route with next hop B resolved by a GRE, LDP, RSVP or BGP tunnel | Yes |
IPv6 (ingress PE) | VPN-IPv6 route with next hop A resolved by a GRE, LDP, RSVP, or BGP tunnel | VPN-IPv6 route with next hop B resolved by a GRE, LDP, RSVP, or BGP tunnel | Yes |
MPLS (egress PE) | IPv4 route with next hop A resolved by an IPv4 route | IPv4 route with next hop B resolved by an IPv4 route | Yes |
MPLS (egress PE) | IPv4 route with next hop A resolved by an IPv4 route | VPN-IPv4 route with next hop B resolved by a GRE, LDP, RSVP or BGP tunnel | Yes |
MPLS (egress PE) | IPv6 route with next hop A resolved by an IPv6 route | VPN-IPv6 route with next hop B resolved by a GRE, LDP, RSVP or BGP tunnel | Yes |
When BGP FRR is enabled, the 7705 SAR reroutes traffic onto a backup path based on input from BGP. When a primary path is no longer usable, BGP notifies the IOM and affected traffic is immediately switched to the backup path.
BGP FRR is triggered when:
The capability to explicitly enable or disable the sending of the BGP community attribute to BGP neighbors, other than through the use of policy statements, is supported.
This feature allows an administrator to enable or disable the sending of BGP communities to an associated peer. This feature overrides communities that are already associated with a given route or that may have been added via an export route policy. In other words, even if the export policies leave BGP communities attached to a given route, when the disable-communities feature is enabled, no BGP communities are advertised to the associated BGP peers.
For each prefix in the routing table, the routing protocol selects the best path. Then, the best path is compared to the next path in the list until all paths in the list are exhausted. The following parameters are used to determine the best path.
BGP route tunnels can be used to distribute MPLS label mapping information for a particular route, as defined in RFC 3107. When BGP is used to distribute a route, it can also distribute the MPLS label for the same route by piggybacking the label onto the BGP update message.
In a network scenario where two adjacent LSRs are also BGP peers, label distribution can be handled entirely by the BGP update message—no other distribution protocol is required.
In a network scenario where the exterior LSRs are BGP speakers, the LSRs can send MPLS labels to each other along with each route they distribute. The MPLS label is piggybacked onto the BGP update message by using the BGP-4 Multiprotocol Extensions Attribute. The label is encoded in the NLRI field and the SAFI (Subsequent Address Family Identifier) field is used to indicate that the NLRI field contains a label. A labeled route update is only exchanged between BGP speakers supporting AFI/SAFI for MPLS Label Capability.
The 7705 SAR supports IPv4 and VPN-IPv4 address families. The types of routes that are advertised are indicated by the AFI/SAFI advertised. These values are controlled by the family ipv4 and advertise-label ipv4 commands for IPv4 unicast and IPv4 labeled unicast, respectively, and by the family vpn-ipv4 command for VPN IPv4.
BGP speakers that are not adjacent to each other may choose LDP or RSVP-TE tunnels to reach the BGP-labeled route next hop. Client applications using BGP tunnels must push two labels (BGP label and LDP/RSVP-TE label) on top of the existing label stack (which will typically include one or more service-specific labels) in order to reach the BGP next hop. The next-hop BGP node can either resolve its own local LDP or RSVP-TE LSPs to reach its next hop.
If BGP speaker nodes are adjacent to each other (for example, ASBRs running an EBGP session) and have exchanged labeled routes, then only the BGP route label is used to forward traffic toward the next hop. If the BGP route tunnel transits through multiple autonomous systems, then each AS segment would have two labels. For the last BGP segment, ASBR may select to have either one (LDP/RSVP-TE) or two (BGP + LDP/RSVP-TE) labels to reach the far end.
Note: The 7705 SAR does not support the transport of Layer 2 or Layer 3 services via a BGP tunnel resolved by an LDP tunnel if the LDP tunnel goes over RSVP-TE shortcuts. The services may show as operationally up, but no traffic will be forwarded. For information on IGP shortcuts, refer to the 7705 SAR OS MPLS Guide, “IGP Shortcuts (RSVP-TE Tunnels)”. |
As an enhancement to the preceding route distribution scenario, inter-AS option B model-like behavior (as per RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)) can be enabled for route reflectors that exchange PE reachability information using IPv4 address family labeled routes. A route reflector acting as an ASBR that receives VPN IPv4 routes from a client over a BGP-labeled tunnel can use next-hop-self to redistribute the VPN routes to another ASBR by means of an IBGP session for the VPN IPv4 address family.
For example (see Figure 20):
When PE2 advertises a VPN IPv4 route to RR2, the route reflector resolves the route to an MPLS tunnel, changes the next hop to itself, advertises the route to RR1, and performs a label swap between the advertised and received labels. RR1 resolves the route via the IPv4 tunnel to RR2. RR1 then changes the next hop to itself, performs a label swap, prepends the local-AS 65002, and readvertises the VPN IPv4 route to PE1.
ECMP is only available for BGP route tunnels and not the transport LSP that is used to resolve the BGP next hop. If multiple LSP next hops are available, only the first next hop is used and the rest are ignored. This means that only a first-level ECMP from the VRF IP lookup of MP-BGP is performed; the second ECMP against different next hops for the LDP tunnel LSP to the same far-end next hop is skipped. For more information, refer to the 7705 SAR OS OAM and Diagnostics Guide, “LSP Diagnostics”.
An MPLS transport tunnel per VPLS/VLL instance is enabled by an explicit MPLS-SDP configuration for each far-end PE.
BGP route tunnel-based SDP binding is allowed for VPLS and VLL services. Any service using BGP SDP must presume a two-label stack to compute the SDP MTU. For more information about SDPs for BGP route tunnels, refer to the 7705 SAR OS Services Guide, “Service Destination Points (SDPs)”.
Either an RSVP-TE or LDP LSP can be used to resolve the next hop between two ASBR nodes. The transport-tunnel CLI command can be used to select the specific transport LSP method. The mpls option under transport-tunnel enables the option to select either an RSVP-TE LSP or LDP LSP. If the mpls option is selected, an RSVP-TE LSP is considered the higher-priority LSP and its availability is checked first. If an RSVP-TE LSP is not available, then an LDP LSP is selected.
This section highlights the BGP command interactions and dependencies that are important for configuration or operational maintenance of 7705 SAR routers. Topics covered in this section are:
This information can be found in the BGP Command Reference, which provides detailed descriptions of the configuration commands.
If the AS number is changed on a router with an active BGP instance, the new AS number will not be used until the BGP instance is restarted either by administratively disabling or enabling the BGP instance or by rebooting the system with the new configuration.
Note: The 7705 SAR supports 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. This allows up to 4 294 967 295 unique AS numbers. |
Changing the local AS of an active BGP instance:
If you configure a new router ID in the config>router-id context, protocols are not automatically restarted with the new router ID. The next time a protocol is initialized or reinitialized, the new router ID is used. An interim period of time can occur when different protocols use different router IDs.
The BGP hold time specifies the maximum time BGP will wait between successive messages (either Keepalive or Update) from its peer, before closing the connection. This configuration parameter can be set at three levels. The most specific value is used:
Although the keepalive time can be user-specified, the configured keepalive timer is overridden by the value of hold time under the following circumstances.
If the hold time or keepalive values are changed, the changed timer values take effect when the new peering relationship is established. Changing the values causes the peerings to restart. The changed timer values are used when renegotiating the peer relationship.
Import and export route policy statements are specified for BGP at the global, group, and neighbor level. Up to five unique policy statement names can be specified in the command line per level. The most specific command is applied to the peer. Defining the policy statement name is not required before being applied. Policy statements are evaluated in the order in which they are specified within the command context until the first matching policy statement is found.
The import and export policies configured at different levels are not cumulative. The most specific value is used. An import or export policy command specified at the neighbor level takes precedence over the same command specified at the group or global level. An import or export policy command specified at the group level takes precedence over the same command specified at the global level.
BGP-4 Explicit AS Override simplifies the use of the same AS number (ASN) across multiple RFC 2547 VPRN sites.
The Explicit AS Override feature can be used in VPRN scenarios where a customer is running BGP as the PE-CE protocol and some or all of the CE locations are in the same Autonomous System (AS). Without this feature, two sites in the same AS would not be able to reach each other directly since there is an apparent loop in the AS path.
With AS Override enabled on an EBGP session on a PE node, the service provider network can rewrite the AS path — overriding the customer ASN with its own ASN — as routes are advertised to other sites within the same VPRN.
The operation of a network can be compromised if an unauthorized system is able to form or hijack a BGP session and inject control packets by falsely representing itself as a valid neighbor. This risk can be mitigated by enabling TCP MD5 authentication on one or more of the sessions. When TCP MD5 authentication is enabled on a session, every TCP segment exchanged with the peer includes a TCP option (19) containing a 16-byte MD5 digest of the segment (more specifically the TCP/IP pseudo-header, TCP header and TCP data). The MD5 digest is generated and validated using an authentication key that must be known to both sides. If the received digest value is different from the locally computed one, then the TCP segment is dropped, thereby protecting the router from a spoofed TCP segment.
TTL security provides protection for EBGP peering sessions against CPU utilization-based attacks such as denial of service (DoS) attacks. This feature is supported for directly connected peering sessions and for multihop EBGP peering sessions. The BGP session can be over router interfaces, over spoke-SDP terminated VPRN interfaces, SAP interfaces, and loopback interfaces, and over IPSec interface tunnels.
TTL security is most important for EBGP PE-CE sessions because CE devices can be multiple hops away, which adds a higher level of risk. TTL security provides a mechanism to better ensure the validity of BGP sessions from the CE device.
TTL security is configured at the group or neighbor level. The ttl-security command sets the minimum TTL that will be accepted in a BGP peering session and checks the TTL of the packets received. For multihop peering sessions, the multihop command sets the TTL in the IP header of egress BGP packets sent to a terminating peer that is several hops away.
When TTL security is configured, the network processor must inspect BGP packets. The value in the TTL field of received IP packets is compared with the TTL security value that is configured locally for each EBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the configured minimum TTL value, the IP packet is accepted and processed normally. If the TTL value is less than the configured value, the packet is discarded.
This section describes the interaction between the BGP advertise-inactive, add-paths, and export policy commands. The 7705 SAR allows the policy-based export of an active and installed route to a peer when the local router has BGP advertise-inactive enabled in its configuration.
Prior to Release 7.0 of the 7705 SAR, when there are multiple routes to a prefix and a non-BGP route is in the routing table, there could be many inactive BGP routes selected by BGP as the best routes as part of the route selection criteria. For example, assume route A is an active non-BGP route and there are a number (n) of BGP routes (routes B1, B2, B3, ..., up to Bn), where the order of preference is determined by the BGP best-path selection algorithm (see Route Selection Criteria). Then the following cases arise.
In Release 7.0 and later, the following behavior for advertise-inactive occurs when an active, non-BGP route (route A) exists in the routing table and is accepted by the configured BGP export policy.
Figure 21 displays the process to provision basic BGP parameters.
This section describes BGP configuration caveats.
The following list summarizes the BGP configuration defaults.
The 7705 SAR OS implementation of the RFC 1657 MIB variables listed in Table 55 differs from the IETF MIB specification.
MIB Variable | Description | RFC 1657 Allowed Values | 7705 SAR OS Allowed Values |
bgpPeerMinASOrig-intionInterval | Time interval in seconds for the MinASOriginationInterval timer. The suggested value for this timer is 15 s. | 1 to 65535 | 2 to 255 |
bgpPeerMinRouteAd-vertisementInterval | Time interval in seconds for the MinRouteAdvertisementInterval timer. The suggested value for this timer is 30 s. | 1 to 65535 | 2 to 255 |
If SNMP is used to set a value of X to the MIB variable in Table 56, there are three possible results:
Condition | Result |
X is within IETF MIB values and X is within 7705 SAR OS values | SNMP set operation does not return an error MIB variable set to X |
X is within IETF MIB values and X is outside 7705 SAR OS values | SNMP set operation does not return an error MIB variable set to “nearest” 7705 SAR OS supported value (for example, 7705 SAR OS range is 2 to 255 and X = 65535, MIB variable will be set to 255) Log message generated |
X is outside IETF MIB values and X is outside 7705 SAR OS values | SNMP set operation returns an error |
When the value set using SNMP is within the IETF allowed values and outside the 7705 SAR OS values as specified in Table 55 and Table 56, a log message is generated. The log messages that display are similar to the following log messages.
Sample Log Message for setting bgpPeerMinASOriginationInterval to 65535
576 2006/11/12 19:45:48 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinASOrigInt to 65535 - valid range is [2-255] - setting to 255:
Sample Log Message for setting bgpPeerMinASOriginationInterval to 1
594 2006/11/12 19:48:05 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinASOrigInt to 1 - valid range is [2-255] - setting to 2:
Sample Log Message for setting bgpPeerMinRouteAdvertisementInterval to 256
535 2006/11/12 19:40:53 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinRouteAdvInt to 256 - valid range is [2-255] - setting to 255:
Sample Log Message for setting bgpPeerMinRouteAdvertisementInterval to 1
566 2006/11/12 19:44:41 [Snmpd] BGP-4-bgpVariableRangeViolation: Trying to set bgpPeerMinRouteAdvInt to 1 - valid range is [2-255] - setting to 2