Henry Kilmer writes:
>(b) Possible evidence for Metzger's cowboyism theory? Were these BGP
>configs tested before they were implemented?Yes. And it wasn't the configs that were wrong. It was a BGP related
Cisco bug.
Did you test the configs in a lab first? Thats the best way to find
these sorts of things -- in test...
Did you have a backout plan in place to rapidly fall back in case of
failure?
Perry
No matter how rigorous the test in a lab is, there are bugs and failure modes
that cannot be discovered until real traffic passes through it.
I assume Sprint got bitten by one of these...
-dorian
Henry Kilmer writes:
> >(b) Possible evidence for Metzger's cowboyism theory? Were these BGP
> >configs tested before they were implemented?
>
> Yes. And it wasn't the configs that were wrong. It was a BGP related
> Cisco bug.Did you test the configs in a lab first? Thats the best way to find
these sorts of things -- in test...
Network engineers don't do lab stuff. That's for researchers.
Ride 'em cowboy!
Did you have a backout plan in place to rapidly fall back in case of
failure?
Hell no, just put them spurs to the hoss and ride... yeeeehaaaa!
Seems to me that it might be useful to have some sort of document that
explains just how cowboys operate their networks. What I have in mind is
something like Emily Postnews. How about it Perry, are you up to the task?
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
Perry E. Metzger writes:
Henry Kilmer writes:
>(b) Possible evidence for Metzger's cowboyism theory? Were these BGP
>configs tested before they were implemented?Yes. And it wasn't the configs that were wrong. It was a BGP related
Cisco bug.Did you test the configs in a lab first? Thats the best way to find
these sorts of things -- in test...
If you read my message, I said "yes" to testing the configs prior to
going live with them. Unfortunately our testing does not turn up all
of the problems we encounter on our backbone since it is very
difficult to generate an accurate environment to simulate our
backbone.
Did you have a backout plan in place to rapidly fall back in case of
failure?
Of course.
-Hank
Michael Dillon writes:
Network engineers don't do lab stuff. That's for researchers.
Ride 'em cowboy!
Seems like the contempt doesn't always flow just towards the small
ISPs, eh, Mr. Dillon?
Did you have a backout plan in place to rapidly fall back in case of
failure?Hell no, just put them spurs to the hoss and ride... yeeeehaaaa!
Seems to me that it might be useful to have some sort of document that
explains just how cowboys operate their networks. What I have in mind is
something like Emily Postnews. How about it Perry, are you up to the task?
Is this the way the encourage better cooperations among the community
of the Internet, including users, small ISPs, and large ISPs?
Not at all. It's the way to educate network engineers about how the world
expects them to use their newly gained technical skills. The problem
isn't whether Sean Doran or Curtis Villamizer, et al. know how to restrain
themselves, because they do know having had years of experience. IMHO
the problem is to get up-and-coming network engineers (most of them even
in the larger companies) to understand a new order of business. This is
not unlike the difference between doing data processing at a small company
(seat of the pants) and a LARGE company (plan, develop, deskcheck, alpha
test, wait until Sunday to run live tests, implement when everybody on the
team checks off on the works, etc...).
Lots of people are picking up the core technical skills like dancing with
BGP, but there is more to it than that. Most of these people have their
hearts in the right place but they just don't understand the problem
because it probably hasn't been explained to them in a way that they can
understand. That's where "art" comes in and things like Dilbert, Emily
Postnews and the suggested "cowboy" document can be useful.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com