[Tfug] Network partitioning

[Bexley Hall]

Hi Tyler,

On 11/2/2013 7:11 AM, vaca at grazeland.com wrote:
> You want to configure routing and ACLs on a router but think VLANs
> are too confusing.

Sorry, you missed my point.  I'm doing this for someone else.
*I* can configure a switch or a router or a bunch of individual
hosts to do this across the fabric.  E.g., the "switch" I'll be
using (for myself) at home does far more than any commercial
switch (so the complexity that *I* see isn't an issue).

But, once configured, I'm going to hand it over to "them" and
largely walk away.  If *they* want to add another printer,
move a host, need to replace a switch, etc. *I* won't be a part
of the equation any longer.

IME, Average Joes can more easily relate to "boxes with specific
functions":
- this box (switch) ties all the printers (shared resources) together;
- this box ties all the private machines together;
- this box ties the public ones together;
- this box ties the exported ones together;
- this box (router) enforces who can talk to whom.

They can find an IT guy and pay him (salary, per diem, T&M).  Or, I
can try to set things up so that a little common sense allows them to
maintain it themselves (it's not a "data center" so they aren't
pushing any envelopes!).

I.e., an intuitive troubleshooting procedure:
- Can X(i) talk to X(j) for all i & j?  If so, assume switch X is
   operational (along with all cabling for its network).  If not,
   begin procedure to troubleshoot switch X (identify blown port,
   bad cable, etc.).  Rewire as necessary.  Replace if necessary
- Repeat for each switch/group of hosts that are part of current
   "problem"
- Can A(i) talk to C(j)?  If not, swap A & D cables on router and
   repeat.  If still a problem, check cable from switches A and C
   to router.  Else, replace router.
- Repeat for D(i) and C(j)
- Ditto B(j)

[Note I don't intend this *here* to be thorough.  Rather, showing how
you can present a checklist that someone could use to troubleshoot
a "set of boxes" implementation.  Now imagine doing the ssame for a
24 or 48 port switch:  "Can A(i) talk to A(j) -- where i and j are
any of the switch ports in the set {1,2,3,4,5,6,19,21,23}?  Can
B(i) talk to B(j) -- where i and j are any of the switch ports in
the set {7,8,9,10,11,12,24}? ...  else replace switch."]

Likewise, if they need to add another 6 ports, they can either
replace the corresponding switch with one that has 6 more ports
or add another switch in cascade with the existing one.

[Remember, performance isn't an issue here.  Just simple connectivity]

> That's your call, but you're really talking about the same level of
> knowledge for the most part.

In the *configuration*, yes.  But, in the use/maintenance, there's
a big difference.

E.g., if you look at *my* switch, you'd be hard pressed to know what
you can move (drops) and *when* you can move it (mine is continuously
reconfiguring itself).

> You say you want something built for this purpose, well there you go.
> You will need a routing an ACL capable router and a pile of generic
> switches or you will need one switch that can do it all.

I think the router constraints, given my requirements as stated, are
pretty trivial.  I'm not filtering based on protocol, IP addresses,
MAC filtering, etc.  Just "this router port can talk to that port"

> Either way you have to know which switch is on what LAN or what ports
> are on each LAN.

Yes.  I expect to just label each switch:  private, public, shared
and exported.  If you plug another switch into one of these, it
inherits the name of the switch to which it is connected.

I've seen some really *poorly* documented equipment rooms.  And,
those that start out well documented don't seem to have their
documentation *maintained* in that state.  E.g., *here* I can
not only see where a cable physically goes (along with *how*
it gets there) but actual cable lengths (in physical length or
propagation delay!) and what, specifically, is on the other end
of the wire.

> Either solution works fine but some configuration and knowledge will
> be needed in either case.

Yes.  I am just wanting all that to be "up front" instead of "ongoing".

> The bottom line is this: You want something more complicated than a
> normal home LAN so you are going to have to increase the level of
> involvement and knowledge.

This isn't for a home though I think a generic box that had these
rules in it would work well in a SOHO environment.  E.g., "these"
are "our machines".  They need access to the internet and the
shared printers, etc.  These other drops (e.g., from the WiFi AP)
are for use by our guests (laptops, cell phones with WiFi, etc.)
that we don't really trust enough to give access to our machines or
the data those machines may be currently exchanging among themselves.
This connects to our shared resources -- but we don't want them
accessible from the "outside".  And, this connects to the WLAN.

[I've got a small VPN router that I currently use in such a
configuration]

All this is *easy* -- *if* you have someone qualified who will be
available to maintain it.  Trickier part is setting things up so
you can walk away from it without leaving people "dependent".
That's where all the "value added" comes into play!

Thx!
--don