Route Reflector Cluster Calculator for BGP Labs

Connecting boxes is great, it’s how you build out a data center fabric or test one in a home lab. You get those boxes fired up and then give them their IP addresses and wait as they blink there lights. But now you’ve reached the routing layer and you’re confronted with reality of BGP.

Should all routers be full-mesh? That’s going to crush your CPU with a session count. In fact, the session count will crush your CPU before you even import a single prefix. This is where route reflectors comes into play. It breaks the need for a full mesh. Instead of peering with each and every router, let the clients peer with just a handful of reflectors.

How to Plan Your BGP Network

The math become tricky here and I built a calculator to run it for you. The biggest mistake engineers make is assuming that session count is the only metric that matters. They don’t. A “session” are a TCP connection. That doesn’t matter. What matters is path state… How many prefixes does each node has to learn? And how do you represent them? How much memory do you use for each one?

Remember, the reflector has to hold all these paths in memory because every prefix a client learns is reflected back to every other client. If you’re doing EVPN, then you aren’t just carrying IPv4 routes. You’re carrying Ethernet auto-discovery entries, MAC/IP routes and multicast entries too. Each of these address families takes its own Adj-RIB. They also consume distinct memory! You can choose the number of address families with the tool, that affects the memory estimate. If you don’t pay attention to this then you might end up crashing due to out of memory issues when things grows large.

Churn. Remember that this is a dynamic network. And you have to account for things like a link going down or even someone changing a policy. How does the route reflector notify everyone? That’s what we call update fanout.

If there’s a lot of churn (such as when you’re drilling through a failover) then you need headroom. Update-group packing efficiency is a technical term for the ability of the daemon to batch up same updates to peers. So it’s able to group identical updates together for multiple peer.

Update fanout, how many clients the reflector has to update when a route changes? Path and session limits is not just about how much RAM you have. You’ll need plenty of processing power to encode & send those updates too!

Anything related to production requires redundancy, and there’s no room for negotiation. A single route reflector are a single point of failure. When it goes down your clients lose all their routes. Dual-homing is the traditional approach. Each client peers with two reflectors, which provides resilience. However, this mean double the number of client sessions different than a single reflector setup.

Changing the reflectors per client setting updates the session count automaticly on the calculator. Also note that it reminds you to maintain consistency in the Cluster ID. Your two reflectors in your cluster has different IDs, which the BGP protocol views as two distinct clusters. This breaks the reflection logic and creates loops.

But when it comes to memory sizing, our intuition goes out the window. There is no guessing what size of VM you want. Instead, you must understand how much space your paths are taking up (average path attribute size). Longer AS paths will be larger. More communities and more extended communities on an EVPN will also consume more space. The tool computes your total memory requirements by multiplying the number of prefixes times the number of paths per prefix times the size per path. That gives you a realistic memory budget.

Oversizing is good but overshooting is bad. You should of not run your BGP daemon anywhere near full memory. Ninety percent is not stable. Leave yourself some headroom; ideally twenty five percent for add-path scenarios and/or policy changes.

Lastly, there is topology. Small labs will benefit from flat clusters; large fabrics demand hierarchies. Combining these also comes at cost. You need to carefully plan to prevent path hiding problem. Thankfully, there are presets in the calculator for typical scenarios. These range from tiny dual-RR labs to giant metro POP clusters. They’re not hard rules but starting points. This help you know where to begin.

You tweak the inputs based off your policy requirements and hardware capabilities. You are not only connecting everything together. You are building a fabric that supports the weight of your routes. Respect the math, start with the basics. Let the control plane do what it does best.