9.4 Configuration Parameters

Before we get into configuration scenarios, it is important to understand what configurable options you will have under the JUNOS command hierarchy. Due to the infinite number of configuration scenarios for BGP, only the most common configuration parameters are listed here. BGP in JUNOS can be configured under multiple hierarchies. The different hierarchies are listed in Table 9-5. However, for clarity, we will provide configuration examples using the basic [edit protocols bgp] hierarchy, but you should understand that the same configuration parameters are valid for all the various listed hierarchies.

Table 9-5. BGP Protocol Hierarchy Levels and Command Syntaxes

Level Number	Hierarchy
1	[edit protocols bgp] set protocols bgp ...
2	[edit protocols bgp group group-name ] set protocols bgp group group-name ...
3	[edit protocols bgp group group-name neighbor address ] set protocols bgp group group-name neighbor address ...
4	[edit routing-instances routing-instance-name protocols bgp] set routing-instances routing-instance-name protocols bgp ...
5	[edit routing-instances routing-instance-name protocols bgp group group-name ] set routing-instances routing-instance-name protocols bgp group group-name ...
6	[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address ] set routing-instances routing-instance-name protocols bgp group group-name neighbor address ...

9.4.1 Configuration Hierarchy

As has been mentioned earlier, there are several instances in which some protocol-independent routing properties must be configured to use certain features. These can be found under the [routing-options] and [policy-options] hierarchy. Due to the scope of this chapter, we will not deviate outside the properties that directly relate to the BGP protocol.

Under the [edit protocols bgp] hierarchy, there are three distinct levels of configuration:

1. Global

2. Group

3. Peer

JUNOS uses a very hierarchical configuration process. Each hierarchy takes precedence over the previous. This means that parameters configured at the group level will take precedence over anything configured at the global level. This approach provides a very structured configuration file that is easy to read. Developing a configuration policy or guideline will help to ensure that configurations are implemented in a specific manner and to eliminate the use of several different styles of configuration across the network.

As mentioned before, there are several ways to configure BGP in JUNOS and achieve the same desired end result. For ease of explanation and clarity, we will list each configuration statement, its syntax, the hierarchy level at which the statement can be configured (see Table 9-5 for a list of hierarchy names and their levels).

9.4.2 Configuration Statements

The following statements are listed to provide insight into the BGP options configurable in JUNOS BGP. Although there are several configuration scenarios and multiple ways to accomplish tasks like peering, this should provide adequate explanation to help you understand the basics and get BGP up and running.

9.4.2.1 advertise-inactive

JUNOS learns routes from various sources. Owing to policy and configuration, some of these routes will not be chosen as the preferred route and thus will not be marked active. The routes remain in the routing table, while the active routes are sent to the master forwarding table in the PFE. In BGP you can advertise these inactive routes, thereby transporting them to another router. That router, owing to its policy, may or may not utilize the routes received. Regardless, you can advertise the inactive routes in the routing table. Table 9-6 shows the advertise-inactive configuration statement's syntax and the levels at which it can be configured.

Table 9-6. advertise-inactive Configuration Statement

Syntax	advertise-inactive;
Level	1, 2, 3, 4, 5, 6

9.4.2.2 allow

In BGP we typically specify the neighbor we want to peer with in our configuration. This is typically done through the use of the neighbor statement, followed by the explicit IP address of the neighbor with which we want to peer. In JUNOS we can use the allow statement to identify the peer in the form of a prefix. This feature can be used when peering with other routers that fall within a range that can be defined with a prefix and mask. The use of 0.0.0.0/0 is an implicit ALL . This should be used with caution as the JUNOS BGP implementation does not allow the use of authentication when the allow statement is used. Table 9-7 shows the allow configuration statement's syntax and the levels at which it can be configured.

Table 9-7. allow Configuration Statement

Syntax	allow [network/mask-length] allow 192.168.250/24
Level	2, 5

9.4.2.3 as-override

The default behavior of BGP is to reject routes that have the local ASN in the AS_PATH for the advertised route to avoid routing loops . The as-override parameter allows JUNOS to override this characteristic and accept the route advertisement. Great caution should be used when implementing this parameter, as routing loops and suboptimal routing conditions can occur. Table 9-8 shows the as-override configuration statement's syntax and the levels at which it can be configured.

Table 9-8. as-override Configuration Statement

