Skip to content

Topological Routing in DC

Jump to bottom Edit New page
gaixas1 edited this page Nov 18, 2016 · 20 revisions

Authors

  • primary contact Author1, institution,
  • Author2, institution
  • Author3, institution

Resources

  • link to the paper
  • link to the RINASim snapshot used in article

Scenario description

In this tutorial, we show how to configure and use topological routing and forwarding policies for datacenter. In special, we show how to work with the Groups Rules and Exceptions forwarding policies (GRE family) and both distributed and centralized routing.

The scenario used in this tutorial can be found under the folder “/examples/Tutorials/Topological_DC_Routing”, and is composed by the following files:

  • net.ned: Network description.

  • omnet.ini: Network and overall configuration.

  • shimqoscube.xml: QoSCubes definition for shim-DIFs.

  • qoscube.xml: QoSCubes definition for upper DIFs.

  • shimconnectionset[Central].xml: Definition of preconfigured flows.

  • qosreq.xml: QoS requirements of preconfigured flows.

  • directory.xml: Configuration of IPCP locations

The network described in “net.ned” is a modified clos DC network with 8 pods with 6 ToRs each and 4 spine-sets of 3 spines each as seen in figure X. In addition, for the centralized routing configuration, manager servers have been connected to the two first ToRs of each pod.

The main objective of this scenario is to show how routing and forwarding policies behave after some flow failures. In order to do that, multiple flows are “killed” after the network is stable and, after it has been stabilized again, all ToRs try to communicate between them.

In this scenario we consider 4 different configurations:

  • Default configuration

Errorless configuration with a default link state routing and forwarding tables.

  • GRE Static configuration “routingxceptions”

Errorless configuration with GRE policies without routing

  • GRE Distributed configuration “routingxceptionsErrors”

Scenario with multiple random errors, GRE policies and distributed erro-based routing.

  • GRE Centraliced configuration “centralized”

Scenario with multiple random errors, GRE policies and centralized erro-based routing.

Simulation setup

Net.ned

The configured network is that of a small datacenter network fabric connecting all ToRs in a Clos topology.

In this network, instead of more common used node modules, in order to test reachability between nodes, we use of “ReachabilityTest_Switch” nodes together with the “ReachabilityTest_Listener” in order to inject and monitor traffic between all ToRs in the network.

In addition, in order to randomly “kill” nodes, we use the “FailureSimulation”, in charge of listening to established flows and to decide if those have to be disconnected.

Finally, each pod has two ToRs connected to a “Manager” node. Those are used for the centralized routing scenario and represents servers located at the ToR Rack.

Omnet.ini

Let’s explain the basic configuration of the network. In this scenario, we have two DIF levels.

At base level “ipcProcess0” we have the shim DIFs (mediums) interconnecting all the nodes. For the configuration of those, we used a simple naming rule where each shim has a unique and node addresses where given as 0 to spine nodes, 1 to fabric nodes, 2 to ToRs and 3 to Masters. Then, at time = 0, flows through all shims are allocated, connecting upper IPCPs, as described in “shimconnectionset.xml”.

In the upper layer, we have the “F” DIF, where addresses where given location dependent as hexadecimal values in the form AABB (being AA the group, either spine-set or pod, and BB the node id within that group). In that DIF, we don’t pre-allocate any flow, as all the testing in this scenario is done via PDUs directly injected into the RMT.

Algo de codigo?

Routing and forwarding

In order to rely correctly PDUs between the different DIF levels, routing and forwarding policies are configured as follows:

  • At shims, not needed, “on wire”.

  • At the F DIF we have multiple configurations:

  • Default configuration

In the default configuration, a simple link state and forwarding table is used.

**.ipcProcess1.resourceAllocator.pdufgPolicyName = "SimpleGenerator"
**.ipcProcess1.relayAndMux.ForwardingPolicyName = "MiniTable"
**.ipcProcess1.routingPolicyName = "SimpleLS"
  • routingxceptions

