Multicasting takes advantage of the fact that LANs, such as Ethernet, are broadcast media, in which all hosts can, if they choose, see all the packets as they go by.

In order to use multicast you have to use a datagram protocol, such as UDP, for reasons that I will not get into in this posting.

One of the more important qualities to test for when building a multicast network is latency. Many people know about testing for bandwidth, i.e. how many bytes/bits per second can we shove down this pipe, but latency tests are rarer. Since such tests are rare I have written one which is now included in FreeBSD. It can be found in the src/tools/tools/mctest directory of CURRENT (8.0). An example is shown below:


Source
mctest -i em0 -s 1024 -n 100 -t 1
Sink
mctest -i em0 -s 1024 -n 100 -r

Send 100 packets of 1024 bytes, with an inter-packet gap of 1 nanosecond.

The mctest program includes both the source and the sink code, and the -r command line argument is what tells the program to be a sink (i.e. to receive packets).

The way that mctest tests for latency is that the source sends out a multicast packet and then the sink(s) send the packet right back. The sinks report statistics like the size of the gap between packets, which shows network jitter, and if any packets were lost. The source reports if packets were lost as well as the round trip latency of the packets.

Results from the test look like this on the source:

Results from client #0
sec: 0 usecs: 73
sec: 0 usecs: 44
sec: 0 usecs: 48
sec: 0 usecs: 39

which shows partial results. The results for all clients are actually output. There is also a convenient shell script mctest_run.sh which can be used to start sinks on multiple hosts. All of this is documented in the manual page as well.

Happy Testing!

http://bsdtalk.blogspot.com/

http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk121.ogg

What does this mean to you?

•  FreeBSD IPsec is now MP Safe, which is a requirement for the 7.0 release.

• FreeBSD IPsec supports offloading cryptographic operations to specialized hardware by default.

•  It’s time to jump in and help test these changes!

So, now it’s time for everyone to get the latest cut of HEAD and try this code out in a wider distribution.

In order to keep ntpd running you have to tell it not to panic when it gets a very large time offset. The ntp daemon will accept an offset of up to 1000 seconds by default, but if you suspend your machine for more than that length of time the daemon will exit. In your /etc/ntp.conf file add the following lines:

tinker panic 0

The 0 says “accept any offset” which means that if your machine is suspended for a long time, as mine often are, when it unsuspends and gets a very large offset from the server everything will be OK.

You can also decide to specify the -g flag to the ntpd daemon in the flags section in rc.conf but it’s likely better to use the configuration file since you’ll need one anyway, and then upgrading and making a mistake with mergemaster won’t kill your settings.

http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk109.mp3

and you can find all the podcasts on BSDTalk here:

http://bsdtalk.blogspot.com/

I’ll be adding more posts about working with virtual machines in the near future.

In order to set up remote GDB you’ll need two virtual machines, one of which you’ll be debugging from, which I call devbox, and the other is the one you’re debugging which is often called a target, and which I call dut, short for Device Under Test.

Preparing a Kernel

For the DUT you will need to prepare a kernel that has support for remote GDB. Add the following lines to your kernel configuration file and compile the kernel on devbox:


options KDB # Enable kernel debugger support.
options DDB # Support DDB.
options GDB # Support remote GDB.


Install the newly compiled kernel into your DUT virtual machine. DO NOT INSTALL IT ON DEVBOX or you will be sorry.

On the DUT you will need to add the following lines to loader.conf:

hint.sio.1.flags=0x90
boot_gdb=1


<a href=http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk101.mp3>Interview</a>

and the BSD Talk page itself is here:

<a href=http://bsdtalk.blogspot.com/>BSDTalk Page</a>

“The Packet Debugger (pdb) is a program which allows people to work with packet streams as if they were working with a source code debugger. Users can list, inspect, modify, and retransmit any packet from captured files as well as work with live packet capture.” – pdb web page

There is a twelve page manual on the web page that describes how to use the debugger as well.

<a href=people.freebsd.org/~gnn/PARA>PARA</a>

<a href=people.freebsd.org/~gnn/loader.conf>loader.conf</a>

To build a proper network test lab you not only need machines with multiple interfaces but a way to hook those interfaces to each other. Until the most recent versions of Parallels, around December of 2006, this was not possible, and so I had to stick with VMware, on Linux. Now with the advent of 3 types of networking on Parallels, bridged, shared and host only, it is possible to have 3 interfaces independently active for use in testing.

At home my typical setup is that ed0 is a bridged network, which connects to the outside world, and ed1 is shared, and then ed2 is host only. Testing occurs on ed1 and ed2 in order for there to be a “quiet” network on which to do tests.

The next step that Parallels needs to take to make this truly work is to provide the equivalent of a hub per network, much like private networks in VMware, at which point all this messing about with different types of network interfaces can cease and I can safely continue to do testing wherever I like.

For those of you who want to do this kind of work I will be uploading my kernel configuration and other files in another post.