Tap Bridge and AdHoc

[NSimidjievski]

Hello,

I am creating an ad hoc scenario , and everything works fine, until I
add a TapBridge interface to every node. The routing protocol stops
working it seems like the nodes can't see each other. What could be
the problem? How can I solve this problem, leaving the Tap Bridges
connected?


Thank you very much in advance,
Nikola

[Jinxue Zhang]

Which kind of TapBridge type do you use? UseBridge?

I also encountered similar problem. Later on, I use IP/MAC address binding to partially solve this problem.

If you are interested, I can share you some documents about my implementation.

Best wishes

Jinxue

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Andrey Mazo]

On Jul 26, 2:48 pm, NSimidjievski <nikola.simidziev...@gmail.com>
wrote:

I guess, this is because after attaching TapBridge to a NetDevice, all
packets from the underlying NetDevice are forwarded to the TapBridge
(and to the host machine) but not to the node.
From doxygen [1]:
"The bridged ns-3 net device is has had its receive callback
disconnected from the ns-3 node and reconnected to the Tap Bridge. All
data received by a bridged device will be sent to the Linux host and
will not be received by the node."

[1] http://www.nsnam.org/doxygen/classns3_1_1_tap_bridge.html#_details

[Jinxue Zhang]

Yes, exactly.

 

Then I filter the packets and put the routing update ones to ns-3 again, while throw the data packets to the hosts.

[NSimidjievski]

Hello all,

So there is no simple solution to this problem? If I connect a virtual
machines to a Tap Interfaces on different nodes in the simulation,
that means that the packets from the VMs never get to the nodes?
@Jinxue :Thanks that will be great, I am using the UseLocal or
ConfigureLocal modes,I can't use UseBridge because of the Send()
problem.And I am using OLSR or AODV as routing algorithms....can your
code work with that?

Thanks all,
Nikola

On Jul 27, 10:45 am, Jinxue Zhang <zhangjin...@gmail.com> wrote:
> Yes, exactly.
>
> Then I filter the packets and put the routing update ones to ns-3 again,
> while throw the data packets to the hosts.
>

> On Tue, Jul 27, 2010 at 4:43 PM, Andrey Mazo <anhi...@gmail.com> wrote:
>
> > On Jul 26, 2:48 pm, NSimidjievski <nikola.simidziev...@gmail.com>
> > wrote:
> > > Hello,
>
> > > I am creating an ad hoc scenario , and everything works fine, until I
> > > add a TapBridge interface to every node. The routing protocol stops
> > > working it seems like the nodes can't see each other. What could be
> > > the problem? How can I solve this problem, leaving the Tap Bridges
> > > connected?
>
> > > Thank you very much in advance,
>
> > I guess, this is because after attaching TapBridge to a NetDevice, all
> > packets from the underlying NetDevice are forwarded to the TapBridge
> > (and to the host machine) but not to the node.
> > From doxygen [1]:
> > "The bridged ns-3 net device is has had its receive callback
> > disconnected from the ns-3 node and reconnected to the Tap Bridge. All
> > data received by a bridged device will be sent to the Linux host and
> > will not be received by the node."
>
> > [1]http://www.nsnam.org/doxygen/classns3_1_1_tap_bridge.html#_details
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "ns-3-users" group.
> > To post to this group, send email to ns-3-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > ns-3-users+...@googlegroups.com<ns-3-users%2Bunsu...@googlegroups.com>
> > .

[Andrey Mazo]

> So there is no simple solution to this problem?

I guess, no.
It's possible to override callbacks (particularly ReceiveCallback)
from NetDevice with a custom callback, which will in turn call both
TapBridge's and ns-3 internet stack's callbacks.

> If I connect a virtual
> machines to a Tap Interfaces on different nodes in the simulation,
> that means that the packets from the VMs never get to the nodes?

Without additional steps, yes.
A packet from a VM will reach either only another VM or a ns-3 node
without TapBridge attached to the only NetDevice.

But I don't understand well, why you are required to have both fully
functional ns-3 internet stack and attached virtual machine on a node.

[Jinxue Zhang]

From my practice, I want to run the real applications on a routing-enabled simulated MANET.

Thus the packets contain both the routing updating packets such as AODV/OLSR and packets to the hosts.

