The show command output and regular expression match are not changed and remain in asplain decimal value format for 2-byte autonomous system numbers regardless of the format configured for 4-byte autonomous system numbers.
RFC was developed to allow BGP to support a gradual transition from 2-byte autonomous system numbers to 4-byte autonomous system numbers. Use of the reserved numbers allow configuration examples to be accurately documented and avoids conflict with production networks if these configurations are literally copied.
The reserved numbers are documented in the IANA autonomous system number registry. Reserved 2-byte autonomous system numbers are in the contiguous block, to and reserved 4-byte autonomous system numbers are from to inclusive.
Private 2-byte autonomous system numbers are still valid in the range from to with being reserved for special use. Private autonomous system numbers can be used for internal routing domains but must be translated for traffic that is routed out to the Internet. BGP should not be configured to advertise private autonomous system numbers to external networks.
Cisco IOS software does not remove private autonomous system numbers from routing updates by default. We recommend that ISPs filter private autonomous system numbers.
Autonomous system number assignment for public and private networks is governed by the IANA. However, you can configure 4-byte autonomous system numbers in both the asplain format and the asdot format as described in RFC For an example of BGP peers in two autonomous systems using 4-byte numbers, see the figure below.
To view a configuration example of the configuration between three neighbor peers in separate 4-byte autonomous systems configured using asdot notation, see the Examples: Configuring a BGP Routing Process and Peers Using 4-Byte Autonomous System Numbers. Cisco also supports RFC , which was developed to allow BGP to support a gradual transition from 2-byte autonomous system numbers to 4-byte autonomous system numbers. To ensure a smooth transition, we recommend that all BGP speakers within an autonomous system that is identified using a 4-byte autonomous system number be upgraded to support 4-byte autonomous system numbers.
When a BGP routing process establishes a peering session with a peer, it goes through the following state changes:. Idle—The initial state that the BGP routing process enters when the routing process is enabled or when the device is reset. In this state, the device waits for a start event, such as a peering configuration with a remote peer.
After the device receives a TCP connection request from a remote peer, the device initiates another start event to wait for a timer before starting a TCP connection to a remote peer.
If the device is reset, the peer is reset and the BGP routing process returns to the Idle state. Start events are ignored while the BGP routing process is in the Active state. If the BGP routing process is reconfigured or if an error occurs, the BGP routing process will release system resources and return to an Idle state.
If the connection fails, the BGP routing process transitions to the Active state. When a keepalive message is received, the BGP routing process transitions to the Established state. If a notification message is received, the BGP routing process transitions to the Idle state. If an error or configuration change occurs that affects the peering session, the BGP routing process sends a notification message with the Finite State Machine FSM error code and then transitions to the Idle state.
Established—The initial keepalive is received from the remote peer. Peering is now established with the remote neighbor and the BGP routing process starts exchanging update message with the remote peer.
The hold timer restarts when an update or keepalive message is received. If the BGP process receives an error notification, it will transition to the Idle state. The address family model for configuring BGP is based on splitting apart the configuration for each address family.
All commands that are independent of the address family are grouped together at the beginning highest level of the configuration, and these are followed by separate submodes for commands specific to each address family with the exception that commands relating to IPv4 unicast can also be entered at the beginning of the configuration. When a network operator configures BGP, the flow of BGP configuration categories is represented by the following bullets in order:.
Global configuration—Configuration that is applied to BGP in general, rather than to specific neighbors. For example, the network , redistribute , and bgp bestpath commands. Address family-dependent configuration—Configuration that applies to a specific address family such as policy on an individual neighbor. The relationship between BGP global and BGP address family-dependent configuration categories is shown in the table below.
Address family configuration must be entered within the address family submode to which it applies. The following is an example of BGP configuration statements showing the grouping of global address family-independent and address family-dependent commands.
The bgp upgrade-cli command simplifies the migration of BGP networks and existing configurations from the network layer reachability information NLRI format to the address family format. Network operators can configure commands in the address family identifier AFI format and save these command configurations to existing NLRI formatted configurations.
For complete support of AFI commands and features, we recommend upgrading existing NLRI configurations with the bgp upgrade-cli command. Whenever the routing policy changes due to a configuration change, BGP peering sessions must be reset by using the clear ip bgp command. Cisco software supports the following three mechanisms to reset BGP peering sessions:. Hard reset—A hard reset tears down the specified peering sessions including the TCP connection and deletes routes coming from the specified peer.
Soft reset—A soft reset uses stored prefix information to reconfigure and activate BGP routing tables without tearing down existing peering sessions. Soft reconfiguration uses stored update information, at the cost of additional memory for storing the updates, to allow you to apply new BGP policy without disrupting the network.
Soft reconfiguration can be configured for inbound or outbound sessions. Dynamic inbound soft reset—The route refresh capability, as defined in RFC , allows the local device to reset inbound routing tables dynamically by exchanging route refresh requests to supporting peers. The route refresh capability does not store update information locally for nondisruptive policy changes.
It instead relies on dynamic exchange with supporting peers. Route refresh must first be advertised through BGP capability negotiation between peers. All BGP devices must support the route refresh capability. To determine if a BGP device supports this capability, use the show ip bgp neighbors command.
The following message is displayed in the output when the device supports the route refresh capability:. The bgp soft-reconfig-backup command was introduced to configure BGP to perform inbound soft reconfiguration for peers that do not support the route refresh capability.
The configuration of this command allows you to configure BGP to store updates soft reconfiguration only as necessary. Peers that support the route refresh capability are unaffected by the configuration of this command. BGP peers store and exchange routing information and the amount of routing information increases as more BGP speakers are configured.
The use of route aggregation reduces the amount of information involved. Aggregation is the process of combining the attributes of several different routes so that only a single route is advertised. Aggregate prefixes use the classless interdomain routing CIDR principle to combine contiguous networks into one classless set of IP addresses that can be summarized in routing tables.
Fewer routes now need to be advertised. Two methods are available in BGP to implement route aggregation. You can redistribute an aggregated route into BGP or you can use a form of conditional aggregation. Basic route redistribution involves creating an aggregate route and then redistributing the routes into BGP.
Conditional aggregation involves creating an aggregate route and then advertising or suppressing the advertising of certain routes on the basis of route maps, autonomous system set path AS-SET information, or summary information. A route that is not installed into the RIB is an inactive route. Inactive route advertisement can occur, for example, when routes are advertised through common route aggregation.
Inactive route advertisements can be suppressed to provide more consistent data forwarding. Routing policies for a peer include all the configurations for elements such as route map, distribute list, prefix list, and filter list that may impact inbound or outbound routing table updates. The policy changes are automatically updated to peers whenever there is a change in the routing policy.
Performing inbound reset enables the new inbound policy configured on the router to take effect. Performing outbound reset causes the new local outbound policy configured on the router to take effect without resetting the BGP session. As a new set of updates is sent during outbound policy reset, a new inbound policy of the neighbor can also take effect. This means that after changing inbound policy you must do an inbound reset on the local router or an outbound reset on the peer router.
Outbound policy changes require an outbound reset on the local router or an inbound reset on the peer router. There are two types of reset: hard reset and soft reset. The table below lists their advantages and disadvantages. Not recommended. Configured inbound soft reset uses the neighbor soft-reconfiguration router configuration command.
Can be used when both BGP routers do not support the automatic route refresh capability. Stores all received inbound routing policy updates without modification; is memory-intensive. Recommended only when absolutely necessary, such as when both BGP routers do not support the automatic route refresh capability. Once you have defined two routers to be BGP neighbors, they will form a BGP connection and exchange routing information. If you subsequently change a BGP filter, weight, distance, version, or timer, or make a similar configuration change, you must reset BGP connections for the configuration change to take effect.
A soft reset updates the routing table for inbound and outbound routing updates. Cisco IOS Release This soft reset allows the dynamic exchange of route refresh requests and routing information between BGP routers, and the subsequent readvertisement of the respective outbound routing table.
There are two types of soft reset:. When soft reset is used to generate inbound updates from a neighbor, it is called dynamic inbound soft reset. When soft reset is used to send a new set of updates to a neighbor, it is called outbound soft reset.
To use soft reset without preconfiguration, both BGP peers must support the soft route refresh capability, which is advertised in the OPEN message sent when the peers establish a TCP session. Clearing the BGP session in this way will have a negative impact upon network operations and should be used only as a last resort. Routes that are advertised through the BGP are commonly aggregated to minimize the number of routes that are used and reduce the size of global routing tables.
However, common route aggregation can obscure more specific routing information that is more accurate but not necessary to forward packets to their destinations. Routing accuracy is obscured by common route aggregation because a prefix that represents multiple addresses or hosts over a large topological area cannot be accurately reflected in a single route. Cisco software provides several methods by which you can originate a prefix into BGP.
Prior to the BGP conditional route injection feature, the existing methods included redistribution and using the network or aggregate-address command. However, these methods assume the existence of more specific routing information matching the route to be originated in either the routing table or the BGP table.
BGP conditional route injection allows you to originate a prefix into a BGP routing table without the corresponding match. This feature allows more specific routes to be generated based on administrative policy or traffic engineering information in order to provide more specific control over the forwarding of packets to these more specific routes, which are injected into the BGP routing table only if the configured conditions are met.
Enabling this feature will allow you to improve the accuracy of common route aggregation by conditionally injecting or replacing less specific prefixes with more specific prefixes. Only prefixes that are equal to or more specific than the original prefix may be injected. BGP conditional route injection is enabled with the bgp inject-map exist-map command and uses two route maps inject map and exist map to install one or more more specific prefixes into a BGP routing table.
The exist map specifies the prefixes that the BGP speaker will track. The inject map defines the prefixes that will be created and installed into the local BGP table. Inject maps and exist maps will only match a single prefix per route map clause. To inject additional prefixes, you must configure additional route map clauses.
If multiple prefixes are used, the first prefix matched will be used. Often, in a BGP network, many neighbors are configured with the same update policies that is, the same outbound route maps, distribute lists, filter lists, update source, and so on. Neighbors with the same update policies can be grouped into BGP peer groups to simplify configuration and, more importantly, to make configuration updates more efficient.
When you have many peers, this approach is highly recommended. In a BGP network topology with two border devices using eBGP to communicate to a number of different autonomous systems, using eBGP to communicate between the two border devices may not be the most efficient routing method. Changing the default administrative distances is not recommended because changing the administrative distance may lead to routing loops.
BGP treats the network specified by the network backdoor command as a locally assigned network, except that it does not advertise the specified network in BGP updates. This method of grouping neighbors for BGP update message generation reduced the amount of system processing resources needed to scan the routing table. This method, however, had the following limitations:.
All neighbors that shared peer group configuration also had to share outbound routing policies. All neighbors had to belong to the same peer group and address family. Neighbors configured in different address families could not belong to different peer groups. These limitations existed to balance optimal update generation and replication against peer group configuration.
These limitations could cause the network operator to configure smaller peer groups, which reduced the efficiency of update message generation and limited the scalability of neighbor configuration.
Existing peer groups are not affected but peers with the same outbound policy configured that are not members of a current peer group can be grouped into an update group. The members of this update group will use the same update generation engine.
When BGP update groups are configured an algorithm dynamically calculates the BGP update group membership based on outbound policies.
Optimal BGP update message generation occurs automatically and independently. BGP neighbor configuration is no longer restricted by outbound routing policies, and update groups can belong to different address families. No configuration is required to enable the BGP dynamic update group and the algorithm runs automatically. When a change to outbound policy occurs, the router automatically recalculates update group memberships and applies the changes by triggering an outbound soft reset after a 1-minute timer expires.
This behavior is designed to provide the network operator with time to change the configuration if a mistake is made. You can manually enable an outbound soft reset before the timer expires by entering the clear ip bgp ip-address soft out command. For the best optimization of BGP update group generation, we recommend that the network operator keeps outbound routing policy the same for neighbors that have similar outbound policies.
To address some of the limitations of peer groups such as configuration management, BGP peer templates were introduced to support the BGP update group configuration. A peer template is a configuration pattern that can be applied to neighbors that share policies.
Peer templates are reusable and support inheritance, which allows the network operator to group and apply distinct neighbor configurations for BGP neighbors that share policies.
Peer templates also allow the network operator to define very complex configuration patterns through the capability of a peer template to inherit a configuration from another peer template. Peer session templates are used to group and apply the configuration of general session commands that are common to all address family and NLRI configuration modes. Peer policy templates are used to group and apply the configuration of commands that are applied within specific address families and NLRI configuration modes.
Peer templates improve the flexibility and enhance the capability of neighbor configuration. Peer templates also provide an alternative to peer group configuration and overcome some limitations of peer groups. BGP peer routers using peer templates also benefit from automatic update group configuration. With the configuration of the BGP peer templates and the support of the BGP dynamic update peer groups, the network operator no longer needs to configure peer groups in BGP and the network can benefit from improved configuration flexibility and faster convergence.
A BGP neighbor cannot be configured to work with both peer groups and peer templates. A BGP neighbor can be configured to belong only to a peer group or to inherit policies from peer templates. The following restrictions apply to the peer policy templates:. A peer policy template can directly or indirectly inherit up to eight peer policy templates.
A BGP neighbor can be configured to belong only to a peer group or to inherit policies only from peer templates. The inheritance capability is a key component of peer template operation.
Inheritance in a peer template is similar to node and tree structures commonly found in general computing, for example, file and directory trees. A peer template can directly or indirectly inherit the configuration from another peer template.
The directly inherited peer template represents the tree in the structure. The indirectly inherited peer template represents a node in the tree. Because each node also supports inheritance, branches can be created that apply the configurations of all indirectly inherited peer templates within a chain back to the directly inherited peer template or the source of the tree. This structure eliminates the need to repeat configuration statements that are commonly reapplied to groups of neighbors because common configuration statements can be applied once and then indirectly inherited by peer templates that are applied to neighbor groups with common configurations.
Configuration statements that are duplicated separately within a node and a tree are filtered out at the source of the tree by the directly inherited template.
A directly inherited template will overwrite any indirectly inherited statements that are duplicated in the directly inherited template. Inheritance expands the scalability and flexibility of neighbor configuration by allowing you to chain together peer templates configurations to create simple configurations that inherit common configuration statements or complex configurations that apply very specific configuration statements along with common inherited configurations.
Specific details about configuring inheritance in peer session templates and peer policy templates are provided in the following sections. When BGP neighbors use inherited peer templates it can be difficult to determine which policies are associated with a specific template. The detail keyword was added to the show ip bgp template peer-policy command to display the detailed configuration of local and inherited policies associated with a specific template.
Peer session templates are used to group and apply the configuration of general session commands to groups of neighbors that share session configuration elements. General session commands that are common for neighbors that are configured in different address families can be configured within the same peer session template.
Peer session templates are created and configured in peer session configuration mode. Only general session commands can be configured in a peer session template. The following general session commands are supported by peer session templates:. General session commands can be configured once in a peer session template and then applied to many neighbors through the direct application of a peer session template or through indirect inheritance from a peer session template.
The configuration of peer session templates simplifies the configuration of general session commands that are commonly applied to all neighbors within an autonomous system. Peer session templates support direct and indirect inheritance. A peer can be configured with only one peer session template at a time, and that peer session template can contain only one indirectly inherited peer session template.
If you attempt to configure more than one inherit statement with a single peer session template, an error message will be displayed. This behavior allows a BGP neighbor to directly inherit only one session template and indirectly inherit up to seven additional peer session templates. This allows you to apply up to a maximum of eight peer session configurations to a neighbor: the configuration from the directly inherited peer session template and the configurations from up to seven indirectly inherited peer session templates.
Inherited peer session configurations are evaluated first and applied starting with the last node in the branch and ending with the directly applied peer session template configuration at the source of the tree.
The directly applied peer session template will have priority over inherited peer session template configurations. Any configuration statements that are duplicated in inherited peer session templates will be overwritten by the directly applied peer session template.
So, if a general session command is reapplied with a different value, the subsequent value will have priority and overwrite the previous value that was configured in the indirectly inherited template. The following examples illustrate the use of this feature. Peer session templates support only general session commands. BGP policy configuration commands that are configured only for a specific address family or NLRI configuration mode are configured with peer policy templates.
Peer policy templates are used to group and apply the configuration of commands that are applied within specific address families and NLRI configuration mode. Peer policy templates are created and configured in peer policy configuration mode. BGP policy commands that are configured for specific address families are configured in a peer policy template. The following BGP policy commands are supported by peer policy templates:.
Peer policy templates are used to configure BGP policy commands that are configured for neighbors that belong to specific address families. Like peer session templates, peer policy templates are configured once and then applied to many neighbors through the direct application of a peer policy template or through inheritance from peer policy templates.
The configuration of peer policy templates simplifies the configuration of BGP policy commands that are applied to all neighbors within an autonomous system. Like a peer session template, a peer policy template supports inheritance. However, there are minor differences. A directly applied peer policy template can directly or indirectly inherit configurations from up to seven peer policy templates.
So, a total of eight peer policy templates can be applied to a neighbor or neighbor group. Like route maps, inherited peer policy templates are configured with sequence numbers. Also like a route map, an inherited peer policy template is evaluated starting with the inherit peer-policy statement with the lowest sequence number and ending with the highest sequence number.
If you like to keep on reading, Become a Member Now! Here is why:. In AS 2 you have named but nowwhere you have configured jim…you have configured JACK …in the second Diagram consisting of 3 routers you have named them James , jim , john…should i assume jim as Jack?..
Excellent explanation by the way …. This is only useful when you are multihomed to a single ISP. These two methods will help if you are multihomed to different ISPs:. Hi Renee, Great lesson but I would like to make one suggestion. I find names harder to keep straight in my head. Just my opinion. Ask a question or join the discussion by visiting our Community Forum.
Skip to content Search for: Search. You are here: Home » BGP. I started reading your BGP blog. But im struggling to find an easy way to start with BGP.
Because topics are scattered all over the place. Can you please help and show me the correct order that i should follow to become a BGP guru. Ask a question or join the discussion by visiting our Community Forum. Skip to content Search for: Search.
You are here: Home » BGP. R1 config router bgp 1 R1 config-router neighbor R1 show ip bgp summary BGP router identifier 1. Explained As Simple As Possible.
0コメント