# Experimenting with Routing Protocols in the Data Center: An ns-3 Simulation Approach
## 4 Validation and Experimental Results
### Comparison against Sibyl Framework
#### 4.2.1 Experimental Setup  
The experiments consist on recording the number of Protocol Data Units (PDUs) exchanged among nodes until convergence of the routing protocol. In our case of study (the BGP protocol), this is equivalent to the number of BGP UPDATE messages. It worth noting that each experiment consider the propagation of a single network prefix for each leaf node in the topology, without losing generality in the results.  
When a simulation starts and the BGP protocol begins to execute, the nodes start exchanging UPDATE messages, until convergence is reached and the UPDATE messages cease to be exchanged. Convergence occurs when all topology information has been distributed (i.e., multi-path connectivity has been reached for every network prefix). Any change in the topology, or in the routing table of a node, generates a new exchange of UPDATE messages until convergence is reached again.  
A scenario comprises a certain fat-tree topology (determined by the parameters k_leaf, k_top and redundancy) and five different situations (test cases) that are described below:  
* Bootstrap: The objective is to study the standard behavior of the protocol in the topology when it is started, without any failure.
* Node Failure: This test case is used both to verify that BGP converges after a switch failure, and also to count the number of PDUs that the protocol exchanged for that purpose. The fault can be introduced in any type of switch in the topology, that is, Leaf, Spine or Tof. It is done by shutting down the BGP daemon on the given switch.
* Node Recovery: In this test case, the objective is to count the number of PDUs exchanged by the switches, after one of them fails and is replaced by a new one. Like the previous case, this case can be run on a Leaf, Spine, or Tof. We implement this case by raising the topology without running BGP on the node in question, we wait for it to converge and then we start BGP. This is equivalent to crashing the node and then starting it again.
* Link Failure: This case also has two goals. On the one hand, to verify BGP convergence after a link failure, and on the other hand, to count the number of PDUs for this purpose. The test can be run for both the Leaf-Spine link case and the Spine-Tof link case, simply by pulling down a given interface.
* Link Recovery: This case counts the number of PDUs after a failed link is replaced. That is, the simulation is started and the protocol is expected to converge. Link failure is then caused and the protocol is again expected to converge. Finally, the link is recovered and the new convergence is expected. The number of PDUs that are taken into account are those exchanged in this last phase.  
Each scenario is named using the following criterion: x_y_z_case-level, where:  
* x is the _k_leaf_ parameter.
* y is the _k_top_ parameter.
* z is the _redundancy_ parameter.
* case represents the test case, which can be link-failure, link-recovery, node-failure, or node-recovery.
* level depends on the case: -If the case is link-failure or link-recovery, level can be leaf-spine or spine-tof, referencing the level where link failure or recovery occurred. -If the case is node-failure or node-recovery, level can be leaf, spine or tof, referencing the level where the failure or recovery of the node occurred.  
The different scenarios where configured using the same values for _k_leaf_ and _k_top_ parameters so as to have homogeneous switches at the different levels of the fat-trees. On the other hand, for a given value of _k_leaf_ and _k_top_, we variate the _redundancy_ parameter, always considering that it divides the _k_top_ value. Moreover, during the different executions of the test cases, we vary the level where the failure is produced so as to cover all the possibilities.