[193407] in North American Network Operators' Group
Re: External BGP Controller for L3 Switch BGP routing
daemon@ATHENA.MIT.EDU (David Bass)
Mon Jan 16 08:41:52 2017
X-Original-To: nanog@nanog.org
From: David Bass <davidbass570@gmail.com>
In-Reply-To: <CAJygYd15RV2JLbQGR9dzHTe7=79r1UYL229+FnsKX0MTfn=Lcg@mail.gmail.com>
Date: Mon, 16 Jan 2017 08:41:44 -0500
To: Yucong Sun <sunyucong@gmail.com>
Cc: Tore Anderson <tore@fud.no>, nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Arista has a version of their switches that can handle a full table. =20
I think what the OP is asking about though is something like openflow though=
. Some have played around with using it to modify the switches routing tabl=
e based on flows that exist. The same theory applies in regard to the prese=
ntation link provided (we don't need the full table 99%of the time, so just i=
nsert what you need).=20
Using filters is an "old school" technique that's been around for a long tim=
e, and I don't think that's what he's asking. =20
> On Jan 16, 2017, at 2:00 AM, Yucong Sun <sunyucong@gmail.com> wrote:
>=20
> In my setup, I use an BIRD instance to combine multiple internet full
> tables, i use some filter to generate some override route to send to my L=
3
> switch to do routing. The L3 switch is configured with the default route
> to the main transit provider , if BIRD is down, the route would be
> unoptimized, but everything else remain operable until i fixed that BIRD
> instance.
>=20
> I've asked around about why there isn't a L3 switch capable of handling
> full tables, I really don't understand the difference/logic behind it.
>=20
>> On Sun, Jan 15, 2017 at 10:43 PM Tore Anderson <tore@fud.no> wrote:
>>=20
>> Hi Saku,
>>=20
>>>>=20
>> https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-tabl=
e.html
>>>=20
>>> ---
>>> As described in a prevous post, we=E2=80=99re testing a HPE Altoline 692=
0 in
>>> our lab. The Altoline 6920 is, like other switches based on the
>>> Broadcom Trident II chipset, able to handle up to 720 Gbps of
>>> throughput, packing 48x10GbE + 6x40GbE ports in a compact 1RU chassis.
>>> Its price is in all likelihood a single-digit percentage of the price
>>> of a traditional Internet router with a comparable throughput rating.
>>> ---
>>>=20
>>> This makes it sound like small-FIB router is single-digit percentage
>>> cost of full-FIB.
>>=20
>> Do you know of any traditional =C2=ABInternet scale=C2=BB router that can=
do ~720
>> Gbps of throughput for less than 10x the price of a Trident II box? Or
>> even <100kUSD? (Disregarding any volume discounts.)
>>=20
>>> Also having Trident in Internet facing interface may be suspect,
>>> especially if you need to go from fast interface to slow or busy
>>> interface, due to very minor packet buffers. This obviously won't be
>>> much of a problem in inside-DC traffic.
>>=20
>> Quite the opposite, changing between different interface speeds happens
>> very commonly inside the data centre (and most of the time it's done by
>> shallow-buffered switches using Trident II or similar chips).
>>=20
>> One ubiquitous configuration has the servers and any external uplinks
>> attached with 10GE to leaf switches which in turn connects to a 40GE
>> spine layer with. In this config server<->server and server<->Internet
>> packets will need to change speed twice:
>>=20
>> [server]-10GE-(leafX)-40GE-(spine)-40GE-(leafY)-10GE-[server/internet]
>>=20
>> I suppose you could for example use a couple of MX240s or something as
>> a special-purpose leaf layer for external connectivity.
>> MPC5E-40G10G-IRB or something towards the 40GE spines and any regular
>> 10GE MPC towards the exits. That way you'd only have one
>> shallow-buffered speed conversion remaining. But I'm very sceptical if
>> something like this makes sense after taking the cost/benefit ratio
>> into account.
>>=20
>> Tore
>>=20
