Applicable Versions | NetSim Standard | NetSim Pro |
Applicable Releases | v14.1 | v13.3 |
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.
Simulation Parameters | Value |
Routing Protocol | OSPF |
Wired Link Speed (Mbps) | 10 |
Mean traffic generation rate (Mbps). | 1.9 (1460-byte packet size and 6147 μs exponentially distributed Inter Packet Arrival Time) |
Transport Protocol | UDP |
Traffic Configuration | Traffic flows uplink and downlink between all pairs of cities |
Simulation Time (sec) | 50 |
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
Simulation Parameters | Value |
Routing Protocol | OSPF |
Wired Link Speed (Mbps) | 10 |
Mean Traffic Generation Rate (Mbps). | 1.95 (1460-byte packet size and 5989 μs exponentially distributed Inter Packet Arrival Time) |
Transport Protocol | UDP |
Traffic Configuration | UL & DL between all cities. |
Simulation Time (sec) | 50 |
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
Simulation Parameters | Value |
Routing Protocol | OSPF |
Wired Link Speed (Mbps) | 10 |
Traffic Generation Rate (Mbps). Mean. | 1.9 (Mean with 1460 byte packet size and 6147 μs exponentially distributed Inter Packet Arrival Time |
Transport Protocol | UDP |
Traffic Configuration | UL & DL between all cities. |
Simulation Time (sec) | 50 |
Link Failure Time (sec) | 10 |
Link ID | 4 (Basel to Zurich) |
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.
Simulation Parameters | Value |
Routing Protocol | OSPF |
Wired Link Speed (Mbps) | 10 |
Mean traffic generation rate (Mbps). | 1.9 (1460-byte packet size and 6147 μs exponentially distributed Inter Packet Arrival Time) |
Transport Protocol | UDP |
Traffic Configuration | Traffic flows uplink and downlink between all pairs of cities |
Simulation Time (sec) | 50 |
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
Simulation Parameters | Value |
Routing Protocol | OSPF |
Wired Link Speed (Mbps) | 10 |
Mean Traffic Generation Rate (Mbps). | 1.95 (1460-byte packet size and 5989 μs exponentially distributed Inter Packet Arrival Time) |
Transport Protocol | UDP |
Traffic Configuration | UL & DL between all cities. |
Simulation Time (sec) | 50 |
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
Simulation Parameters | Value |
Routing Protocol | OSPF |
Wired Link Speed (Mbps) | 10 |
Traffic Generation Rate (Mbps). Mean. | 1.9 (Mean with 1460 byte packet size and 6147 μs exponentially distributed Inter Packet Arrival Time |
Transport Protocol | UDP |
Traffic Configuration | UL & DL between all cities. |
Simulation Time (sec) | 50 |
Link Failure Time (sec) | 10 |
Link ID | 4 (Basel to Zurich) |
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.