Connecting to JANET

Sorry it’s been a little while since our last post. We’re just coming to the end of the summer vacation, the point when we (and most other IT support staff around the university) get things ship-shape in time for the start of the new academic year. It’s been hectic, to say the least, with a number of exciting projects to talk about in these pages.

Several weeks ago now we upgraded the university’s connection to JANET to 10 Gigabits per second (from 2 Gbps). JANET-UK is the ISP for UK universities and in this region of the country we form part of something called the Thames Valley Network (TVN), which connects institutions to the JANET network, and each other. Here I’ve drawn a simplified image of the current TVN topology:

Thames Valley Network

Thames Valley Network

It was back in 2007 that we upgraded from 1 Gbps to 2 Gbps. That was a very exciting project, delivering some much needed resilience improvements by having two 1 gbps feeds on separate line cards in our edge router. These upgrades had been driven by our discussions with the university’s auditors, so next time you have the auditors come knocking, remember there can be a silver lining to that cloud! At the time we also were in need of the bandwidth upgrade, as Internet traffic continued on its ever upwards climb. Here’s a rather cute graph using data from the OUCS Annual Report showing this growth:

Average JANET traffic in GB/day

There are likely a number of causes of this rise in traffic in the past three years. Services on the Internet such as YouTube, iTunes, and more recently iPlayer, have played a part. Also, our friends in the Particle Physics (GridPP) community are making use of any and all available bandwidth to transfer experiment data around the globe. It was them that in part prompted JANET-UK and ourselves to move for the 10 Gbps upgrade this summer, knowing that CERN ‘s LHC is due to come back on-line.

Under normal circumstances we’d like to keep plenty of headroom on the JANET link, but from time to time these experiments result in about 400 Mbps of extra traffic. Whilst the “2 Gbps” link can take this, that is actually two separate 1 Gbps links using a simple hashing algorithm to load balance. If 400 Mbps is destined for one host elsewhere on the Internet it will hash onto one link and potentially fill it up even with spare capacity on the other link. This is one reason why JANET-UK themselves run 40 and 100 Gbps links in the core rather than bonding together multiple 10 Gpbs links with hash based load balancing. Here’s another graph from the depths of summer 2009, showing one such GridPP session receiving a few hundred Megabits:

Link to SJ5

A few weeks from now when term is underway, that 1.3 Gbps peak will be a daily average with the GridPP traffic on top. So for us the next step was to move from 2 Gbps to 10 Gpbs, but of course that means a pair of them to maintain the resilience we installed back in 2007. With good foresight we’d planned for this since before the 2 Gpbs upgrade, so all the 10 Gbps line cards were in place in our routers. Not so straightforward for the JANET-UK engineers though, who had to make a few visits to OUCS to upgrade their routers at our site. It was quite interesting for us to get an insight into their operations and the hardware platforms they’re moving to for the Thames Valley Network.

There still remain areas where we can improve on the resilience. Most significantly the new OUCS data centre currently under construction (and due 2011/2012) will likely house a second point of access for the university into the Thames Valley Network (and hence JANET and the Internet). Between now and then we will be working with JANET-UK in 2010 to make some improvements to the fibre routes in the city of Oxford to provide for greater resilience. As you might tell from the above, the work never ends. There will continue to be a need for more bandwidth and resilience, and the university is fortunate to have some great engineers at JANET-UK to help us deliver on that.

Posted in Backbone Network, Cisco Networks | Comments Off on Connecting to JANET

Moving to a new ARP and MAC logging system

To locate a node (workstation, printer, etc) on the network, you use a combination of the ARP logs from a router, and the MAC-port mappings from a switch. The ARP log translates IP to MAC, and the MAC-port log translates the MAC address to a switch port. The standard mechanism used to gather all this data is SNMP, from a central network management host.

On the University backbone network we gather this information once an hour from all our devices. In the past year, we implemented a new database backed system to replace the older flat-file data store (which had understandably grown large with historical data and was slow to query). The new system uses a piece of software called Netdisco, which is written in Perl and has a reasonable web front-end to perform basic querying and reporting.

