[AusNOG] Carrier aggregation port redundancy

[paul+ausnog at oxygennetworks.com.au]

I agree Mark that L2TP isn’t an issue, and DSL or something is an obvious choice for a backup of a customer EVC, but I am more concerned about aggregation port redundancy, protection for our business not just some customers.
 
We already have multiple aggregation ports due to capacity requirements and the carriers preference not to go 10G, go figure, so it’s already getting complicated from that point, but really, apart from covering your own equipment failure, having redundant ports in the same DC Is a waste of money and not really an adequate DR plan for our business as far as I’m concerned.
 
We can easily split our core between geographic locations, we can take peering, transit, and L2TP handoffs for DSL and NBN stuff in multiple locations easily, but redundant geographically separated EVC/VLAN handoff for Ethernet services seems to be an unnecessary challenge for carriers, when really it should be designed into a product from the start.
 
Ordering second EVC’s would be an answer for sure, but ultimately you are doubling your cost everywhere unless you are happy for a lower speed EVC for redundancy, and with the response times and restoration times seeming to be impossible to meet for carriers lately we can’t afford to run some remote sites on low speed links for 12 hours while Telstra gets out of bed at 2am.
 
Regards
Paul
 
From: Mark Tees [mailto:marktees at gmail.com] 
Sent: Tuesday, 18 August 2015 12:10 AM
To: Nathan Brookfield
Cc: paul+ausnog at oxygennetworks.com.au; ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Carrier aggregation port redundancy
 
L2TP terminated stuff should be easy enough providing the carrier lets you advertise your LNS prefixes by BGP etc.
 
Layer 2 hand offs could be redundant psudowires or VPLS multi-homing in theory but who is going to do that when they can bill for another EVC or specifically a VPLS service :D
 
For sites that require that level of redundancy it's probably good to build in a backup via DSL or a second EVC.
 
Also, having DR plans for those links in place is good too. IE have a second port on another device prepped and get remote hands to move it if there is a major failure on your side.
 

On Monday, August 17, 2015, Nathan Brookfield <Nathan.Brookfield at simtronic.com.au> wrote:
Hey Mate,
 
Layer 3 redundancy everyone will do without to much pushing, Layer 2 no one will.
 
If customers want Layer 2 redundancy they need EVC's to multiple DC's.

Nathan Brookfield 
Chief Executive Officer
 
Simtronic Technologies Pty Ltd
http://www.simtronic.com.au

On 17 Aug 2015, at 23:11, "paul+ausnog at oxygennetworks.com.au" <paul+ausnog at oxygennetworks.com.au> wrote:
HI all, just wondering what experience people have had with negotiating aggregation port redundancy/failover at different datacentres within the same state for major carriers ?
 
We are looking at implementing some geographic redundancy for our layer 2 connections which are handed off on an aggregation port in one datacentre so that we have a second aggregation port in another datacentre should the carrier or ourselves experience a major failure like an exchange switch or something.
 
We have had 2 or 3 failures over the last couple of years which luckily were on weekends and the impact was lower than normal, however the carrier does not have any interest in providing such an option across datacentres, they will do it within the one datacentre as long as you pay the full install and MRC on the second redundant port, but I can’t get them to do anything in separate locations.
 
Am I the only one who thinks that having geographic redundancy for such services is important ?
They don’t seem to think it’s an issue and are saying that they won’t do it but I would really like to have it for obvious reasons and am not sure if I should keep pushing or not.
 
I’m interested in other peoples experience in this area please.
 
Regards
Paul
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog


-- 
Regards,

Mark L. Tees
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150818/c46d54aa/attachment.html>