Vendor Quirks & Common Pitfalls in BGP Configuration

When it comes to configuring BGP, no two network vendors are exactly alike. While the fundamentals of BGP remain consistent—prefix exchange, neighbor relationships, route policies—the implementation, defaults, and command structures can vary significantly between platforms. These differences can lead to frustrating issues during the peering setup or troubleshooting process.

In this post, I walk through some key quirks and common pitfalls you might encounter when configuring BGP on MikroTik

RouterOS (v6 & v7), Cisco IOS, Juniper Junos, and Arista EOS.

---

MikroTik RouterOS v6: Legacy Gotchas

Quirks:

• Single-core BGP process: Performance bottlenecks on high-prefix-count routers. This can lead to slow route convergence.
• BGP filtering is extremely manual: Uses chains, but lacks the granular match conditions of other vendors. I prefer the V6 filters over v7 due to the ease of configuration.
• No proper VRF support: MPLS/VPN setups are extremely limited.

Common Pitfalls:

• Forgetting to set instance and router-id.
• Route filters applied inconsistently (especially inbound). The trick I always use is to go into filters and drag some around to kickstart it.
• IPv6 BGP sessions may appear up, but fail to exchange routes without proper prefix configuration and firewall adjustments.
• Changes in filters don’t always take effect immediately—requires a soft reset or neighbor disable/enable. Sometimes a reboot is necessary.

---

MikroTik RouterOS v7: Modernized but Still Evolving

Quirks:

• Rewritten BGP stack: Much improved but can appear quirky. Some of these quirks are GUI vs CLI quirks.
• Routing filters completely redesigned: More powerful but also more complex.

Common Pitfalls:

• Not defining separate filter chains per protocol family.
• Forgetting to add the network in ip/firewall/address list
• Not enabling BFD per-peer (default is off).
• Assuming ROSv7 behavior matches Cisco/Juniper in terms of prefix acceptance—it doesn’t.

---

Cisco IOS: Classic but Strict

Quirks:

• No BGP IPv6 by default: You must explicitly configure address-family ipv6.
• Needs no bgp default ipv4-unicast in dual-stack environments to prevent unwanted prefix leakage.
• No automatic next-hop self: You need to explicitly configure it.
• Soft-reconfiguration must be enabled to view inbound routes before applying filters. this is not on by default

Common Pitfalls:

• Missing neighbor activate under the appropriate address-family.
• Not using update-source when peering via loopback.
• Route-map logic errors: using a prefix-list in the wrong direction or missing a permit after a deny.
• Forgetting maximum-paths for ECMP/BGP load sharing.
• Know the difference between the FIB and RIB

---

Juniper Junos: Policy-Driven Everything

Quirks:

• Nothing is exported or imported by default: You must create and apply policies explicitly.
• Routing policies are very granular: Mistakes in term order or filter logic are common.
• Family-based BGP groups: Clear separation of IPv4/IPv6 under the hood.
• Loopback-based peering is common, but requires local-address and sometimes ebgp-multihop.

Common Pitfalls:

• Forgetting to apply export and import policies results in a BGP session that’s up—but no routes are exchanged.
• Route-filter terms like orlonger vs exact often misunderstood.
• Prefix-lists must match exactly, unlike some vendor defaults.
• Misunderstanding reject as a default policy action—it is.

---

Arista EOS: Cisco-Like with a Twist

Quirks:

• Cisco-style CLI, but with some added flexibility via EOS features.
• No soft reconfiguration support: Route refresh must be supported and used instead.
• Extensive JSON/structured CLI capabilities: Great for automation, confusing for manual users.
• Default maximum-prefix values are lower than Cisco/Juniper. This really is not an issue as you should be setting these specifically anyway. However, not knowing abotu a default behavior can cause issues.

Common Pitfalls:

• Not adjusting maximum-prefix—can cause peer drops on full table.
• Forgetting peer-group inheritance hierarchy, which can lead to inconsistent policies.
• Missing default-originate for default route injection.
• Confusing CLI hierarchy due to Arista’s mix of Cisco-style and structured commands.

---

Final Thoughts

Understanding the quirks and defaults of each vendor can save hours of troubleshooting and missed prefixes. While BGP is standardized, each vendor’s implementation decisions—from routing policy behavior to peer session setup—can break things in subtle ways.

Before blaming the peer, route server, or the IX, double-check:

• Address families activated?
• Route maps/policies applied?
• Prefixes actually in the routing table?
• Filters rejecting your advertisements?

Always read the documentation for your specific platform version. And if you’re working across multiple vendors, having a tested configuration template pack (such as the Juniper one) can smooth out cross-platform deployments.

The post Vendor Quirks & Common Pitfalls in BGP Configuration appeared first on j2sw Blog.