So with running both the old and the new systems, our switches and routers were being queried twice an hour, and this was beginning to put an unwelcome load on their CPUs. Normally the CPUs on these devices do very little except for what’s called “management plane and control plane” activities – SSH, routing protocols, spanning tree, and so on. SNMP can be very intensive for a device, so we want to minimize it if at all possible.

Last week I rewrote three of our web tools for IT Staff, to migrate them from the flat file data source to the new database. In fact, I wasn’t able to completely migrate them, as we’ve not yet installed our new IP Address Management system, but I was at least able to drop one of our major hourly SNMP processes. So now we’re much happier about the load on our devices’ CPUs, but you may notice a couple of side effects in these web tools.

The main ARP Query tool doesn’t yet have much historical DNS data. The old flat file system logged the DNS entry of the IP at the time it was seen in an ARP log. The new system now does that too, but we’ve not imported the historical data from the old to the new. I looked at this, and it was a daunting data munging task, which I’ll leave for another day.

The Network Audit and Status tools similarly now speak to our new database backend. Unfortunately without our new IP Address Management system they also still load up some large flat files, so are slow to run – a typical query taking about 10 seconds. I hope this will be acceptable for the next nine months or so until we are able to move to full dynamic data lookups.

Posted in Backbone Network | Comments Off on Moving to a new ARP and MAC logging system

OWL Phase 2 WAP, Oxpoints integration

When OWL Phase 2 funding was given we were asked to quickly put together a database table and front end so that IT support staff could register access points. We were aware at the time that the schema was going to be incomplete as we didn’t have a good location data source, but it was more important to get things underway in terms of the hardware deployment, so the interface was completed with a basic text location field.

Now the issue is correcting this structure and data so that it’s more meaningful and useful.

The University Estates Directorate department has unique building numbers (and room numbers etc) for all departments and we were impressed by what they’d done with their data (example: web based browsing of floorplans with popup annotations), however the colleges have their own numbering scheme unique to each college. Consequently we couldn’t adopt the Estates data as our backend since it only covered half the locations. That is – the unique way of identifying an access point’s location couldn’t be a building/room number because there is no common scheme for this numbering.

Oxpoints seemed like a useful backend, but the data would need to be created. We met with the Oxpoints team to see if they could import the Estates data, which they have since completed.  This only leaves the college locations to worry about.  For this our modified web interface will give the option of using an existing Oxpoints location, or creating a new one, with some care needed to get this usable and intuitive in the interface design. From here our application will then need to ask Oxpoints to create a location and have a location ID of the new location returned. We’ll then store an Oxpoints location ID against each access point.

What does all this mean?

The better quality location data will allow better automated scripting for infrastructure purposes, but it also gives some interesting options for other teams perhaps thinking of applications giving data based on location (a crude GPS). For example, a laptop with no GPS could still make use of a web application which knew the user’s geographic location. Although new services like Skyhook Wireless are mapping WAPs, of course many of ours are within University or College buildings which cannot easily be surveyed, so our storage of this data is still very useful. It’s also likely to be more accurate and extensible than the external service, being based on Oxpoints.

Posted in Wireless | Comments Off on OWL Phase 2 WAP, Oxpoints integration

OUCS Data Centre Clean-Up

This is just a minor post about our day to day background operations.

Our team is currently making efforts to clear up our equipment and locations, spurred on by

  • Having a new data centre manger
  • Having IT support staff inductions always include a tour of the OUCS data centre
  • Wanting to clear up years of accumulated clutter
  • Adhering to the commitment to greener computing
  • Ensuring that in an emergency the data, labelling and servers are accessible

To reduce power consumption and physical presence the majority of our development hosts were disposed of and instead setup on a simple virtual machine. Development servers were traditionally hosted on out of warranty hardware before this.

