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