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.
— Rasmus Kirkegaard (@kirk3gaard) January 26, 2017
After a successful configuration test (millions of fast5 files generated) we contacted Oxford Nanopore and they organised to pick up the configuration unit.
— Rasmus Kirkegaard (@kirk3gaard) February 9, 2017
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.
still building and shipping em – more to follow pic.twitter.com/F38RbGZyGp
— Clive G. Brown (@Clive_G_Brown) February 9, 2017
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
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 184.108.40.206 as this is the actual range used. Static routes can be needed, but should be kept as small as possible”
Rasmus H. Kirkegaard
Latest posts by Rasmus H. Kirkegaard (see all)
- What is a good genome assembly? - November 1, 2017
- Can you beat our Nanopore read error correction? We hope so! - May 3, 2017
- Promethion configuration test and “reboxing” - February 16, 2017