Routing & BGP
Routing decides where every packet goes, and BGP (RFC 4271, TCP port 179) decides how a network talks to the rest of the Internet. Our team designs and runs BGP edges, internal routing and route-policy for multi-homed businesses, hosting providers and multi-region enterprises, on open-source routing daemons and carrier-grade router operating systems.
What we do
- BGP edge design for multi-homed and multi-region networks
- BIRD 2, FRRouting and OpenBGPD configuration and review
- Route policy with prefix filters, communities and large communities
- RPKI route-origin validation with Routinator or rpki-client feeding the routers over RTR
- BFD for fast detection of failed links and neighbors
- Route-server and IXP peering setups
- OSPF and IS-IS design for the internal core
- Session monitoring, change review and tested rollback
We build policy the way it should be built: prefix filters and communities on every session, large communities (RFC 8092) for traffic engineering, BFD (RFC 5880) for fast failure detection, and route-origin validation (RFC 6811) so invalid announcements are dropped. Where several networks meet, we also work with IXP route servers (RFC 7947).
This work sits under our Managed IT and Cybersecurity services. The same team that writes the routing policy monitors the sessions, reviews changes before they go live and keeps a rollback plan for each one.
Leading platforms we work with
- BIRD 2
- FRRouting
- OpenBGPD
- Arista EOS
- Cisco IOS XR
- Routinator
- rpki-client
- Juniper Junos
- Cisco IOS XE
- MikroTik RouterOS
Platforms and practices
- RPKI route-origin validation (ROV)
- RTR (RPKI-to-Router)
- BFD
- BGP communities & large communities
- IXP route servers
- OSPF & IS-IS
- Prefix filtering & route policy
- Multi-homed BGP edges
References
- BIRD Internet Routing Daemon (project site)
- FRRouting documentation (overview and protocol list)
- OpenBGPD (OpenBSD project)
- RFC 4271: A Border Gateway Protocol 4 (BGP-4)
- RFC 6811: BGP Prefix Origin Validation
- RFC 5880: Bidirectional Forwarding Detection (BFD)
- RFC 8092: BGP Large Communities Attribute
- RFC 7947: Internet Exchange BGP Route Server
- Routinator (NLnet Labs RPKI relying party)
- rpki-client
- Arista EOS (vendor page)
- Cisco IOS XR (vendor page)
- Wikipedia: Junos OS (network operating system, FreeBSD base; Juniper now part of HPE)
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
A BGP edge that survives a lost carrier
Two edge routers run BIRD 2, peer with two transit carriers and an internet exchange, validate every route with RPKI and detect a dead link in under a second with BFD, so traffic moves to the other carrier before users notice.
Failover in under a second
ISP A fails at 300 ms. BFD (RFC 5880) with a 50 ms interval and multiplier 3 declares the session down 150 ms later, BGP withdraws the routes, and the forwarding table repoints to ISP B. Traffic is back at full rate in well under a second; without BFD the router would wait for the 90 s BGP hold timer. Illustrative figures.
How we use Routing & BGP for clients
Managed IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreCybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreCloud Management
Cloud cost review and management, without compromising on quality or security.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhat is BGP and why does a business network need it?
BGP, the Border Gateway Protocol (RFC 4271, TCP port 179), is how your network exchanges routes with your internet providers and the rest of the Internet. You need it when you have your own address space or autonomous system number, or want to connect to more than one provider and have traffic move to the others when one fails.
What is the difference between SD-WAN and BGP multihoming?
BGP multihoming advertises your own prefixes to two or more providers, so the whole Internet can reach you through either and inbound and outbound paths follow routing policy. SD-WAN steers outbound traffic per application across circuits, usually behind provider-assigned addresses, and does not by itself make your public address space reachable through several providers. Larger designs often combine them: BGP at the datacenter edge, SD-WAN at branches.
What is RPKI route-origin validation and should we turn it on?
RPKI lets the holder of an address block publish a signed Route Origin Authorization saying which autonomous system may originate it. With route-origin validation (RFC 6811) your routers mark received routes as valid, invalid or not-found, and you can drop invalid ones. We recommend publishing ROAs for your own prefixes and validating at the edge, with a validator such as Routinator or rpki-client feeding the routers over RTR.
Which routing software do you use: BIRD, FRRouting or vendor routers?
We work with BIRD 2, FRRouting and OpenBGPD as well as router operating systems from the major vendors. The choice follows throughput, features, who will operate it and your budget; a Linux host running BIRD can handle many edges, while very high packet rates call for hardware routers. Whatever the platform, the policy is written the same way and documented.
What are BGP communities and how do they help?
A community is a tag attached to a route that tells a neighbor what to do with it, such as set a local preference, prepend, or not announce to a given peer. Providers publish their community lists, so you can steer traffic without calling anyone. Large communities (RFC 8092) extend the idea for four-byte AS numbers.
How do you protect against route leaks and prefix hijacks?
We filter what we accept and what we announce: strict prefix lists for customers, maximum-prefix limits on sessions, and RPKI validation on everything received. For our own space we publish ROAs and monitor for unexpected origins. These controls limit both accidental leaks and deliberate hijacks, though they do not replace upstream providers doing the same.