# Experimenting with Routing Protocols in the Data Center: An ns-3 Simulation Approach
## 5 Performance Analysis  
Given the possible massive size of a network (in number of nodes and links) in MSDCs, it is important to study how the simulator performs and scales with different network's sizes. Specifically, we decided to evaluate the scalability in two aspects, memory usage and simulation runtime for different network sizes. Even more, while developing and testing our implementation, we notice that the performance regarding memory usage and simulation time was a limiting factor to obtain results with big networks. Therefore, we decided to incorporate two features to improve the performance: disable the zebra daemon and disable IPv6 support. Regarding the first one, our implementation allows us to run a simulation without running the zebra daemon. In fact, a routing protocol in FRR does not need zebra to execute, therefore it can be tested correctly without using zebra. On the other hand, when disabling zebra, we lost the data plane functionality, and the kernel routing tables are not updated. This means that the nodes will exchange routing information following the routing protocol algorithm, but the routes will not be saved. As a consequence, there will not be connectivity between nodes. Nevertheless, as our objective is to study the behavior of the control plane only, in particular the convergence of BGP under different situations, the previous drawbacks do not affect our results. So as to be able to run a routing protocol (and BGP in particular) without zebra, some modifications and extensions are needed. For example, it is not possible to discover neighbor interfaces. For the case of BGP, this implies that in the configuration it is not possible to refer to the _BPG peers_ in a generic form using the interface. Instead, we must use the IP address. In our code, we provide all the configurations and modifications of the FrrHelper to run simulations with the zebra daemon disabled. Regarding IPv6, we notice a high load of IPv6 control packets such as _ICMPv6 Router Solicitation_ and _ICMPv6 Router Advertisement_ in our simulations. This was due to the use of the Linux kernel in DCE, which includes IPv6 in all interfaces by default. Therefore, our solution allows us to easily disable the use of IPv6 in all interfaces by executing a single command. Additionally, in the results we also show the execution time of each scenario. It can be seen that the experiments without zebra can run faster, taking approximately half of the time to execute in comparison with the experiments with zebra. Even more, when running without zebra, the simulations use much less RAM memory, which allows us  
Figure 5: Evolution of the results of ns-3 and Sibyl for the Leaf failure scenario, in comparison with the evolution of the polynomials \(P1=k^{3}-k\) and \(P2=\frac{5k^{3}}{4}-\frac{3k}{2}\). to experiment with bigger scenarios. Without zebra, we were able to run a scenario with 1125 nodes (15_15_1_*) while when using zebra, the biggest scenario was one with 320 nodes (8\(8\)1_*). In summary, if the objective of a given use case is only to test the control plane of a routing algorithm, it is recommended to disable the zebra daemon, as it has shown to improve the simulations performance in execution time and consumed memory. In order to illustrate the performance improvement that the above changes produced, the example 6\(6\)6_link-failure-spine-tof was run. In it, the changes will be applied independently, and then all together. Table 2 illustrates the results of execution time, memory used and improvement percentage for the introduced change. This improved version allows us to scale the experiments and perform the same scenarios performed with Sibyl in the work of reference [9]. Despite both experimentation environments managing the internal time differently, we can still compare the execution times and the resource consumption of each environment.