On Thursday 21 August 2008 01:10, Peter N. M. Hansteen wrote:
> Rule 1) don't hire fools (suits tend to underestimate the importance of
> that) Rule 2) document as you go or soon enough after the fact that you
> still understand what you did and why (suits tend to pay lipservice to this
> but rarely leave you time to actually do it)
>
> a corollary to rule 2) is that with from-the-trenches documentation,
> you will be a lot better prepared to design the network that's based
> on an analysis of observed needs and an actual specification, somewhere
> down the road.
Many times, I've walked in on a network I've never seen before and thought
"What fool did this mess?". But after a while, I find that I'm dealing with
some neat hacks that solved a particular problem, or ugly kludges that
nevertheless worked at the time. But given enough of these, they're either
going to start crashing into each other, or make some network addition or
change start breaking things. I try to write comments with this in mind, I
don't want to be someone else's fool.
Sometimes, of course, my initial impression is correct. But there's little I
can do to enforce rule #1, especially ex post facto.
In regards to the present discussion, my initial impression was that using the
pf rules route-to and reply-to would provide a simple, in one place solution
(if you've ever tried to do this using Linux, iptables, iproute2 and one of
the SWANs you know why this is desirable), but I couldn't get it working. I
was hoping that someone could just point out something I was missing, but
that appears not to be the case.
Thanks to everyone for the assistance.
--
Jeff Simmons [EMAIL PROTECTED]
Simmons Consulting - Network Engineering, Administration, Security
"You guys, I don't hear any noise. Are you sure you're doing it right?"
-- My Life With The Thrill Kill Kult