Nikola, I will share the resource soon after cleaning up.

Best wishes

Jinxue

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.

To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.

[Jinxue Zhang]

Hi Nikola,

        The attached is the patching file for ns-3.8 and an example. 

          

         Among them, two key designs are:

         1. TapBridge is uased as a gateway, i.e. replace the IP and MAC address of packets from host to the ns-3 network, and revert it at the adverse direction. Thus at the configuration phase, you should input the IP and MAC mapping between hosts and ns-3

          2.  In order to distinguish the packets for ns-3 and hosts, the filtering module is used in TapBridge.  At current phase, it can only support AODV and OLSR since their UDP port is unique and can be easily recognized.

          Hopes that help you.

        Best wishes

         Jinxue

[Andrey Mazo]

> From my practice, I want to run the real applications on a routing-enabled
> simulated MANET.
> Thus the packets contain both the routing updating packets such as
> AODV/OLSR and packets to the hosts.

It's not clear to me, how the VMs will get use of routing tables from
ns nodes.
Before sending a packet to a tap net device, a VM must have already
checked it's own guest OS routing table and made a decision about
gateway and interface.
Also, packets injected from TapBridge into the simulation are actually
Layer 2 frames and thus bypass ns node internet stack with it's
routing table (carefully populated by ns AODV/OLSR).

[Jinxue Zhang]

So a modification for TapBridge is needed. Actually, in this situation, TapBridge acts like a gateway/router.

 

From one direction, VM will send the packets to Ethernet card as default gateway. Since the Ethernet card is bridged to a Tap device , TapBridge will capture it by listening the tap device. This is done in current ns-3. After obtaining the packets, TapBridge delivers the packets to the ns-3 network by replacing the IP/MAC header.

 

Likewise, on the other direction, TapBridge will hook the packets from ns-3 network and reverting them to the original IP/MAC address of VM. After doing that, TapBridge sends the packet to Tap device, which will then deliver to the VM, as implemented in current ns-3.

In summary, since TapBridge can capture the L2 packet from both VM and ns-3, it can determine and control the transmission of packets.

 

I draft a paper for this design and implementation. Welcome your comments.~~ Thanks very much!

 

Best wishes

Jinxue

--

[Andrey Mazo]

On Jul 29, 1:37 pm, Jinxue Zhang <zhangjin...@gmail.com> wrote:
> I draft a paper for this design and implementation. Welcome your comments.

It was quite an interesting reading.
Some comments following.

1) It would be nice to implement a little bit more generic framework
to allow easy extending to other types of routing protocols.
I'm not sure, but maybe these efforts are in some kind similar to
porting netfilter framework to ns-3.
Particularly I do not like hardcoded protocol port numbers directly
into TapBridge.
2) Subsection 3.1, paragraph Tap Layer.
"[...] tap is a virtual network interface which can bridge the
network access and local file access."
What do you mean by "tap can bridge local file access"? Or am I
missing something?
3) Subsection 5.1.
You are measuring time overhead and getting times ~ 1e-5 sec.
What was the resolution of your clocking source? Or at least what
was the clocking source?
(I mean like `cat /sys/devices/system/clocksource/clocksource0/
current_clocksource`)
4) Section 6.
Do you have any proposals on how to improve real-time scheduler?

A couple of cosmetic notes are made in the pdf file in place.
Unfortunately I don't have any pdf annotators at hand, so I have to do
the notes in Okular and save them in it's internal format.

[Andrey Hippo]

On Fri, Aug 13, 2010 at 4:17 PM, Andrey Mazo <anh...@gmail.com> wrote:
> A couple of cosmetic notes are made in the pdf file in place.
> Unfortunately I don't have any pdf annotators at hand, so I have to do
> the notes in Okular and save them in it's internal format.

Oops, forgot to attach the file.

--
Andrey Mazo.

[Jinxue Zhang]

Andrey, thanks very much for your reviews and suggestions.

Since I am still fighting for a KDE environment, I would like to first consider your comments at Email :-)

1. A good suggestion about the generic framework. 

At current design, the recieved part needs to manually classify the packets for each specific routing protocol from underlying ns-3 packets. It seems that we can provide an interface for user to specify which kinds of packets relating to the routing protocols should be passed to the ns-3 packets. These packets can be identified by port number, for example. Maybe the protocol packets are easily to filter, therefore no need for the somehow complete netfilter.

