Network for Learning - The Journey Begins

Last Things First

N4L are now using my services part time in 2014 to assist with school transitions to N4L.  I've decided that my "title" (something I'm never particularly comfortable with!) should be "Integration Advisor".  I will work with schools, N4L integrators and current providers to help make the transition for a school to N4L as seamless as possible.  Expect me to have lots to say, to be impartial, and to put the needs of schools first - teaching and learning is what it is all about after all.  A critical component for any change process is planning - schools need to be thinking now about the long term bigger picture ahead of their transition to N4L.  I'm more than happy to share experiences, discuss strategies and help implement these.  The job will doubtless evolve - all things do - so expect to see all sorts of things  pop up.  I am excited and positive about the opportunities, both personally and for New Zealand schools.  The future is here and it is happening.

And I still teach - I'm very passionate about my classroom time spent with kids!  In 2014 I have a Y11 ICT class and a Y12 Mathematics class.  Thus I offer practical solutions based on very real experiences and my own daily interactions with teachers, students (Y7-13), administrators, support staff, external agencies and IT contractors.

To all those who have commented so positively to me about this site:  Thank you.  For me the reward is knowing that you find it useful.

I can be contacted at tim.harper@n4l.co.nz.


prior to 11 October 2013

Mt Aspiring College was approached verbally and offered the opportunity to be one of the initial schools to join N4L in 2013.  We readily agreed.

A contract for services was sent to the school and signed by the principal. This was scanned and sent back to N4L as a PDF.  BoT chair is kept informed.

Discussions were held (via phone conference) with the N4L Provisioning team to ensure that they understand our network architecture and our external connectivity needs for video conferencing, web hosting of services like Moodle and our SMS portals, as well as remote access needs. The N4L team provide us with a plan that describes our current network external connectivity arrangements.

Initially the N4L connection will be about access - firewall and filtering services will happen later - so we will continue in the short term to use our existing pfSense firewall and filtering.  Discussions are held relating to default firewall and filtering configurations. 

The CPE device is defined to be a Cisco 2951 router.  It is 2U rack-mounted 88.9 x 438.2 x 469.9 mm - nothing small about it.  The rack in the comms room (where our ONT is located) has enough space and power for it.

The ONT and Chorus fibre are capable of handling multiple profiles - this is a part of the UFB/RBI design brief.  This means that the Cisco 2951 router can be connected to a separate port on the ONT and effectively allow us to run N4L services in tandem with our existing Telecom Ultra Fibre service during the acceptance phase.  If there are any issues with the N4L connection it will be easy to load the relevant profile into the existing pfSense firewall and roll back if any issues are found.   

Note:  pfSense uses XML formatted data to allow the configuration to be backed up or restored.  By editing the XML file new WAN details can be assigned easily and multiple configurations managed quickly simply by restoring the relevant backup.  Multiple WAN interfaces could also be used but there are some things that don't work well with multiple WAN interfaces in pfSense.


11 October 2013

1:05pm: Associate Education Minister Nikki Kaye makes an announcement at uLearn in Hamilton that Mt Aspiring College will be one of the first schools to join N4L.

2:25pm: We announce the news to our staff and board via email - it is holiday time.  We explain to them what N4L is and what it will mean.

3:15pm: Telecom call to say that the process is now underway and to expect Chorus to arrange to visit for a site inspection.  It is explained that we already have a running connection using RBI fibre so things should be fine but as this will be the first of these connections it is decided that a cautious approach to everything should be taken and everything should be checked.


18 October 2013

8:40am: N4L confirm that Chorus are now expected on 23 October to complete the ONT inspection.  Given the local weather conditions over the last week Chorus will have been busy - lots of thunder and lightning will have been impacting on Chorus staff.


23 October 2013

2:30pm: Chorus call to say that they are on their way. Two technicians arrive at 2:50pm.  It has been decided to install a second ONT and deliver N4L services via a second fibre core rather than use multiple profiles.  The new ONT is mounted on the wall and the ETP is inspected.  The ETP only has one bulkhead connector in place and a call is made to splice a pigtail to the second fibre strand inside the ETP.  The Chorus technicians ring to check but this is not permitted as a part of the build specifications.  They also need to check on the termination for the second fibre strand as it was installed prior to RBI using different specifications.  It is also understood that the fibre terminates in a different room in the Wanaka Exchange and that some internal fibre jumpering may be needed at the Exchange to route the fibre to the correct room where the other RBI connections exist, along with the fibre to the RBI/UFB handover in Queenstown.


The image above of the inside of the ETP shows a vertical green bulkhead connector for our Telecom Ultra Fibre connection.  Immediately to the left is the connector for the original fibre strand - it is white and clearly different.  It is this white connector that will need to be replaced with an RBI-standard bulkhead connector.

Chorus will be back but the two technicians cannot give a time frame.


12 November 2013

