BGP

In This Chapter

This chapter provides information on configuring BGP.

Topics in this chapter include:

  1. BGP Overview
  2. Group Configuration and Peers
  3. BGP Route Tunnels
  4. Command Interactions and Dependencies
  5. BGP Configuration Process Overview
  6. Configuration Notes
  7. Configuring BGP with CLI
  8. BGP Command Reference

BGP Overview

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 peer(s) can be enabled among groups of routes to enforce administrative preferences and routing policy decisions.

BGP Communication

There are two types of BGP peers: internal BGP (IBGP) peers and external BGP (EBGP) peers (see Figure 10).

  1. Within an AS, IBGP is used to communicate with peers.
  2. Between ASs, EBGP is used to communicate with peers. Routes received from a router in a different AS can be advertised to both EBGP and IBGP peers.
  3. The 7705 SAR supports EBGP within the router context and VPRN context. For information on configuring EBGP within the VPRN context, refer to the 7705 SAR OS Services Guide, “VPRN Services”. IBGP is supported within a router context but not within a VPRN context.

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.

Figure 10:  BGP Configuration 

Message Types

Four message types are used by BGP to negotiate parameters, exchange routing information and indicate errors. They are:

  1. Open message — after a transport protocol connection is established, the first message sent by each side is an Open message. If the Open message is acceptable, a Keepalive message confirming the Open message is sent back. Once the Open message is confirmed, Update, Keepalive, and Notification messages can be exchanged.
    Open messages consist of the BGP header and the following fields:
    1. version — the current BGP version number is 4
    2. local AS number — the autonomous system number is configured in the config>router context
    3. hold time — the maximum time BGP will wait between successive messages (either Keepalive or Update) from its peer, before closing the connection. Configure the local hold time within the config>router>bgp context.
    4. BGP identifier — IP address of the BGP domain or the router ID. The router ID must be a valid host address.
  2. Update message — Update messages are used to transfer routing information between BGP peers. The information contained in the packet can be used to construct a graph describing the relationships of the various autonomous systems. By applying rules, routing information loops and some other anomalies can be detected and removed from the inter-AS routing.
    The Update messages consist of a BGP header and the following optional fields:
    1. unfeasible routes length — the length of the field that lists the routes being withdrawn from service because they are considered unreachable
    2. withdrawn routes — the associated IP address prefixes for the routes withdrawn from service
    3. total path attribute length — the total length of the path field that provides the attributes for a possible route to a destination
    4. path attributes — the path attributes presented in variable-length TLV format
    5. network layer reachability information (NLRI) — IP address prefixes of reachability information
  3. Keepalive message — Keepalive messages, consisting of only a 19-octet message header, are exchanged between peers frequently so hold timers do not expire. The Keepalive messages determine if a link is unavailable.
  4. Notification message — A Notification message is sent when an error condition is detected. The peering session is terminated and the BGP connection (TCP connection) is closed immediately after sending it.

BGP Add-Path

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.

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 11.

Figure 11:  BGP Update Message with Path Identifier for IPv4 NLRI 

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:

  1. IPv4 (including labeled IPv4 routes)
  2. VPN-IPv4

Path Selection Mode and Parameters for Multiple Paths to Add-path Peers

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.

Routing Policy for Multiple Paths

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.

BGP Route Advertisement Rules for Multiple Paths

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.

Group Configuration and Peers

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.

Hierarchical Levels

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:

  1. global level
  2. group level
  3. neighbor level

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.

Route Reflection

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 reflector(s) 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 12 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.

Figure 12:  Fully Meshed BGP Configuration 

When route reflectors are configured, the routers within a cluster do not need to be fully meshed. Figure 12 depicts a fully meshed network and Figure 13 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 13, 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.

Figure 13:  BGP Configuration with Route Reflectors 

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

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.

Sending of BGP Communities

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.

Route Selection Criteria

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.

  1. Routes are not considered if they are unreachable.
  2. An RTM’s preference is lowered as well as the hierarchy of routes from a different protocol. The lower the preference, the higher the chance of the route being the active route.
  3. Routes with higher local preference have preference.
  4. Routes with the shorter AS path have preference.
  5. Routes with the lower origin have preference: IGP = 0, EGP = 1, INCOMPLETE = 2.
  6. Routes with the lowest Multi-Exit Discriminator (MED) metric have preference. Routes with no MED value are exempted from this step unless always-compare-med is configured.
  7. Routes learned from an EBGP peer rather than those learned from an IBGP peer are preferred.
  8. Routes with the lowest IGP cost to the next-hop path attribute are preferred.
  9. Routes with the lowest BGP-ID are preferred.
  10. Routes with shortest cluster list are preferred.
  11. Routes with lowest next-hop IP address are preferred.

