Computer Networks: Lab-IX Manual and Task

(NS3-I)

Sanjay K. Sahay
Dept. of CSIS, BITS Pilani, K.K. Birla Goa Campus

March 19, 2025

NS3 – 1

0.1 Theory
The Network Simulator 3 (NS-3) is a powerful, open-source discrete-event network simulator
widely used in academic research and teaching. It enables the design, configuration, and anal-
ysis of complex network scenarios without the need for real hardware deployment. Whether
you are experimenting with novel protocols, evaluating performance in large-scale topologies,
or studying how diverse network layers interact, NS-3 provides a flexible and highly customiz-
able environment.

Why NS-3?
• Realistic Models: NS-3 offers detailed implementations of protocols across layers (Eth-
ernet, Wi-Fi, TCP, UDP, etc.) with configurable parameters like bandwidth, latency, and
error rates. This realism helps generate results that closely approximate real-world be-
haviors.

• Rich Library of Modules: From point-to-point links to sophisticated wireless and mo-
bility models, NS-3’s modular design lets you combine or extend components (e.g., LTE,
Wi-Fi, 5G).

• Reproducible Experiments: Every scenario is defined in C++ or Python scripts, so you

can precisely document network configurations, easily replicate results, and compare
different protocol variants or topologies.

• Scalability and Efficiency: While some simulators struggle with large numbers of nodes,
NS-3 is optimized to handle thousands of nodes in a single experiment, if hardware re-
sources permit.

• Educational Value: Students learning networking concepts benefit from building and
visualizing scenario scripts, tweaking parameters (e.g., queue lengths, routing protocols),
and seeing how changes affect throughput, latency, or packet loss.

Motivation and Goals for this Lab

• Hands-On Protocol Study: Implementing basic topologies in NS-3 helps you grasp how
different protocols (TCP variants, routing protocols) behave under diverse conditions
(e.g., varying bandwidth, delays, or error rates).

• Experimentation Without Physical Hardware: Many networking labs require special-

ized routers, switches, or wireless gear. NS-3 circumvents these needs by emulating the
entire stack in software, saving cost and setup time.

1
 • Safe Environment for Novel Ideas: If you are designing new algorithms or custom pro-
tocols, testing them in a simulator is safer and faster than deploying them on production
networks.

• Detailed Statistics and Tracing: NS-3’s tracing framework yields packet-level logs,
queue-depth histories, and event timestamps. This granularity allows thorough analysis
of network metrics and fine-grained debugging of any issues.

By using NS-3, you will learn how to construct network topologies in code, configure link
properties, and run simulations that produce consistent, repeatable results. The lab sessions
that follow demonstrate how to create simple scenarios, gather trace data, and interpret metrics
like throughput, latency, and packet loss. This understanding will prove invaluable for both aca-
demic research and real-world network evaluations, as it builds a foundation for more complex
simulations and advanced performance analysis.

0.1.1 NS-3 Installation, Setup, and Basic Interaction

This section details the steps required to install NS-3, any special considerations you may need
during the installation process, and how to begin using NS-3 once it is properly set up. While
NS-3 does not come with a full graphical user interface (GUI) for scenario building—since it
is primarily a command-line and script-driven simulator—it does provide various command-
line interactions and can generate visual outputs (such as logs, traces, and optional anima-
tion/visualization) if configured accordingly.

1. Installing NS-3
• Check the home directory, a file ns-allinone-3.36.1.tar.bz2 will be available, else down-
load ns-allinone-3.36.1.tar.bz2 from local quanta.

• Use the command

$ tar jxvf ns-allinone-3.36.1.tar.bz2

Now, go to the folder

$ cd ns-allinone-3.36.1/, and run

$ ./build.py –enable-examples –enable-tests

This process takes some time depends on the speed of your system.

2
 • Now go to the directory

$ cd ns-3.36.1/, and run

$ ./ns3 run hello-simulator

Hello Simulator
(You will get this output)

• To run the examples, copy the examples/tutorial/first.cc, etc. to the scratch folder and
execute the file as shown below