Syntax	as-override;
Level	2, 3, 5, 6

9.4.2.4 authentication-key

BGP4 supports authentication. This authentication is used to send an encrypted checksum between two routers, using a predetermined authentication key. When entering the key, you can use up to 255 characters of plain text. However, when displayed, the encrypted version of the key is shown. If there is a need to use spaces as part of the key, make sure the key is enclosed in quotation marks. Although the use of authentication can ensure peering with authorized peers, the implementation will not work with the allow statement. Table 9-9 shows the authentication-key configuration statement's syntax and the levels at which it can be configured.

Table 9-9. authentication-key Configuration Statement

Syntax	authentication-key key; authentication-key secure; authentication-key "this is a secure key";
Level	1, 2, 3, 4, 5, 6

9.4.2.5 bgp

BGP4 is the only EGP available in Juniper Networks routers. When configuring BGP, you cannot just issue the set protocols bgp statement. It must be followed by additional parameters. Table 9-10 shows the bgp configuration statement's syntax and the levels at which it can be configured.

Table 9-10. bgp Configuration Statement

Syntax	bgp { }
Level	1, 4

9.4.2.6 cluster

For scaling purposes, BGP supports a function known as route reflection. Each route-reflector cluster requires a cluster-identifier , which is unique to the AS or confederation in which the system resides. The identifier is in the form of an IP address. Table 9-11 shows the cluster configuration statement's syntax and the levels at which it can be configured.

Table 9-11. cluster Configuration Statement

Syntax	cluster cluster-identifier; cluster 192.168.250.59;
Level	1, 2, 3, 4, 5, 6

9.4.2.7 damping

BGP routes commonly consist of reachability information from ASs throughout the Internet. Reliability of these ASs is typically outside the local AS's control and responsibility. Thus, the continual adding or withdrawl of routes ”a condition known as flapping ”can cause a large number of UPDATE messages to be injected into the BGP routing domain, in turn causing instability within the local AS routing infrastructure.

Damping is a method by which you can control how often BGP recalculates your BGP tables in a route flap condition. By default, damping is disabled in JUNOS. Once damping is enabled, specific parameters, such as decay , hold-down , reuse , and cutoff , can be configured under the [edit policy-options] hierarchy. Table 9-12 shows the damping configuration statement's syntax and the levels at which it can be configured.

Table 9-12. damping Configuration Statement

Syntax	damping;
Level	1, 2, 3, 4, 5, 6

9.4.2.8 description

Within the configuration of JUNOS, you can place descriptions annotating configuration parameters and statements. This provides the opportunity to add clarity to otherwise complex portions of the configuration. If the description is going to have spaces, then the use of quotation marks to enclose it is necessary. Table 9-13 shows the description configuration statement's syntax and the levels at which it can be configured.

Table 9-13. description Configuration Statement

Syntax	description text-description; description MGMT_INTFC; description "Do not disable, this interface is for Mgmt purposes";
Level	1, 2, 3, 4, 5, 6

9.4.2.9 disable

JUNOS supports the disabling of a set of configuration statements without removing them from the actual configuration. Pay close attention to the hierarchy in which the statement can be applied. Table 9-14 shows the disable configuration statement's syntax and the levels at which it can be configured.

Table 9-14. disable Configuration Statement

Syntax	disable;
Level	1, 4

9.4.2.10 export

The export parameter is used to indicate which policies are to be used to move routes from the routing table into the BGP protocol for advertisement. Table 9-15 shows the export configuration statement's syntax and the levels at which it can be configured.

Table 9-15. export Configuration Statement

Syntax	export [policy-name]; export static-routes;
Level	1, 2, 3, 4, 5, 6

9.4.2.11 family

By default, BGP only sends unicast reachability information. By using the family inet statement, we are enabling Multiprotocol BGP (MBGP). This allows the local router to propagate NLRI for multicast and unicast systems. JUNOS must have an MBGP peer to send multicast NLRI. Otherwise, only unicast NLRI will be passed. Table 9-16 shows the family configuration statement's syntax and the levels at which it can be configured.

Table 9-16. family Configuration Statement

