NetSim Support Portal

SWITCHlan is the national research and education network in Switzerland. It is operated by SWITCH, the Swiss National Research and Education Network organization. It connects Swiss universities, research institutions, and other educational organizations, providing them with high-speed and reliable network connectivity. It allows Swiss institutions to benefit from global connectivity and participate in international research collaborations.  

     Fig 1: The network connection between universities of different cities in Switzerland

NetSim allows you to model and simulate complex networks, including LANs and WANs, using different types of network devices. By abstracting SWITCHlan with routers and WAN links in NetSim, you can simulate various traffic loads, test different configurations, and evaluate the performance of the network under different conditions. 

Each router would represent a network node or institution within the SWITCHlan network. The WAN links would simulate the connections between these nodes, allowing the simulation to mimic the behavior and performance of the actual network.

NetSim can provide a realistic representation of the SWITCHlan network in a simulated environment. As part of this study, we develop traffic models between the cities by considering different cases.

A network scenario is created to connect universities in 6 cities. It uses 1 router and 1 server per city.

Fig 2: Network Scenario in NetSim having a router and a server for each city. Every link has a capacity of 10 Mbps

In this network, we configure traffic to flow from each city to every other city. Since there are 6 cities, we have a total of 6*5 = 30 traffic flows

Case 1: The traffic rate in each flow is 1.9 Mbps 

The traffic rate of 1.9 Mbps is chosen because there are 5 flows through any of the bottleneck links (connecting the router to a server) in one direction. The 5 flows are nothing but traffic coming in (and going out) from (to) the other 5 cities. Thus the bottleneck flow rate is ~ 2 Mbps (10 Mbps / 5). We, therefore, start with 1.9 Mbps which is just below the saturation capacity of 2 Mbps per flow.  The parameter configuration is as below.

Table 1: Network settings for Case 1

We enable application and delay plot and run the simulation for 50 seconds.

Fig 3: Enabled Application and Latency plot from NetSim design window

The following plots shows the Application throughput for traffic between Lausanne and Zurich.

                            Fig 4: NetSim plot of throughput vs. time for traffic flowing from Lausanne to Zurich

Fig 5: NetSim plot of throughput vs. time for traffic flowing from Zurich to Lausanne

In the application metrics, we observe that the packets generated total 7978, packets received are 7922, and errored packets are 56. The mean generation rate is 1.90 Mbps, and the obtained throughput is 1.84 Mbps. The small difference is due to the errored packets. 

Fig 6: Simulation results shown in Application metrics

The spread occurs because we are generating a variable bit rate, not a constant one, with a mean of 1.9 Mbps. This is achieved using an exponential random variable for inter-arrival time to simulate real-world traffic flow

The following plots show the Latency vs. Time for traffic between Lausanne and Zurich Servers

Fig 7: Delay vs Time for traffic from Lausanne to Zurich servers.

                                Fig 8: Delay vs Time for traffic from Zurich to Lausanne servers.
 

We see that the average latency is not continuously increasing, but only varies around a mean. From this, we can infer that the network is able to fully handle the traffic flows between these two end points. 

OSPF convergence time:  We define the time at which the first data packet is forwarded by the Router as the convergence time. From the packet trace, we see that in this example, OSPF tables have converged at time ~1217 µs or 1.2 ms (highlighted in orange). The 3 entries seen in the packet trace at 1217 µs are transmissions starting at 3 routers after table convergence. 

Download the attached exported file, Swiss_University_case1_GN_1.9Mbps.netsimexp, and import the exp file into NetSim and run the simulation on your machine to see the results for case 1. 

Case 2: The traffic rate is 1.95 Mbps. (Set below 2Mbps bottleneck)

We now increase the generation rate to 1.95 Mbps

Table 2: Network settings for Case 1

Run the simulation and observe the Application Throughput Plot:

                               Fig 9: NetSim plot of throughput vs. time for traffic flowing from Lausanne to Zurich

                              Fig 10: NetSim plot of throughput vs. time for traffic flowing from Zurich to Lausanne

We observe application throughput is less than the generation rate of 1.95. However, we cannot immediately say if the network can or cannot handle this traffic load of 1.95 Mbps. To correctly estimate we need to observe how latency varies with time

Fig 10: Simulation results shown in Application metrics

The following plots show Latency vs. Time for traffic between Lausanne and Zurich Servers

                                      Fig 11: Delay vs Time plot for traffic from Lausanne to Zurich servers.
 

                                      Fig 12:  Delay vs Time plot for traffic from Zurich to Lausanne servers.
 

We see latency increasing with time. This is a sign of queuing and an indication that the network is unable to handle the traffic load of 1.95 Mbps. Saturation occurs somewhere between 1.90 to 1.95 Mbps. 

