
I modified the FdPing example. I replaced the ping application with an upd socket to the server and a function with send packet. (Blue node in the diagram). It's working fine.I noticed it created 1 tap interface with 10.0.0.1 and 10.0.0.2 for the actual application.
![]()
Now I want to extend this topology with multiple nodes with client applications installed.
While doing this I had some issues with understanding the difference between the FdNetDevice and TapFdNetDevice.
The FdNetDevice is a generic device that allows ns-3 to read/write packets to and from a file descriptor. To ns-3, this looks like a NetDevice. However, unlike other NetDevice types, it is not hooked to a physical layer model but instead to a file descriptor.
A file descriptor can be associated with a real device, such as
your Ethernet device (e.g., 'eth0'). With this kind of binding,
you can send/receive frames from the real device (to hook ns-3 up
with the outside world). The EmuFdNetDevice helper class can
manage this binding.
A tap device is a special virtual network device-- it is not
associated to any real hardware device. However, it can be
bridged to other (virtual or real) network devices using a Linux
bridge. In ns-3, it can be bridged
In general, if you want a real application or container or Linux network namespace to run "on top of" an ns-3 network (like a Wi-Fi network), you would use a TapBridge device to bridge to an ns-3 NetDevice.
In general, if you want ns-3 applications to run "on top of" a real network, you would use the EmuFdNetDevice helper to associate a FdNetDevice with a real underlying physical device.
So, one way to think of the difference is that they are kind of the inverse of one another, depending on whether you want ns-3 to be providing the higher layers (Emu) or the lower layers (TapBridge).
So, if you want real applications to be sending into the ns-3 simulation from multiple vantage points, you would need to create multiple TapBridge devices and associate each one of these with a distinct ns-3 NetDevice.
Hope this helps,
Tom
I am not sure how to extend the topology? do I need to create a tap interface for all the nodes separately? (Which doesn't seem right) . As in the tap-Bridge example, they used one tap for multiple nodes.
Can you please guide and explain how these two work and the difference between them? and what can the correct approach to extend the topology?
RegardsNauman
--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/c5051a50-25aa-434a-b624-f78e4c6a5077n%40googlegroups.com.
Hi TomMany thanks for your reply, I use docker container and LXC and give the containers IP address (eth0) outside the ns-3 script. My topology is like the below graph (use docker container). In this scenario only single-hop works. I have tried to run a routing protocol in ns3 script but it does not work. In this case, I think I can not stop ARP because the TAP device works in L2.