[AusNOG] Monitoring ULL drops on AAPT MBE connections

[Joseph Goldman]

For the sake of simplicity, a ULL is a single copper pair. MBE/EoC/SHDSL 
connections can bond multiple pairs together to give higher synchronous 
speeds for a service. Usually in the many hundreds of $$ per month, 
tends to be business grade connections.

The beauty of it is that a) it bonds, so if a single pair gives you 5/5, 
and you have 2 pair, you get 10/10, and b) if one copper pair fails, the 
other takes up all the slack (and it just becomes a 5/5 connection), so 
you get some decent redundancy out of it

In these scenarios it is more common than not for the infrastructure 
provider to terminate the copper directly in their equipment, and 
provide ethernet hand-off to the CPE.

Without some support of the infrastructure provider - I quite like the 
idea of say a raspberry pi sitting next to the customers router doing 
tests to check throughput. Its not a definitive test by any means but it 
could at least flag a potential problem for you to start investigating.

On 03/04/14 10:42, Alex Samad - Yieldbroker wrote:
> Disclaimer - not sure what a ULL or its infrastructure is but
>
>
> Can't you snmp probe the device and check for status  ?
>
> A
>
>> -----Original Message-----
>> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Paul
>> Gear
>> Sent: Thursday, 3 April 2014 10:36 AM
>> To: ausnog at lists.ausnog.net
>> Subject: Re: [AusNOG] Monitoring ULL drops on AAPT MBE connections
>>
>> I'm generally a bigger Linux fanboi than the next guy, but I don't consider this
>> adequate for determining whether a line is sound.  It needs real stats like
>> uptime, retransmits, CRC errors, etc.
>>
>> On 04/03/2014 09:31 AM, Luke Iggleden wrote:
>>> If you have access to run a command over SSH you could setup nagios or
>>> some monitoring software to exec a ssh command on a remote
>> server/client:
>>> wget -O /dev/null http://some.host.in.your.dc/file.100MB.bin
>>>
>>> in the early hours of the morning when you know there is no traffic on
>>> each client, if the script doesn't return within x amount of seconds
>>> then its running suboptimal, email from monit back to create a ticket
>>> for someone to investigate.
>>>
>>> Would need some tuning for each client depending on the speed of the
>>> original deployment.
>>>
>>> Just a thought.
>>>
>>> Cheers,
>>>
>>> L
>>>
>>> On 3/04/2014 10:19 am, Joshua D'Alton wrote:
>>>> There was a thread recently on this. Think the conclusion was,
>>>> basically if the service is provider-NTU, you're stuffed.
>>>>
>>>>
>>>> On Thu, Apr 3, 2014 at 10:07 AM, Radek Tkaczyk <radek at tkaczyk.id.au
>>>> <mailto:radek at tkaczyk.id.au>> wrote:
>>>>
>>>>      Hi Guys,____
>>>>
>>>>      __ __
>>>>
>>>>      We are getting more and more cases where an AAPT MBE connection
>>>>      drops a ULL, and no-one notices this until the client complains
>>>>      about poor speeds, or another ULL drops and takes the connection
>>>>      offline.____
>>>>
>>>>      __ __
>>>>
>>>>      For example, say an end user has an AAPT 10/10 MBE connection which
>>>>      uses 2 x ULLs. If one of the ULLs drops, the speed will drop to
>>>>      around 5/5 and everything keeps going at the lower speed. This is
>>>>      all fine, except that AAPT do not correct the issue until you log a
>>>>      fault. Or worse, the second ULL drops at a later time and takes the
>>>>      connection completely offline.____
>>>>
>>>>      __ __
>>>>
>>>>      How are we supposed to log a fault if we can't monitor for a ULL
>>>>      connection getting dropped?____
>>>>
>>>>      __ __
>>>>
>>>>      How are other people handling this situation?____
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog