We understand that multi-hop BGP may seem less secure than traditional direct peering. This FAQ addresses common security concerns and demonstrates how proper configuration makes multi-hop BGP sessions just as secure—if not more secure—than traditional peering.

🔗 "We Are at the Mercy of Our Hops... But We Eliminate Them!"

Sounds like a paradox, right? Let us explain what makes Multihopix different from traditional internet routing:

The Problem: Normally, when you announce BGP routes over the internet, your packets traverse multiple autonomous systems (ASes) between you and your peers. Each hop is a potential point of failure or manipulation. Your traffic might bounce through Tier 3 to Tier 2 to Tier 1 to Peer, with each hop adding delay and uncertainty.

Our Solution: Multihopix acts as a BGP route server that eliminates intermediate transit hops. Instead of your announcements going through multiple providers to reach peers, we create direct BGP adjacencies. Think of it like this:

Traditional Multi-hop (many ASes):
You → ISP (AS1) → Tier-2 (AS2) → Tier-1 (AS3) → Peer (AS4)
↑ Multiple autonomous systems, policies, and delays

Multihopix Multi-hop (one logical hop):
You → Multihopix Route Server → Peer
↑ Direct BGP session, no intermediate AS policy interference

Technical Magic:

  • 🎯 eBGP Multi-hop with TTL >1: We establish direct BGP sessions over IP transport, bypassing intermediate AS boundaries
  • 🚀 Route Server Architecture: We're a transparent route reflector—your AS peers directly with other members
  • 🔐 Cryptographic Session Security: MD5/TCP-AO authentication ensures session integrity regardless of underlying transport
  • 📡 Encapsulation Options: GRE, WireGuard, or IPsec tunnels create point-to-point links over the internet
  • BGP Path Attributes Preserved: AS_PATH, MED, and communities pass through unchanged—no policy manipulation

The "Mercy" Part: Yes, your IP packets physically traverse intermediate networks to reach us (that's unavoidable, it's the internet). But from a BGP routing perspective, those intermediate networks don't see or touch your routing policy. Your BGP UPDATE messages are end to end encrypted and authenticated.

The "Eliminate" Part: We eliminate the BGP level hops (the AS_PATH length), not the physical network hops. Traditional IXPs give you single hop eBGP, but they require physical presence. We give you the same single hop BGP semantics over multi hop IP transport.

⚠️ Important Reality Check - Understanding the Path: While we eliminate BGP policy hops, your packets still traverse the same physical internet path. We just hide the intermediate hops from your traceroute. Here's what that looks like:

Traditional ISP to Datacenter Traceroute:
$ traceroute datacenter.example.tld
1 your-router.local (10.0.0.1) 0.5 ms
2 isp-gateway.provider.tld (10.20.1.1) 0.8 ms
3 isp-core1.provider.tld (10.20.1.5) 1.2 ms
4 transit-peer.backbone.tld (10.30.5.10) 1.8 ms
5 transit-core.backbone.tld (10.30.5.15) 2.3 ms
6 transit-edge.backbone.tld (172.16.10.50) 2.9 ms
7 datacenter-border.network.tld (172.16.10.51) 3.2 ms
8 datacenter-core.network.tld (10.40.8.20) 3.6 ms
9 datacenter-distribution.example.tld (10.1.1.100) 3.9 ms
10 datacenter.example.tld (10.1.1.101) 4.0 ms
↑ 10 visible hops, 4ms to datacenter

Multihopix Connection (Public ASN with /24):
$ traceroute your-static-ip.customer.tld
1 remote-source.tld (192.168.1.1) 0.3 ms
2 transit-gateway.backbone.tld (10.50.1.1) 0.9 ms
3 multihopix-datacenter.tld (172.16.10.50) 3.2 ms
4 customer-edge.network.tld (10.1.1.100) 3.9 ms
5 your-static-ip.customer.tld (10.0.0.50) 4.0 ms
↑ 5 visible hops, 4ms direct to your network

