<div dir="ltr"><div class="gmail_extra">Doesn't give you a specific answer so apologies if not useful to your situation but in past teams I've seen the following kind of things done. <br><br>- We matched the customer SLA to the 'lowest common denominator' of the access link, or the aggregation router (generally we had 24x7x4 hour hardware replacement, so we doubled that to give time to install and reconfigure e.g. 8 hours restoration ETA). Often there was a switching layer between the assorted backhaul providers and the aggregation PE so the option also existed to re-provision customers but that was never really something we planned to do.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- We ran multiple boxes, so we spread the impact of hardware outages (and upgrades). If a customer wanted higher availability, we provisioned them two links on two different aggregation boxes and ran HSRP or BGP sessions with them.<br><br>Single boxes failing wasn't something that kept me up at night to be honest, it's empirical but we had more failures with backhaul providers and customer premises losing power than we ever had routers shit themselves in either a hardware or software fashion. We tended to not run lots of complicated features on the one box, again we tended to build out at least a pair of aggregation edge devices for each type of service (PPP, colocation, business services etc)<br><br>Sam<br><br><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, May 25, 2017 at 8:21 PM, Matt Selbst <span dir="ltr"><<a href="mailto:matt.j.selbst@gmail.com" target="_blank">matt.j.selbst@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes indeed I'm talking about the aggregation router failing.<div><br></div><div>Perhaps clustering multiple chassis although I don't know any Cisco agg routers that can do that.<div><div class="h5"><br><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 8:46 PM, Sam Silvester <span dir="ltr"><<a href="mailto:sam.silvester@gmail.com" target="_blank">sam.silvester@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Matt,</div><span><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, May 25, 2017 at 8:05 PM, Matt Selbst <span dir="ltr"><<a href="mailto:matt.j.selbst@gmail.com" target="_blank">matt.j.selbst@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Hoping for some advice. What is everyone doing for terminating point-to-point Ethernet services like AAPT's e-Line in a high availability environment? Cisco environment.</div><div><br></div><div>With PPPoE, high availability was much easier as you could just have multiple LNS's and failover easily when the client would re-auth. With terminating a VLAN handoff on a /30 or /31 it makes HA much harder. If the customer edge router dies, failover seems pretty hard. VRRP doesn't seem to be an option especially with hundreds of customer sub-interfaces.</div><div></div></div></blockquote></div><br></span>Do you mean HA on the customer side or on your side?<br><br>e.g. I assume you mean you want to protect against when your aggregation router dies, as obviously the P2P Ethernet service is kind of a single point of failure in and of itself, as is the CPE...</div></div>
</blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br></div></div>