We’ve moved remaining non rack based equipment to a new location to facilitate the data centre manager’s plans to restructure the room for better air conditioning flow.

An audit of the data centre’s primary patch cabinet is underway, with cable labels being added, checked and updated as needed as well as defunct cabling being removed.

As a team, Networks and Network Control (who cover the more physical side of networking) already had a cabling colour standard however it wasn’t widely published to other teams so we’re aiming to correct this. We’ve updated the OUCS internal wiki to include the details and are hoping to put a small poster with the details on each cabinet we own, where it will be visible to others.

While disposing of our old development machines we also prompted other groups in OUCS to use the opportunity to dispose of their old hosts. In the end a massive pile of ancient machines was built in the data centre from old servers hidden under shelving and desk units in the area. The pile grew large enough that it became intrusive to operations in the room and it was a big relief when collected!

Posted in General Maintenance | Comments Off on OUCS Data Centre Clean-Up

URIBL is back

We had to remove Oxmail’s checking of URIs against the URIBL blacklist a couple of weeks ago after a change of licensing meant that we could no longer use it for free.

JANET(UK) has now purchased a private datafeed and offers lookups via multi.uribl.dnsbl.ja.net.

Oxmail’s SpamAssassin is once again scoring URIs which show up in this blacklist.  As an added bonus we gain access to the Gold blacklist by virtue of using the paid-for datafeed.

Posted in Mail Relay | Comments Off on URIBL is back

Wireless Application Firewall

In order to prevent ‘Location Independent Network’ abuse resulting in C&D orders landing on the desks of ITSS, we’ve recently added an Allot Netenforcer to the backend of eduroam and OWL. It will be configured to block P2P traffic and we plan to provide an ADSL-type experience for users, to ensure fair use of wireless resources (roughly speaking: 8Mbps download and 2 Mbps upload to Oxford IPs, 2Mbps download and 0.5 Mbps upload to the Internet).

We’ve not announced this formally yet as we are waiting for a software patch from Allot which will allow us to enable a ‘catch all’ rule for P2P type traffic, in addition to the rules for known protocols like BitTorrent. Once this is complete we’ll announce the change through the usual channels.

Posted in Wireless | Tagged | Comments Off on Wireless Application Firewall

VPN Service changing server IP addresses

This change is not happening now.  This message is simply to give advance notice in order to give you time to change your firewall rules if necessary.

The current VPN Service is provided by a single server with IP address 192.76.27.246 .

The servers of the new VPN Service will have IP addresses from the 163.1.94.16/28 netblock.

The new Service will be provided by a cluster of servers in order to provide server redundancy.  Because of the way in which Cisco ASA clusters work, all the cluster’s members’ IP addresses need to be accessible rather than just a single “master” address.  Since firewall administrators who have 192.76.27.246 in their ruleset will have to change it, we’ve taken the opportunity to give the VPN servers their own small netblock so that any future changes won’t require further ruleset editing.

When connecting to the cluster, VPN clients first connect to the IP address of vpn.ox.ac.uk which is known as the Virtual Cluster Master (VCM).  The VCM then gives the VPN client the IP address of the cluster member that it should use.  The VPN client now makes a new connection directly to the cluster member to which it has been assigned.

Posted in VPN | Tagged | Comments Off on VPN Service changing server IP addresses

Hello world!

Welcome to the OUCS Networks Team blog.

This blog is a new venture for us, but it’s something we’ve wanted to do for a long time. Our days are filled with a mix of the usual IT firefighting but also a lot of development of our services. We work on so many projects, but it would quickly become annoying to witter on about them on regular mail lists. So we started this blog to provide those interested with more information about each of our services, and the changes we make.

We’d love to have feedback as well, and comments will be enabled on some posts. As always, though, the best way to contact us is at networks@oucs.ox.ac.uk, because we may not always be watching your responses here. We’ll also continue to always make official service announcements in the regular places such as the OUCS web site, and IT mail lists.

Posted in Uncategorized | Comments Off on Hello world!