The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes frequently asked questions (FAQs) about Border Gateway Protocol (BGP).
A. Refer to these documents for information on how to configure BGP and BGP functioning:
Configure BGP
BGP Case Studies
A. The use of a loopback interface ensures that the neighbor stays up and is not affected by malfunctioned hardware.
BGP uses the IP address configured on the physical interface directly connected to the BGP peer as the source address when it establishes the BGP peering session, by default. Issue the neighbor <ip address> update-source <interface> command in order to change this behavior and configure the BGP that speaks to the router to establish peering with the use of a loopback address as the source address.
Refer to Sample Configuration for iBGP and eBGP With or Without a Loopback Address for more information.
A. The order of preference varies based on whether the attributes are applied for inbound updates or outbound updates.
For inbound updates the order of preference is:
route-map
filter-list
prefix-list, distribute-list
For outbound updates the order of preference is:
filter-list
route-map | unsuppress-map
advertise-map (conditional-advertisement)
prefix-list|distribute-list
ORF prefix-list (a prefix-list the neighbor sends us)
Note: The attributes prefix-list and distribute-list are mutually exclusive, and only one command (neighbor prefix-list or neighbor distribute-list) can be applied to each inbound or outbound direction for a particular neighbor.
A. A network in the BGP table with a next hop address of 0.0.0.0 means that the network is locally originated via redistribution of Interior Gateway Protocol (IGP) into BGP, or via a network or aggregate command in the BGP configuration.
A. The community attribute is a transitive, optional attribute designed to group destinations in a certain community and apply certain policies (such as accept, prefer, or redistribute). This table shows the well-known BGP communities.
Community | Description |
---|---|
Local-AS | Use in confederation scenarios to not send packets outside the local autonomous system (AS). |
no-export | Do not advertise to external BGP (eBGP) peers. Keep this route within an AS. |
no-advertise | Do not advertise this route to any peer, internal or external. |
none | Apply no community attribute when you want to clear the communities associated with a route. |
internet | Advertise this route to the internet community, and any router that belongs to it. |
Refer to the Configure BGP Community Filtering section of Configure BGP for more information about the configuration of communities.
A. In Cisco IOS® Software Release 12.0 and later, you can configure communities in three different formats called decimal, hexadecimal, and AA:NN. By default, Cisco IOS uses the older decimal format. In order to configure and display in AA:NN, where the first part is the AS number and the second part is a 2-byte number, issue the ip bgp-community new-format global configuration command.
Note: BGP Community Attribute is a numerical value (arbitrary) that can be assigned to a specific prefix and advertised to other neighbors. Although the community attribute can be represented in decimal, hexadecimal, or AA:NN, it is still a 32-bit number. For example, any of these three configuration commands specify the community 30:20 (AS 30, number 20):
- set community 30:20
- set community 0x1E0014
- set community 1966100
Regardless of which command you use, the community displayed in the router configuration file and the BGP table is 30:20.
Refer to the Community Attribute section of BGP Case Studies , and Configure and Control an Upstream Provider Network with BGP Community Values for more information.
A. Auto-summary behavior has changed across Cisco IOS software releases. Initially, auto-summary was enabled by default. However, with Cisco bug ID CSCdu81680 this behavior has changed. In the latest Cisco IOS, auto-summary is disabled by default. When auto-summary is enabled, it summarizes the locally originated BGP networks to their classfull boundaries. Auto-summary is only enabled by default in the old versions. When auto-summary is disabled, the routes introduced locally into the BGP table are not summarized to their classfull boundaries. When a subnet exists in the routing table and these three conditions are satisfied, then any subnet of that classfull network in the local routing table can prompt BGP to install the classfull network into the BGP table.
Classfull network statement for a network in the routing table
Classfull mask on that network statement
Auto-summary enabled
For example, if the subnet in the routing table is 10.75.75.0 mask 255.255.255.0, and you configure network 10.0.0.0 under the router bgp command, and auto-summary is enabled, BGP introduces the classfull network 10.0.0.0 mask 255.0.0.0 in the BGP table.
Note: Only registered Cisco users can access internal Cisco tools and information.
If these three conditions are not all met, then BGP does not install any entry in the BGP table unless there is an exact match in the local routing table.
Note: If the AS that performs BGP does not own the complete classfull network, Cisco recommends that you issue the no auto-summary command under router bgp in order to disable auto-summary.
A. Use these commands in order to check if the IP blocks are announced to the directly connected ISP:
The show ip bgp neighbors <address> advertised-routes command shows which messages are sent.
The show ip bgp neighbors <address> routes command shows which messages are received.
Note: The show ip bgp neighbors <address> advertise-routes command does not take into account any outbound policies you have applied. In future Cisco IOS software releases, the command output can be changed to reflect the outbound policies. If there are two alternate paths to a destination, BGP always uses the best route to advertise.
In order to verify how the IP blocks get propagated to the global BGP mesh via the directly connected ISP, log onto a route server on the Internet and look for the BGP entries of the prefix in the route server.
A. Clear a BGP session when you change the inbound/outbound policy for this session. Issue the clear ip bgp x.x.x.x soft out command to clear a BGP session in order to bring outbound policy changes into effect. Issue the clear ip bgp x.x.x.x command in order to clear a BGP session to bring inbound policy changes into effect. If the neighbor has the soft reconfiguration capability, you can issue the clear ip bgp x.x.x.x soft in command. The BGP session can be cleared automatically if you set up the Optimized Edge Routing (OER). OER automatically clears the BGP session for both Inbound and Outbound directions. Refer to Setting Up OER Network Components for more information on OER.
Note: With Cisco IOS Software Release 12 and later, a new BGP Soft Reset Enhancement feature is introduced.
A. Yes, refer to ASA/PIX: BGP through ASA Configuration Example for complete configuration details.
A. AS numbers are globally unique numbers that are used to identify ASes, and which enable an AS to exchange exterior routing information between adjacent ASes. An AS is a connected group of IP networks that adhere to a single and clearly defined routing policy.
There are a limited number of available AS numbers. Therefore, it is important to determine which sites require unique AS numbers and which do not. Sites that do not require a unique AS number use one or more of the AS numbers reserved for private use, which are in the range from 64512 to 65535. Access the AS Number Registration Services website to obtain an AS number.
A. BGP path selection criteria is documented in BGP Best Path Selection Algorithm.
A. A complete explanation of the differences between these commands is documented in How the bgp deterministic-med Command Differs from the bgp always-compare-med Command.
A. iBGP sessions preserve the next hop attribute learned from eBGP peers. This is why it is important to have an internal route to the next hop. The BGP route is otherwise unreachable. In order to make sure you can reach the eBGP next hop, include the network that the next hop belongs to in the IGP or issue the next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. Refer to the BGP Next Hop Attribute section of BGP Case Studies for a more detailed explanation.
A. No, eBGP sessions between confederation sub-ASes do not modify the next hop attribute. All iBGP rules still apply to have the whole AS behave as a single entity. The metric and local preference values also remain unaltered among confederation eBGP peers. Refer to the BGP Confederation section of BGP Case Studies for more information about confederations.
A. In eBGP peering, the next hop is the IP address of the neighbor that announces the route. However, when the route is advertised on a multi-access media (such as Ethernet or Frame Relay), the next hop is usually the IP address of the router interface connected to that media, which originated the route. Refer to the BGP Next Hop Attribute of BGP Case Studies for a more detailed explanation.
A. By default, the next hop attribute is not changed when a prefix is reflected by route reflector. However, you can issue the neighbor next-hop-self command in order to change the attribute of the next hop for prefixes reflected from an eBGP peer to any route reflector client.
A. BGP advertises routes from its BGP table to external peers by default. The BGP conditional advertisement feature provides additional control of route advertisement rest on on the existence of other prefixes in the BGP table. Normally, routes are propagated regardless of the existence of a different path. The BGP conditional advertisement feature uses the non-exist-map and advertise-map configuration commands to track routes by the route prefix. If a route prefix is not present in the non-exist-map command, the route specified by the advertise-map command is announced. Refer to the Configure BGP Conditional Advertisement section of Configure BGP for more information.
A. The amount of memory required to store BGP routes depends on many factors, such as the router, the number of alternate paths available, route dampening, community, the number of maximum paths configured, BGP attributes, and VPN configurations. Without knowledge of these parameters it is difficult to calculate the amount of memory required to store a certain number of BGP routes. Cisco typically recommends a minimum of 512 MB of RAM in the router to store a complete global BGP routing table from one BGP peer. However, it is important to understand ways to reduce memory consumption and achieve optimal routing without the need to receive the complete Internet routing table. Refer to Configure BGP Routers for Optimal Performance and Reduced Memory Consumption for more detailed information.
A. The major benefit of a BGP peer group is that it reduces the amount of system resources (CPU and memory) used in an update generation. It also simplifies BGP configuration since it allows the routing table to be checked only once, and updates to be replicated to all other in-sync peer group members. This can significantly reduce the load, which depends on the number of peer group members, the number of prefixes in the table, and the number of prefixes advertised. Cisco recommends that you group together peers with identical outbound announcement policies. Refer to BGP Peer Groups for more detailed information.
A. If your AS passes traffic from another AS to a third AS, BGP cannot advertise a route before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates the route within the AS and then advertises it to external peers. A BGP router with synchronization enabled does not install iBGP learned routes into its routing table if it is not able to validate those routes in its IGP. Issue the no synchronization command under router bgp in order to disable synchronization. This prevents BGP from not to authenticate iBGP routes in IGP. Refer to BGP Case Studies: Synchronization for a more detailed explanation.
A. The set metric-type internal route-map configuration command causes BGP to advertise a MED that corresponds to the IGP metric associated with the next hop of the route. This command is available in Cisco IOS Software Release 10.3 and later.
A. The default BGP ConnectRetry timer is 120 seconds. Only after this time passes does the BGP process check to see if the passive TCP session is established. If the passive TCP session is not established, then the BGP process starts a new active TCP attempt to connect to the remote BGP speaker. During this idle 120 seconds of the ConnectRetry timer, the remote BGP peer can establish a BGP session to it. Presently, the Cisco IOS ConnectRetry timer cannot be changed from its default of 120 seconds.
R1> show ip bgp BGP table version is 5, local router ID is 10.200.200.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path r> 10.6.6.0/24 10.10.13.3 0 130 0 30 i *> 10.7.7.0/24 10.10.13.3 0 125 0 30 i
When BGP tries to install the bestpath prefix into Routing Information Base (RIB) (for example, the IP Routing table), RIB can reject the BGP route due to any of these reasons:
Route with better administrative distance already present in IGP. For example, if a static route already exists in IP Routing table.
Memory failure.
The number of routes in VPN routing/forwarding (VRF) exceeds the route-limit configured under the VRF instance.
In such cases, the prefixes that are rejected for these reasons are identified by r RIB Failure in the show ip bgp command output and are advertised to the peers. This feature was first made available in Cisco IOS Software Release 12.2(08.05)T.
A. The redistribution of iBGP routes into Interior Gateway Protocol (IGP) —Enhanced Interior Gateway Routing Protocol/Open Shortest Path First/Intermediate System-to-Intermediate System (EIGRP/OSPF/IS-IS)— can cause routing loops within the Autonomous System, which is not recommended. By default, iBGP redistribution into IGP is disabled. Issue the bgp redistribute-internal command in order to enable redistribution of iBGP routes into IGP.
Note: Precautions must be taken to redistribute specific routes with route-maps into IGP.
A sample configuration to redistribute an iBGP learned default route 0.0.0.0/0 into EIGRP is shown in this output. Configurations for OSPF/IS-IS are similar.
router bgp 65345 [...] bgp redistribute-internal ! router eigrp 10 [...] redistribute bgp 65345 route-map check-def ! ip prefix-list def-route seq 5 permit 0.0.0.0/0 ! route-map check-def permit 10 match ip address prefix-list def-route
Note: After you configure the bgp redistribute internal command, ensure that clear ip bgp command is entered so as to clear all routes in the local routing table.
A. The specific routes can be filtered if you use inbound filter-list, distribute-list, prefix-list and route-map all at the same time for the same bgp neighbor. This is the order of operation:
Filter-list
Router-map
Distribute-list (or) prefix-list
A. The reason for the error message protocol not in this image is because BGP feature is not supported in the Cisco IOS version that runs on the router. In order to resolve this error, upgrade the Cisco IOS to a later Cisco IOS version that supports BGP.
A. This message only shows up when a BGP debug is turned on the router. It is just an informational message and not an error message. This informational message relates to BGP internal timers. This message can be ignored by the undebug all command.
A. Yes, it is possible to track the state change of an interface and route availability with the Enhanced Object tracking.
A. IP RIB Update allocates the prefixes, and attributes are held in chunks. It is not possible to free the entire chunk until every element in the chunk is freed. If more routes are learned, then those free elements in the chunks are used.
A. The show bgp ipv6 unicast summary command is used to see the IPv6 BGP neighbours
A. For example:
network 10.150.0.0 mask 255.255.0.0 no auto-summary
ip route 10.150.0.0 255.255.0.0 Null0
The router stops to advert the route but it still sends the other most specific routes.
A. It is the normal behaviour, as bfd hellos are sent in sub minimal seconds and in case you run debugs for that, the router cannot handle. So the bfd messages are seen in debug only when flaps happens. This is the purpose of the debug bfd
command:
debug bfd events
This command enables the logging of BFD events for all the currently configured BFD sessions. It captures BFD events like session state change, session configuration change triggered by local CLI or by remote end.
debug bfd packets
This command enables the logging of BFD packets for all the currently configured BFD sessions. It only captures BFD hello packets that are exchanged when there are bfd configuration changes like session state change happens. Normal BFD packets are not captured by this command.
A. If the new maximum number of Prefixes is larger that the current maximum, there is no need to soft/hard clear the BGP session, and reload is not required.
A. When AS-path prepending is set, the AS numbers to be prepended are appended to the AS-path and when the update leaves the AS towards the eBGP peers, the local AS number is prepended to the complete AS-path.
But, you can easily check whether the AS Path prending is done with one of these options:
Check the BGP AS PATH Attribute on Peering device. This is one of the easiest ways to check whether the router performs AS PATH prepending or not.
Run debug on BGP updates (in outbound direction) and then check for prepends. Use an access-list while you debug BGP updates.
Example: Router#debug ip bgp updates 1 out BGP: TX IPv4 Unicast Mem global 3 1 10.1.1.2 Refresh has to wait for net prepend. BGP: TX IPv4 Unicast Top global Start net prepend. BGP: TX IPv4 Unicast Top global Done net prepend (1 attrs). The router has prepended the prefix. BGP: TX IPv4 Unicast Grp global 3 Starting refresh after prepend completion.
Another option would be to take a packet capture on exit interface and see what update is sent on the wire.
A. The neighbor soft-reconfiguration inbound command causes the router to store all received (inbound) routing policy updates without modification, for example, a duplicate table is stored in the memory for each peer.
Note: This method is memory-intensive and not recommended unless absolutely necessary. Refer to the BGP Soft Reset enhancement in order to achieve the soft reset without the use of additional memory.
A. This message occurs when there is another BGP session already established. The router that receives the cease message has tried to send a BGP OPEN message to the same peer on another IP. This message is cosmetic and is due to a misconfiguration.
A. This error message indicates that there is not enough memory to accommodate BGP prefixes, learnt from neighbors.
A. Yes, GSR with Cisco IOS XR supports Route Reflector functionality for VPLS-BGP auto-discovery.
A. Use the debug bgp keepalive [vrf [vrf-name | all]] vpnv4 unicast command in order to debug routes for a given vrf in the Cisco IOS XR environment. This is a sample output:
*Mar 1 00:16:06.735: BGP: ses TWO 10.2.2.3 (0x69A1C8F4:1) Keep alive timerfired. *Mar 1 00:16:06.735: BGP: 10.2.2.3 KEEPALIVE requested (bgp_keepalive_timer_expired) *Mar 1 00:16:06.743: BGP: ses TWO 10.2.2.3 (0x69A1C8F4:1) service keepalive IO request. *Mar 1 00:16:06.747: BGP: 10.2.2.3 KEEPALIVE write request serviced in BGP_IO *Mar 1 00:16:07.759: BGP: ses ONE 10.1.1.1 (0x6900D344:1) Keep alive timer fired. *Mar 1 00:16:07.759: BGP: 10.1.1.1 KEEPALIVE requested (bgp_keepalive_timer_expired) *Mar 1 00:16:07.759: BGP: ses ONE 10.1.1.1 (0x6900D344:1) service keepalive IO request. *Mar 1 00:16:07.763: BGP: 10.1.1.1 KEEPALIVE write request serviced in BGP_IO
A. When you use the redistribution of IGP into BGP to advertise the route, then there is no need to specify the network statement for all the subnets individually. Also when the route is obtained from any other routing protocols into BGP table by redistribution, the Origin attribute is Incomplete (?) and when you specify the network command then it is Internal/IGP (i). During the route selection, the lowest origin code is preferred (IGP<EGP<Incomplete).
A. In order to view the summary information on Layer 4 forwarding, use the show mls cef summary command. For example:
Router#show mls cef summary Total routes: 532462 IPv4 unicast routes: 502841 IPv4 Multicast routes: 6 MPLS routes: 19794 IPv6 unicast routes: 9821 IPv6 multicast routes: 3 EoM routes: 0 Router#show mls cef maximum-routes FIB TCAM maximum routes : ======================= Current :- ------- IPv4 + MPLS - 512k (default) IPv6 + IP Multicast - 256k
Revision | Publish Date | Comments |
---|---|---|
4.0 |
28-Aug-2023 |
Recertification |
2.0 |
20-Jul-2022 |
Initial Release |
1.0 |
23-Oct-2001 |
Initial Release |