BGP
| The Border Gateway Protocol (BGP) is an exterior gateway protocol (EGP) that is used to exchange routing information among routers in different autonomous systems (ASs). In BGP, routers are grouped into ASs. Each AS is a set of routers that is under a single technical administration and that normally uses a single interior gateway protocol (IGP) and a common set of metrics to propagate routing information within the set of routers. To other ASs, an AS appears to have a single, coherent interior routing plan and presents a consistent picture of what destinations are reachable through it. BGP is a path -vector routing protocol that is used to exchange routing information among different ASs. BGP routing information includes the complete route to each destination, as well as additional information about the route. The route to each destination is called the AS path, and the additional route information is included in path attributes. BGP uses the AS path and the path attributes to completely determine the network topology. BGP uses the routing information to maintain a database of network reachability information, which it exchanges with other BGP systems. Once BGP understands the topology, it can detect and eliminate routing loops , and it can select among groups of routes to enforce administrative preferences and routing policy decisions. BGP supports two types of exchanges of routing information: exchanges between different ASs and exchanges within a single AS. When used between ASs, BGP is called external BGP (EBGP), and BGP sessions perform inter-AS routing. When used within an AS, BGP is called internal BGP (IBGP), and BGP sessions perform intra-AS routing.
BGP systems are arranged into groups. In an IBGP group, all peers in the group ”called internal peers ”are in the same AS. Internal peers can be anywhere in the local AS and do not have to be directly connected. Internal groups use routes from an IGP to resolve forwarding addresses. They also propagate external routes among all other internal routers running internal BGP, computing the next hop by taking the BGP next hop received with the route and resolving it using information from one of the IGPs. In an EBGP group, the peers in the group ”called external peers ”are in different ASs and normally share a subnet. In an external group, the next hop is computed with respect to the interface that is shared between the external peer and the local router. BGP peers advertise routes to each other in update messages. The routes consist of a destination, described as an IP address prefix, and the AS path to the destination and path attributes. The AS path is a list of numbers of the ASs that a route passed through to reach the local router. The first number in the path is that of the last AS in the path ”the AS closest to the local router. The last number in the path is the AS farthest from the local router, which is generally the origin of the path. Path attributes contain additional information about the AS path that is used in routing policy. BGP stores its routes in the JUNOS routing table, including routing information learned from update messages received from peers, local routing information that the BGP system selects by applying local policies to routes received in update messages, and information that the BGP system selects to advertise to its BGP peers in the update messages it sends. For each prefix in the routing table, the routing protocol process selects a single best path, called the active path. The algorithm for determining the active path is described in "How the Active Route Is Determined," on page 376. Table 9.2 lists the BGP Version 4 standards and protocol extensions supported by the JUNOS software. Table 9.2. BGP Standards Supported by JUNOS Software
BGP MessagesBGP systems send four types of messages: open , update, keepalive, and notification. All BGP messages have the same fixed-size header, which contains a marker field indicating the total length of the message and a type field indicating the message type. Open MessagesAfter a TCP connection is established between two BGP systems, they exchange BGP open messages to create a BGP connection between them. After the connection is established, the two systems can exchange BGP messages and data traffic. Open messages consist of the BGP header plus the following fields:
Update MessagesBGP systems send update messages to exchange network reachability information. BGP systems use this information to construct a graph that describes the relationships among all known ASs. Update messages consist of the BGP header plus the following optional fields:
Keepalive MessagesBGP systems exchange keepalive messages to determine whether a link or host has failed or is no longer available. Keepalive messages are exchanged often enough so that the hold timer does not expire. These messages consist only of the BGP header. Notification MessagesBGP systems send notification messages when an error condition is detected . After the message is sent, the BGP session and the TCP connection between the BGP systems are closed. Notification messages consist of the BGP header plus the error code and subcode, and data that describes the error. Configuring BGPTo configure BGP, include the following statements. To configure a BGP routing instance, include the statement at the [edit routing-instances routing-instance- name routing-options] hierarchy level. For BGP to run on the router, you must define the local AS number, configure at least one group, and include information about at least one peer in the group (the peer's IP address and AS number). protocols { bgp { numerous global BGP statements group group-name { peer-as autonomous-system ; type type ; allow [ prefix / prefix-length ]; numerous group-specific statements neighbor address { numerous peer-specific statements } } } } routing-options { autonomous-system autonomous-system ; confederation confederation-autonomous-system members [ autonomous-systems ]; router-id address ; } When configuring BGP on an interface, you must also include the family inet statement at the [edit interfaces interface- name unit logical-unit-number ] hierarchy level. Each router running BGP must be configured with its AS number in the autonomous-system statement. This number is included in the local AS number field in BGP open messages. To enable the local system to participate as a member of an AS confederation, you define the AS confederation identifier and specify the AS numbers that are members of the confederation in the confederation statement. Each router running BGP must have a BGP identifier. This identifier is included in the BGP identifier field of open messages. You can explicitly assign a BGP identifier in the router-id statement. If you do not assign one, the IP address of the first interface encountered in the router is used. You can configure many BGP properties at the global, group, and peer level (see Table 9.3). Global properties apply to all groups and peers and are configured at the [edit protocols bgp] hierarchy level. Group properties apply to the particular group and its peer, and they override global properties. Configure these properties at the [edit protocols bgp group group-name ] hierarchy level. Peer properties apply to the particular peer, and they override global and group properties. Configure these properties at the [edit protocols bgp group group-name neighbor address ] hierarchy level. Table 9.3. Global-, Group-, and Peer-Level BGP Configuration Statements
Defining BGP Groups and PeersA BGP system must know which routers are its peers (neighbors). You define the peer relationships explicitly by configuring the neighboring routers that are the peers of the local BGP system. After peer relationships have been established, the BGP peers exchange update messages to advertise network reachability information. You arrange BGP routers into groups of peers. Different peer groups must have different group types, AS numbers, or router reflector cluster identifiers. Each group must contain at least one peer. To define a BGP group that recognizes only the specified BGP systems as peers, statically configure all the system's peers by including one or more neighbor statements. Include one neighbor statement for each peer. The peers on at least one side of each BGP connection must be configured statically. [edit protocols bgp] group group-name { peer-as autonomous-system ; type type ; neighbor address ; } To define a BGP group in which the local system's peers are dynamic and change over time, include the allow statement. To recognize all BGP systems as peers, include the allow all statement. To recognize BGP systems within specified address ranges, specify a set of addresses in the allow network/mask-length statement. [edit protocols bgp] group group-name { peer-as autonomous-system ; type type ; (allow [ prefix /prefix-length... ] allow all); } A BGP group can be an IBGP or EBGP. All peers in an IBGP group are in the same AS, whereas peers in an EBGP group are in different ASs and normally share a subnet. To configure an IBGP group, which allows intra-AS BGP routing, include the following form of the type statement: [edit protocols bgp group group-name ] type internal; To configure an EBGP group, which allows inter-AS BGP routing, include the following form of the type statement: [edit protocols bgp group group-name ] type external; When configuring a peer, you must specify the peer system's AS by including the peer-as statement, either globally, for all peers in a group, or for an individual peer. For EBGP, the peer is in another AS, so the AS number you specify in the peer-as statement must be different from the local router's AS number, which you specify in the autonomous-system statement. For IBGP, the peer is in the same AS, so the two AS numbers that you specify in the autonomous-system and peer-as statements must be the same. peer-as autonomous-system ; To define group-specific properties, include one or more of the statements listed in Table 9.3 at the [edit protocols bgp group group-name ] hierarchy level. When you use the neighbor statement to configure BGP peers statically, you can also define peer-specific properties listed in Table 9.3 at the [edit protocols bgp group group-name neighbor address ] hierarchy level. Configuring ConfederationsIn standard IBGP implementations , all BGP systems within the AS are fully meshed so that any external routing information is redistributed among all routers within the AS. This type of implementation can present scaling issues when an AS has a large number of IBGP systems because of the amount of identical information that BGP systems must share with each other. BGP confederations provide one means of decreasing BGP control traffic, minimizing the number of update messages sent within the AS. BGP AS confederations split a single AS into multiple smaller ASs, referred to as sub-ASs. Figure 9.2 illustrates an example confederation topology. For AS 32 to be a valid confederation, all routers in the AS must be members of the confederation. So, for example, Router B must have a confederation member AS number as well as a confederation AS number. Within a confederation, the links between the confederation member ASs must be EBGP links, not IBGP links. Figure 9.2. Example: BGP Confederation Topology To enable the local router to participate as a member of an AS confederation, define the AS confederation identifier and specify the AS numbers that are members of the confederation in the confederation statement: [edit routing-options] confederation confederation-autonomous-system members [ autonomous-systems ]; Configuring Route ReflectionRoute reflection is a second method for decreasing BGP control traffic, minimizing the number of update messages sent within the AS. In route reflection, BGP systems are arranged in clusters. Each cluster consists of at least one system that acts as a route reflector, along with any number of client peers. BGP peers outside the cluster are called nonclient peers. The route reflector reflects ( redistributes ) routing information to each client peer ( intracluster reflection ) and to all nonclient peers ( intercluster reflection ). Because the route reflector redistributes routes within the cluster, the BGP systems within the cluster do not have to be fully meshed. When the route reflector receives a route, it selects the best path. Then, if the route came from a nonclient peer, the route reflector sends the route to all client peers within the cluster. If the route came from a client peer, the route reflector sends it to all nonclient peers and to all client peers except the originator. In this process, none of the client peers sends routes to other client peers. To configure route reflection, specify a cluster identifier only on the BGP systems that are to be the route reflectors. These systems then determine, from the network reachability information they receive, which BGP systems are part of its cluster and are client peers, and which BGP systems are outside the cluster and are nonclient peers. To configure a router to be a route reflector, you must configure multiple IBGP groups, configure a cluster identifier (using the cluster statement) for groups that are members of the cluster, and configure all the groups with the same IBGP AS number. To configure the route reflector, include the following statements in the configuration. The first group statement is for the group of nonclient peers of the local system that is acting as a route reflector. The second group statement is for the group of peers in the cluster; each peer is treated as a route reflector client by the local system. The peer AS numbers must be the same in both groups. [edit protocols bgp] group group-name { type internal; peer-as autonomous-system neighbor address1 ; neighbor address2 ; } group group-name { type internal; peer-as autonomous-system ; cluster cluster-identifier ; neighbor address3 ; neighbor address4 ; } By default, the route reflector performs intracluster reflection, because it assumes that all the client peers are not fully meshed. However, if the client peers are fully meshed, intracluster reflection results in the sending of redundant route advertisements. In this case, you can disable intracluster reflection by including the no-client-reflect statement: [edit protocols bgp group group-name ] no-client-reflect; Configuring Route Flap DampingRoute flapping describes the situation in which BGP systems send an excessive number of update messages to advertise network reachability information. Flap damping is a method of reducing the number of update messages sent between BGP peers, thereby reducing the load on these peers, without adversely affecting the route convergence time for stable routes. By default, route flap damping is disabled. To enable it, include the damping statement: damping; Damping is applied to external peers and to peers at confederation boundaries. For finer control over which peers have damping enabled, include the damping statement at the group level.
By default, route flap damping uses the following parameters:
To change the default parameters, define the flap damping parameters with the damping statement at the [edit policy-options] hierarchy level, then apply them using an import statement when configuring BGP. Modifying the Hold-Time ValueThe hold time is the maximum number of seconds allowed to elapse between the time that a BGP system receives successive keepalive or update messages from a peer. When establishing a BGP connection with the local router, a peer sends an open message, which contains a hold-time value. BGP on the local router uses the smaller of either the local hold-time value or the peer's hold-time value received in the open message as the hold time for the BGP connection between the two peers. The hold time is three times the interval at which keepalive messages are sent. The default is 90 seconds. To modify the default on the local BGP system, include the hold-time statement: hold-time seconds ; Configuring AuthenticationAll BGP protocol exchanges can be authenticated to guarantee that only trusted routers participate in the AS's routing. By default, authentication is disabled. You can configure MD5 authentication. The MD5 algorithm creates an encoded checksum that is included in the transmitted packet. The receiving router uses an authentication key (password) to verify the packet's MD5 checksum. To configure authentication, include the authentication-key statement. The key (password) can be up to 255 characters long. Characters can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (double quotes). authentication-key key ; When configuring authentication for all peers in a group, you cannot include the allow statement in the configuration because BGP keys require a destination address. Applying IPSec Security AssociationIPSec can be applied to BGP traffic. IPSec is a protocol suite used for protecting IP traffic at the packet level. IPSec is based on security associations (SAs). A security association is a simplex connection that provides security services to the packets carried by the SA. After configuring the security association, you can apply the SA to BGP peers. To apply a security association, include the ipsec-sa statement: ipsec-sa ipsec-sa ;
A more specific security association overrides a less general SA. For example, if a specific SA is applied to a specific peer, that SA overrides the SA applied to the whole peer group. Opening a Peer Connection PassivelyYou can configure a router not to send open messages to a peer. After you configure the router to be passive, the router does not originate the TCP connection. However, when the router receives a connection from the peer and an open message, it replies with another BGP open message. Each router declares its own capabilities. To configure the router so that it does not send open messages to a peer, include the passive statement: passive; Configuring the Local IP AddressYou can explicitly specify the address of the local end of a BGP session. You generally do this to explicitly configure the system's IP address from BGP's point of view. Typically, an IP address is assigned to a loopback interface, and that IP address is configured here. This address is used to accept incoming connections to the peer and to establish connections to the remote peer. To assign a local address, include the local-address statement: local-address address ; If you also include the default-address-selection statement at the [edit system] hierarchy level, the software chooses the system default address as the source for most locally generated IP packets. For protocols in which the local address is unconstrained by the protocol specification, for example IBGP and multihop EBGP, if you do not configure a specific local address when configuring the protocol, the local address is chosen using the same methods as other locally generated IP packets. Configuring the Multiple Exit DiscriminatorThe BGP multiple exit discriminator (MED, or MULTI_EXIT_DISC ) is an optional path attribute that can be included in BGP update messages. This attribute is used on EBGP links (that is, on inter-AS links) to select among multiple exit points to a neighboring AS. The MED attribute has a value that is referred to as a metric. If all other factors in determining an exit point are equal, the exit point with the lowest metric is preferred. If a MED is received over an EBGP link, it is propagated over internal links to other BGP systems within the AS. A MED metric is advertised with a route according to the following general rules:
BGP update messages include a MED metric if the route was learned from BGP and already had a MED metric associated with it, or if you configure it. To directly configure a MED metric to advertise in BGP update messages, include the metric-out statement: metric-out ( metric minimum-igp < offset > igp < offset >); metric is the primary metric on all routes sent to peers. It can be a value in the range 0 through 2 32 “ 1. Specify minimum-igp to set the metric to the minimum metric value calculated in the IGP to get to the BGP next hop. If a newly calculated metric is greater than the minimum metric value, the metric value remains unchanged. If a newly calculated metric is lower, the metric value is lowered to that value. Specify igp to set the metric to the most recent metric value calculated in the IGP to get to the BGP next hop. Specify a value for offset to increase or decrease the metric that is used from the metric value calculated in the IGP. The metric value is offset by the value specified. The metric calculated in the IGP (by specifying either igp or igp-minimum ) is increased if the offset value is positive. The metric calculated in the IGP (by specifying either igp or igp-minimum ) is decreased if the offset value is negative. offset can be a value in the range “2 31 through 2 31 “ 1. Note that the adjusted metric can never go below 0 or above 2 32 “ 1.
To use routing policy to define a MED metric to advertise, define the routing policy with the policy-statement statement at the [edit policy-options] hierarchy level, then apply the filter using the import and export statements when configuring BGP. When defining the routing policy filter, include an action that specifies the desired metric value. Controlling the Aggregator Path AttributeThe JUNOS implementation of BGP performs route aggregation, which is the process of combining the characteristics of different routes so that only a single route is advertised. Aggregation reduces the amount of information that BGP must store and exchange with other BGP systems. BGP adds the aggregator path attribute to BGP update messages. This attribute contains the local system's AS number and IP address (router ID). To prevent different routers within an AS from creating aggregate routes that contain different AS paths, set the IP address in the aggregator path attribute to 0 by including the no-aggregator-id statement: no-aggregator-id; Choosing the Protocol Used to Determine the Next HopBy default, BGP uses the active routes determined from all IGPs when resolving routes to next hops. To limit the IGPs that BGP uses, include the protocol statement, specifying the protocol as isis or ospf : protocol protocol ; Configuring an EBGP Multihop SessionIf an EBGP peer is more than one hop away from the local router, you must specify the next hop to the peer so that the two systems can establish a BGP session. This type of session is called a multihop BGP session. To configure a multihop session, include the multihop statement: multihop < ttl-value >; To configure the maximum value for the TTL in the IP header of BGP packets, specify ttl-value . If you do not specify a TTL value, the system's default maximum TTL value is used. Configuring the BGP Local PreferenceIBGP sessions use a metric called the local preference , which is carried in IBGP update packets in the path attribute LOCAL_PREF . This metric indicates the degree of preference for an external route. The route with the highest local preference value is preferred. The LOCAL_PREF path attribute is always advertised to IBGP peers and to neighboring confederations. It is never advertised to EBGP peers. The default behavior is not to modify the LOCAL_PREF path attribute if it is present. The LOCAL_PREF path attribute is applied to exported routes only. By default, if a received route contains a LOCAL_PREF path attribute value, the value is not modified. If a BGP route is received without a LOCAL_PREF attribute, the route is handled locally (that is, it is stored in the routing table and advertised by BGP) as if it were received with a LOCAL_PREF value of 100. A non-BGP route that is advertised by BGP is advertised with a LOCAL_PREF value of 100 by default. To change the local preference metric advertised in the path attribute, include the local-preference statement, specifying a value from 0 through 4,294,967,295 (2 32 “ 1): local-preference local-preference ; Controlling Route PreferenceWhen the JUNOS software determines a route's preference to become the active route, it selects the route with the lowest preference as the active route and installs this route into the forwarding table. By default, the routing software assigns a preference of 170 to routes that originated from BGP. Of all the routing protocols, BGP has the highest default preference value, which means that routes learned by BGP are the least likely to become the active route.
To modify the default BGP preference value, include the preference statement, specifying a value from 0 through 4,294,967,295 (2 32 “ 1): preference preference ; Configuring Routing Table Path SelectionBy default, only the MEDs of routes that have the same peer ASs are compared. You can configure routing table path selection options to get different behaviors. To configure routing table path selection behavior, include the path-selection statement: [edit protocols bgp] path-selection (cisco-non-deterministic always-compare-med); Routing table path selection can be configured in one of two ways:
Configuring BGP to Select Multiple BGP PathsYou can configure BGP to select multiple nonmultihop EBGP or IBGP paths as active paths. Selecting multiple paths allows BGP peerings to load-balance traffic across an AS confederation boundary. The JUNOS BGP multipath supports the following:
To configure a BGP multipath, include the multipath statement: multipath; Configuring a Local ASYou can configure BGP with a different local AS number for each EBGP session, which allows BGP to configure a local AS for each EBGP session. Configuring a local AS simulates a virtual AS for the router. The AS paths for the routes from that EBGP peer have the configured local-as prepended before the peer AS for that session. To configure a local AS, include the local-as statement: local-as autonomous-system <private>; If you include the private keyword, the local AS is not prepended before the peer AS. This means that the AS paths do not show details of such a configuration. Removing Private AS Numbers from AS PathsBy default, when BGP advertises AS paths to remote systems, it includes all AS numbers, including private AS numbers. Configuring the software so that it removes private AS numbers from AS paths is useful when all the following circumstances are true:
To have the local system strip private AS numbers from the AS path, include the remove-private statement: remove-private; The AS numbers are stripped from the AS path starting at the left end of the AS path (the end where AS paths have been most recently added). This operation takes place after any confederation member ASs have already been removed from the AS path, if applicable . The software is preconfigured with knowledge of the set of AS numbers that is considered private, a range that is defined in the IANA assigned numbers document. The set of AS numbers reserved as private are in the range 64,512 through 65,534, inclusive. Enabling MBGPMultiprotocol BGP (MBGP) is an extension to BGP that enables BGP to carry routing information for multiple network layers and address families. MBGP can carry the unicast routes used for multicast routing separately from the routes used for unicast IP forwarding. To enable MBGP, you configure BGP to carry network layer reachability information (NLRI) for address families other than unicast IPv4 by including the family inet statement: family inet { (any multicast unicast) { prefix-limit { maximum number ; teardown < percentage > <idle-timeout (forever minutes )>; } rib-group group-name ; } } By default, BGP peers carry only unicast routes used for unicast forwarding purposes. To configure BGP peers to carry only multicast routes, specify the multicast option. To configure BGP peers to carry both unicast and multicast routes, specify the any option. When MBGP is configured, BGP installs the MBGP routes into different routing tables. Each routing table is identified by the protocol family or address family identifier (AFI) and a subaddress family indicator (SAFI). The JUNOS software supports AFI IPv4 and IPv6 and SAFI 1 for unicast routes, AFI IPv4 and IPv6 and SAFI 2 for multicast sources, and AFI IPv4 and IPv6 and SAFI 3 for both unicast and multicast prefixes. If BGP receives a prefix (NLRI) with SAFI 1, it places this route into the inet routing table. It places NLRIs with SAFI 2 into the inet.2 routing table and those with SAFI 3 into both the inet.0 and inet.2 routing tables. If peers do not support MBGP, you cannot export routes from the inet.2 routing table to them, only routes in the inet.0 routing table. Routes in the inet.2 routing table can be sent only to MBGP peers, because they are sent with a SAFI that identifies them as routes to multicast sources. The inet.2 routing table should be a subset of the routes that you have in the inet.0 routing table, because it is unlikely that you would have a route to a multicast source to which you could not send unicast traffic. The inet.2 routing table is used to keep the unicast routes that are used for multicast reverse-path-forwarding checks. An inet.2 routing table is automatically located when you configure MBGP (by setting NLRI to any ). The additional reachability information learned by MBGP from the NRLI multicast updates is placed in the inet.2 routing table. When you enable multiprotocol BGP, you can limit the number of prefixes received on a BGP peering and log rate-limited messages when the number of injected prefixes exceeds a set limit. You can also tear down the peering when the number of prefixes exceeds the limit. To configure a maximum number of prefixes, include the prefix-limit statement: prefix-limit { maximum number ; teardown < percentage > <idle-timeout (forever minutes )>; } When you set the maximum number of prefixes, a message is logged when that number is reached. If you include the teardown statement, the session is torn down when the maximum number of prefixes is reached. If you specify a percentage, messages are logged when the number of prefixes reaches that percentage. After the session is torn down, it is reestablished in a short time (unless you include the idle-timeout statement). Then the session can be kept down for a specified amount of time, or forever. If you specify forever , the session is reestablished only after you issue a clear bgp neighbor command. When a BGP session receives a unicast or multicast NLRI, it installs the route in the appropriate routing table ( inet.0 for unicast and inet.2 for multicast). To add unicast prefixes to both the unicast and multicast routing tables, you can configure BGP routing table groups. This is useful if you cannot perform multicast NLRI negotiation. To configure BGP routing table groups, include the rib-group statement: rib-group group-name ; Configuring BGP Routing PolicyAll routing protocols use the JUNOS software routing table to store the routes they learn and to determine which routes they should advertise in their protocol packets. Routing policy allows you to control which routes the routing protocols store in and retrieve from the routing table.
You define routing policy at the [edit policy-options] hierarchy level. To apply policies you have defined for BGP, include the import and export statements within the BGP configuration. You can apply BGP policies as follows :
To apply policy to routes being imported into the routing table from BGP, include the import statement, listing the names of one or more policies to be evaluated: import [ policy-names ]; To apply policy to routes being exported from the routing table into BGP, include the export statement, listing the names of one or more policies to be evaluated: export [ policy-names ]; If you specify more than one policy, they are evaluated in the order specified, from first to last, and the first matching filter is applied to the route. If, on importing, no match is found, BGP places into the routing table only those routes that were learned from BGP routers. If, on exporting, no routes match the filters, the routing table exports into BGP only the routes that it learned from BGP. By default, BGP stores the route information it receives from update messages in the JUNOS routing table, and the routing table exports only active routes into BGP, which BGP then advertises to its peers. To have the routing table export to BGP all routes learned by BGP even if the JUNOS software did not select them to be active routes, include the advertise-inactive statement: advertise-inactive; BGP stores the route information it receives from update messages in the routing table, and the routing table exports active routes from the routing table into BGP. BGP then advertises the exported routes to its peers. By default, the exchange of route information between BGP and the routing table occurs immediately after the routes are received. This immediate exchange of route information might cause instabilities in the network reachability information. To guard against this, you can delay the time between when BGP and the routing table exchange route information. To configure a delay between when the routing table receives route information and when it exports that information to BGP, include the out-delay statement: out-delay seconds; By default, the routing table retains some of the route information learned from BGP. To have the routing table retain all or none of this information, include the keep statement: keep (all none); The routing table can retain the route information learned from BGP in one of the following ways:
Configuring BGP to Log System Log MessagesWhenever a BGP peer makes a state transition, you can configure BGP so that it generates a system log (syslog) message by including the log-updown statement: log-updown; Describing the BGP Router ConfigurationTo configure a plain text string to describe the BGP router configuration, include the description statement: description description-text ; Tracing BGP Protocol TrafficTo trace BGP protocol traffic, specify BGP-specific options by including the traceoptions statement: [edit protocols bgp] traceoptions { file name <replace> <size size > <files number > <no-stamp> <(world-readable no-world-readable)>; flag flag < flag-modifier > <disable>; }
You can specify the following BGP-specific options in the BGP traceoptions statement:
|
EAN: 2147483647
Pages: 185