[161535] in North American Network Operators' Group
Re: [c-nsp] DNS amplification
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Tue Mar 19 14:25:48 2013
In-Reply-To: <3F828001-B02C-44C8-B753-6703BD43CEA2@puck.nether.net>
From: "Patrick W. Gilmore" <patrick@ianai.net>
Date: Tue, 19 Mar 2013 14:15:37 -0400
To: North American Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Composed on a virtual keyboard, please forgive typos.=20
On Mar 19, 2013, at 13:57, Jared Mauch <jared@puck.nether.net> wrote:
>=20
> On Mar 19, 2013, at 1:50 PM, Christopher Morrow <morrowc.lists@gmail.com> w=
rote:
>=20
>> On Tue, Mar 19, 2013 at 1:45 PM, David Conrad <drc@virtualized.org> wrote=
:
>>> On Mar 19, 2013, at 10:12 AM, Christopher Morrow <morrowc.lists@gmail.co=
m> wrote:
>>>> There's nothing inherent in BGP that would not work with an
>>>> unconstrained growth of the routing table, right? You just need enough
>>>> bandwidth and interrupts to deal with updates.
>>>=20
>>> With enough thrust, pigs fly quite well. Landing can get messy though..=
.
>>=20
>> I was being serious... the current 'bgp unconstrained dies' problem
>> isn't such a problem if you have (today):
>> 4-8 cores
>> 16 gb ram
>> ssd
>> gigabit ethernet
>>=20
>> or as you'd call this, your desktop computer... trying to do this on a
>> 600mhz mips with 512mb ram is, clearly, a problem. put modern
>> hardware to work and it gets simpler. Yes, the above addresses
>> getting/sending 'rib' data, it doesn't address programming a FIB, but
>> rethinking the programming of the fib a bit could, I bet, even get us
>> to a palatable point for a longer while, in a relatively short period
>> of time.
>=20
> Try telling this to a vendor that uses these common components (eg: Junipe=
r)
>=20
> We have had numerous performance issues that have been attributed to softw=
are defects they haven't observed on their 'modern' hardware, but is visible=
in the prior generation or few back of routing engines.
>=20
> There's also the problem of fitting the data in the appropriate SRAM on a l=
inecard which is very expensive on a per-bit basis to purchase and on a per-=
watt basis to operate. This is why some folks have TCAM based platforms, wh=
ich have their own tradeoffs.
Has anyone implemented (properly) FIB compression?
Will LISP get is an order of magnitude gain over proper FIB compression? (Ho=
nest question, don't know enough about LISP to say.)
> We all can't just forward with N*10GE interfaces in a x86_64 platform. Th=
at may work if your scale is small, but when you're quite large the dynamics=
change considerably.
>=20
> Also, a "modern router" might look like this:
>=20
> cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of m=
emory.
> Intel 686 F6M14S4 processor at 2134MHz, Revision 2.174
>=20
> vs
>=20
> Cisco 7206VXR (NPE-G1) processor (revision B) with 983040K/65536K bytes of=
memory.
> Processor board ID 23671962
> SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2, 512KB L2 Cache
>=20
>=20
> Those that are confusing the two need to be sent to reeducation camp :)
And do you have the slightest problem with BGP churn / convergence / filteri=
ng / etc. on the former?
--=20
TTFN,
patrick
