...
The advantage of having multiple namespaces is a stronger isolation and not having all routes and iptables crammed in one network stack. Also, this solution is completely transparent to processes (like dnsmasq, radvd, etc.). The major downside of this solution is a higher overhead (memory footprint in particular, in particular the increased memory footprint of the management plane as it is split into multiple processes (see below why it is needed). Also debugging will be somewhat more difficult. For example, for packet tracing one has to first switch to the proper network namespace or trace packets across multiple namespaces at once.
...
The main idea of Bridge Manager is to split an overloaded zedrouter and run management of every network instance in a separate Go routine. In this proposal we would go even further and suggest to run Bridge Manager (here called "NetNS manager" because it would manage an entire namespace) as a child process of zedbox (or as a separate containerd task). The main communication mechanism of EVE - pubsub - is already prepared for interprocess messaging.
Splitting the management plane into multiple processes increases overhead and for edge devices the most concerning is the memory footprint. Experimentally, it was estimated that the size of the NetNS binary would be around 22 MB.This was done simply by creating a Go binary importing all packages that are expected to be needed. Please note that this is only a subset of total process RSS. The rest is harder to estimate without fully implementing the NetNS manager. Given that we should support up to 256 network instances, this quickly adds up to hundreds of megabytes of extra memory usage.
The following diagram shows how network instances could be isolated from each other using network namespaces. As it can be seen, not only the network configuration is spread The following diagram shows how network instances could be isolated from each other using network namespaces. As it can be seen, not only the network configuration is spread across namespaces, but also the management plane is split into multiple processes (all of which increases complexity and overhead, thus making this proposal less appealing).
...
Development Steps (VRF Proposal)
| No Format |
|---|
PR 1: * Build Linux kernel with VRF support = https://www.pivotaltracker.com/story/show/178785411 PR 2: * LD-PRELOAD library for VRF-unaware processes = https://www.pivotaltracker.com/story/show/178785483 - or test 'ip vrf exec' as an alternative PR 3: * Eden test for local networks with overlapping IP subnets = https://www.pivotaltracker.com/story/show/178785541 subnets - without VRFs this test will be failing (i.e. would not be merged until PR 4 is done) PR 4: * Local & Switch Network instance (Create/Modify/Delete) = https://www.pivotaltracker.com/story/show/178785641 * ACLs = https://www.pivotaltracker.com/story/show/178785656 * Flow collection = https://www.pivotaltracker.com/story/show/178785689 collection * Network instance metrics = https://www.pivotaltracker.com/story/show/178785716 PR 5: * Eden test for VPN networks with overlapping traffic selectors = https://www.pivotaltracker.com/story/show/178785745 - without VRFs this test will be failing (i.e. would not be merged until PR 6 is done) PR 6: * VPN Network instance = https://www.pivotaltracker.com/story/show/178785793 |