# Megalos: A Scalable Architecture for the Virtualization of Large Network Scenarios +
## 8 Conclusions & Future Work  
We proved that, by using off-the-shelf container-based technologies (Docker and Kubernetes) and standard network protocols (VXLAN and EVPN BGP), it is possible to build a framework that allows us to emulate in a distributed environment large and complex network scenarios. In particular, we presented Megalos, a scalable, and distributed architecture, that supports the implementation of virtual network scenarios consisting of several networking devices (VDs) where each VD:  
1. can implement a fully-fledged network device and
2. can have several Layer 2 interfaces, each connected to a virtual LAN. Some problems, mainly of technical nature, remain open. Megalos architecture inherits from Kubernetes some limitations. For example, when the latency among the cluster nodes is too high, Kubernetes is not guaranteed to work as worker nodes appear to be unreachable due to the Kubernetes timeout values. This may cause problems when the cluster is geographically distributed among weakly connected  
Figure 6: Number of VDs, number of interfaces, and startup times (in minutes) for Fat-Trees networks of increasing size. White boxes are obtained on a local virtual cluster. Black boxes are obtained on an Azure cluster. Figure 7: Startup times (in seconds) of a VD with a given number of network interfaces. sites. Empirically, we measured that 300 ms of delay among two cluster nodes is a too high value for Kubernetes to work properly. A second limitation is that Kubernetes currently supports containers only and does not support virtual machines. This rules off hybrid VM/container scenarios which would allow us to emulate network functions that are impractical to containerize. Examples of such non-containerizable devices are those that need additional kernel modules or specific kernels different from the Kubernetes worker ones. These include devices using a different Operating System; platform using the Soft-RoCE [56] kernel module; some vendor router images distributed via VM only; etc. A solution to this limitation could come from the project KubeVirt [57], aimed at allowing Kubernetes to also manage VMs. The compatibility of KubeVirt with Megalos architecture and, in particular, with Megalos CNI has to be further investigated. A third limitation inherited from Kubernetes is that IPv6 is not yet fully supported for the addresses of the cluster nodes. We remark, though, that Megalos emulation pushes itself down to Layer 2, allowing arbitrary Layer 3 protocols for the virtual LANs, including IPv6. IPv6 support in Kubernetes will be likely introduced in the future versions (up to now it is only provided in the beta version). A limitation of Megalos coming from the use of Multus CNI is the impossibility to dynamically modify the number of network interfaces after the VD's deployment. Until Multus CNI does not support the dynamic creation and deletion of network interfaces, this limitation cannot be easily addressed. In addition to solving some of the limitations above, future work include the following. * Investigate the technical feasibility of using Kubernetes instances provided directly by public clouds like Amazon Web Services, Microsoft Azure, or Google Cloud Platform. This would improve the usability of Megalos and reduce the costs of an emulation. * Improve the flexibility of Megalos by allowing external software components to interface with it, leveraging on standard protocols (e.g., via REST APIs). * Support IPSec for the connections among VTEPs in different worker nodes, allowing the encryption of the traffic flowing into virtual LANs. * Use Megalos to perform an emulation of the current network of the Autonomous Systems in the Internet. All authors were involved in conceptualization, methodology, investigation, validation, formal analysis, and writing; L.A. and M.S. took also care of software, data curation, and visualization; G.D.B. and M.P. were involved in supervision, project administration, and funding acquisition. All authors have read and agreed to the published version of the manuscript.