How to Start Border Gateway Protocol Projects Using NS3

To start Border Gateway Protocol (BGP) using NS3, that is not directly supported because NS3 mainly concentrates on lower-layer networking protocols and simulation for wireless and ad hoc networks. But, we can be replicated the behaviour of BGP within NS3 by utilising Direct Code Execution (DCE) incorporating external BGP software like Quagga or FRR (Free Range Routing). These tools offer actual BGP protocol executions and it can be executed in an NS3 using DCE.

Below is a sequential process to configuring a BGP simulation in NS3 using DCE with Quagga.

Steps to Start Border Gateway Protocol Projects in NS3

Step 1: Install NS3 with DCE Support

If doesn’t install NS3 with DCE then we follow these commands:

  1. Download and install DCE and NS3 by replicating the DCE repository that contains both DCE and suitable NS3 version.

git clone https://gitlab.com/nsnam/ns-3-dce.git

cd ns-3-dce

./waf configure –enable-examples –enable-tests

./waf build

  1. Install Quagga in the DCE environment**. DCE contains Quagga pre-packaged version, which can utilise for routing protocols such as BGP.

Step 2: Set Up a Basic BGP Network with Quagga in NS3

This instance makes BGP basic simulation to utilize Quagga’s BGP capabilities with three routers. Each router will be executed a BGP daemon, and they will make BGP sessions including one another.

Create a New Script for BGP Simulation

In the scratch directory of NS3 DCE configuration, we can save below code like bgp_simulation.cc in.

Example Code for bgp_simulation.cc

This instance code sets up three routers, making BGP sessions and exchange routes.

#include “ns3/core-module.h”

#include “ns3/network-module.h”

#include “ns3/internet-module.h”

#include “ns3/point-to-point-module.h”

#include “ns3/dce-module.h”

using namespace ns3;

NS_LOG_COMPONENT_DEFINE(“BGPExample”);

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

LogComponentEnable(“BGPExample”, LOG_LEVEL_INFO);

// Create nodes representing routers

NodeContainer routers;

routers.Create(3); // Three BGP routers

// Create point-to-point links between routers

PointToPointHelper p2p;

p2p.SetDeviceAttribute(“DataRate”, StringValue(“1Gbps”));

p2p.SetChannelAttribute(“Delay”, StringValue(“2ms”));

NetDeviceContainer devices1 = p2p.Install(NodeContainer(routers.Get(0), routers.Get(1)));

NetDeviceContainer devices2 = p2p.Install(NodeContainer(routers.Get(1), routers.Get(2)));

// Install IP stack

InternetStackHelper internet;

internet.Install(routers);

// Assign IP addresses to the point-to-point links

Ipv4AddressHelper ipv4;

ipv4.SetBase(“10.0.1.0”, “255.255.255.0”);

Ipv4InterfaceContainer interfaces1 = ipv4.Assign(devices1);

ipv4.SetBase(“10.0.2.0”, “255.255.255.0”);

Ipv4InterfaceContainer interfaces2 = ipv4.Assign(devices2);

// Install DCE manager

DceManagerHelper dceManager;

dceManager.Install(routers);

// Install Quagga on each router

QuaggaHelper quagga;

quagga.EnableBgp(routers.Get(0), “65001”);

quagga.EnableBgp(routers.Get(1), “65002”);

quagga.EnableBgp(routers.Get(2), “65003”);

// Configure BGP neighbors

quagga.BgpAddNeighbor(routers.Get(0), “10.0.1.2”, “65002”);

quagga.BgpAddNeighbor(routers.Get(1), “10.0.1.1”, “65001”);

quagga.BgpAddNeighbor(routers.Get(1), “10.0.2.2”, “65003”);

quagga.BgpAddNeighbor(routers.Get(2), “10.0.2.1”, “65002”);

// Assign routing addresses

ipv4.SetBase(“192.168.1.0”, “255.255.255.0”);

Ipv4InterfaceContainer router1Iface = ipv4.Assign(p2p.Install(NodeContainer(routers.Get(0))));

ipv4.SetBase(“192.168.2.0”, “255.255.255.0”);

Ipv4InterfaceContainer router2Iface = ipv4.Assign(p2p.Install(NodeContainer(routers.Get(1))));

ipv4.SetBase(“192.168.3.0”, “255.255.255.0”);

Ipv4InterfaceContainer router3Iface = ipv4.Assign(p2p.Install(NodeContainer(routers.Get(2))));

// Start Quagga BGP daemons

quagga.Install(routers);

// Schedule to print routing tables at 10 seconds

for (uint32_t i = 0; i < routers.GetN(); ++i) {

Ptr<Node> node = routers.Get(i);

Simulator::Schedule(Seconds(10.0), &QuaggaHelper::PrintRoutingTable, quagga, node);

}

Simulator::Stop(Seconds(20.0));

Simulator::Run();

Simulator::Destroy();

return 0;

}

Explanation of the Code

  • Router Setup:
    • We make three nodes that each node denoting a BGP router.
    • Point-to-point links are set up among the routers, replicating direct connections.
  • Quagga BGP Setup:
    • Utilize QuaggaHelper to permit BGP on each router, to allocate each router a single Autonomous System (AS) number.
    • BGP neighbors are sets up to utilize BgpAddNeighbor launching BGP sessions among the routers.
  • IP Address Assignment:
    • IP addresses are allocated to the point-to-point links, to permit interaction among routers.
  • Quagga Daemon Start and Routing Table Printing:
    • The Quagga BGP daemon is begun at each router.
    • Routing table of each router is printed at 10 seconds, confirming that BGP routes have been swapped.

Step 3: Build and Run the Simulation

  1. In the scratch directory, we need to save bgp_simulation.cc.
  2. Go to a terminal, pass through to the NS3 DCE directory, and make the script:

./waf build

  1. Run the simulation:

./waf –run scratch/bgp_simulation

Above command will run the simulation and then indicate log messages including routing table entries, to show that routes have been swapped through BGP.

Further Experimentation Ideas

To discover BGP behavior in detail, we can deliberate:

  • Adding More Routers and ASes: Prolong the network with more routers including various ASes, replicating a larger BGP network.
  • Experiment with BGP Policies: Change Quagga configuration files to experiment the BGP policies like route filtering or path prepending.
  • Use Different Topologies: We make multi-hop topologies to monitor the BGP path selection within more complex networks.
  • Add Data Traffic: Configure applications such as TCP or UDP to make traffic among the networks and monitor how BGP transmits the information.
  • Log BGP Update Messages: Monitor BGP modernizes messages and transmits advertisements using Quagga’s logging aspects within real time.

Overall, we effectively simulated the Border Gateway Protocol projects through the above provided stepwise process along with sample coding using NS3 simulation tool. If you require more in-depth details on this topic, we will be shared later.

phdprojects.org focuses on Border Gateway Protocol projects utilizing the NS3 tool, offering customized and high-quality documentation for researchers. Our experienced team is proficient in replicating BGP software such as Quagga and FRR (Free Range Routing), accompanied by detailed explanations. To achieve outstanding results in your projects, let our team handle your requirements. Contact phdprojects.org for additional support. You can be confident that our pricing is affordable, and we provide reliable, high-quality work completed promptly by our specialists.