[geeks] Rant: Network "Industry Leaders" That Don't.

[Jonathan C. Patschke]

How long has the use of VLSM/CIDR in network design been considered Good
Thing?  Seven or so years?  I know the CIDR RFC was ratified almost nine
years ago, but people were using classful allocation in a widespread
manner long after that.  Anyway, I like it, I use it, and living without
it on the modern Internet sucks.

Oh, and this "NAT" thing I keep hearing about.  That's a good thing, too.

I'm sure the answer here is obvious, but I fail to see why Lucent is
unable to implement either of these technologies in a sensible manner--in
kit that isn't even three years old.

<background>

A client of mine has a really, really, really horrible network design that
they've asked me to "fix".  Just imagine the worst IP allocation you've
ever seen, spread it across five locations, toss in two NAT boxes, and
toss in the fact that nowhere do cables terminate to jacks in three of the
locations.

That's right.  One cable per computer: runs from the hub, through the wall
(about 100 feet) to the computer's NIC.  Oh, and nothing's labeled.  -And-
everything plugs into stackable 8- or 16-port hubs.

It gets better.  Said customer is connecting to the Internet via two
wireless connections.  Said connections aren't at the same location, and
they're not using the same addressing scheme.  Never mind that the
connections are with the same utterly fscking clueless ISP[1].

Yes, it's a government network.  No, they actually -paid- someone outside
of the organization to fsck this up this badly.

</background>

Both connections to the 'net use Lucent Orinoco wireless kit (the big
"corporate" kit, not the identical "consumer-grade" kit) which -doesn't-
do VLSM/CIDR (even though it needs to because of the way things have been
arse-fscked to eternity).

Also, if your entire network is 192.168.1.0/22, but your Orinoco POS is on
192.168.1.0/24, it refuses to NAT 192.168.2.0/23 and 192.168.0.0/24.  If
you tell it that you -really- want the entire /22 NATed, it won't NAT
-anything-.  It -drops- all the packets because you obviously didn't want
it to do what you told it to.  This sort-of makes sense, as that working
would imply VLSM -not- making its little brain explode.

There's one way to fix this, and I really hate-hate-hate doing this, but I
need to do a selective NAT.  Meaning, NAT everything from 192.168.2.0/23
to anywhere -but- 192.168.1.0/24 and a.b.c.d/24 (a public network address
block[2]).  The only way I can see to do this is by entering $buttload of
rules into /etc/nat.conf.  Unless there's a way of inserting a logical
(not bitwise) "or" into a NAT negation rule, like:

nat on fxp0 from 192.168.2.0/23 to !(192.168.0.0/16 OR a.b.c.d/24) -> fxp0

But that doesn't seem to be supported in nat.conf, or in the ioctl() calls
to /dev/pf on OpenBSD.  This must be one of the extremely-rare things that
Linux can do (with the tradeoff of more expensive NAT) that OpenBSD can't.

Obvious question: why not just NAT everything?

Did I mention that the network design sucks?

Site 1: Has a network connection to Site 2 and 'net.  Also has Very
        Important Application Server.
Site 2: Nas 'net connection, and connections to sites 2 and 3.  No one
        uses VIAS.
Site 3: -Everyone- uses VIAS.  Shares subnet with 2.  Connects to 4 & 5.
        OpenBSD router is housed here.
Site 4: Doesn't share network with 2 or 3.  Everyone uses VIAS.  VIAS
        prints via lpr to printers at this site.
Site 5: Clone of site 4 in another city.

Splitting the subnet that 2 and 3 share breaks 2, 3, 4, & 5's 'net access
because Lucent sucks.  NATing 4 & 5 unconditionally breaks printing from
VIAS.  Extending the subnet shared by 2 & 3 to 4 & 5 won't work because
that would break VAIS, and $softwareVendor would take eons to fix it.
Moving VIAS to 3 isn't possible "for security reasons".

Moving the physical connections won't work without lots of government
intervention, since the buildings are historical, and we have to get
clearance (which will take great amounts of time) to drag the two more
fibre strands[3] between 2 & 3 necessary to make this halfway sane.  I've
put that in as my recommendation.  Based on how they actually -use- their
network, those two strands will -really- improve performance.

This really is one of those situations where doing the right thing
requires an act of something not altogether unlike congress.

I guess I'd better start typing about 100 NAT rules.  Hopefully the NAT
box won't need more RAM to keep from falling over.

*grumble*

--Jonathan
[1] Hint: The one I left has more remaining clue than this particular
    bunch of morons.
[2] One Internet connection comes with a /24.  One comes with a /32.  No,
    $ISP didn't/doesn't have the option of splitting the block into two
    /25s because $ISP also doesn't know what CIDR is.  Never mind that
    there are only 64 or so computers -total- across the entire five-site
    network.  Yes, this means that a portion of the network is double-
    NATed, and that really pisses me off.
[3] Question: Can you multiplex 100baseFX over fibre so that you can run
    three 33MHz Ethernet connections over a single strand?