How can i configure bgp

This allows Layer 2 adjacent routers to discover each other and form routing protocol adjacencies with each other. Link-local multicast is not however suitable for BGP because the neighbors are often multiple router hops apart.

You have to manually specify the BGP neighbors. Targeted unicast TCP sessions using TCP port are used to establish the peering and also to exchange routes once the peering has been done.

This is one of the first things to check when troubleshooting BGP peering issues. R1 has IP address We configure R1 to say that we want it to form a BGP peering with It says, "I'm R3 will reply within that TCP session and it will agree to set up the BGP peer relationship if it has a matching neighbor statement for R If the IP address of a physical interface is used for the BGP session and that physical interface goes down then so will the BGP session, even though there is an alternative path to the other BGP router.

If that doesn't make sense yet, you'll see it in the next diagram coming up. Loopback addresses which are advertised in the IGP are typically used as the address in the BGP neighbor statement because of this.

This way, BGP peers can continue to reach each other even if a physical interface goes down. There's redundant backup links between the two routers. From R1, when we configure the BGP neighbor statement pointing at R2, we could say we want to peer with But if we do that and that link goes down, then the BGP relationship is going to go down as well, even though R1 still has connectivity to R2 along the bottom path at Obviously, if we point at If that bottom path goes down, BGP also goes down, even though we can get to the router along the top path.

Using loopback addresses for our neighbor statements leads to a common gotcha with BGP. BGP has a security mechanism where it will only peer with another router if it has a matching neighbor statement for that peer.

The source address in the packets received from the neighbor must match the exact IP address in the neighbor statement on this router. When a router sends packets from itself, it uses the IP address of the exit interface as the source address by default. After this initial exchange, the BGP peers send only incremental updates when a topology change occurs in the network or when a routing policy change occurs. In the periods of inactivity between these updates, peers exchange special messages called keepalive s.

The hold time is the maximum time limit that can elapse between receiving consecutive BGP update or keepalive messages. Cisco NX-OS supports the following peer configuration options:. You can configure the router ID. If no loopback interface is configured on the router, then the software chooses the highest IPv4 address configured to a physical interface on the router to represent the BGP router ID.

Although BGP might receive advertisements for the same route from multiple sources, BGP selects only one path as the best path. BGP puts the selected path in the IP routing table and propagates the path to its peers.

The best-path algorithm runs each time that a path is added or withdrawn for a given network. The best-path algorithm also runs if you change the BGP configuration. BGP selects the best path from the set of valid paths available for a given network. Note The order of comparison determined in Part 2 is important. Consider the case where you have three paths, A, B, and C.

The AS-path attribute includes the list of autonomous system numbers AS numbers traversed in the advertised path. If you subdivide your BGP autonomous system into a collection or confederation of autonomous systems, the AS path contains confederation segments that list these locally defined autonomous systems.

This first step in the BGP best-path algorithm compares two paths to determine which path is better. The following sequence describes the basic steps that Cisco NX-OS uses to compare two paths to determine the better path:. Cisco NX-OS chooses a valid path for comparison.

For example, a path that has an unreachable next hop is not valid. Cisco NX-OS chooses the path with the highest weight. Cisco NX-OS chooses the path with the highest local preference.

Cisco NX-OS chooses the path with the lower origin. You can configure a number of options that affect whether or not this step is performed. If one path is from an internal peer and the other path is from an external peer, then Cisco NX-OS chooses the path from the external peer.

Cisco NX-OS uses the path that was selected by the best-path algorithm the last time that it was run. If all path parameters in Step 1 through Step 9 are the same, then you can configure the best-path algorithm to compare the router IDs. Note When using the attribute originator as the router ID, it is possible that two paths have the same router ID.

It is also possible to have two BGP sessions with the same peer router, and therefore you can receive two paths with the same router ID. Cisco NX-OS selects the path with the shorter cluster length. If a path was not received with a cluster list attribute, the cluster length is 0. Locally generated paths for example, redistributed paths have a peer IP address of 0. Note Paths that are equal after step 9 can be used for multipath if you configure multipath. Cisco NX-OS partitions the paths into groups.

Typically, this comparison results in one group being chosen for each neighbor autonomous system. If you configure the bgp bestpath med always command, then Cisco NX-OS chooses just one group that contains all the paths. Cisco NX-OS determines the best path in each group by iterating through all paths in the group and keeping track of the best one so far. Cisco NX-OS compares each path with the temporary best path found so far and if the new path is better, it becomes the new temporary best path and Cisco NX-OS compares it with the next path in the group.

The next part of the implementation is to determine whether Cisco NX-OS will use the new best path or suppress the new best path. The router can continue to use the existing best path if the new one is identical to the old path if the router ID is the same. Cisco NX-OS continues to use the existing best path to avoid route changes in the network. You can turn off the suppression feature by configuring the best-path algorithm to compare the router IDs. If you configure this feature, the new best path is always preferred to the existing one.