In this scenario, we have the basic GRE configuration without the use of routing.


## Routing static rules&exceptions
**._*_F*.ipcProcess1.resourceAllocator.pdufgPolicyName = "StaticGenerator"
**._*_F*.ipcProcess1.relayAndMux.ForwardingPolicyName = "SimpleTable"
**._*_F*.ipcProcess1.routingPolicyName = "DummyRouting"
**._{0..2}_*.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_Clos2R"
**._{0..2}_*.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos2"

**._*_{0..2}.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_Clos1R"
**._*_{0..2}.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos1"

**._*_*.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_Clos0R"
**._*_*.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos0"

**.ipcProcess1.resourceAllocator.pduFwdGenerator.pods = 8
**.ipcProcess1.resourceAllocator.pduFwdGenerator.fabrics = 3
**.ipcProcess1.resourceAllocator.pduFwdGenerator.spines = 4
**.ipcProcess1.resourceAllocator.pduFwdGenerator.tors = 6

**.ipcProcess1.routingPolicyName = "eRouting"
  • routingxceptionsErrors

In this scenario, we have a GRE configuration with distributed routing.

**._*_F*.ipcProcess1.resourceAllocator.pdufgPolicyName = "StaticGenerator"
**._*_F*.ipcProcess1.relayAndMux.ForwardingPolicyName = "SimpleTable"
**._*_F*.ipcProcess1.routingPolicyName = "DummyRouting"

**._{0..2}_*.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_Clos2R"
**._{0..2}_*.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos2"

**._*_{0..2}.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_Clos1R"
**._*_{0..2}.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos1"

**._*_*.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_Clos0R"
**._*_*.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos0"

**.ipcProcess1.resourceAllocator.pduFwdGenerator.pods = 8
**.ipcProcess1.resourceAllocator.pduFwdGenerator.fabrics = 3
**.ipcProcess1.resourceAllocator.pduFwdGenerator.spines = 4
**.ipcProcess1.resourceAllocator.pduFwdGenerator.tors = 6

**.ipcProcess1.routingPolicyName = "eRouting"
  • centralized

In this scenario, we have a GRE configuration with centralized routing.

**._*_F*.ipcProcess1.**.addrComparatorName = "EndPoint"
**.ipcProcess1.**.addrComparatorName = "ReachabilityTest_Comparator"

## Routing default Link state
**._*_F*.ipcProcess1.resourceAllocator.pdufgPolicyName = "GRE_ManagerClos"
**._*_F*.ipcProcess1.relayAndMux.ForwardingPolicyName = "DefaultGW"


**._{0..2}_*.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_ClosSpine"
**._{0..2}_*.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos2"

**._*_{0..2}.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_ClosFabric"
**._*_{0..2}.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos1"

**._*_*.ipcProcess1.resourceAllocator.pdufgPolicyName ="GRE_ClosToR"
**._*_*.ipcProcess1.relayAndMux.ForwardingPolicyName = "Clos0"


**._*_F*.ipcProcess1.routingPolicyName = "RoutingManager"
**._{0..2}_*.ipcProcess1.routingPolicyName = "RoutingDumb"
**._*_*.ipcProcess1.routingPolicyName = "RoutingClient"

**.ipcProcess1.resourceAllocator.pduFwdGenerator.pods = 8
**.ipcProcess1.resourceAllocator.pduFwdGenerator.fabrics = 3
**.ipcProcess1.resourceAllocator.pduFwdGenerator.spines = 4
**.ipcProcess1.resourceAllocator.pduFwdGenerator.tors = 6

**.ipcProcess1.routingPolicy.pods = 8
**.ipcProcess1.routingPolicy.fabrics = 3
**.ipcProcess1.routingPolicy.spines = 4
**.ipcProcess1.routingPolicy.tors = 6

Data injection

Results

  • how to run the scenario in order to reproduce same results as in the paper
  • result analysis including how to interpret them
  • fingerprint check
Add a custom footer
Add a custom sidebar
Clone this wiki locally