At the heart of network infrastructure, BGP (Border Gateway Protocol) is the routing protocol that forms the backbone of the internet. By exchanging prefix information between different Autonomous Systems (AS), it ensures data packets reach the right destination. But the smallest mistake in BGP’s complex structure or its policies can turn into a real nightmare for network operators: “BGP Neighbor Wars.”
In this post we’ll cover in detail what BGP neighbor wars mean, how they threaten network stability, and which strategies you can apply to escape this operational nightmare. The goal is to give network admins a practical guide for understanding and resolving these tough scenarios.
What Are BGP Neighbor Wars?
BGP neighbor wars are situations where two or more BGP routers continuously disagree on routing decisions. They’re characterized by routers constantly offering each other different paths and each one trying to invalidate the other’s offer. The result is constant route flap for prefixes in the network, which seriously hurts network performance.
These wars typically come from misconfigured BGP policies, faulty AS Path Prepending, Local Preference mismatches or misinterpreted MED (Multi-Exit Discriminator) values. Instability in the network can hurt user experience and even cause service outages.
Common BGP Neighbor War Scenarios
BGP neighbor wars can emerge from various configuration mistakes or misunderstandings. Understanding these scenarios is critical for problem detection and resolution. Here are the most common ones:
AS Path Prepending Misconfigurations
AS Path Prepending is a technique where an AS lowers its preference for a path by adding its own AS number multiple times to the AS Path for a specific prefix. It’s used to redirect incoming traffic to another path. But wrong or aggressive AS Path Prepending can lead to neighbor wars.
For example, consider an AS connected to two different ISPs. If one ISP signals it doesn’t want traffic by adding more AS Path Prepending than the other, but the other ISP also applies a similar policy, both sides will try to push traffic to the other. That causes constant path changes and instability.
# Router A (AS 65001) configuration example
router bgp 65001
neighbor 192.0.2.1 remote-as 65002
neighbor 192.0.2.1 route-map PREPEND_PATH out
ip as-path access-list 1 permit .*
route-map PREPEND_PATH permit 10
match ip address prefix-list ADVERTISED_PREFIXES
set as-path prepend 65001 65001 65001Local Preference Mismatches
Local Preference is a BGP attribute that determines which path routers in an AS prefer when there are multiple exit paths to the same prefix. A higher Local Preference value means that path will be preferred. This attribute is generally used to direct traffic coming from inside.
If two ASes advertise different Local Preference values to each other for the same prefix, or apply inconsistent Local Preference policies in their internal networks, it can cause a neighbor war. For example, if AS A prefers a route from AS B with high Local Preference while AS B also prefers the route from AS A for the same prefix with high Local Preference, both ASes will want to route traffic through themselves. That creates a constant preference-change loop.
# Router A (AS 65001) configuration example
router bgp 65001
neighbor 192.0.2.1 remote-as 65002
neighbor 192.0.2.1 route-map SET_LOCAL_PREF_OUT out
route-map SET_LOCAL_PREF_OUT permit 10
set local-preference 200 # Higher preference for routes learned from this neighborMED (Multi-Exit Discriminator) Misunderstandings
MED is an attribute used to tell a neighbor AS which entry point to prefer when there are multiple entry points to your network. A lower MED value means that entry point is preferred. MED is generally used to optimize traffic flow within an AS.
But MED values are only compared between paths learned from the same neighbor AS, and they aren’t always a reliable selection criterion. Inconsistent or wrong application of MED values across different ISPs can make it hard for routers to determine the best path and lead to neighbor wars. Especially since some BGP implementations interpret MED differently, that can cause unexpected behavior.
Route Flap Damping
Route Flap Damping is a BGP feature that aims to increase network stability by temporarily hiding paths that constantly change (flap) in the network. If a path changes more often than a threshold, the damping mechanism kicks in and hides the path for a period. That helps reduce the load on the network.
But aggressive Route Flap Damping settings can mistakenly hide path changes caused by real network problems, or even worsen issues. Excessive damping can delay important path updates, masking the symptoms of BGP neighbor wars or making resolution harder. So damping settings need to be configured carefully.
# Cisco IOS example for BGP route-flap damping
router bgp 65001
bgp dampeningMax-Prefix Limit Violations
Setting a max-prefix limit on BGP peerings is an important security measure to limit the maximum number of prefixes that can be received from a neighbor. It prevents a neighbor from accidentally or maliciously advertising too many prefixes and from overloading the router’s resources (memory, CPU).
If a neighbor exceeds the defined max-prefix limit, the BGP session is typically closed and reset. If this repeats continuously, the BGP session keeps opening and closing — i.e. a “neighbor war.” This can happen especially when there’s a configuration error on the neighbor side or an unexpected prefix increase, increasing instability in the network.
# Router A (AS 65001) configuration example
router bgp 65001
neighbor 192.0.2.1 remote-as 65002
neighbor 192.0.2.1 maximum-prefix 10000 restart 60Methods to Detect BGP Neighbor Wars
Detecting BGP neighbor wars early is vital for protecting network stability. We can diagnose these issues using various tools and commands. Here are some effective methods:
- BGP session state monitoring: Check whether BGP sessions (peers) are repeatedly transitioning to “Active” or “Idle.” A stable session should be “Established.”
- Log records: Regularly review router logs. Messages indicating BGP sessions repeatedly going up and down,
max-prefix limitwarnings, or other BGP error messages can be heralds of a war. - Monitor prefix counts: Sudden or constant fluctuations in the number of prefixes received from or sent to neighbors can indicate a neighbor war.
- CPU and memory usage: Abnormally high CPU or memory usage on routers can stem from continuous BGP update processing.
- Network monitoring tools: Modern tools like Grafana, Prometheus, ELK Stack can be used to visualize BGP metrics (session state, prefix counts, route changes) and detect anomalies.
The following commands are frequently used to check BGP state:
# Cisco IOS / Juniper Junos CLI examples
# Show BGP session summary
show ip bgp summary
show bgp summary # Juniper
# Detailed info about a specific neighbor
show ip bgp neighbors 192.0.2.1
show bgp neighbor 192.0.2.1 # Juniper
# Show BGP log messages
show logging | include BGP
show log messages | match BGP # Juniper
# Show prefixes received or advertised
show ip bgp neighbors 192.0.2.1 received-routes
show ip bgp neighbors 192.0.2.1 advertised-routes
show route receive-protocol bgp 192.0.2.1 # Juniper
show route advertising-protocol bgp 192.0.2.1 # JuniperThese commands let you quickly check BGP session status, neighbor connection info and exchanged prefixes. Regular checks and automated alerts are vital for early detection of neighbor wars.
Strategies to Escape the Operational Nightmare
To avoid BGP neighbor wars and ensure network stability, you need to take proactive and systematic approaches. Here are some strategies you can apply to escape this operational nightmare:
Standard Configuration and Automation
Ensuring consistency in network device configuration is the foundation of preventing BGP neighbor wars. Using standardized configuration templates and leveraging automation tools (Ansible, Puppet, Chef, SaltStack) minimizes human error. That ensures all BGP routers are configured according to the same policies and best practices.
Automation doesn’t just reduce configuration errors — it also offers fast and error-free change management. When new BGP peerings are set up or existing policies are updated, automated processes greatly reduce the risk of inconsistency.
Proactive Monitoring and Alerting Systems
Continuous and proactive monitoring is critical for catching the first signs of BGP neighbor wars. Use a Network Monitoring System (NMS) to continuously track BGP session states, received/sent prefix counts and route changes. When certain thresholds are exceeded (e.g. a BGP session flapping more than a few times within a period), automatic alerts should fire.
These alerts give the network operations team immediate information and a chance to respond fast. That way, a potential neighbor war can be detected and resolved before it grows.
BGP Policy Review and Audits
BGP policies are the rules that define how the network behaves, and configuring them correctly is the key to preventing neighbor wars. Regularly review and audit BGP policies. Especially when a new peering agreement is signed or an existing one changes, make sure the related BGP policies are consistent and correct.
To prevent misunderstandings around mutual AS Path Prepending, Local Preference or MED values, communicate openly with your peers. Periodic audits help you detect potential conflicts and misconfigurations early.
Training and Awareness
A network operations team well-trained on BGP’s nuances, common error scenarios and troubleshooting techniques plays a vital role in preventing neighbor wars. Understanding BGP’s complex structure and policy mechanisms helps make right decisions and minimize mistakes.
Encourage knowledge sharing within the team and benefit from the experience of seasoned personnel for solving complex BGP issues. Regular training and workshops will increase your team’s BGP capability.
Safe Configuration Transitions
Every configuration change in the network carries potential risk. When changing BGP policies or peering settings, take a careful and controlled approach. All changes should pass through a change management process, be tested, and be supported by a rollback plan.
Applying changes in small steps and in a controlled way limits the impact of potential issues and lets you roll back fast. That’s an indispensable strategy especially for critical BGP peerings.
Conclusion
BGP neighbor wars can pose a serious threat to modern network infrastructures and turn into a real operational nightmare for network operators. These wars can lead to network instability, performance drops and even service outages. But with the right strategies and proactive measures, escape from this nightmare is possible.
Understanding scenarios like the AS Path Prepending misconfigurations, Local Preference mismatches, MED misunderstandings, misuse of Route Flap Damping and Max-Prefix Limit violations covered in this guide is the first step in preventing these issues. Standardized configurations, strong monitoring systems, regular policy audits and a well-trained team are the keys to protecting your network from these wars.
Don’t forget — a well-managed BGP infrastructure is the foundation of the smooth operation of the internet. Don’t hesitate to apply these steps to keep your network safe.