2. For the tap device, I am sorry to make a mistake for its functionality at this statement, as you pointed out. Many thanks anyway. 

My original meaning is that each tap device, connecting to a single virtual machine, acts like a local file descriptor, allowing the upper applications as ns-3 to access it as normal file by opening, reading, writing, etc. While for the direction of underlying network, the tap handles the network packets. So the paper presented that "tap can bridge local file access". This explanation is unclear and somehow ambiguous. 

BTW, I also consider the necessity of the middle tap layer. It seems that ns-3 can talk to the network cards in wirtual machines directly. With more details, each network card in virtual machine typically links to a virtual network card in hosting machine, known as "veth" in OpenVZ, for instance. Since now ns-3 can bind to tap device, it can also bind to veth directly, hence bypassing the tap layer. This reduction can hopefully save some overheads by contrast with current design.

3. The operation-system level virtualization such as OpenVZ and lxc, use the clock from hosting machine.

I have checked the clock source, it uses "tsc", which is said to provide the accuracy of microsecond, used by gettimeofday(). Is that reasonable?

4. Well, I do discover that when the count of transmitted packets reaches to a limit, the ns-3 will crash by throwing out a error of likely scheduler. However, the elaborate exploration is still needed and the proposal is in the way. Any suggestions?

Thanks again for your comments. Welcome your further discussion later:-)

Best wishes

Jinxue

--

[Andrey Hippo]

A pdf file with comments is attached.

--
Andrey Mazo.

[Andrey Mazo]

On Aug 13, 7:58 pm, Jinxue Zhang <zhangjin...@gmail.com> wrote:
> 1. A good suggestion about the generic framework.
> At current design, the recieved part needs to manually classify the packets
> for each specific routing protocol from underlying ns-3 packets. It seems
> that we can provide an interface for user to specify which kinds of packets
> relating to the routing protocols should be passed to the ns-3 packets.
> These packets can be identified by port number, for example. Maybe the
> protocol packets are easily to filter, therefore no need for the somehow
> complete netfilter.

Such an interface would be very helpful.

> 2. For the tap device, I am sorry to make a mistake for its functionality at
> this statement, as you pointed out. Many thanks anyway.
> My original meaning is that each tap device, connecting to a single virtual
> machine, acts like a local file descriptor, allowing the upper applications
> as ns-3 to access it as normal file by opening, reading, writing, etc. While
> for the direction of underlying network, the tap handles the network
> packets. So the paper presented that "tap can bridge local file access".
> This explanation is unclear and somehow ambiguous.

Oh, it's now clear to me, what you have meant.

> BTW, I also consider the necessity of the middle tap layer. It seems that
> ns-3 can talk to the network cards in wirtual machines directly. With more
> details, each network card in virtual machine typically links to a virtual
> network card in hosting machine, known as "veth" in OpenVZ, for instance.
> Since now ns-3 can bind to tap device, it can also bind to veth directly,
> hence bypassing the tap layer. This reduction can hopefully save some
> overheads by contrast with current design.

Do you mean binding to veth in CT0 with EmuNetDevice?
It should work fine, but I had some problems with deploying similar
design (I don't remember well though, what the difficulties was
actually).

> 3. The operation-system level virtualization such as OpenVZ and lxc, use the
> clock from hosting machine.
> I have checked the clock source, it uses "tsc", which is said to provide the
> accuracy of microsecond, used by gettimeofday(). Is that reasonable?

As fas as I understand, TSC itself has a very nice resolution (1/
CPU_clock_rate ~ 1ns).
Due to system call overhead the resolution is worse, but looks like
about ~1us.
You're getting times near ~10us, so the resolution is going to be
enough.
It's maybe interesting to measure time via clock_gettime() and also
clock_getres() on your machine.

> 4. Well, I do discover that when the count of transmitted packets reaches to
> a limit, the ns-3 will crash by throwing out a error of likely scheduler.
> However, the elaborate exploration is still needed and the proposal is in
> the way. Any suggestions?

Well, I'm getting the similar behavior (ns-3 crash) on high traffic
loads, but with different symptoms on CSMA and Wifi devices.
Unfortunately, no, I don't have any suggestions right now.