You cannot suppress the best-path change if any of the following conditions occur:. After selecting the best path, if BGP determines that the best path change needs to be reflected in the routing table, it sends a route update to the unicast RIB. It also receives route notifications about other protocol routes to support redistribution.

BGP uses these notifications to keep track of the reachability and IGP metric to the next-hop addresses. The following table shows the licensing requirements for this feature:. BGP has the following prerequisites:.

BGP has the following configuration guid elines and limitations:. Table lists the default settings for BGP parameters. From a mode, you can enter the? Use global configuration mode to create a BGP process and configure advanced features such as AS confederation and route dampening.

This example shows how to enter router configuration mode:. This example shows how to enter VRF configuration mode:. You can optionally configure the address families that BGP supports. Use the address-family command in router configuration mode to configure features for an address family. Use the address-family command in neighbor configuration mode to configure the specific address family for the neighbor.

You must configure the address families if you are using route redistribution, address aggregation, load balancing, and other advanced features. This example shows how to enter address family configuration mode from the router configuration mode:.

You can use neighbor configuration mode to configure all parameters for a peer. This example shows how to enter neighbor configuration mode:. This example shows how to enter VRF neighbor configuration mode:. An address family configuration submode inside the neighbor configuration submode is available for entering address family-specific neighbor configuration and enabling the address family for the neighbor.

Use this mode for advanced features such as limiting the number of prefixes allowed for this neighbor and removing private AS numbers for eBGP. This example shows how to enter neighbor address family configuration mode:. This example shows how to enter VRF neighbor address family configuration mode:. Configuring a basic BGP network consists of a few required tasks and many optional tasks. Optional show feature. Optional copy running-config startup-config. Optional Displays enabled and disabled features.

Use the no feature bgp command to disable the BGP feature and remove all associated configuration. Disables the BGP feature and removes all associated configuration. BGP must be able to obtain a router ID for example, a configured loopback address. Optional router-id ip-address. Optional network ip-prefix [ route-map map-name ]. 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.

However, there is a difference; a peer policy template will not collapse like a route map. Every sequence is evaluated, and if a BGP policy command is reapplied with a different value, it will overwrite any previous value from a lower sequence number. The directly applied peer policy template and the inherit peer-policy statement with the highest sequence number will always have priority and be applied last.

Commands that are reapplied in subsequent peer templates will always overwrite the previous values. This behavior is designed to allow you to apply common policy configurations to large neighbor groups and specific policy configurations only to certain neighbors and neighbor groups without duplicating individual policy configuration commands.

Peer policy templates support only policy configuration commands. BGP policy configuration commands that are configured only for specific address families are configured with peer policy templates. The configuration of peer policy templates simplifies and improves the flexibility of BGP configuration. A specific policy can be configured once and referenced many times. Because a peer policy supports up to eight levels of inheritance, very specific and very complex BGP policies can also be created.

When an IPv6 peer is configured, that neighbor is automatically activated under the IPv4 unicast address family.

You can manually activate the IPv6 neighbor under the IPv4 address family if, for example, you have a dual stack environment and want to send IPv6 and IPv4 prefixes. If you do not want an existing IPv6 peer to be activated under the IPv4 address family, you can manually deactivate the peer with the no neighbor activate command. Until then, existing configurations that activate an IPv6 neighbor under the IPv4 unicast address family will continue to try to establish a session.

Configuring a basic BGP network consists of a few required tasks and many optional tasks. A BGP routing process must be configured and BGP peers must be configured, preferably using the address family configuration model. The other tasks in the following list are optional:. Perform this task to configure a BGP routing process.

You must perform the required steps at least once to enable BGP. The optional steps here allow you to configure additional features in your BGP network. Several of the features, such as logging neighbor resets and immediate reset of a peer when its link goes down, are enabled by default but are presented here to enhance your understanding of how your BGP network operates. However, a BGP routing process and autonomous system can support multiple concurrent BGP address family and subaddress family configurations.

The configuration in this task is done at Router A in the figure below and would need to be repeated with appropriate changes to the IP addresses for example, at Router B to fully achieve a BGP process between the two devices.

No address family is configured here for the BGP routing process, so routing information for the IPv4 unicast address family is advertised by default. Configures a BGP routing process, and enters router configuration mode for the specified routing process. Use the autonomous-system-number argument to specify an integer, from 0 and , that identifies the device to other BGP speakers. Optional Specifies a network as local to this autonomous system and adds it to the BGP routing table.

For exterior protocols, the network command controls which networks are advertised. Interior protocols use the network command to determine where to send updates. Use the ip-address argument to specify a unique router ID within the network. Use the keepalive argument to specify the frequency, in seconds, with which the software sends keepalive messages to its BGP peer.

By default, the keepalive timer is set to 60 seconds. Use the holdtime argument to specify the interval, in seconds, after which the software, having not received a keepalive message, declares a BGP peer dead. By default, the holdtime timer is set to seconds. By default, the BGP sessions of any directly adjacent external peers are reset if the link used to reach them goes down. Optional Enables logging of BGP neighbor status changes up or down and neighbor resets.

