|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical [[email protected]: FW: Web Based tool for tracking circuits]
----- Forwarded message from "Roland H. Alden" <[email protected]> ----- Date: Mon, 8 Mar 2004 10:04:13 -0800 From: "Roland H. Alden" <[email protected]> To: Marius Strom <[email protected]> Subject: FW: Web Based tool for tracking circuits Return-Path: [email protected] I guess I'm not allowed to post but here is something I sent for your info. -----Original Message----- From: Roland H. Alden Sent: Monday, March 08, 2004 8:37 AM To: [email protected] Subject: RE: Web Based tool for tracking circuits > If there is, let me know. I started to work on one a couple > of years ago, I could dust off the project. Same here. I haven't got time to dust off my project but I would gladly contribute what I have to someone else; basically a complex SQL schema with some queries, constraints and triggers done and/or partially baked. My model was as follows: A location hierarchy tunable to whatever resolution was of interest; i.e., City:Facility:Floor:Rack etc. A very complex model for pieces of equipment; i.e. chassis, blades within chassis, physical ports on blades. Ports themselves are modeled with data about their connectors (i.e., RJ45 male/female, DB9 male/female, etc.). A model of special "ports" which are status indicators like LEDs, what their exact equipment labeling is, and what colors and what not they might normally be. I.e., information of value when walking some remote hands through a troubleshooting procedure. A model for port-specific configuration so that the database can "know" that port x13 on such an such an ethernet switch is connected to VLAN 3, etc. A model for what ports should be physically connected to what ports. A necessary list of cables can then be generated automatically; connector specs and unique cable ID's are generated. A database of common connectors and their "opposite sex" is part of the model. The system does not take advantage of any understanding of how far apart ports are to suggest a cable length, but once a cable table is generated that can be added by hand so that the information is captured. A "fanout" cable model accomodates single cables that connect more than two ports. A power model that records how much heat is generated by each device and how much power of what flavor it consumes. A circuit model similar to the cable model (port:circuit:port) but accomodates "tunnels" such as a ds1 inside a ds3, or a VPN tunnel. A "noc contact" record can be associated with a particular circuit and the contractual details of a circuit (such as SLA) can also be recorded. A unique circuit ID is generated and a vendor's circuit ID can be recorded as well. Equipment configurations (and history of them) is stored within each item of equipment. However, there is no sophisticated linkage or syntax checking between the equipment model and the configuration and there is no way to automatically push a configuration to its equipment. Documents such as PDF files of equipment manuals or contracts can be attached to various items like equipment records, circuit records, etc. However this does require "blob" support and in my implementation is all MSFT specific code. A somewhat badly implemented fine-grained security model so that various views show only the rows a person was allowed to see and/or edit. My notion was that the system would be used across handoff boundaries but I didn't exactly get that far. FWIW. ----- End forwarded message ----- -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Mike Andrews |--------------------> |