[AusNOG] Monitoring ULL drops on AAPT MBE connections

[Tony]

Hi,

On Thu, 03 Apr 2014 09:56:02 +1000, Joseph Goldman <joe at apcs.com.au> wrote:
>
> 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.

Which might be fine for a handful of connections, but what about when you  
have 50 of them ? What about if you have 200 ?

Do/Can you charge the customer for this service (can you, really) ? At the  
very least the cost to you is a minimum of $100 to get the R.Pi installed  
at the customer site.

It'd be nice to avoid having to plug into the customers infrastructure  
(ie. switch) but then you need to be putting a router on site that has at  
least one spare ETH port to plug your R.Pi into. On these type on links  
we're typically installing an 1841/1941 as our managed CPE device, so then  
you're up for an extra WIC in the router to plug the R.Pi into (add  
another $200).

The correct solution is for the carrier to monitor this and expose it to  
the SP in such a way that it can be monitored by the SP. The problem with  
this is the carrier doesn't really care because it's a cheap product  
(cheap compared to fibre for a 20/20m service) and they don't really want  
to spend any money on it. I doubt there is a "standard" way of monitoring  
this kind of thing, so it would require the carrier to spend time  
developing a customised solution and then maintain it (extract stats from  
their device via SNMP and then populate into their NMS somewhere), all for  
no extra revenue (unless you're willing to pay more for "advanced  
monitoring option" so that you can see individual ULL status). By all  
means hit your account manager up about it. Every time we've spoken to  
ours the answer has been that they're not going to check ULL status  
pro-actively so it's up to us to somehow "know" a ULL might have dropped  
out and then log a fault (cue R.Pi idea).

The more ULL's you get, the harder it is to know one has dropped out. If  
you've got a 10M service over two ULL's, it's "fairly" obvious when one  
drops out because your speed is halved. When you've got a 10M service that  
is delivered over 8 ULL's then it's not quite so obvious when one drops  
out as the throughput might only go down to 9.5M if the last ULL was only  
there to make it up to the full 10M.


In summary - keep hassling your carriers about getting a solution to this.


regards,
Tony.