Use this command for troubleshooting network connectivity problems and measuring network stability. Unexpected neighbor resets might indicate high error rates or high packet loss in the network and should be investigated. Only the syntax applicable to this task is used in this example. The following sample output from the show ip bgp command shows the BGP routing table for Router A in the figure above after this task has been configured on Router A.

You can see an entry for the network Use the ping command to check basic network connectivity between the BGP routers. The address family configured here is the default IPv4 unicast address family and the configuration is done at Router A in the figure above.

Remember to perform this task for any neighbor routers that are to be BGP peers. By default, neighbors that are defined using the neighbor remote-as command in router configuration mode exchange only IPv4 unicast address prefixes. To exchange other address prefix types, such as IPv6 prefixes, neighbors must also be activated using the neighbor activate command in address family configuration mode for the other prefix types, such as IPv6 prefixes.

Adds the IP address of the neighbor in the specified autonomous system to the IPv4 multiprotocol BGP neighbor table of the local router. The unicast keyword specifies the IPv4 unicast address family.

By default, the router is placed in configuration mode for the IPv4 unicast address family if the unicast keyword is not specified with the address-family ipv4 command. The multicast keyword specifies IPv4 multicast address prefixes. The vrf keyword and vrf-name argument specify the name of the virtual routing and forwarding VRF instance to associate with subsequent IPv4 address family configuration mode commands.

Enables the neighbor to exchange prefixes for the IPv4 unicast address family with the local router. The following sample output from the show ip bgp command shows the BGP routing table for Router A in the figure above after this task has been configured on Router A and Router B. You can now see an entry for the network Use the ping command to verify basic network connectivity between the BGP routers. The 4-byte AS numbers in this task are formatted in the default asplain decimal value format; for example, Router B is in AS number in the figure above.

To exchange other address prefix types, such as IPv6 prefixes, neighbors must also be activated using the neighbor activate command in address family configuration mode for the other prefix types. Enter your password if prompted. Enters router configuration mode for the specified routing process.

In this example, the 4-byte AS number, , is defined in asplain notation. Repeat Step 4 to define other BGP neighbors, as required. Specifies the IPv4 address family and enters address family configuration mode.

By default, the device is placed in configuration mode for the IPv4 unicast address family if the unicast keyword is not specified with the address-family ipv4 command. Enables the neighbor to exchange prefixes for the IPv4 unicast address family with the local device. Repeat Step 7 to activate other BGP neighbors, as required.

For exterior protocols the network command controls which networks are advertised. Exits address family configuration mode and returns to privileged EXEC mode. Optional Displays the entries in the BGP routing table. Optional Displays the status of all BGP connections. The following output from the show ip bgp command at Router B shows the BGP routing table entry for network The following output from the show ip bgp summary command shows the 4-byte AS number for the BGP neighbor Perform this task to modify the default output format for 4-byte autonomous system AS numbers from asplain format to asdot notation format.

The show ip bgp summary command is used to display the changes in output format for the 4-byte AS numbers. Changes the default output format of BGP 4-byte AS numbers from asplain decimal values to dot notation. This command affects only the output displayed for show commands or the matching of regular expressions. Clears and resets all current BGP sessions. In this example, a hard reset is performed to ensure that the 4-byte AS number format change is reflected in all BGP sessions.

Displays the status of all BGP connections. Displays routes that match the AS path regular expression. In this example, a regular expression to match a 4-byte AS path is configured using asdot format. Exits router configuration mode and returns to privileged EXEC mode. The following output from the show ip bgp summary command shows the default asplain format of the 4-byte AS numbers.

Note the asplain format of the 4-byte AS numbers, and Note the asdot format of the 4-byte AS numbers, 1. Although a 4-byte AS number can be configured in a regular expression using either asplain format or asdot format, only 4-byte AS numbers configured using the current default format are matched. In the first example below, the show ip bgp regexp command is configured with a 4-byte AS number in asplain format.

The match fails because the default format is currently asdot format and there is no output. In the second example using asdot format, the match passes and the information about the 4-byte AS path is shown using the asdot notation. The asdot notation uses a period, which is a special character in Cisco regular expressions. To remove the special meaning, use a backslash before the period. The address family configured here is the IPv4 VRF address family and the configuration is done at Router B in the figure below with the neighbor This task does not show the complete configuration required for VPN routing.

For some complete example configurations and an example configuration showing how to create a VRF with a route-target that uses a 4-byte autonomous system number, see.

Use the vrf-name argument to specify a name to be assigned to the VRF. Creates routing and forwarding tables and specifies the default route distinguisher for a VPN. Use the import keyword to import routing information from the target VPN extended community. Use the export keyword to export routing information to the target VPN extended community. Use the both keyword to import both import and export routing information to the target VPN extended community.