Multihopix Connection (Internal ASN):
$ traceroute your-static-ip.customer.tld
1 remote-source.tld (192.168.1.1) 0.3 ms
2 transit-gateway.backbone.tld (10.50.1.1) 0.9 ms
3 multihopix-datacenter.tld (172.16.10.50) 3.2 ms <-- Routes terminate here
4 multihopix-core.tld (172.16.10.51) 3.6 ms <-- Hair-pinned back out
5 isp-gateway.provider.tld (10.20.1.1) 4.2 ms
6 customer-edge.network.tld (10.1.1.100) 7.8 ms
7 your-static-ip.customer.tld (10.0.0.50) 8.0 ms
↑ 7 visible hops, 8ms (traffic goes to datacenter then back to you)

But your BGP session looks the same in both cases:
$ show ip bgp summary
Neighbor AS MsgRcvd MsgSent Up/Down State PfxRcd
172.16.10.50 65000 1543 1521 3d02h Estab 150
↑ Direct eBGP peer (AS_PATH length = 1), no intermediate ASes

What This Means: The Multihopix traceroute shows fewer visible hops because intermediate routers are hidden inside tunnels. However:

  • Public ASN (/24 block): Your routes are announced directly from our datacenter. Traffic flows straight to you (4ms). If you are receiving static IP addresses from us or have your own /24.
  • Internal ASN: Routes must be announced from our datacenter since you don't have provider-independent space. Traffic reaches the datacenter (4ms), then we route it back out to your location (additional 4ms = 8ms total). This is the "hair pin" routing pattern.

The Trade-off: You get simpler BGP (direct peering, clean AS_PATH) regardless of which plan you choose. We're still at the mercy of those "hidden" hops in the physical path. With Internal ASN, traffic makes an extra trip to our datacenter and back.

🤓 Nerd Translation: We're doing eBGP multi hop (IP TTL > 1) to create logical single hop BGP adjacencies. The "multi hop" is at Layer 3 (IP routing), but the BGP peering is direct. It's like using a VPN to your office. Sure, your packets hop through the internet, but your logical connection is point to point. We just do it for BGP at scale.

Is multi-hop BGP safe?

Yes, when properly configured. Multi-hop BGP with appropriate security measures provides the same level of security as direct BGP peering. The key is implementing proper authentication, filtering, and encryption.

Multi-hop BGP security relies on:

  • MD5 or TCP-AO authentication to prevent session hijacking
  • Prefix filtering to control what routes are accepted and advertised
  • AS-path filtering to prevent route spoofing
  • TTL security (GTSM) to protect against certain attack vectors
  • Optional: WireGuard or IPsec tunnels for encrypted transport

→ See secure configuration examples for Cisco, Juniper, and Mikrotik

How does Multihopix protect my BGP sessions?

Multihopix implements multiple layers of security:

  • Authentication: All BGP sessions require MD5 or TCP-AO authentication
  • Route Filtering: We enforce strict prefix filters on all peering sessions
  • RPKI Validation: Route Origin Validation prevents prefix hijacking
  • AS-path Filtering: Prevents unauthorized AS path manipulation
  • Rate Limiting: Protection against route flapping and excessive updates
  • Monitoring: 24/7 monitoring for anomalous routing behavior
  • Isolation: Customer sessions are isolated from each other

→ Learn how to configure these protections on your equipment

What prevents someone from hijacking my BGP session?

Multiple security mechanisms work together to prevent session hijacking:

  • Authentication: MD5 passwords or TCP-AO keys ensure only authorized peers can establish sessions
  • TTL Security (GTSM): Generalized TTL Security Mechanism prevents attackers from multiple hops away
  • Source Address Validation: Sessions only accept connections from configured peer IP addresses
  • Session Encryption: Optional WireGuard or IPsec tunnels encrypt all BGP traffic

An attacker would need to compromise multiple security layers simultaneously, which is cryptographically infeasible with proper configuration.

→ View implementation examples for maximum security

Can someone inject false routes into my network?

Not with proper filtering. Route injection is prevented through multiple mechanisms:

  • Prefix Lists: Only explicitly allowed prefixes are accepted
  • AS-path Filters: Routes must originate from authorized ASNs
  • RPKI/ROA Validation: Route Origin Authorization verifies prefix ownership
  • Maximum Prefix Limits: Sessions terminate if excessive routes are received
  • Community Filtering: Controls route propagation and prevents leaks

Even if an attacker somehow established a BGP session, they couldn't inject unauthorized routes past these filters.

→ See example prefix and AS-path filter configurations

Is multi-hop BGP more vulnerable than direct peering?