Download the attached exported file, Swiss_University_case2_GN_1_95Mbps .netsimexp, and import the exp file into NetSim and run the simulation on your machine to see the results for case 2. 

Case 3: Link failure (Link 4 at 10 sec)

Next, we study the impact of link failure. To do so, we fail the Basel – Zurich link at t = 10s by setting downtime to 10s in link 4 properties.

Fig 13: Network scenario in NetSim with link failure in link 4

 Parameter configuration

Run the simulation and see the Application Throughput Plot:

                              Fig 14: NetSim plot: throughput vs. time for traffic flowing from Lausanne to Zurich

                             Fig 15: NetSim plot: throughput vs. time for traffic flowing from Zurich to Lausanne

See how the throughput changes after the 10th second when the Basel – Zurich link fails, this affects all other links since Basel – Zurich traffic is now routed on other links. Therefore Lausanne – Zurich, and Zurich – Lausanne traffic is affected by this failure. Throughput falls to 1.2 Mbps after the 10th second.

The following plots explain the Latency vs. Time for traffic between Lausanne and Zurich Servers

                                 Fig 16: Delay vs Time plot for traffic from Lausanne to Zurich servers.

                                 Fig 17:  Delay vs Time plot for traffic from Zurich to Lausanne servers.

Latency starts spiking up at the 10th second when the Basel – Zurich link fails. Prior to the 10th second, the average delay is ~51 ms, and post the 10th second the average delay shoots up to ~5025 ms (or 5 seconds)

Basel – Zurich Application Throughput (Mbps) and Latency (sec) vs Time (sec)

Fig 18:  NetSim plot of throughput vs. time for traffic flowing from Basel to Zurich  

Fig 19: Delay vs Time plot for traffic from Basel to Zurich servers.
 

Here we observe Basel – Zurich application since the Basel – Zurich direct link failed. Prior to the 10th second, the average delay is ~61 ms. Post 10th second the average delay shoots up to ~2373 ms (or 2.4 seconds) since packets are re-routed

The new route taken by the packets, i.e., Basel > Bern > Luzern > Zurich and can be observed from the packet trace. 

OSPF convergence time: 

• Initially, routes converge at time at ~1217 µs or 1.22 ms
• Before link failure, data flows using link 4 are Basel-Luzern, Basel-Zurich, Bern-Zurich, Fribourg-Zurich and  Lausanne-Zurich 
• Transmissions in Link 4 get disrupted at 10 sec 
• It then takes approximately an average of 30 ms for OSPF to converge
• When the link failure occurs, a packet buffer builds at the router since packets can no longer be sent over the failed link
• Once OSPF converges packets queued in the router buffer - along with newly arriving packets - start getting transmitted in the new route

For example, in the Bern-Zurich traffic flow the new route is obtained and data transmissions start at 10.030 s

Download the attached exported file,  Swiss_University_case3_link_failure.netsimexp and import the exp file into NetSim and run the simulation on your machine to see the results for case 3. 

v13.3

A network scenario is created to connect universities in 6 cities. It uses 1 router and 1 server per city.

Fig 2: Network Scenario in NetSim having a router and a server for each city. Every link has a capacity of 10 Mbps

In this network, we configure traffic to flow from each city to every other city. Since there are 6 cities we have a total of 6*5 = 30 traffic flows.

Case 1: The traffic rate in each flow is 1.9 Mbps 

The traffic rate of 1.9 Mbps is chosen because there are 5 flows through any of the bottleneck links (connecting the router to a server) in one direction. The 5 flows are nothing but traffic coming in (and going out) from (to) the other 5 cities. Thus the bottleneck flow rate is ~ 2 Mbps (10 Mbps / 5). We, therefore, start with 1.9 Mbps which is just below the saturation capacity of 2 Mbps per flow.  The parameter configuration is as below. 

We run the simulation and observe the Application Throughput Plot:

                            Fig 3: NetSim plot of throughput vs. time for traffic flowing from Lausanne to Zurich

                            Fig 4: NetSim plot of throughput vs. time for traffic flowing from Zurich to Lausanne

• Packets generated = 7978, packets received = 7910, packets errored = 68. 
• Mean throughput = 1.84 Mbps vs. mean generation rate of 1.90 Mbps. This small difference is due to packet errors.
• Spread is seen because we are not generating a constant bit rate, but a variable rate with a mean of 1.9 Mbps using an exponential random variable for inter-arrival time to simulate real-world traffic flow.

The following plots show the Latency vs. Time for traffic between Lausanne and Zurich Servers

                         Fig 5: Delay vs Time for traffic from Lausanne to Zurich servers.

                                Fig 6: Delay vs Time for traffic from  Zurich to Lausanne servers.