2:50pm: N4L advise that router installation can be expected on Friday 22 November.  WAN / Public IP addressing  will be available prior to this so that a new instance of pfSense can be configured for testing purposes independently of the rest of the school.  We are still waiting for the bulkhead connector issue to be resolved by Chorus but a positive outcome is expected by router installation time.


15 November 2013

9:30am:  I was away on Wednesday/Thursday and Chorus have been in to make the second N4L fibre live.  They have used the existing bulkhead connector and connected this to the second N4L ONT.


The N4L fibre in the above photo is on the left using the white bulkhead connector.  Our existing Education Plus fibre is on the right using the green bulkhead connector.  If you look closely you can see that a new fibre strand has been used.  The new one is white - compare this with the earlier photo that shows a blue fibre strand on the white bulkhead connector.  Originally only two fibre strands were spliced from the school back to the exchange so Chorus must have been busy to patch a third strand as that would have meant opening at least two pits between the school and the exchange to do it - then they would have had to unravel the strands before splicing them.



The N4L ONT is at the top in the above photo.  The "Optical" light shows green.  The Education Plus ONT is at the bottom.

In a week's time (22 November) the N4L Cisco 2951 router is due.  We will also be installing an additional APC rack mount 1200W UPS as we are starting to push the two current UPSs in this cabinet - especially as we will run a second pfSense server to enable testing to be completed in tandem with the existing connection.


18 November 2013

12:15pm:  N4L have asked that the school be prepared to go live on N4L at 4pm on Wednesday 27 November 2013. Public IP addressing details are expected shortly so that the firewall can be configured.  Testing will then be completed between Friday 22 November once the router is installed and Wednesday 27 November.


19 November 2013

3:35pm:  The static public IP range for the connection has been assigned:  210.54.147.16/29.  The Cisco 2951 router will have IP address 210.54.147.22 and pfSense will use 210.54.147.16.  The remaining IP addresses will be used for our servers and video conference units.


21 November 2013

7:00pm:  Details around router IP addressing have been released.   The Cisco 2951 router will have a /31 point-point range from the router back into the Telecom core.  This is exactly the same as our current Education Plus fibre.  The /29 range is routed via the /31 range making it available for use for servers if a school needs more than one static public IP address.  If necessary additional ranges can be routed.

The upstream end of the /31 range will be useful to us as a local monitor IP in pfSense to check on connectivity between the school and the core.  (We could use any public IP but it seems more polite to use our own!)

