[192088] in North American Network Operators' Group
Re: Two BGP peering sessions on single Comcast Fiber Connection?
daemon@ATHENA.MIT.EDU (Jason Canady)
Mon Oct 17 09:30:03 2016
X-Original-To: nanog@nanog.org
From: Jason Canady <jason@unlimitednet.us>
In-Reply-To: <213679615.3830.1476707434794.JavaMail.mhammett@ThunderFuck>
Date: Mon, 17 Oct 2016 09:29:58 -0400
To: Mike Hammett <nanog@ics-il.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
I completely concur. We spread our uplinks across separate boxes and we hav=
e /29 allocations. Get the best of all worlds. But if I only had one provid=
er, I'd want to have multiple BGP sessions for this reason. =20
> On Oct 17, 2016, at 08:30, Mike Hammett <nanog@ics-il.net> wrote:
>=20
> It really seems like it's a grave oversight to *NOT* support multiple BGP s=
essions. I drop to two routers for that same reason, I can do maintenance on=
one, while the other carries traffic.=20
>=20
>=20
>=20
>=20
> -----=20
> Mike Hammett=20
> Intelligent Computing Solutions=20
> http://www.ics-il.com=20
>=20
> Midwest-IX=20
> http://www.midwest-ix.com=20
>=20
> ----- Original Message -----
>=20
> From: "Mike Poublon" <mpoublon@secantnet.net>=20
> To: "rar" <rar@syssrc.com>, nanog@nanog.org=20
> Sent: Thursday, October 13, 2016 2:04:29 PM=20
> Subject: Re: Two BGP peering sessions on single Comcast Fiber Connection?=20=
>=20
> I started a thread around the same topic back on 10/16 of 2014. A=20
> Comcast engineer (who ultimately spoke to the national product manager)=20=
> came back after discussing and said the same thing "We don't support=20
> that". I got a slightly longer explanation of:=20
>=20
> --------------------------------------------=20
>=20
> In a nutshell, when we design a product we do it to accommodate the most=20=
> typical customer cases.=20
> Given that the design includes a single fiber path and thus the fiber=20
> path and device that terminates on either end each are a single point of=20=
> failure, adding extra BGP sessions doesn=E2=80=99t seem to add value in th=
e=20
> typical failure scenarios. In order to achieve the simplest and most=20
> scalable solution to address the market, we rely on narrowing the=20
> possible combinations of parameters.=20
>=20
> --------------------------------------------=20
>=20
> I explained to them that their interpretation prevents me from being=20
> able to do concurrent maintenance on my side (single router=20
> reboot/upgrade, etc). Never got anywhere with it though.=20
>=20
> I'm still interested in having this set up, but have given up on it ever=20=
> really coming to reality. Luckily ALL of my other providers were more=20
> than happy to set up an extra session.=20
>=20
> If anyone from Comcast is listening, there is customer demand for this.=20=
> It's not about making it better for Comcast, it's about allowing=20
> customers to have more flexibility.=20
>=20
> Mike Poublon=20
>=20
> /Senior Datacenter Network Engineer/=20
>=20
> *Secant Technologies*=20
>=20
> 6395 Technology Ave. Suite A=20
>=20
> Kalamazoo, MI 49009=20
>=20
>> On 10/13/2016 1:48 PM, rar wrote:=20
>> After a many month wait, we were ready to turn up our BGP peering session=
s on a new Comcast fiber connection.=20
>>=20
>> With our other providers (Level 3 and Verizon) we have edge routers that d=
irectly connect between the provider's on premise connection and our primary=
and a backup core routers. Each core router has a multihop BGP session with=
the provider's BGP router. The goal is to keep the single BGP router from b=
eing a single point of failure.=20
>>=20
>> Comcast said they could not support two separate BGP peering sessions on t=
he same circuit. Does anyone have any counter examples? We used to have this=
setup with Comcast 5+ years ago, but now they say they can't support it.=20=
>>=20
>>=20
>> Bob Roswell=20
>> broswell@syssrc.com<mailto:broswell@syssrc.com>=20
>> 410-771-5544 ext 4336=20
>>=20
>> Computer Museum Highlights<http://museum.syssrc.com/>
>=20
>=20