Syntax	family inet { (any multicast unicast_{ prefix-limit {V maximum number; teardown <percentage>; } rib-group routing-table-group-name; } }
Level	1, 2, 3, 4, 5, 6

9.4.2.12 group

Groups can be defined in JUNOS BGP for peer relationships that share the same characteristics. If a group is assigned, any configuration parameters applied affect not only the whole group, but override any parameters applied at the global level. Table 9-17 shows the group configuration statement's syntax and the levels at which it can be configured.

Table 9-17. group Configuration Statement

Syntax	group group-name; group IBGP;
Level	1, 4

9.4.2.13 hold-time

Earlier in this chapter, we discussed, in general terms, the establishment of BGP sessions in Sections 9.1 and 9.2. Part of this establishment was the exchange of KeepAlive and UPDATE messages. However, in the exchange of these messages, the time period for the hold-time counter is exchanged. In JUNOS, the hold-time default value is 90 seconds. Most implementations of BGP autonegotiate the hold-time during the session-establishment process. If one side of the session wants to use a different value, this can be negotiated. If a value of 0 is configured, then the local system will not pass KEEPALIVE messages. If the remote system is not configured properly for this characteristic, the BGP session will not establish properly. Table 9-18 shows the hold-time configuration statement's syntax and the levels at which it can be configured.

Table 9-18. hold-time Configuration Statement

Syntax	hold-time seconds ;
Level	1, 2, 3, 4, 5, 6

9.4.2.14 import

The import parameter is used to list the policies to apply to routes sent from BGP to the routing table. Table 9-19 shows the import configuration statement's syntax and the levels at which it can be configured.

Table 9-19. import Configuration Statement

Syntax	import [policy-name]; import no24s;
Level	1, 2, 3, 4, 5, 6

9.4.2.15 keep

This statement manipulates how JUNOS treats BGP routes in the Adj-RIB-In table. By default, JUNOS, which does not use the keep statement, keeps all routes that are received by BGP and not looped in the Adj-RIB-In table. If the keep all statement is used, JUNOS will keep all of the routes, regardless of any loops in the path . If the keep none statement is used, then JUNOS will discard all BGP routes in the Adj_RIB-In table, once the input policy has been run on them. If the input policy is changed and needs to be run again, JUNOS will have to request that the peer readvertise the routes, then run the import policy on the routes again. If the default of not using the keep statement or keep all statement is used, JUNOS will simply run the import policy against the Adj-RIB-In table upon a change to the policy. This is similar to the soft-reconfigure on a Cisco router. See Section 9.1.4 for additional RIB information. Table 9-20 shows the keep configuration statement's syntax and the levels at which it can be configured.

Table 9-20. keep Configuration Statement

Syntax	keep (all none);
Level	1, 2, 3, 4, 5, 6

9.4.2.16 local-address

When establishing a BGP peering session, part of the validation process is to check the incoming RID against that which is configured for the peer. If there is a mismatch of these addresses, the session will not establish. When configuring a session, unless specified otherwise, the address of the egress interface will be used in the BGP session. This works most of the time for EBGP sessions. However, in IBGP it is more common to peer with loopback interface addresses. Using the local-address statement will instruct JUNOS to use a specified address in the BGP header. It is important that if this is used in the local system, the remote system must use the same address as its neighbor. Table 9-21 shows the local-address configuration statement's syntax and the levels at which it can be configured.

Table 9-21. local-address Configuration Statement

Syntax	local-address address; local-address 172.16.24.1;
Level	1, 2, 3, 4, 5, 6

9.4.2.17 local-as

Configuration of this statement allows for a virtual AS on the router. When using this statement, the local router will use this ASN for the peering relationship. Thus, when receiving an update from a remote peer, the local system will prepend the path with the local-as prior to installing it in the routing table. If the keyword private is specified in the statement, then the local-as information will not be prepended to the AS_PATH . This is a useful feature at times when multiple ASNs are necessary for peering purposes, but what gets advertised out does not need this additional AS. Table 9-22 shows the local-as configuration statement's syntax and the levels at which it can be configured.

Table 9-22. local-as Configuration Statement

Syntax	local-as autonomous-system <private> ;
Level	1, 2, 3, 4, 5, 6

9.4.2.18 local-preference

In IBGP the LOCAL_PREF attribute is used to establish a level of preference to certain prefixes. For instance, if there are multiple egress points from the local AS to the rest of the Internet, then a preference can be given to a particular egress point. This is essential when trying to shape traffic towards certain egress points. The higher the local preference, the more preferred it is over others. The default LOCAL_PREF value in JUNOS is 100. Table 9-23 shows the local-preference configuration statement's syntax and the levels at which it can be configured.

Table 9-23. local-preference Configuration Statement

Syntax	local-preference local-preference; local-preference 150;
Level	1, 2, 3, 4, 5, 6

9.4.2.19 log- updown

Once BGP sessions are established, it is important that they remain up until it is administratively viable to bring them down. When peering sessions transition (flap), you can experience computational strain on your local system, as well as on the integrity of route information supplied by the local system to remote peers. In JUNOS, the log-updown function will notify the syslog function on the local system if such transitions in the BGP session occur. This can be used to maintain the network proactively and intervene immediately once a session has been identified as going up and down. This will not prevent flaps, but if they are monitored properly, you can resolve issues prior to getting that angry phone call from an upstream provider or downstream customer. Table 9-24 shows the log-updown configuration statement's syntax and the levels at which it can be configured.

Table 9-24. log-updown Configuration Statement

Syntax	log-updown;
Level	1, 2, 3, 4, 5, 6

9.4.2.20 metric-out

When sending MED values to external peers, the metric-out statement can be used to set this value explicitly. When presented with multiple exit points, and all things being equal, the receiving AS will prefer the egress point with the lowest MED value. The metric-out option provides a constant MED value. There is a lot of flexibility with the statement; however, policy on a per-peer basis will allow the same amount of flexibility, if not more. Table 9-25 shows the metric-out configuration statement's syntax and the levels at which it can be configured.

Table 9-25. metric-out Configuration Statement

Syntax	metric-out (metric minimum-igp <offset> igp <offset> );
Level	1, 2, 3, 4, 5, 6

9.4.2.21 multihop

A characteristic of EBGP is that the IP packets used for the BGP sessions and messages have a TTL value of 1 by default. This means that BGP peers needing to establish an EBGP session must be directly connected. The multihop statement can be used to change this characteristic of EBGP sessions by providing the ability to assign the TTL value and provide flexibility in implementation.

There are often times when it is necessary to establish an EBGP session between two systems that are not directly connected. This is common in Network Access Points (NAPs) and peering points where individual systems may be connected to a third-party system, such as a Layer 3 switch. This means the individual systems are not directly connected. In our typical EBGP scenario, the IP packets with the BGP information would be dropped after the first hop owing to the TTL expiring. When we use the multihop statement in our configuration, we arbitrarily set the TTL to 255 to prevent it from expiring. Now, when we attempt to establish our EBGP session between nondirectly connected peers, it will establish.

Note that using multihop and arbitrarily setting the TTL to 255 also makes the local system vulnerable to having BGP sessions spoofed by other systems. It is good practice to assign the TTL parameter to the appropriate hop value when using the multihop statement to minimize the potential for outside systems to establish sessions with local systems. Table 9-26 shows the multihop configuration statement's syntax and the levels at which it can be configured.

 group EBGP-Mhop {      type external;  multihop ttl 3;  neighbor 10.0.23.1 {         peer-AS300;     } } 

Table 9-26. multiphop Configuration Statement

Syntax	multiphop; multihop ttl <ttl-value>;
Level	1, 2, 3, 4, 5, 6

9.4.2.22 multipath

This is an essential part of load balancing. Juniper Networks routers support 8 or 16 equal-cost paths, depending on the type of Internet processor ASIC installed on the local system. If the local system is using the Internet Processor I, then there is the possibility for 8 equal-cost paths; if the Internet Processor II ASIC is in the system, there is a capability of 16 equal-cost paths. The multipath statement allows JUNOS to bypass the lowest RID decision, which is the last tiebreaker for route selection. Table 9-27 shows the multipath configuration statement's syntax and the levels at which it can be configured.

Table 9-27. multipath Configuration Statement

Syntax	multipath;
Level	2, 3, 5, 6

9.4.2.23 neighbor

BGP requires a neighbor to peer with. The address used is the same address that will be considered as the RID of the remote system. If it is not set correctly, the session will not establish. Table 9-28 shows the neighbor configuration statement's syntax and the levels at which it can be configured.

Table 9-28. neighbor Configuration Statement

Syntax	neighbor address ;
Level	2 and 5

9.4.2.24 no-aggregator-id

Juniper Networks routers are capable of route aggregation. This allows for fewer routes to be advertised by using less-specific network statements, thereby covering more hosts and networks with a single statement. When aggregation occurs, the local system adds the local AS and RID to the AGGREGATOR path attribute. Using a the no-aggregator-id statement will cause JUNOS to place a 0 in the RID field and eliminate the possibility of having multiple aggregate advertisements floating around the network, each with different path information. Table 9-29 shows the no-aggregator-id configuration statement's syntax and the levels at which it can be configured.

Table 9-29. no-aggregator-id Configuration Statement

Syntax	no-aggregator-id;
Level	1, 2, 3, 4, 5, 6

9.4.2.25 no-client-reflect

In route reflection, the route reflector receives a route from a route-reflector client, and then propagates that route to other clients in the cluster. The typical scenario for the clients in this case is to peer only with the route reflector. In the event that a client is fully meshed with other clients (this is common in migration scenarios), it is undesirable for the route reflector to advertise redundant routing information. JUNOS allows us to control this with the no-client-reflect statement. In the event the client is fully meshed with other clients, it will send out its advertisement to everyone with whom it peers. The route reflector would still send the route information to everyone with whom it peers, as well. This excess information does not need to be advertised out because of the full-mesh. The use of no-client-reflect prevents the route reflector from readvertising routes learned from a client that we know to be fully meshed with the other IBGP speakers . Table 9-30 shows the no-client-reflect configuration statement's syntax and the levels at which it can be configured.

Table 9-30. no-client-reflect Configuration Statement

Syntax	no-client-reflect;
Level	1, 2, 3, 4, 5, 6

9.4.2.26 out-delay

In JUNOS, when a route is installed in the routing table and BGP is operational, the route will immediately be imported into BGP. The out-delay statement requires the route to remain in the table for a predetermined amount of time before being imported into the BGP process. This can be useful in scenarios where flapping becomes a problem and other controls besides damping need to be implemented. Table 9-31 shows the out-delay configuration statement's syntax and the levels at which it can be configured.

Table 9-31. out-delay Configuration Statement

Syntax	out-delay second;
Level	1, 2, 3, 4, 5, 6

9.4.2.27 passive

JUNOS implements a parameter to allow for the establishment of passive BGP peering sessions. The passive statement allows the BGP speaker to be configured for BGP, but will suppress the sending of the OPEN message to a peer. Instead, it will stand by, waiting to receive an OPEN message, then go through the peer-establishment process. This can be useful in migration scenarios where peers are being added. The local systems can be configured to establish peering-sessions to remote peers as they are integrated. Essentially, the local system will stand by for an attempted peer establishment from a remote system and will not initiate any peer establishment actions, such as creating a TCP session to allow the BGP session to establish over. Table 9-32 shows the passive configuration statement's syntax and the levels at which it can be configured.

Table 9-32. passive Configuration Statement

Syntax	passive;
Level	1, 2, 3, 4, 5, 6

9.4.2.28 path-selection

Part of the path-selection process in JUNOS includes the comparison of the MED value. This only occurs when the local AS receives a prefix more than once from a single peer AS. If the prefix is received from two different peer ASs, then the MED value will not be compared. JUNOS would simply go to the next path-selection criteria, as outlined in Section 9.1.4.4. When MED s are compared, JUNOS uses a deterministic method. By comparison, Cisco defaults to a nondeterministic method, although Cisco does recommend the use of the bgp deterministic-med statement when configuring BGP on their routers.

The difference between deterministic and nondeterministic methods is the way in which the MED value is compared. The deterministic method will group routes together based on the announcing AS. So, if prefix 10.10.0.0/16 were announced from AS100 once and AS200 twice, they would be grouped. However, only the MED values from AS200 would be compared, because JUNOS only will compare MED values from advertisements received from the same AS. If the MED values were compared between AS200 announcements, the winner of that comparison would then be compared to the AS100 announcement, and some other selection criteria would choose which prefix advertisement to select.

When using Cisco-nondeterministic as the path-selection criteria, the routes will be compared in the order of their receipt. So, if the announcement order were AS100, AS200, AS100, JUNOS would not compare the MED s of the first announcements because they are from different ASs. The winning route of this first announcement would then be compared to the second announcement from AS100. Thus, if the first announcement won over AS200, then AS100 would be compared against the second AS100 announcement. Whichever MED value was preferred will be selected.

When using the path-selection always-compare-med statement, JUNOS will compare MED s regardless of whether the announcement comes from the same AS or not. If an announcement for a prefix comes in AS100, AS200, AS100, JUNOS will compare the MED of the first two announcements AS100 and AS200, even though they are each from a different AS. Then, the winner will be compared to the third announcement from AS100.

Note that due to potential loops, Cisco-nondeterministic is not recommended. Table 9-33 shows the path-selection configuration statement's syntax and the levels at which it can be configured.

Table 9-33. path-selection Configuration Statement

Syntax	path-selection (cisco- non-deterministic always-compare-med)
Level	1, 4

9.4.2.29 peer-as

When configuring a BGP session, the peer-as parameter must be specified. This tells the local system which AS it will be peering. Table 9-34 shows the peer-as configuration statement's syntax and the levels at which it can be configured.

Table 9-34. peer-as Configuration Statement

Syntax	Peer-as autonomous-system ;
Level	1,2,3,4,5,6

9.4.2.30 preference

In JUNOS, there is a preference placed on each protocol used. This preference is the same as the administrative distance on Cisco routers. It is used to determine which route to make active in the routing table. All other things being equal, the protocol with the lowest preference will be used. The preference statement can be used to manipulate the default characteristics and modify the values assigned for each protocol. Table 9-35 shows the preference configuration statement's syntax and the levels at which it can be configured.

Table 9-35. preference Configuration Statement

Syntax	preference preference ;
Level	1,2,3,4,5,6

9.4.2.31 prefix-limit

This statement allows us to limit the number of prefixes that will be accepted and would typically be set on a per-peer basis. If customer A and the ISP have agreed that customer A will not send more than 10 prefix advertisements to the ISP, the ISP would want to be able to enforce this. The maximum limit to 10 could be set with the prefix-limit statement. A teardown would then be set, using a percentage of 90. This will log a message when 90 percent of the maximum allowed prefixes have been sent and tear down the peering session once the maximum threshold has been crossed. We can also specify a duration of how long to keep the peering session down before attempting to re-establish the session. Table 9-36 shows the prefix-limit configuration statement's syntax and the levels at which it can be configured.

Table 9-36. prefix-limit Configuration Statement

Syntax	prefix-limit { maximum number; teardown <percentage> idle-timeout (forever timelimit in minutes); } group cx-A { type external; peer-AS200; neighbor 10.0.23.2 { family inet { unicast { prefix-limit { maximum 10; teardown 90; } } } } }
Level	1, 2, 3, 4, 5, 6

9.4.2.32 protocol

JUNOS has the ability to run multiple IGP protocols. For next-hop resolution, BGP does a recursive lookup to make sure the next-hop for a route is reachable , prior to installing a route into the routing table. This statement allows us to tell the BGP process which IGP to use for the next-hop resolution. Table 9-37 shows the protocol configuration statement's syntax and the levels at which it can be configured.

Table 9-37. protocol Configuration Statement

Syntax	protocol protocol ;
Level	2 and 5

9.4.2.33 remove-private

In BGP you can use private ASNs. These include confederation, private networks, or networks multihomed to an AS with no official ASNs assigned to them. It is possible to propagate these private ASs through BGP. JUNOS implements a mechanism to strip these private ASs from the AS_PATH , so they are not used or sent further. To achieve this effect, use the remove-private statement. Table 9-38 shows the remove-private configuration statement's syntax and the levels at which it can be configured.

Table 9-38. remove-private Configuration Statement

Syntax	remove-private;
Level	1, 2, 3, 4, 5, 6

9.4.2.34 trace-options

In JUNOS we can debug certain events by using the trace-options statement. This powerful feature allows the user to view virtually all processes and functions of the BGP protocol, as well as other functions. This information is especially valuable when troubleshooting session- and update- related problems in BGP. Table 9-39 shows the trace-options configuration statement's syntax and the levels at which it can be configured.

Table 9-39. trace-options Configuration Statement

Syntax	Syntax traceoption { file name <replace> <size size> <files number> <no-stamp> <(world readable no-world-readable)>; flag flag <flag-modifier> <disable>; }
Level	1, 2, 3, 4, 5, 6

9.4.2.35 type

In BGP there are two types of sessions that can be created. In the configuration, we use the type statement to specify whether the session will be internal or external. Table 9-40 shows the type configuration statement's syntax and the levels at which it can be configured.

Table 9-40. type Configuration Statement

Syntax	type type ;
Level	2, 5