VRF Route Leaking Calculator
Measure how much route leaking between VRFs amplifies the routing table under hub, mesh or selective policy.
About VRF Route Leaking Calculator
Leaking is implemented by importing route targets, and every imported prefix is a real FIB entry in the receiving VRF. A shared-services hub adds a fixed number of routes per VRF, while mutual full-mesh import multiplies the table by the VRF count. Route leaking is also the mechanism that quietly defeats the isolation the VRFs were built for, so the entry count is both a capacity number and a security review item.
Formulas
VRF Route Leaking
Hub leaking adds VRFs × shared routes; full-mesh leaking adds n(n − 1) × routes per VRF; selective leaking adds pairs × routes per VRF.
- route target
- The extended community that drives import and export between VRFs
- shared services
- A hub VRF holding DNS, NTP, monitoring and other common destinations
- amplification
- Total entries ÷ natively originated entries
Table amplification
amplification = (own routes + leaked routes) ÷ own routes.
Worked example
With the default values below, VRF Route Leaking Calculator returns Leaked Route Entries of 1,000. Change any input above and every figure here is recalculated in your browser.
Inputs used
- VRFsaccepts 2–2,000 VRFs
- 20 VRFs
- Routes originated per VRFminimum 1 routes
- 500 routes
- Shared-services routes each VRF importsminimum 0 routes
- 50 routes
- Leaking policyone of Shared-services hub — every VRF imports the hub, Full mesh — every VRF imports every other, Selective — named VRF pairs only
- Shared-services hub — every VRF imports the hub
- Leaking VRF pairs (selective only)accepts 0–10,000 pairs
- 12 pairs
Results
- Leaked Route Entries
- 1,000
- Total Route Entries
- 11,000
- Natively Originated Routes
- 10,000
- Table Amplification Factor
- 1.10 ×
- Entries if Fully Meshed
- 190,000
- Policy Verdict
- Shared-services hub scales linearly — 1.1× the native table
Step by step
- 1Values used
- 2VRF Route Leaking
- 3Table amplification
- 4Leaked Route Entries= 1,000
- 5Total Route Entries= 11,000
- 6Natively Originated Routes= 10,000
- 7Table Amplification Factor= 1.10 ×
- 8Entries if Fully Meshed= 190,000
- 9Policy Verdict= Shared-services hub scales linearly — 1.1× the native table
Assumptions and limits
- The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is VRF Route Leaking calculated?
Hub leaking adds VRFs × shared routes; full-mesh leaking adds n(n − 1) × routes per VRF; selective leaking adds pairs × routes per VRF. Leaking is implemented by importing route targets, and every imported prefix is a real FIB entry in the receiving VRF. A shared-services hub adds a fixed number of routes per VRF, while mutual full-mesh import multiplies the table by the VRF count.
Why does VRF Route Leaking matter?
Route leaking is also the mechanism that quietly defeats the isolation the VRFs were built for, so the entry count is both a capacity number and a security review item.
What values do I need to enter?
This calculator takes 5 inputs: VRFs, Routes originated per VRF, Shared-services routes each VRF imports, Leaking policy, Leaking VRF pairs (selective only). The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Is leaking or a firewall the right way to reach shared services?
Route the traffic through a firewall or fusion router when policy matters. Leaking gives any-to-any reachability between the leaked prefixes with no inspection point, which is rarely what a segmented design intended.