[AusNOG] Monitoring ULL drops on AAPT MBE connections
Stephen Carter (FirstPath)
stephen.carter at firstpath.com.au
Thu Apr 3 15:31:24 EST 2014
FYI, the way we do this (FirstPath) is let our resellers nominate a management VLAN and BYOD, granted our network is very different and we do not reply on ULL's etc... but there are carriers out there that are trying to help provide solutions to this and greater visibility etc .... this solution scales well too n both copper and fibre.
Have a great day all.
Cheers
Stephen
-----Original Message-----
From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Tony
Sent: Thursday, 3 April 2014 2:13 PM
To: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Monitoring ULL drops on AAPT MBE connections
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.
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
More information about the AusNOG
mailing list