North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: [admin] [summary] RE: YouTube IP Hijacking
- From: Greg VILLAIN
- Date: Sun Mar 02 11:40:30 2008
On Feb 27, 2008, at 2:09 AM, Adrian Chadd wrote:
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...
(speaking as someone who has built large ACLs/prefix-lists and has
6MB+ configs that can't be loaded on my routers. without vendor
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
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
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
the sort of newbie network operators that exist today. For examples
of what "new school" netops are like, visit isp-* lists. There's a
clue there, its just "different" and "haven't learnt from the old
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
Make the public tools better. Push the tools as best practice.
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 :)