News

There will be a quick downtime tomorrow morning at 7am PST. I will be swapping out a bad memory DIMM in users. The downtime should not last more than 10min.

Our upstream switch here at ISI was replaced this morning and they are still in the process of configuring it. The link to Berkeley is down at the moment and expect intermittent connectivity problems to ISI.

We are hosting monthly phone conferences for DETER users to ask questions of the staff, swap issues and solutions, and look for collaborations. All registered DETER users are cordially invited.

The next user call will be on January 10, 2008, 11 am - noon PST. We will send a reminder and agenda one week before the call. Summaries of previous calls will be found at http://www.isi.edu/deter/telecons/telecons.html.

Join us in Boston, MA, August 6–7, 2007, for the DETER Community Workshop on Cyber Security Experimentation and Test 2007. This workshop will address issues in the design and use of moderate-to-large scale network testbeds to conduct experiments on security topics such as worm propagation, infrastructure defense (e.g., defending the DNS and BGP routing), and denial of service defense. Such experiments are challenging because of complexity, scale, and possible risk.

http://www.usenix.org/events/deter07/

A 200 node experiment has been scheduled for the week of December 18th. The ISI side of the testbed will be unavailable during that time. The week of December 18th is *this week*.

There are a number of Berkeley nodes free for use. To specifically use Berkeley nodes, in your .ns file you can request

tb-set-hardware $node bpc2800

(or bpc3000, or bpc3060)

It is worth noting that lilo based images are not transportable between bpc2800's and anything else; for image compatibility, the 4 types pc3000, pc3060, bpc3000, bpc3060 are essentialy identical.

We just upgraded DETER to FreeBSD-6.1 and incorporated a series of improvements from Emulab. Please report all problems (and there no doubt will be some!) to testbed-ops@isi.deterlab.net.

We have recently fixed a misconfiguration of the DETER testbed that was causing idle experiment detection to fail. Our Cisco and Nortel switches were generating periodic proprietary Ethernet packets, which were registering with the idle system's network traffic counters.

Now that this is fixed, experiments will start to get swapped out after a period of time with no network, tty, or CPU activity. If you wish for your experiments to remain swapped in past the idle time, you can adjust the experiment metadata to prevent idle swap.

For more information, please consult our node use policies.

Tuesday, August 15 and Wednesday, August 16, DETER will be down in order to switchover to a new UPS. We expect to power the systems down Tuesday evening around 10PM, and hope to have them back up sometime after 9AM.

Our expectation is that you can leave your experiments swapped in, and your nodes should come back up when we apply power to the testbed. It would be a good idea to do a 'shutdown -h' on your experimental nodes, to cleanly shut down the systems. As with any operation like this, though, there may be further problems.

In case of problems, Keith Sklower is setting up www.ucb.deterlab.net to mirror the current contents of the ISI machines, so that users could swap in experiments at UCB if necessary.

After some tweaks to the ISI-UCB interconnect, the bpc2800s are now available again from www.isi.deterlab.net.

DETER experienced an unexpected power outage the morning of Saturday, June 24. It scrambled some switch configurations which took us some time to track down and fix. The testbed should be working again now. Please send mail to testbed-ops@isi.deterlab.net if you see problems.

Due to some ongoing difficulties with the bpc2800s, we've decided to make them available via the UCB users node, www.ucb.deterlab.net. They will, at least for the next few weeks, not be available via www.isi.deterlab.net.

Keith Sklower is rsyncing the files from the ISI systems onto the UCB systems, so that users should be able to log into the UCB systems with no problems. Please be aware, though, that future rsyncs could overwrite the files stored at UCB, so be careful.

UCB staff have managed to significantly improve the robustness of the serial connections to the bpc2800s, so serial console access should be much improved.

Keith Sklower of UC Berkeley has added another 30 nodes to the testbed. These bpc2800 nodes will show up as bpc001 - bpc030.

Due to excessive noise in the serial lines, the consoles for these systems have been turned off. You can still run 'console bpc001', but you won't see any output.

As with all Berkeley-based nodes (type bpcxxxx), users should remember that the link between these nodes and the ISI nodes has limited, unpredictable bandwidth, and that this can sometimes effect the speed and reliability of node image loading as well.

DETER will be down both Monday, May 15, and Tuesday, May 16, from 2PM to 5PM, for malware experiments. For safety, the testbed (including users.isi.deterlab.net) will be disconnected from the Internet, and all active experiments will be swapped out.

We've got 64 new Dells, similar to the 64 pc3000s already available at DETER, with dual 3.0 GHz Xeon CPUs, 2GB of RAM, and 36GB 15,000 RPM disks. The new systems have larger CPU caches.

62 of the systems have six network interfaces (five experimental interfaces), and are listed on DETER as pc3060s. The two pc3100s have 10 interfaces (nine experimental) to allow for experiments with more complex topologies.

These systems are connected via Nortel switches -- the experimental switch is a stack of seven Nortel 5510s and one Nortel 5530 with dual 10Gb uplinks, while the control switch is made up of two Nortel 5510s. This is similar the switch configuration for our pc3000s and for the Berkeley nodes.

In addition, Keith Sklower reinstalled the Emulab software with a number of his fixes as well as bug fixes from Utah.

As mentioned in the weekly report #59, experiments have the limitations on the number of links that cross switches and sites. It is due to the way the 'assign' script in the emulab software works. The 'assign' script allocates 100 Mbps per link even though the ns file specifies the link speed as less than 100 Mbps (e.g., 1 Mbps). This means, the number of VLAN's that cross two switches like, Cisco and Nortel at ISI would be limited to 10 even when each link has 1 Mbps as the speed.

To increase the number of VLAN's across the switch boundaries and the two campuses, we set the inter-switch trunk speeds in the testbed database as 4 Gbps, instead of the current real 1 Gbps, so that total of 40, instead of 10 VLAN's can be assigned. The ISI-UCB tunnel speed is set to 1 Gbps, instead of the real 150 Mbps. Doing this would potentially over-subscribe the trunk or the tunnel.

http://www.isi.deterlab.net/doc/Inter-Switch-Bandwidth-Limit.pdf

In the diagram on the above URL, the numbers next to the arrows stand for the actual bandwidth of the links, and the numbers next to them in parentheses are the number of VLAN's that can be assigned over the links. Please keep in mind that these links are shared by all the experiments running on the testbed.