$ ./ns3 run scratch/first or similarly other example files.

3. Basic Elements in NS-3: Nodes, Links, Routers, Switches, etc.

Conceptually, NS-3 treats everything in your network scenario as an object in the simulator:
• Nodes: Virtual hosts or routers. Each node can have one or more NetDevices repre-
senting network interfaces (Ethernet, Wi-Fi, LTE, etc.).
• Channels/Links: A PointToPointChannel, CsmaChannel, or WiFiChannel
that interconnects two or more nodes. You typically configure data rate, delay, and op-
tional error models.
• Protocols & Stacks: Each node can have an InternetStackHelper installed, en-
abling IP, ARP, routing tables, and so on. Additional stack modules (like TCP variants or
custom routing) can be added as well.
• Applications: On top of each node’s stack, you place client/server apps (e.g., OnOffApplication,
UdpEchoServer). These define how traffic is generated or received.

3
 • Switches, Routers: If you’re simulating an Ethernet or CSMA-based LAN, you might
create a node with multiple NetDevices bridging them to emulate a switch. Routers
are basically nodes with forwarding enabled, IP addresses set on each interface, and
routing tables configured.

When writing a scenario script, you typically:

1. Create Nodes: NodeContainer nodes; nodes.Create(2);

2. Install NetDevices and Channel: PointToPointHelper p2p; → p2p.SetDeviceAttribut

→ NetDeviceContainer devices = p2p.Install(nodes);

