Our BGP multihoming turnkey solution includes BGP setup, BGP peering, and eBGP configuration. When using static routes with two providers, failover time can reach minutes — manual switching or waiting for BFD (if enabled) is required. This is unacceptable for services where every minute of downtime costs money. BGP (Border Gateway Protocol) solves this: it is a dynamic routing protocol that allows you to announce your own IP block and choose the best path based on policies. BGP (RFC 4271) provides fault tolerance and traffic balancing for multihoming. We specialize in BGP setup for multihoming, including BGP peering with two or more multihoming providers. Our eBGP configuration is a complete BGP turnkey solution that incorporates RPKI ROA, BFD BGP integration, and Cisco BGP traffic balancing. We also handle ASN acquisition and RIPE LIR registration. We configure BGP peering turnkey for two or more providers with guaranteed stability. We use BFD, RPKI, prefix-list, route-map. We support Cisco, Juniper, MikroTik, Linux FRR equipment. Timeline: from 3 to 5 days. Investment in BGP multihoming pays off through reduced downtime and traffic balancing, saving up to 30% on links. For an e-commerce site with $10,000 per hour revenue, BGP can prevent significant losses; investment starts from $2,500 for a basic multihoming setup. The full BGP turnkey solution is available for $7,500. Get a consultation from our engineer — we will assess your network and propose a solution.
Problems of Multihoming Without BGP
Without BGP, you are tied to static routes. When a link fails, failover takes minutes (until BFD triggers or you manually change routes). Traffic balancing is only equal-cost, without considering link load. Additionally, static routes do not protect against BGP hijack: an attacker can announce your IP block from another ASN, and traffic will be diverted.
BGP solves these issues: the protocol selects the best path based on policies, supports failover in seconds (with BFD), and allows control of inbound traffic via AS_PATH prepend and community.
| Parameter | Static Routes | BGP Multihoming |
|---|---|---|
| Failover time | Minutes (manual or BFD) | Sub-second (BFD 300 ms) |
| Traffic balancing | Only equal-cost | Per policies (LOCAL_PREF, weight) |
| Protection against hijack | No | RPKI, prefix-list, filtering |
| Traffic engineering (inbound) | Impossible | AS_PATH prepend, community |
| Prefix management | Manual | Automatic via BGP |
Why is BGP necessary for multihoming?
BGP is the only protocol that allows you to control routing between your AS and multiple providers. It enables announcing your own IP block, filtering prefixes, and applying local preferences. Without BGP, you cannot implement traffic engineering — for example, direct outgoing traffic through a cheaper provider and incoming traffic through a more reliable one.
How does BFD improve failover detection?
The default BGP hold timer is 90 seconds. If a physical link goes down, BGP only learns about it after 90 seconds. BFD (Bidirectional Forwarding Detection) reduces this to hundreds of milliseconds (e.g., 300 ms interval, multiplier 3 gives 900 ms detection). With BFD, when a link fails, the BGP session is torn down in ~900 ms — that's 100 times faster than the standard hold timer. We always enable BFD on all BGP peers.
Basic eBGP Configuration
Below is a configuration for two providers (ISP1 AS 65000, ISP2 AS 65001) on Cisco IOS. Our AS is 65100, block 198.51.100.0/24.
router bgp 65100
bgp router-id 198.51.100.1
bgp log-neighbor-changes
neighbor 203.0.113.1 remote-as 65000
neighbor 203.0.113.1 description "ISP1-Primary"
neighbor 203.0.113.1 password <BGP_MD5_PASSWORD>
neighbor 203.0.113.1 prefix-list OUR-PREFIX out
neighbor 203.0.113.1 prefix-list ISP1-ACCEPT in
neighbor 203.0.113.1 route-map ISP1-IN in
neighbor 203.0.113.1 route-map ISP1-OUT out
neighbor 203.0.114.1 remote-as 65001
neighbor 203.0.114.1 description "ISP2-Secondary"
neighbor 203.0.114.1 password <BGP_MD5_PASSWORD>
neighbor 203.0.114.1 prefix-list OUR-PREFIX out
neighbor 203.0.114.1 prefix-list ISP2-ACCEPT in
neighbor 203.0.114.1 route-map ISP2-IN in
neighbor 203.0.114.1 route-map ISP2-OUT out
network 198.51.100.0 mask 255.255.255.0
ip prefix-list OUR-PREFIX seq 10 permit 198.51.100.0/24
ip prefix-list OUR-PREFIX seq 20 deny 0.0.0.0/0 le 32
ip prefix-list ISP1-ACCEPT seq 10 permit 0.0.0.0/0
ip prefix-list ISP1-ACCEPT seq 100 deny 0.0.0.0/0 le 32
route-map ISP1-IN permit 10
set local-preference 200
route-map ISP2-IN permit 10
set local-preference 100
route-map ISP2-OUT permit 10
set as-path prepend 65100 65100 65100
route-map ISP1-OUT permit 10
MD5 authentication is mandatory for public BGP peering — it protects against BGP packet spoofing. To enable fast failover, add BFD on interfaces:
interface GigabitEthernet0/0
bfd interval 300 min_rx 300 multiplier 3
router bgp 65100
neighbor 203.0.113.1 fall-over bfdTraffic Engineering: Managing Inbound and Outbound Traffic
Outbound traffic is controlled by LOCAL_PREF: in the example above, ISP1 gets pref 200, ISP2 gets 100. All outbound traffic will go through ISP1 as long as it is alive. Inbound traffic is controlled by AS_PATH prepend: we add our AS three times to the announcement for ISP2, making the path through ISP2 longer. For fine-tuning, we use community: for example, blackhole community (65000:666) for RTBH (Remote Triggered Black Hole). With community, you can steer traffic by percentage, e.g., 65000:80 sends 80% traffic to ISP1.
RPKI and IRR: Protection Against Route Hijack
Registering a ROA (Route Origin Authorization) in RPKI ensures that only your AS can announce your IP block. Providers with ROV (Route Origin Validation) will not accept the route without a valid ROA. We also register the AS-SET in IRR RIPE and configure inbound prefix filtering. ROA validation typically completes in under one second.
Process of Setting Up BGP Multihoming
- Network audit: analysis of links, bandwidth, and fault tolerance requirements.
- Obtaining ASN and IP block (if not already owned): membership in RIPE, obtaining a public ASN and a /24 prefix.
- Configuration of BGP sessions: setting up neighbors, prefix filtering, routing policies (LOCAL_PREF, AS_PATH prepend, community).
- Implementation of BFD and monitoring: configure BFD on all interfaces (300 ms interval, multiplier 3), integrate with SNMP, Prometheus/Grafana for alerting on BGP state changes.
- Registration of RPKI and IRR: creating ROA, registering AS-SET, validating.
- Failover testing: simulating one provider outage, verifying switchover time (target < 1 second).
- Documentation and training: providing network diagram, operations manual.
Timeline and Cost
| Stage | Duration |
|---|---|
| BGP with one ISP + filtering | 1–2 days |
| Multihoming (2 ISPs) + traffic engineering | 3–5 days |
| RPKI + IRR registration + RTBH | 2–3 days |
| iBGP within AS + Route Reflector | 3–5 days |
| Complete AS with BGP policies + documentation | 1–2 weeks |
Cost is calculated individually after an audit. The financial benefit of BGP multihoming is clear: fault tolerance prevents revenue loss. For a typical e-commerce site, preventing one hour of downtime can save $10,000, so the investment of $2,500–$5,000 pays off quickly. The full BGP turnkey solution is available for $7,500. Contact us for a project assessment.
Work Deliverables
- Configuration of BGP sessions on your equipment (Cisco, Juniper, MikroTik, Linux stack).
- Setup of prefix-list and route-map filtering.
- Implementation of BFD on all links.
- Registration of RPKI and IRR (if required).
- Integration of BGP session monitoring into Prometheus/Grafana.
- Documentation: network diagram, policy description, operator runbook.
- Training of your personnel on basic operations (
show bgp summary, session verification).
Typical Mistakes
- Using private ASN for external peering (public ASN is mandatory).
- Lack of MD5 authentication — vulnerability to BGP hijack.
- Incorrect prefix-list configuration: announcing a prefix smaller than /24 will be rejected by providers.
- Ignoring BFD: failover time increases to minutes.
- Not using RPKI: your network can be hijacked (route hijack).
We guarantee that your BGP infrastructure will operate stably and securely. Our engineers have 10+ years of experience in configuring BGP for large projects. Order a consultation — we will assess your network.