Promethion configuration test and “reboxing”

Following our PromethION unboxing event we have finally managed to connect the machine to our University network and pass the configuration run. The configuration test demonstrates that the network can handle the data produced and transfer it fast enough to a network storage solution.

 

After a successful configuration test (millions of fast5 files generated) we contacted Oxford Nanopore and they organised to pick up the configuration unit.

So now we just have to wait for the sequencing unit which they mentioned should be available around the end of February (Pretty soon!). Maybe the CTO is building it himself this very moment.

The hardware installation was super-easy, but the network configuration was a challenge. The PromethION settings are controlled through a web-interface, which seem to run some configuration scripts whenever we have changed something and submitted the change. However, it is not completely transparent what is going on and handling the PromethION as a “black” box system with multiple network interfaces was not exactly straightforward. Furthermore, our University runs what they call an “enterprise configuration”. This essentially means that we are not allowed to play with settings, and in order to ensure maintenance of the entire network is feasible, we cannot make too many “quick and dirty” workarounds.

Hence, our local IT-experts have been essential in getting the PromethION up and running!

I would highly recommend that you get your hands on a “linux ninja” and a true network expert if you risk running into non standard configurations (My personal guess is that it would probably have worked fairly straightforward if we would have plugged it into a standard off the shelf router with default configuration).

Our IT guys came up with the following wishes for improving the network setup:

“For faster understanding of the device, it would be nice with a network drawing, and maybe a few lines on how it is designed to work (for a Sysadmin or Network admin)

The possibility to use static address for everything should be possible.

It would be really nice if you could tell the setup script a start or end IP. We had to reconfigure our network because setup insisted on using, the top 2 addresses in the /24 network we had assigned to it (.253 and .254) which are used for HRSP in our network. We had to remove HSRP, on our 10G network and enable DHCP on the local server network (Ethernet), which is not desirable.

Having a “management” interface on a DHCP assigned address, is a hassle. Allow static addresses, so its easy to use DNS names in stead of guessing IP´s

Allow configuring static DNS.

The test device came with static defined routes

172.16.0.0 255.240.0.0
192.168.0.0 (Cant remember subnet on this one)

Both are problematic, as they are WAY bigger than they need to.

Especially 172.16.0.0 is problematic for our network, as our DNS servers are on 172.18.x.y

I did not find any good reason for 172.16 anywhere.
192.168 I am guessing is there for the Default setup. That should in my point of view be limited to 192.16.253.0 as this is the actual range used. Static routes can be needed, but should be kept as small as possible”

The following two tabs change content below.
Rasmus H. Kirkegaard

Rasmus H. Kirkegaard

Staff scientist
Playing with microbes and bioinformatics on the path towards "finished" genomes for "everyone" of them and rapid detection. My bet is currently on nanopore sequencing and I am fortunate to be involved in MinION and PromethION research in our lab.
Rasmus H. Kirkegaard

Latest posts by Rasmus H. Kirkegaard (see all)

Posted in General.

Leave a Reply

Your email address will not be published. Required fields are marked *