N4L have also sent the "Transition Service" document that contains detailed transition implementation tasks.  This contains details about the upstream DNS servers, NTP server, an upstream SMTP server address and port (should we need this - which we don't as we use Google to supply mail services), the WAN Connection IP addresses for the /29 range and specific confirmation about the router model.

Interestingly the port setting on the Cisco 2951 router is defined to be Auto-speed and Auto-duplex.  This is a change from standard Cisco setups that require the port setting to be "100/Full" rather than "Auto/Auto".  The Telecom Education Plus Cisco 2960 that we currently use requires a port setting of "100/Full" and this setting tripped up lots of schools as by default all switch ports etc are set to "Auto/Auto" and for many schools changing this was hard work unless they knew what to do.  Thus having equipment delivered that matches the existing default school equipment setup has to be a good idea.

We will need to contact Asnet to get the bridge updated with the new static public IP address details.  There may be a fee from Asnet for this. We will also need to update the public IP inside each VC unit too.


22 November 2013

12:30pm:  Rick and Andrew from Alpine Communications Ltd (ACL) arrive to install and test the Cisco 2951 router.


Extensive testing is needed so so the router is patched through to our nearby Board Room for Rick (on the right) and Andrew (on the left) in the photo below.  They have several 15+ page documents to wade through to complete testing so sitting in the Comms Room is not particularly appealing.


Whilst completing all the testing they are in a phone conference with the Telecom/Gen-i IP Provisioning team.  This is new for everybody so lots of learning takes place and all aspects of the circuit are fully examined.

Our go-live date is scheduled for sometime later in the week ending 29 November with the actual switch over for the school LAN happening late afternoon that day.

Having Andrew from ACL involved is a great little back-story.  He is an ex-student of Mt Aspiring College and attended when we only had a 512k S-DSL link.  ACL, with Andrew, also completed our SNUP upgrade in 2008.  We have all grown up together!


26 November 2013

4:30pm: There is now a live N4L connection at school.  We are seeing really nice speed from the fibre circuit.

The image below shows a test to Telecom's Christchurch server using http://www.speedtest.net


Using the same website Telecom's Wellington server is only 6ms further away for the return trip!


The local Mig 15 jet can make the return trip to Dunedin in about 720,000ms - that's high latency, off-the dial jitter and bandwidth to burn.

Mig 15 jet at Wanaka


The pfSense firewall traffic graphs confirm the results of the tests:




Our plan is to go-live on the school LAN on Monday 2 December after school - the only reason for waiting is school reports and access for teachers from home needs to be uninterrupted until reports are completed.  Whilst the actual change over process is quick DNS propagation will mean that there is a period of time when staff won't get access easily.  Teachers are working late and early at the moment.  Thus it is best to simply wait.

When we do change over we will continue in the short term to use pfSense for all firewall and filtering needs.  Later (possibly sooner!) we will change to the N4L provided Cisco Cloud Web Security filtering service.  This is looking like an amazing system.  People will be pleased to know that no proxy needs to be defined to a local browser and there is scope for all the things that schools are likely to want in a web filtering solution. 


2 December 2013

3:30pm: The  school is now connected to Network for Learning.  All is go and all is good.  



We have decided to use Cisco Cloud Web Security filtering as an overarching safety net and we are impressed by the wide range of configuration and reporting options.  What follows below is a really brief overview - hopefully you will get the idea.

Filter configuration is built around policies with each policy having these components:  "Who", What" and "When".  There can be up to 100 policies.  Initially Mt Aspiring College will need 4 policies to manage staff, privileged students, naughty students and finally every one else. This may change later as the need arises.

Each policy can be defined in detail:
  • The "Who" component has the ability to use IP addressing,  LDAP or (if I understand it correctly) SAML (via an IdP) to manage users.  Or you can simply have one group with everyone in it (which is how we are managing things at the moment.)  The example in the screen captures below shows just one of the options for defining the "Who" component - for example it can be based on a whole LDAP group.
  • The "What" component is incredibly flexible - it can use category filters for a broad-brush approach, allow sites to be defined using DNS or IP addressing, content types, file types, application specific filters (eg block Facebook Video Chat) or even user agents (eg block a specific browser on a specific platform!) 
  • Finally the "When" component of a policy allows time based scheduling.
Each policy has a "Rule Action" setting:
  • Allow—Access is allowed, and data is stored for reporting purposes.
  • Anonymize—User, group, internal, and external IP details are replaced with “undisclosed” in reporting data.
  • Authenticate—The user must authenticate. 
  • Block—Access is denied.  You can define the html code that shows on the "Blocked Site" page.
  • Warn—Access is allowed only if the user clicks through the warning page.  You can define the html code that shows on the "Acceptable Use Policy" page.
The policies are processed in hierarchical order.

There is a "Child Abuse Content" category - this is never displayed and the block setting cannot be disabled.  All browsing is also subject to the Department of Internal Affairs Child Protection filter and that is non-configurable by schools.

There is also a "Dynamic Classification Engine" that will attempt to classify previously unclassified websites based on their content.  Currently the categories that are supported by the "Dynamic Classification Engine" are "Pornography", "Gambling", Hate Speech", "Filter Avoidance", "Illegal Drugs" and "Illegal Downloads".

Despite looking complicated the "out of the box" N4L-provided default settings should keep many schools very happy as no modification will be needed.  Those schools with more complex needs have the opportunity to develop an incredibly comprehensive filtering solution.

See the screen captures below for details.




With regard to Category filters shown above don't be fooled by the screen capture showing no block on eg the "Pornography" category - that is managed in the Default block policy as a separate item.  The above is for an "Allow" rule and we have not specifically allowed a category - rather we have blocked specific categories in another policy.  A tick in a box on the above example would implicitly allow that category for everyone.








4 December 2013

7:30pm: We are on track to disconnect our Education Plus fibre service on Monday 9 December.  

After 2 days of use with just our Year 7-10 students we have chewed our way through 39.8GB of data.  Below is our real-time traffic graph for the 20 minute period 12:52pm - 1:12pm (during period 4 just before lunch):


When the senior students and hostellers return in 2014 we expect to see data use rise significantly - the older students do make up a higher proportion of our BYOD users.

So far only two sites have been added to the Cisco Scansafe allow filter rule.  This was easy to do by adding the domains into the "Domain" list (see the example screen posted on 2 December) and the changes were reflected within a few minutes.

The only oddity is that web sites are geo-referencing the school as being in Australia.  (Now that really does help our anonymity!)  This manifests itself by eg Google redirecting us to www.google.com.au, by having auto-populate fields try to add in Australian phone numbers or by eg Meraki suddenly showing all the "Room 3" computers as being in Melbourne.  This may lead to issues where content is restricted to New Zealand registered IP addresses but sites like TVNZ OnDemand still work.  May be we can watch Australian content?  An experiment is needed!

Incorrect geo-referencing is caused by the Cisco Scansafe system - their cloud currently resides in Australia.  An equivalent system will be built in New Zealand and should be available early in the new year.  In the mean time a work-around is being sorted out.


7 December 2013

5:00pm: Geo-referencing - the experiment failed and we cannot view eg Australian TV from www.abc.net.au.  Never mind - it was worth a try!