Change Details

To read the routing table, we call sysctl() with a NULL pointer to get the size of the result (needed), then allocate a buffer that large, and then call sysctl() for real. However, if you are operating a large router, like a BGP full feed, your routing table is changing rapidly, and the routing table may grow by one or more entries between the estimate, and the real read. Currently, this results in the confusing error message: ` # netstat -rnf inet Routing tables netstat: sysctl: net.route.0.2.dump.0: Cannot allocate memory ` On a router with 12GB of free memory. This patch will expand `needed` by 10% over the last estimate and try again. During convergence, when 100s of thousands of routes are being added rapidly, this can be the difference between being able to read the routing table, and not. This patch was inspired by one Hiroki offered on the mailing list in 2014. https://lists.freebsd.org/pipermail/freebsd-current/2014-February/thread.html#48412 That version of the patch only grew the buffer by 4kb, however the routing table in this case is over 180 MB, and the churn may be more than the ~16 additional routes that would fit in an extra 4kb of memory.

To read the routing table, we call sysctl() with a NULL pointer to get the size of the result (needed), then allocate a buffer that large, and then call sysctl() for real. However, if you are operating a large router, like a BGP full feed, your routing table is changing rapidly, and the routing table may grow by one or more entries between the estimate, and the real read. Currently, this results in the confusing error message: ` # netstat -rnf inet Routing tables netstat: sysctl: net.route.0.2.dump.0: Cannot allocate memory ` On a router with 12GB of free memory. This patch will expand `needed` by 10% over the last estimate and try again. During convergence, when 100s of thousands of routes are being added rapidly, this can be the difference between being able to read the routing table, and not. This patch was inspired by one Hiroki offered on the mailing list in 2014. https://lists.freebsd.org/pipermail/freebsd-current/2014-February/thread.html#48412 That version of the patch only grew the buffer by 4kb, however the routing table in this case is over 180 MB, and the churn may be more than the ~16 additional routes that would fit in an extra 4kb of memory.

To read the routing table, we call sysctl() with a NULL pointer to get the size of the result (needed), then allocate a buffer that large, and then call sysctl() for real. However, if you are operating a large router, like a BGP full feed, your routing table is changing rapidly, and the routing table may grow by one or more entries between the estimate, and the real read. Currently, this results in the confusing error message: ` # netstat -rnf inet Routing tables netstat: sysctl: net.route.0.2.dump.0: Cannot allocate memory ` On a router with 12GB of free memory. This patch will expand `needed` by 10% over the last estimate and try again. During convergence, when 100s of thousands of routes are being added rapidly, this can be the difference between being able to read the routing table, and not. This patch was inspired by one Hiroki offered on the mailing list in 2014. https://lists.freebsd.org/pipermail/freebsd-current/2014-February/thread.html#48412 That version of the patch only grew the buffer by 4kb, however the routing table in this case is over 180 MB, and the churn may be more than the ~16 additional routes that would fit in an extra 4kb of memory.