[AusNOG] Going beyond ADSL in a non-NBN world

[Paul Gear]

Hi all,

I asked this on IRC today and after discussing it for a while with 
various people I agreed that it needed a fuller expression here. (It has 
also been posted to SAGE-AU - apologies to those on both lists.)

My biggest client has a growing network of about 30 branch offices 
scattered around Queensland, mostly connected on ADSL, almost 
exclusively through iiNet.  We've had a number of poor support 
experiences recently, particularly last week where I was flown in on 
site to try to resolve some connectivity issues.  I had logged a fault 
on the line and was told a Telstra tech would visit site early in the 
week.  When the Telstra tech didn't show, I rang iiNet and was told that 
Telstra had decided there were no problems with the line (and so didn't 
bother coming on site), and was told the fault was resolved, despite the 
fact that I was still experiencing 20% packet loss on pings, and tens of 
thousands of receive CRC errors every hour.  When I pushed for more 
information, I was told that there was a congestion issue on that DSLAM 
and it wouldn't be fixed for another 2.5 months.  (Somebody please tell 
me how congestion can cause CRC errors!)  So over the week, I got a lot 
more familiar with ABC Jazz (iiNet's hold music), and came to the 
conclusion that we need to investigate alternatives to ADSL (and iiNet).

What I'm looking for is (in rough order of importance):

 1. better line reliability
 2. better line monitoring (so that I can prove I'm getting better
    reliability)
 3. access to technical support which is more thorough, transparent,
    communicative, and technical
 4. better uplink speeds

At the moment most of our sites use a standard consumer-grade ADSL modem 
in bridging mode, and our Linux firewall runs the PPPoE connection and 
an OpenVPN tunnel to our data centres.  We could get #2 simply by using 
a more advanced CPE (e.g. Cisco 88x series has been recommended), but 
all this it would do is prove that we have a bad line.  Finding an ISP 
that is big enough to understand how to deal with Telstra but small 
enough to talk technical with us will solve #3, but #1 & #4 are 
problematic.  Many of our sites are regional, so Metro Ethernet will not 
likely be available.  Some of them are 6+ km from their local exchanges, 
and, as a special bonus, get terrible 3G reception.  MPLS doesn't seem 
to solve the issue of line quality or monitoring - it works with 
whatever L2 technology is there.  Most ISPs EoC offerings seem to be 
just bonded SHDSL, and there's no guarantee the ISP is actually 
monitoring the pairs that make up the EoC bundle, and I'm told that they 
generally don't monitor it until the customer complains.

So getting down to my actual questions:

  * What technology is the most cost-effective step up from ADSL, given
    the above parameters?
  * What CPE would you recommend for getting useful quality metrics
    about the line (exposed via SNMP or some other openly standardised
    method) so that we can go straight to the ISP with hard data when a
    line fails?
  * How relevant is OAM as part of this solution?

My current thinking is tending towards SHDSL with low-end Cisco/Juniper 
CPE.  In the sites where it's viable, obviously we'd go fibre in 
preference to copper if the cost difference were low. Either way, this 
would be a big cost increase over our current setup, so I need to 
convince management (and be convinced myself) that this will actually be 
a cost-benefit win on the reliability, monitoring, and support sides.

Any thoughts?  I'm happy to take off-list plugs from relevant service 
providers, as long as you're OK with the fact that you'll be behind our 
existing suppliers in the queue.  (Please, no offers of fully managed 
network services.  No offense, but I just don't believe that you care 
about our connections enough to monitor them well.)

Thanks,
Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140324/ce4c90ea/attachment.html>