6.1.1. BGP Communication

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

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 17:  BGP Configuration 

6.1.2. Message Types

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

6.1.3. BGPv6

The 7705 SAR supports BGPv6 in the GRT (for network and IES interfaces) to provide increased IPv6 connectivity in a PE-CE environment.

Figure 18 shows an example of a network with 7705 SAR nodes on the CE utilizing BGPv6. The 7705 SAR can also be used on the PE.

Figure 18:  BGPv6 

CEs are connected via EBGP or, in some cases, IBGP to edge routers, which then connect the CEs across a core BGP network. A privately owned customer network uses IBGP by default. For backup, a third-party network that uses EBGP for connectivity between edge routers and the backup network is used.

Any failures occurring between PEs and CEs are detected with BFD and BGP PIC and resolved with BGP fast reroute.

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

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

Figure 19:  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:

6.1.5. Outbound Route Filtering (ORF)

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.

6.1.6. BGP Route Target Constrained Route Distribution

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

6.2.1. 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:

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.

6.2.2. 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 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 20 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 20:  Fully Meshed BGP Configuration 

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

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

6.2.4. BGP Fast Reroute With Prefix-Independent Convergence

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 on either IPv4 or IPv6 prefixes. For information about BGP FRR for VPRNs, refer to the 7705 SAR Services Guide, “BGP Fast Reroute with Prefix-Independent Convergence in a VPRN”.

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 65 lists the supported BGP FRR scenarios.

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

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

6.3.1. 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 or VPN IPv6 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 or VPN IPv6 address family.

For example (see Figure 22):

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 22:  Route Reflector Next-Hop-Self for VPN IPv4 Routes over IPv4 Labeled Routes 

6.3.2. 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 OAM and Diagnostics Guide, “LSP Diagnostics”.

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

6.3.4. 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 Services Guide, “Service Destination Points (SDPs)”.

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

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

6.4.2. Changing the Local AS Number

Changing the local AS of an active BGP instance:

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

6.4.4. 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:

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.

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

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

6.4.7. TCP MD5 Authentication

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, the TCP segment is dropped, thereby protecting the router from a spoofed TCP segment.

The TCP Enhanced Authentication Option, as specified in draft-bonica-tcpauth-05.txt, Authentication for TCP-based Routing and Management Protocols, is a TCP extension that enhances security for BGP, LDP, and other TCP-based protocols. It extends the MD5 authentication option to include the ability to change keys in a BGP or LDP session seamlessly without tearing down the session, and allows for stronger authentication algorithms to be used. It is intended for applications where secure administrative access to both endpoints of the TCP connection is normally available.

TCP peers can use this extension to authenticate messages passed between one another. This strategy improves upon the practice described in RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option. Using this new strategy, TCP peers can update authentication keys during the lifetime of a TCP connection. TCP peers can also use stronger authentication algorithms to authenticate routing messages.

TCP enhanced authentication uses keychains that are associated with every protected TCP connection.

Keychains are configured in the config>system>security>keychain context. For more information about configuring keychains, refer to the 7705 SAR System Management Guide, “TCP Enhanced Authentication and Keychain Authentication”.

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

6.4.9. Advertise-Inactive, Add-Paths, and Export Policy Interaction

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.

6.6.1. General

6.6.2. BGP Defaults

The following list summarizes the BGP configuration defaults.

6.6.3. BGP MIB Notes

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

If SNMP is used to set a value of X to the MIB variable in Table 67, there are three possible results:

When the value set using SNMP is within the IETF allowed values and outside the 7705 SAR values as specified in Table 66 and Table 67, a log message is generated. The log messages that display are similar to the following log messages.

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:

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:

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:

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