3. Assign IP Addresses: Ipv4AddressHelper address; → address.SetBase("10.1.1.0"

→ address.Assign(devices);

4. Install Applications: e.g., UdpEchoServerHelper echoServer(9); or OnOffHelper

onoff("ns3::UdpSocketFactory",...);

5. Set Simulation Time and Run: Simulator::Stop(Seconds(10.0)); → Simulator::Run

→ Simulator::Destroy();

4. Visualization Options
• NetAnim (Animation Tool): An external Qt-based utility which reads .xml trace files
generated by NS-3 scripts. It can animate nodes moving around (in wireless scenarios),
show packet transmissions, etc (See the directory NetAnim)

What You Typically See

• A console-based log or summary after the simulation ends, e.g., "Sent 1024 bytes
at t=2.0s".

• Optionally, .pcap files (one per node’s NetDevice) that can be opened in Wireshark to
see the “wire-level” packet traces, even though it’s all virtual in the simulator.

• If you incorporate NetAnim, you open a .xml file in the NetAnim GUI, which shows
a 2D layout of nodes and animations of packets. This is quite basic but sufficient to
illustrate movement in a wireless scenario or packet flow in a small topology.

5. Requirements for the Lab: Nodes, Links, Basic Setup

6. What You Will Do in This Lab
Setting Up Simple Scenarios

• Single P2P Link: Two nodes, each assigned an IP on a /24 network, exchange UDP or
TCP traffic. Compare throughput under different link speeds or delay configurations.

• Small LAN: Four or five nodes connected over a CSMA channel, run a UdpEcho or
OnOff application to see how collisions or queue parameters might impact performance.

• Trace Collection: Enable pcap output or ASCII tracing to capture all packets. Inspect
the logs or open them in Wireshark to confirm addresses, protocols, and timing.

4
Interpreting Results
• Typically, you gather stats (throughput, packet drops, latency) from a built-in NS-3 fea-
ture like FlowMonitor.

• Alternatively, parse log messages or event hooks that you add to the scenario code.

• Summarize your findings: e.g., "When link is 10Mbps with 10ms delay,
TCP throughput was 8Mbps. With 5ms delay, we got 9.2Mbps."

0.1.2 Common Simulation Scenarios and Observing Results

In this section, three foundational NS-3 scenarios along with detailed scripts in C++ and step-
by-step instructions on how to run them, observe packet exchanges, and capture relevant statis-
tics. Each scenario demonstrates a different aspect of basic network simulation:

1. Point-to-Point Link: Two nodes sending packets to each other.

2. Three Nodes on a Switch: Illustrate ARP traffic and simple LAN communication.

3. Two LANs Interconnected by a Router: Show how basic IP forwarding occurs between
two subnets.

All scripts assume a working NS-3 environment (see Section 0.1.1). Place these scripts in
your NS-3 directory (e.g., scratch/), build them, and then run them with your chosen build
system (waf or meson/ninja).

1. A Point-to-Point Link with Two Nodes

Scenario Overview Two nodes, Node A and Node B, are connected by a point-to-point
link. Both nodes use UdpEcho applications to exchange packets. We’ll assign IP addresses
and observe the traffic sent and received on each end.

C++ Script: p2p-two-nodes.cc

#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/internet-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/applications-module.h"

using namespace ns3;

int main(int argc, char *argv[])

{
// Enable logging for UdpEchoClient and Server (optional)
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);

// Create 2 nodes
NodeContainer nodes;

5
 nodes.Create(2);

// Configure point-to-point link attributes

PointToPointHelper p2p;
p2p.SetDeviceAttribute("DataRate", StringValue("5Mbps"));
p2p.SetChannelAttribute("Delay", StringValue("2ms"));

// Install NetDevices on the nodes

NetDeviceContainer devices;
devices = p2p.Install(nodes);

// Install the Internet stack (IP + routing) on both nodes

InternetStackHelper stack;
stack.Install(nodes);

// Assign IP addresses
Ipv4AddressHelper address;
address.SetBase("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer interfaces = address.Assign(devices);

// Set up a UdpEchoServer on Node B

UdpEchoServerHelper echoServer(9); // port 9
ApplicationContainer serverApps = echoServer.Install(nodes.Get(1));
serverApps.Start(Seconds(1.0));
serverApps.Stop(Seconds(10.0));

// Set up a UdpEchoClient on Node A, sending to Node B

UdpEchoClientHelper echoClient(interfaces.GetAddress(1), 9);
echoClient.SetAttribute("MaxPackets", UintegerValue(3));
echoClient.SetAttribute("Interval", TimeValue(Seconds(2.0)));
echoClient.SetAttribute("PacketSize", UintegerValue(512));

ApplicationContainer clientApps = echoClient.Install(nodes.Get(0));

clientApps.Start(Seconds(2.0));
clientApps.Stop(Seconds(10.0));

// Enable pcap tracing (so we can open in Wireshark)

p2p.EnablePcapAll("p2p-two-nodes");

Simulator::Stop(Seconds(10.0));
Simulator::Run();
Simulator::Destroy();
return 0;
}

How to Build and Run

• Place this file in scratch/ as p2p-two-nodes.cc.

6
 • Run:

./ns3 run scratch/p2p-two-nodes

Observing Results

• Console Logs: You’ll see messages like "UdpEchoClientApplication: Sent

512 bytes" or "Received 512 bytes" indicating packet transmission and re-
ception.

• Wireshark PCAP Files: A file named p2p-two-nodes-0-0.pcap (and one for

node 1) is generated. Open it in Wireshark to observe ARP requests (Node A discovering
Node B’s MAC) and UDP echo packets.

• Delay and Throughput Tuning: Change the link DataRate or Delay in the script to see
how it impacts packet travel time or overall throughput.

3. Two Switches (LANs) Connected by a Basic Router

Scenario Overview Create two separate LANs, each with multiple nodes connected by a
CSMA channel (acting like a switch). In the middle, we have a dedicated router node with one
interface on each LAN. This router performs basic IP forwarding between the two subnets.

Topology Sketch

LAN1: [Node A, Node B, Node C] -- (CSMA) -- Router -- (CSMA) -- LAN2: [

C++ Script: two-lans-router.cc

#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/csma-module.h"
#include "ns3/internet-module.h"
#include "ns3/applications-module.h"

using namespace ns3;

int main(int argc, char *argv[])

{
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);

// NodeContainer for LAN1

NodeContainer lan1Nodes;
lan1Nodes.Create(3); // 3 end-hosts
// Router node
Ptr<Node> router = CreateObject<Node>();

7
// NodeContainer for LAN2
NodeContainer lan2Nodes;
lan2Nodes.Create(4); // 4 end-hosts

// Combine them if needed

NodeContainer allNodes;
allNodes.Add(lan1Nodes);
allNodes.Add(router);
allNodes.Add(lan2Nodes);

// Install Internet stack on all

InternetStackHelper stack;
stack.Install(allNodes);

// Create CsmaHelper for LAN1

CsmaHelper csma1;
csma1.SetChannelAttribute("DataRate", StringValue("100Mbps"));
csma1.SetChannelAttribute("Delay", StringValue("1ms"));

// NetDeviceContainer for LAN1

NodeContainer lan1WithRouter;
lan1WithRouter.Add(lan1Nodes);
lan1WithRouter.Add(router);
NetDeviceContainer lan1Devices = csma1.Install(lan1WithRouter);

// Create CsmaHelper for LAN2

CsmaHelper csma2;
csma2.SetChannelAttribute("DataRate", StringValue("100Mbps"));
csma2.SetChannelAttribute("Delay", StringValue("1ms"));

// NetDeviceContainer for LAN2

NodeContainer lan2WithRouter;
lan2WithRouter.Add(lan2Nodes);
lan2WithRouter.Add(router);
NetDeviceContainer lan2Devices = csma2.Install(lan2WithRouter);

// Assign IP addresses for LAN1

Ipv4AddressHelper address1;
address1.SetBase("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer lan1Interfaces = address1.Assign(lan1Devices);

// Assign IP addresses for LAN2

Ipv4AddressHelper address2;
address2.SetBase("10.1.2.0", "255.255.255.0");
Ipv4InterfaceContainer lan2Interfaces = address2.Assign(lan2Devices);

// We need to turn on IP forwarding on the router

// (by default, NS-3 sets it if there’s more than 1 interface)

8
 Ptr<Ipv4> routerIpv4 = router->GetObject<Ipv4>();
routerIpv4->SetAttribute("IpForward", BooleanValue(true));

// Let’s pick one node from LAN1 to run a server,

// and one node from LAN2 to be a client
Ptr<Node> serverNode = lan1Nodes.Get(0);
Ptr<Node> clientNode = lan2Nodes.Get(0);

// UdpEchoServer on serverNode
UdpEchoServerHelper echoServer(9);
ApplicationContainer serverApps = echoServer.Install(serverNode);
serverApps.Start(Seconds(1.0));
serverApps.Stop(Seconds(20.0));

// UdpEchoClient on clientNode,
// targeting serverNode’s IP in 10.1.1.x
// find its assigned interface
Ipv4Address serverAddr = lan1Interfaces.GetAddress(0);
UdpEchoClientHelper echoClient(serverAddr, 9);
echoClient.SetAttribute("MaxPackets", UintegerValue(5));
echoClient.SetAttribute("Interval", TimeValue(Seconds(2.0)));
echoClient.SetAttribute("PacketSize", UintegerValue(512));

ApplicationContainer clientApps = echoClient.Install(clientNode);

clientApps.Start(Seconds(2.0));
clientApps.Stop(Seconds(20.0));

// Enable pcap
csma1.EnablePcapAll("two-lans-router-lan1", false);
csma2.EnablePcapAll("two-lans-router-lan2", false);

// Run simulation
Simulator::Stop(Seconds(20.0));
Simulator::Run();
Simulator::Destroy();

return 0;
}

How to Build and Run Same steps:

./ns3 run scratch/two-lans-router

Observing and Interpreting Results

• Console Output: The UdpEchoClientApplication from Node in LAN2 will at-
tempt to reach the server in LAN1. Because the router node has IP forwarding enabled,

9
 it can route from 10.1.2.0/24 to 10.1.1.0/24.

• ARP Across Subnets: Hosts in LAN1 only ARP for the router interface’s IP within
the same subnet. Meanwhile, the client in LAN2 will ARP for 10.1.2.x gateway
(router interface). The router does the route lookup to forward to 10.1.1.x on the
other interface.

• PCAP Files: You’ll see separate captures for each LAN (e.g., two-lans-router-lan1
-2-0.pcap for router on LAN1, two-lans-router-lan2-5-0.pcap for router
on LAN2, etc.). Examining these in Wireshark reveals how the router receives packets
on one interface and forwards them out the other.

• Potential Enhancements: - Add more nodes on each side. - Introduce different DataRates
or Delays on each LAN. - Use a TCP application instead of UDP to observe handshake
and congestion control.

Each scenario above provides a fundamental stepping stone:

• Scenario 1 clarifies basic point-to-point usage, addressing, and simple UDP echo traffic.

• Scenario 2 demonstrates how multiple nodes share a broadcast domain, emphasizing

ARP resolution and how traffic is visible to all on a LAN segment.

• Scenario 3 covers multi-subnet routing, letting you see how IP forwarding occurs in the
router node. This concept extends to building more elaborate topologies or connecting
additional routers and LANs.

In all cases, analyzing the generated pcap files with Wireshark or reviewing NS-3 console
logs/traces can reveal extensive details about packet flows, protocol behavior, and timing. By
tweaking parameters (link speeds, delays, application rates), you can see immediate changes
in throughput, latency, and ARP or routing overhead. This iterative experimentation is at the
heart of using NS-3 for networking research and education.

0.2 Lab Experiments

Below are four suggested lab experiments that guide you through foundational NS-3 simula-
tions, mirroring the scenarios discussed in Section 0.1.2. Each experiment includes a descrip-
tion of what to build, how to run it, and the kinds of observations and metrics you should
collect.

1. Two-Node Point-to-Point Echo

Objective: Familiarize yourself with a minimal NS-3 setup by creating two nodes con-
nected by a PointToPoint link. Use UdpEcho applications to confirm successful
packet exchange, and collect basic timing/throughput data.

10
 Tasks:
• Create a C++ script (p2p-two-nodes.cc) to instantiate exactly 2 nodes.
• Use PointToPointHelper with attributes like:
– DataRate = "5Mbps"
– Delay = "2ms"
• Assign IP addresses (e.g., 10.1.1.0/24).
• Install a UdpEchoServer on Node B, listening on a designated port (e.g., 9).
• Install a UdpEchoClient on Node A, sending 3 packets of 512 bytes each at
intervals of 2 seconds.
• Enable pcap tracing, run the simulation for 10 seconds, and stop.

What to Observe:
• Console logs indicating packet transmissions and receptions (e.g., “Sent 512 bytes”).
• A .pcap file named (for instance) p2p-two-nodes-0-0.pcap containing
ARP and UDP packets, which you can inspect in Wireshark.
• How changing the DataRate or Delay affects packet arrival time or throughput.

Expected Results:
• Node A should successfully send and receive the echoed packets from Node B.
• ARP resolution (e.g., “Who has 10.1.1.2?”) in the pcap before UDP flow starts.
• Potential minimal packet loss if you deliberately lower the link rate or increase the
packet size beyond the capacity (depending on buffer settings).
2. Three-Node LAN via CSMA and ARP Demonstration

Objective: Illustrate how multiple nodes share a broadcast domain (like a switch), fo-
cusing on ARP requests and potential collisions. Use UdpEcho between two nodes
while a third node remains idle (or also sends/receives data).

Tasks:
• Create a C++ script (three-csma-arp.cc) with three nodes in a CsmaHelper
network:
– DataRate = "100Mbps"
– Delay = "2ms"
• Install UdpEchoServer on Node 2 (port 9). Install UdpEchoClient on Node
0 (sending 5 packets at 1 s intervals).
• Leave Node 1 idle or optionally install another UdpEchoClient for additional
traffic.
• Capture traffic with csma.EnablePcapAll("three-csma-arp") for Wire-
shark analysis.

11
 What to Observe:

• ARP broadcast frames: Node 0 asking “Who has 10.1.2.3?” for Node 2’s IP.
• Node 1 seeing these broadcasts even if it’s not actively transmitting.
• Throughput or delay differences if you reduce DataRate or adjust packet sizes.

Expected Results:

• Confirmation that ARP resolves the MAC addresses within the LAN.
• UdpEcho traffic flows from Node 0 to Node 2 once ARP completes.
• Possibly see collisions or packet reorder if the CsmaHelper is configured with
certain attributes (like a lower DataRate and multiple active senders).

3. Two Switches (LANs) with a Router in Between

Objective: Demonstrate basic IP routing across two subnets. Each LAN has multiple
nodes, with a single router node bridging them. Observe how traffic from one LAN can
reach a server on the other LAN via simple IP forwarding.

Tasks:

• Create a two-lans-router.cc script with:

– LAN1: Three nodes + router interface connected by csma1.
– LAN2: Four nodes + the same router node’s second interface connected by
csma2.
– Distinct subnets: 10.1.1.0/24 (LAN1) and 10.1.2.0/24 (LAN2).
– Router node with IP forwarding enabled (two interfaces, each in a different
subnet).
• Place a UdpEchoServer on LAN1’s Node A, and a UdpEchoClient on LAN2’s
Node D. Let the client send packets for 20 seconds.
• Examine pcap captures on both LAN segments to see IP forwarding in action.

What to Observe:

• ARP interactions within each LAN: Nodes discovering the router’s MAC, the router
discovering the end-host MAC, etc.
• IP-level forwarding inside the router: Packets entering interface on 10.1.2.x,
being routed, then exiting interface on 10.1.1.x.
• Potential use of Ipv4GlobalRoutingHelper or static routes if you want ad-
vanced routing. Typically, IP forwarding is enough for small subnets.

12
 Expected Results:

• Successful echo traffic between LAN1 and LAN2 hosts, verifying that the router is
indeed forwarding.
• Additional console logs or UdpEcho messages showing how many bytes were sent,
received, and any timing details.
• If you block or disable IP forwarding, traffic fails to cross subnets, illustrating the
necessity of a properly configured router.

4. Varying Link Parameters and Collecting Metrics

Objective: Deepen your understanding of how adjusting link rates, delays, and queue
sizes influences throughput, latency, and packet loss in any of the above scenarios.

Tasks:

• Pick one of the previous scenarios (e.g., two-lans-router.cc).

• Modify the csma.SetChannelAttribute("DataRate", ...) or p2p.
SetDeviceAttribute("DataRate", ...) lines to experiment with dif-
ferent speeds (1Mbps, 10Mbps, 100Mbps).
• Adjust "Delay" to 10ms or 50ms. Potentially add an ErrorModel if you want to
simulate packet corruption or random losses.
• Integrate FlowMonitor (from flow-monitor-module.h) to gather per-flow
throughput, average delay, and packet drops. Or rely on the UdpEcho logs plus
pcap files for simpler stats.

What to Observe:

• For each link rate/delay combination, record the measured throughput, end-to-end
latency, and any drops if applicable.
• Identify the “breaking point” where if the data rate is too low or the delay is too
high, the application experiences poor performance (higher round-trip time, possi-
ble timeouts).
• If you enable an ErrorModel, watch the pcap for any packets flagged as cor-
rupted or missing from the flow sequence.

Expected Results:

• A table or chart showing how your scenario’s performance metrics (throughput,

delay) vary with link parameters.
• A deeper grasp of how real-world network constraints (limited bandwidth, higher
latency, or unreliable links) impact application performance in a purely simulated
environment.

13
 By performing these four experiments, you’ll progress from a simple two-node point-to-
point test to multi-node LAN setups, then to multi-subnet routing scenarios and more advanced
parameter tweaking. Throughout each experiment, the key is to:

• Write (or modify) a straightforward C++ script defining nodes, channels, and applica-
tions.

• Run the simulation, gather logs, pcap traces, or flow-monitor data.

• Analyze the traffic in Wireshark or console output to verify correct addressing, ARP
resolution, and IP routing.

• Correlate changes in link attributes (bandwidth, delay) to observed performance, thereby

learning how fundamental network parameters shape end-to-end behavior.

This comprehensive practice will build essential skills for future NS-3 labs, research projects,
or advanced experimentation, providing a robust foundation in discrete-event network simula-
tion.

—xxx—

14