Recently in nanog quotes Category
While working at a distinguished university with a religious affiliation, I
learned, as did one of the priest-biologists, not to refer to a piece of
instrumentation as possessed. While one of the priest-theologians meant
well, we learned what happened when holy water is sprinkled into the high
voltage supply of a gas chromatograph. Beckman Instruments was so amused
they didn't charge for equipment abuse not under maintenance contract.
http://article.gmane.org/gmane.org.operators.nanog/49438
This entry was originally posted in my livejournal
learned, as did one of the priest-biologists, not to refer to a piece of
instrumentation as possessed. While one of the priest-theologians meant
well, we learned what happened when holy water is sprinkled into the high
voltage supply of a gas chromatograph. Beckman Instruments was so amused
they didn't charge for equipment abuse not under maintenance contract.
http://article.gmane.org/gmane.org.oper
This entry was originally posted in my livejournal
Many years ago I worked for a small Mom-and-Pop type ISP in New York
state (I was the only network / technical person there) -- it was a
very free wheeling place and I built the network by doing whatever
made sense at the time.
One of my "favorite" customers (Joe somebody) was somehow related to
the owner of the ISP and was a gamer. This was back in the day when
the gaming magazines would give you useful tips like "Type 'tracert
$gameserver' and make sure that there are less than N hops". Joe
would call up tech support, me, the owner, etc and complain that
there was N+3 hops and most of them were in our network. I spent much
time explaining things about packet-loss, latency, etc but couldn't
shake his belief that hop count was the only metric that mattered.
Finally, one night he called me at home well after midnight (no, I
didn't give him my home phone number, he looked me up in the
phonebook!) to complain that his gaming was suffering because it was
"too many hops to get out of your network". I finally snapped and
built a static GRE tunnel from the RAS box that he connected to all
over the network -- it was a thing of beauty, it went through almost
every device that we owned and took the most convoluted path I could
come up with. "Yay!", I figured, "now I can demonstrate that latency
is more important than hop count" and I went to bed.
The next morning I get a call from him. He is ecstatic and wildly
impressed by how well the network is working for him now and how
great his gaming performance is. "Oh well", I think, "at least he is
happy and will leave me alone now". I don't document the purpose of
this GRE anywhere and after some time forget about it.
A few months later I am doing some routine cleanup work and stumble
across a weird looking tunnel -- its bizarre, it goes all over the
place and is all kinds of crufty -- there are static routes and
policy routing and bizarre things being done on the RADIUS server to
make sure some user always gets a certain IP... I look in my pile of
notes and old configs and then decide to just yank it out.
That night I get an enraged call (at home again) from Joe *screaming*
that the network is all broken again because it is now way too many
hops to get out of the network and that people keep shooting him...
What I learnt from this:
1: Make sure you document everything (and no, the network isn't
documentation)
2: Gamers are weird.
3: Making changes to your network in anger provides short term
pleasure but long term pain.
http://article.gmane.org/gmane.org.operators.nanog/48735
This entry was originally posted in my livejournal
state (I was the only network / technical person there) -- it was a
very free wheeling place and I built the network by doing whatever
made sense at the time.
One of my "favorite" customers (Joe somebody) was somehow related to
the owner of the ISP and was a gamer. This was back in the day when
the gaming magazines would give you useful tips like "Type 'tracert
$gameserver' and make sure that there are less than N hops". Joe
would call up tech support, me, the owner, etc and complain that
there was N+3 hops and most of them were in our network. I spent much
time explaining things about packet-loss, latency, etc but couldn't
shake his belief that hop count was the only metric that mattered.
Finally, one night he called me at home well after midnight (no, I
didn't give him my home phone number, he looked me up in the
phonebook!) to complain that his gaming was suffering because it was
"too many hops to get out of your network". I finally snapped and
built a static GRE tunnel from the RAS box that he connected to all
over the network -- it was a thing of beauty, it went through almost
every device that we owned and took the most convoluted path I could
come up with. "Yay!", I figured, "now I can demonstrate that latency
is more important than hop count" and I went to bed.
The next morning I get a call from him. He is ecstatic and wildly
impressed by how well the network is working for him now and how
great his gaming performance is. "Oh well", I think, "at least he is
happy and will leave me alone now". I don't document the purpose of
this GRE anywhere and after some time forget about it.
A few months later I am doing some routine cleanup work and stumble
across a weird looking tunnel -- its bizarre, it goes all over the
place and is all kinds of crufty -- there are static routes and
policy routing and bizarre things being done on the RADIUS server to
make sure some user always gets a certain IP... I look in my pile of
notes and old configs and then decide to just yank it out.
That night I get an enraged call (at home again) from Joe *screaming*
that the network is all broken again because it is now way too many
hops to get out of the network and that people keep shooting him...
What I learnt from this:
1: Make sure you document everything (and no, the network isn't
documentation)
2: Gamers are weird.
3: Making changes to your network in anger provides short term
pleasure but long term pain.
http://article.gmane.org/gmane.org.oper
This entry was originally posted in my livejournal
http://www.merit.edu/mail.archives/nanog/msg05264.html
No transition plan
Declared victory before the hard part even started
No real long term plan
No realistic estimation of costs
No real support for the folk on the front lines
Victory will be next month
Describes:
a - The war in Iraq
b - DNSsec
c - IPv6
d - All of the above
No transition plan
Declared victory before the hard part even started
No real long term plan
No realistic estimation of costs
No real support for the folk on the front lines
Victory will be next month
Describes:
a - The war in Iraq
b - DNSsec
c - IPv6
d - All of the above
> disagreed. (because DNSSEC is coming.)
The operational question is, of course, whether we need to worry about allocating
resources for deploying DNSSEC before or after IPv6. ;)
This entry was originally posted in my livejournal
The operational question is, of course, whether we need to worry about allocating
resources for deploying DNSSEC before or after IPv6. ;)
This entry was originally posted in my livejournal
Back around 1981 I worked in a shop which had just taken delivery on an IBM 8100 system, a "mini-computer" about the size of a washing machine. We had an operator who weighed about 350lb (160Kg), and whenever this guy got within 10' (3m) of the thing it would crash. When the IBM FE came in, a circuit board was found to have a micro-fracture in it. Apparently whenever said operator got close enough, the floor would warp a bit, shifting the box enough to open a gap in the board.
This entry was originally posted in my livejournal
>>configuration known as "collapsed backbone". in this instance, both
>>pairs of fiber ride in the same conduit for some portion of the
>>distance
>
>
>... or even as two wavelengths on the same pair of fibre.
>
>It's a sick, sick, twisted world.
Come on, that is what we call lambda-diversity. In case your fiber fails
to carry, say 1550nm in the middle of the night, you are protected with
your 1590nm lambda.
I don't believe how many people engineer for physical diversity and not
lambda diversity -- and then its too late.
This entry was originally posted in my livejournal
>>pairs of fiber ride in the same conduit for some portion of the
>>distance
>
>
>... or even as two wavelengths on the same pair of fibre.
>
>It's a sick, sick, twisted world.
Come on, that is what we call lambda-diversity. In case your fiber fails
to carry, say 1550nm in the middle of the night, you are protected with
your 1590nm lambda.
I don't believe how many people engineer for physical diversity and not
lambda diversity -- and then its too late.
This entry was originally posted in my livejournal
