<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Paul,<br>
      <br>
      I think the key to your problem is...<br>
      "At the moment most of our sites use a standard consumer-grade
      ADSL modem in bridging mode"<br>
      That would imply that you don't have access to any DSL stats from
      the modem?<br>
      <br>
      Unless you can obtain the RS Error counters from the DSL modem,
      you will remain in the dark.<br>
      <br>
      You simply can't accurately diagnose DSL problems at the IP layer.<br>
      That's a bit like using a speedo to diagnose a faulty spark plug.<br>
      <br>
      Cheers,<br>
       - Guy.<br>
      <br>
      <br>
      On 24/03/2014 10:16 PM, Paul Gear wrote:<br>
    </div>
    <blockquote cite="mid:533013F8.8090008@libertysys.com.au"
      type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      Hi all,<br>
      <br>
      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.)<br>
      <br>
      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).<br>
      <br>
      What I'm looking for is (in rough order of importance):<br>
      <ol>
        <li>better line reliability</li>
        <li>better line monitoring (so that I can prove I'm getting
          better reliability)<br>
        </li>
        <li>access to technical support which is more thorough,
          transparent, communicative, and technical<br>
        </li>
        <li>better uplink speeds</li>
      </ol>
      <p>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.<br>
      </p>
      <p>So getting down to my actual questions:<br>
      </p>
      <ul>
        <li>What technology is the most cost-effective step up from
          ADSL, given the above parameters?<br>
        </li>
        <li>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?</li>
        <li>How relevant is OAM as part of this solution?<br>
        </li>
      </ul>
      <p>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.<br>
      </p>
      <p>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.)<br>
      </p>
      <p>Thanks,<br>
        Paul<br>
        <br>
      </p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
AusNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a>
<a class="moz-txt-link-freetext" href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Guy Ellis
<a class="moz-txt-link-abbreviated" href="mailto:guy@traverse.com.au">guy@traverse.com.au</a>
<a class="moz-txt-link-abbreviated" href="http://www.traverse.com.au">www.traverse.com.au</a>
T: +61 3 9386 4435 M: +61 419 398 234
</pre>
  </body>
</html>