[admin] [summary] RE: YouTube IP Hijacking
Greg VILLAIN
nanog at grrrrreg.net
Sun Mar 2 16:29:07 UTC 2008
On Feb 27, 2008, at 2:09 AM, Adrian Chadd wrote:
>
>> (speaking as someone who has built large ACLs/prefix-lists and has
>> 6MB+ configs that can't be loaded on my routers. without vendor
>> support
>> those that want to do the right thing can't, so the game is lost).
>
> I remember the days of making rtconfig work properly in various
> situations (heck, do people still use that? Does it even do IPv6
> right?)
> and building router configs out of both public and private IRR data.
>
> Perhaps if the entry barrier to building dynamically generated router
> configurations were lowered significantly (to the point of it being
> free, GUI, and multi-platform) then it may be used for new network
> designs by people starting off.
>
> Getting Cisco/Juniper/etc to push -that- as part of their best
> practices
> for network design would be quite helpful.
>
> The problem isn't that the router config is too easy Jared, its that
> there's no nice and easy way of doing it right from scratch that
> matches
> the sort of newbie network operators that exist today. For examples
> of what "new school" netops are like, visit isp-* lists. There's a
> lot of
> clue there, its just "different" and "haven't learnt from the old
> school
> experience" clue, and its amusing/sad to watch people make the same
> mistakes you all did in the 90s. :)
>
> (Where's vijay now when science for generated network configurations
> is needed?)
>
> Make the public tools better. Push the tools as best practice.
>
> ADrian
>
Well there is a slight risk that the more you will improve the
automated tools, the less net engineers will actually understand the
reasons why it is done...
That being said, all the filtering work is a significant part of every
Network Engineer's work, and is not that big of a deal.
Education is the art of repeating, and has always been. I'm not saying
we should systematically point the ones making mistakes and make it
public, what I'm saying is that the reason why mailing lists such as
nanog exist is actually mutual education.
I'm sure the people involved in this incident were (or now are) Nanog
readers, and that they've understood the message.
Still, what should be done is, I assume, centralizing the info in one
single mail, kept for the record:
- list the incident chronology
- analyze what technical mistake lead to that
- list -all- the ways to prevent it
Another mean of education is including the analysis of this incident
(troubleshooting, resolution, implementing means to avoid it) next
Nanog agenda, which I already think is the case :)
Greg VILLAIN
More information about the NANOG
mailing list