Hi Nicholas, On 03/02/11 3:42 PM, Ritter, Nicholas wrote: > Relative to the discussion about adding ifAlias functionality, does it > make sense to create a separate table in the PF database for switch > metadata? This would allow for easier additions to PF for additional > OIDs to be added. It also makes sense to me that a config file directive > should be added to tell PF which SNMP OID to display for the port data.
New network_devices (switch) table sounds good to me. Static information about the network_devices (switch) with an aim to replace current conf/switches.conf. As for your which SNMP OID to display, I would prefer making it all available for a consumer network_devices::view() but the ui would display the one as configured. Right now it's done in php but there will be a mean to do that in conf/ui.conf (see #1083 and #1099). A user-provided name (identifier) field could be added to the table. > > At first I figured the table would contain the ifIndex, per-switch key > and the ifAlias so that the ifIndex and switch information from other > functions in the product could be used to lookup the ifAlias Internally we will always use ifIndex since it's the robust, integer-based representation of the actual hardware. We do some basic math for stacked switches based on them and we also need to translate them from 802.1X to physical ports when doing RADIUS Auth. > > Would it make sense to create a switch entity table the stores switches > (and the rest of the data in switches.conf) as rows in a DB table, each > with a unique key that could then be used to reference a second table of > metadata such as ifAlias, ifLocation, etc. A separate perl script could > then be created to maintain the data (as mentioned on the users > listserv.) With such granular setup of data, the perl script could poll > different switches at different intervals even. s/perl script/perl daemon/g - yes that sounds fine to me for sysInfo, sysLocation and sysDescr but not for ifDesc, ifAlias ... then again, you might convince me. However, we don't want to become an NMS. There is already great competition in the open source area there. Throwing an idea here: can you change ifAlias on is it bound to the interface? If it's a value that doesn't change per model (ex: ifIndex 10001 will always be fastEthernet 0/1 on a Cisco 2950) then we could create lookup tables. But this won't cover ifDesc's case. > > Out of curiosity, why was the whole switches.conf file stuck in the > database versus individual rows for each switch? Regardless of this, is > the setup I mention seem like the a feasible approach? If so, I can > start some of the design and coding. This could open some interesting > functionalities on a management level for PF. You are referring to the configfiles table. This was meant as a quick way to push and pull local flat files config from one server to another in an active-passive setup. We are thinking about a new active-passive technique that could allow us to remove this code. Thanks for your ideas! I can't wait to see the code! :) -- Olivier Bilodeau obilod...@inverse.ca :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Packetfence-devel mailing list Packetfence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