BGP Route Tunnels

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.

Route Reflector Next-Hop-Self for VPN IPv4 Routes over IPv4 Labeled Routes

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 14):

  1. a route reflector (RR1), acting as an ASBR in AS 65001, receives VPN IPv4 routes from PE1 over a BGP-labeled tunnel
  2. a route reflector (RR2), acting as an ASBR in AS 65002, receives VPN IPv4 routes from PE2 over a BGP-labeled tunnel
  3. the enable-rr-vpn-forwarding command is enabled on RR1, which allows it to distribute VPN IPv4 routes
  4. the next-hop-self command is enabled on both RR1 and RR2
  5. RR1 has an IBGP session established with RR2. To establish the IBGP session, RR1 must have a local-AS value configured as AS 65002.

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.

Figure 14:  Route Reflector Next-Hop-Self for VPN IPv4 Routes over IPv4 Labeled Routes 

ECMP and BGP Route Tunnels

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”.

Layer 2 Services and BGP Route Tunnel

An MPLS transport tunnel per VPLS/VLL instance is enabled by an explicit MPLS-SDP configuration for each far-end PE.

BGP Route Tunnel SDP Binding

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)”.

BGP Route Tunnel With Multihop EBGP Resolution

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.

Command Interactions and Dependencies

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:

  1. Changing the Autonomous System Number
  2. Changing the Local AS Number
  3. Changing the Router ID at the Configuration Level
  4. Hold Time and Keepalive Timer Dependencies
  5. Import and Export Route Policies
  6. AS Override
  7. TTL Security

Note that this information can be found in the BGP Command Reference, which provides detailed descriptions of the configuration commands.

Changing the Autonomous System Number

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 Number

Changing the local AS of an active BGP instance:

  1. at the global level — causes the BGP instance to restart with the new local AS number
  2. at the group level — causes BGP to re-establish the peer relationships with all peers in the group with the new local AS number
  3. at the neighbor level — causes BGP to re-establish the peer relationship with the new local AS number

Changing the Router ID at the Configuration Level

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.

Hold Time and Keepalive Timer Dependencies

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:

  1. global level — applies to all peers
  2. group level — applies to all peers in the group
  3. neighbor level — only applies to the specified peer

Although the keepalive time can be user-specified, the configured keepalive timer is overridden by the value of hold time under the following circumstances.

  1. If the hold time specified is less than the configured keepalive time, then the operational keepalive time is set to one third of the specified hold time; the configured keepalive time is unchanged.
  2. If the hold time is set to zero, then the operational value of the keepalive time is set to zero; the configured keepalive time is unchanged. This means that the connection with the peer will be up permanently and no keepalive packets are sent to the peer.

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 Policies

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.

AS Override

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.

TTL Security

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.

BGP Configuration Process Overview

Figure 15 displays the process to provision basic BGP parameters.

Figure 15:  BGP Configuration and Implementation Flow 

Configuration Notes

This section describes BGP configuration caveats.

General

  1. Before BGP can be configured, the router ID (a valid host address, not the MAC address default) and autonomous system global parameters must be configured.
  2. BGP instances must be explicitly created on each BGP peer. There are no default BGP instances on a 7705 SAR.

BGP Defaults

The following list summarizes the BGP configuration defaults.

  1. By default, the 7705 SAR is not assigned to an AS.
  2. A BGP instance is created in the administratively enabled state.
  3. A BGP group is created in the administratively enabled state.
  4. A BGP neighbor is created in the administratively enabled state.
  5. No BGP router ID is specified. If no BGP router ID is specified, BGP uses the router system interface address.
  6. The 7705 SAR OS BGP timer defaults are the values recommended in IETF drafts and RFCs (see BGP MIB Notes).
  7. If no import route policy statements are specified, then all BGP routes are accepted.
  8. If no export route policy statements specified, then all BGP routes are advertised and non-BGP routes are not advertised.

BGP MIB Notes

The 7705 SAR OS implementation of the RFC 1657 MIB variables listed in Table 52 differs from the IETF MIB specification.

Table 52:  7705 SAR OS and IETF MIB Variations  

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 53, there are three possible results:

Table 53:  MIB Variable with SNMP  

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 52 and Table 53, 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