-
-
We've recently implemented an internal DNS structure on the KCN. This means that if you try to access a resource based at another school from within the KCN, this should now work automatically.
So, for example, if I'm at school A but I normally work for school B, I can visit http://mail.schoolb.kent.sch.uk and access my emails remotely via the web client for my mail server without any fuss. Previously this would have required fiddling with DNS and creating dummy zones at 'school A' but will now work seamlessly.
To ensure that you benefit from this you'll need to be using the KCN forwarders (172.31.81.46 - primary for West Kent and 172.31.49.46 - primary for East Kent) where the zones are located.
Neat eh!
Tom Bell
-
-
To gather information for the Kent Community Network (KCN) report to schools 2006, we've generated some statistics in relation to latency across the KCN.
We were pleasantly suprised with the results. The polling engine is based at the core of the Maidstone WAN centre, and polls all nodes on the KCN every 60 seconds. Typical latency from the polling engine to a school CPE is 2 milliseconds (ms), this is very impressive.
We decided to time the latency from the furthest node (school switch) to the West of the KCN to the furthest node East (Swanley > Wingham) which is 10 hops, the latency round trip time (RTT) was 4ms, which is very impressive.
Although the Internet is beyond the control of the KCN, the KCN obtains its internet access via KentishMAN and JANET this provides advantages when accessing websites peered with JANET. Websites such as the British Museum, BBC and British Pathe are peered with JANET, and therefore traffic destined to these websites will go via JANET, a network we know is reliable.
Below is a chart illustrating the latency from a client machine on a school LAN to a website peered with JANET:
|
bbc.co.uk |
4 ms |
|
thebritishmuseum.ac.uk |
3 ms |
|
britishpathe.com |
4 ms |
|
nationalarchives.gov.uk |
8 ms |
Below is a chart illustrating the latency to websites which are not peered with JANET:
|
kent.gov.uk |
6 ms |
|
unisys.co.uk |
16 ms |
|
apple.com (America) |
141 ms |
Attached to this post are some charts that illustrate traffic, latency and packet loss (scales vary). The average latency is commented, however, some short spikes in latency are noticeable. Closer investigation shows that most of these spikes are in timing with spikes of traffic.
The latency increasing when traffic increases is due to prioritization of traffic. The ICMP (ping) protocol is used to monitor latency. However, ICMP has the lowest priority, so when traffic peaks, ICMP is delayed, hence the spikes.
Marc Turner
-
-
The new IronPort Mail relay Servers have now been in place for several months. Last week, of the 3.45 million messages processed by both servers, 93% (over 3.2 million) were classed as threat messages of which 82% were stopped by reputation filtering at the connection phase. Only 11% of all messages were actually processed "on box".
The mail relays now have a centralised tracking and reporting server which allows our helpdesk to quickly and effieciently track any false positives, although currently these are few and far between.
For additional information on the mail relays, feel free to contact any member of the KCN Team.
Gavin Hutchinson