Re: [LANdb] Suggested schema and app changes

> > I've included a .png of my current work on the schema for review.  Stuff
> > that still has to go in are support for subnets, and any extra information
> > each table is to hold.    See the bottom of the message for a couple of
> > small explanations.
>
> All I get is a blank image.. Am I doing something wrong here?

Nevermind.  Netscape doesn't like it apparently, but the Gimp does just fine with
it.  Lemme paste your stuff back in, now that I can see and comment on it. :)

>I've got VLANS as a N-N relationship with port.  If we're looking into snmp
>support, it'll work great for things like trunking where you say that this
>port will carry vlans 1-1000, but only the vlans needed actually get set up.

Ports should have a select box for their type - ie, trunking or non-trunking, and
if trunking, what port of what switch they're connected to.

>There are seperate jack and port entities in this schema.  The device could
>possibly store what it is connected to.

Absolutely.  Commonly requested feature, and certainly a good one to have.

>Port.Connection and Port.IsJack:  The former contains either a Jack.Jack_IDX
>or Port.Port_IDX reference, and IsJack says which table to look in.  I
>didn't think it was clean, but I'm told it's the best way to do it, unless
>we make a Jack_IDX distinguishable from a Port_IDX.  The rationale behind
>these fields is that a Port on a switch can connect to either a jack, or to
>another switch.

Hmm.  I'm not sure if having a unique identifier for EVERY port on the network is
such a great idea.  Then again, if every port on the network is to be stored in
one table, we don't have much choice. :)  This should work just fine, and I'm not
concerned about coming up with a method of distinguishing between switches and
ports_idx's.. Since it was already mentioned that removing mysql's auto_increment
feature would be nice for ports to Oracle, it would seem plausible to simply tack
a 'P' in front of every perl_incremented (*wink*) IDX for ports, and an 'S' for
switches.

>Now that I think about this, how can/should we model a jack-jack connection,
>as in a fibre patch panel?  Do we ignore this altogether, and say that the
>device plugged into one end is plugged into the device on the other end?
>For simplicity's sake, I'd venture a "yes".

I'm not sure ignoring it would hold up for long (sure, for now, don't worry about
it though).  Keeping track of what fiber is connecting to what fiber elsewhere is
a must; example: You've got three fibers in a wall between one closet and another,
the first closet feeding the second.  At some point, one fiber in the wall pukes,
and you have to switch to another.  Marking one bad with a permanent marker is ok,
but how do you tell which fiber is bad and which are good from the office.  This
very situation came up a few weeks ago.  (Funny: Telco (does all the fiber
installs) insisted that the bad fiber was good, because "light goes through it."
Apparently, they aren't familiar with the concept of dropping packets. :))

>How should subnets fit in?  Can a subnet span more than one VLAN?  (no?)
>Can a VLAN contain multiple subnets (yes?).  To complicate things, you can
>have a subnet without a vlan, and vice versa.

No, no subnet can span more than one Vlan, that I know of (imagine trying to route
to two identical subnets that are actually on two separate vlans.. eck?).  And
yes, Vlans can contain multiple subnets, which are all routed as basically one big
subnet.  Someone help me out here though: if you've got 255 subnets in your class
B (er, C?), and you can have up to 4,000 or so Vlans (exact #?), how do you do it
without repeating subnets?  Anyway, since subnets are essentially irrelevant most
of the time, since the only routing issue is what vlan they're on, I don't thing
too much has to be changed here.  It's nice to have something that keeps track of
data in a nice fashion, but really, only the Vlan(s) needs to come into play when
you're talking about a particular port:

Q: What subnet is that machine on?  A: Duh, what's it's IP?
Q: What Vlan is that machine on?  A: Lemme look up its port...
Q: What Vlan is sub 68 on?  A: Lemme look up that vlan and get a list of
subnets...
Q: What Vlans are on this port?  A: Well, let's see.. Ah, yep, it's trunking, and
ah-hah, vlans 1-100 are on it.
Q:  ...?

John






-------------------------------------
LANdb - Network Management through SQL
To unsubscribe, send email to landb-request@avenir.dhs.org
	and put 'unsubscribe' in the subject line
Administrative contact: weez@avenir.dhs.org
-------------------------------------