No, when properly secured. The attack surface is similar to direct peering, and in some cases, multi-hop with encryption is actually more secure.

Direct Peering Vulnerabilities:

  • Still vulnerable to session hijacking without authentication
  • Still requires prefix filtering and validation
  • Physical access to exchange point can compromise security
  • Traffic is typically unencrypted

Multi-hop BGP Advantages:

  • Can use encrypted tunnels (WireGuard/IPsec) for all traffic
  • No physical infrastructure at exchange points to compromise
  • Centralized security policy enforcement
  • Same authentication and filtering mechanisms apply

→ Compare security configurations for both scenarios

What encryption options are available?

Multihopix supports multiple encryption options for BGP sessions:

  • WireGuard: Modern, fast, and simple VPN (recommended for most users)
  • IPsec: Industry-standard encryption with broad device support
  • GRE over IPsec: Traditional approach for enterprise environments
  • TCP-AO: TCP Authentication Option for authenticated BGP without tunnels

While authentication alone (MD5/TCP-AO) prevents hijacking, encryption adds protection against eavesdropping and man-in-the-middle attacks.

→ See configuration examples for each encryption method

How do I verify my BGP session is secure?

Follow this security checklist to verify your BGP session configuration:

  1. Confirm MD5 or TCP-AO authentication is enabled and active
  2. Verify prefix filters are applied inbound and outbound
  3. Check AS-path filters are configured to prevent spoofing
  4. Enable maximum prefix limits appropriate for your peer
  5. Configure TTL security (GTSM) if supported
  6. Review logs for authentication failures or rejected routes
  7. Test failover scenarios to ensure redundancy works
  8. Validate RPKI is working if implemented

→ Use our security verification commands and scripts

What happens if security is breached?

Multiple safeguards limit the impact of any potential breach:

  • Automatic Session Termination: Invalid authentication causes immediate disconnection
  • Prefix Limit Protection: Excessive routes trigger session shutdown
  • Route Filtering: Invalid routes are dropped before entering your network
  • Monitoring Alerts: Anomalous behavior triggers immediate notifications
  • Isolation: Breaches are contained to the affected session only
  • Audit Logging: All session events are logged for forensic analysis

Our architecture ensures that even in worst-case scenarios, damage is contained and quickly identified.

Does Multihopix comply with security standards?

Yes. Multihopix implements industry best practices and complies with:

  • RFC 4271: BGP-4 core protocol specifications
  • RFC 2385: Protection of BGP Sessions via TCP MD5
  • RFC 5925: TCP Authentication Option (TCP-AO)
  • RFC 6811: BGP Prefix Origin Validation (RPKI)
  • RFC 7454: BGP Operations and Security best practices
  • RFC 5082: GTSM (Generalized TTL Security Mechanism)
  • MANRS: Mutually Agreed Norms for Routing Security

We follow NIST cybersecurity framework guidelines and participate in routing security communities.

Can I use my own security policies?

Absolutely. Multihopix provides baseline security, but you maintain full control over your router configurations. You can implement:

  • Custom prefix filters and route policies
  • Additional authentication layers
  • Your own encryption solutions (WireGuard, IPsec, etc.)
  • Stricter maximum prefix limits
  • Custom community tagging and filtering
  • Organization-specific security requirements

We provide templates and examples as starting points that you can customize for your specific needs.

→ View customizable security templates

What platforms are supported for secure BGP?

Multihopix supports secure BGP sessions on all major routing platforms:

  • Cisco IOS/IOS-XE/IOS-XR: Full support for all security features
  • Juniper JunOS: Complete implementation of security mechanisms
  • MikroTik RouterOS: BGP security with some platform limitations
  • Arista EOS: Enterprise-grade security features
  • Nokia SR OS: Carrier-class BGP security
  • BIRD: Open-source routing daemon with full security support
  • FRRouting (FRR): Linux-based routing with modern security features
  • VyOS: Open-source router with BGP security capabilities

→ See platform-specific configuration guides

Ready to Establish Secure BGP Sessions?

Follow our detailed security configuration guides for your routing platform

View Security Configuration Guide

Still Have Questions?

Our team is here to help you configure secure BGP sessions. Contact us for personalized assistance with your specific security requirements.

Contact Our Security Team →