Advisory: record's default prefix check lets a small leak pass¶
A baseline written by netdryrun record in 0.3.3 and 0.4.0 allows each BGP neighbor up to 20% more prefixes (at least 2) than today. So a change that leaks one or two extra prefixes from a neighbor can pass.
Our own end-to-end test found it on 31 October: deleting the match line of a customer's inbound route-map let the customer's 203.0.113.128/25 in, the recorded check allowed 1 to 3 prefixes, the neighbor sent 2, and netdryrun run passed. We released 0.4.0 on the same code without publishing it, which was our mistake.
- Workaround now:
netdryrun record <topology> --exact-prefixes, or set eachmax:to today's count, and addpresent: falseroute checks for prefixes that must never arrive. A pinned count still misses a leak that replaces a prefix at the same count. - Fix in 0.4.1:
recordadds a check that no new prefix arrives from each eBGP neighbor, and the release gate refuses a release while our end-to-end test reports a false pass. 0.3.3 and 0.4.0 will be yanked when it ships.