We see that the average latency is not continuously increasing, but only varies around a mean. From this, we can infer that the network is able to fully handle the traffic flows between these two end points. 

OSPF convergence time:  We define the time at which the first data packet is forwarded by the Router as the convergence time. From the packet trace, we see that in this example, OSPF tables have converged at time ~1217 µs or 1.2 ms (highlighted in orange). The 3 entries seen in the packet trace at 1217 µs are transmissions starting at 3 routers after table convergence. 

Download the attached zip file Swiss_University_case1_GN_1.9Mbps.zip and import the configuration file and run the simulation on your machine to obtain these above results for case 1. 

Case 2: The traffic rate is 1.95 Mbps. (Set below 2Mbps bottleneck)

We now increase the generation rate to 1.95 Mbps

Run the simulation and see the Application Throughput Plot:

                               Fig 7: NetSim plot of throughput vs. time for traffic flowing from Lausanne to Zurich

                               Fig 8: NetSim plot of throughput vs. time for traffic flowing from Zurich to Lausanne

We observe application throughput is less than the generation rate of 1.95. However, we cannot immediately say if the network can or cannot handle this traffic load of 1.95 Mbps. To correctly estimate we need to observe how latency varies with time

The following plots show Latency vs. Time for traffic between Lausanne and Zurich Servers

                                      Fig 9: Delay vs Time plot for traffic from Lausanne to Zurich servers.

                                      Fig 10:  Delay vs Time plot for traffic from  Zurich to Lausanne servers.

We see latency increasing with time. This is a sign of queuing and an indication that the network is unable to handle the traffic load of 1.95 Mbps. Saturation occurs somewhere between 1.90 to 1.95 Mbps. 

Download the attached zip file Swiss_University_case2_GN_1.95Mbps.zip, import the configuration file, and run the simulation on your machine to see the results for case 2. 

Case 3: Link failure (Link 4 at 10 sec)

Next, we study the impact of link failure. To do so, we fail the Basel – Zurich link at t = 10s by setting downtime to 10s in link 4 properties.

                             Fig 11: Network scenario in NetSim with link failure in link 4

Parameter configuration

Run the simulation and see the Application Throughput Plot:

                              Fig 12: NetSim plot: throughput vs. time for traffic flowing from Lausanne to Zurich

                             Fig 13: NetSim plot: throughput vs. time for traffic flowing from Zurich to Lausanne

See how the throughput changes after the 10th second when the Basel – Zurich link fails, this affects all other links since Basel – Zurich traffic is now routed on other links. Therefore Lausanne – Zurich, and Zurich – Lausanne traffic is affected by this failure. Throughput falls to 1.2 Mbps after the 10th second.

The following plots explain the Latency vs. Time for traffic between Lausanne and Zurich Servers

                                 Fig 14: Delay vs Time plot for traffic from Lausanne to Zurich servers.

                                 Fig 15:  Delay vs Time plot for traffic from  Zurich to Lausanne servers.

Latency starts spiking up at the 10th second when the Basel – Zurich link fails. Prior to the 10th second, the average delay is ~51 ms, and post the 10th second the average delay shoots up to ~5025 ms (or 5 seconds)

Basel – Zurich Application Throughput (Mbps) and Latency (sec) vs Time (sec)

                             Fig 16:  NetSim plot of throughput vs. time for traffic flowing from Basel to Zurich 

                           Fig 17: Delay vs Time plot for traffic from Basel to Zurich servers.

Here we observe Basel – Zurich application since the Basel – Zurich direct link failed. Prior to the 10th second, the average delay is ~61 ms. Post 10th second the average delay shoots up to ~2373 ms (or 2.4 seconds) since packets are re-routed

The new route taken by the packets, i.e., Basel > Bern > Luzern > Zurich and can be observed from the packet trace.

OSPF convergence time: 

• Initially, routes converge at time at ~1217 µs or 1.22 ms
• Before link failure, data flows using link 4 are Basel-Luzern, Basel-Zurich, Bern-Zurich, Fribourg-Zurich and  Lausanne-Zurich 
• Transmissions in Link 4 get disrupted at 10 sec 
• It then takes approximately an average of 30 ms for OSPF to converge
• When the link failure occurs, a packet buffer builds at the router since packets can no longer be sent over the failed link
• Once OSPF converges packets queued in the router buffer - along with newly arriving packets - start getting transmitted in the new route

For example, in the Bern-Zurich traffic flow the new route is obtained and data transmissions start at 10.030 s

Download the attached zip file Swiss_University_case3_link_failure.zip and import the configuration file and run the simulation on your machine to see the results for case 3.