[hobbit] bbwin 0.10 available

Sebastian spa at syntec.co.uk
Fri Jan 18 14:05:58 CET 2008


Henrik Stoerner <mailto:henrik at hswn.dk> wrote:
> 
> Etienne writes:
>> With the centralized mode, you will see that you get graphs for each
>> of your networks connections. However, for Windows, the names are too
>> long compared to the unix name (eth0, eri0..). So, at this time, I
>> use the mac address of the network card for the graph name. Would you
>> prefer to use the name by making a very short name ? the ip address ?
>> or is the mac address fine ?
> 
> There's really two sides to this issue. One thing is to identify the
> network interface from one poll to the next, so we put the right data
> into the RRD files - for this we can use any identifier that is
> guaranteed to be a)unique and b)permanent. Another thing is to present
> the interface name in some sensible way on the graph.
> 
> I don't really like using the MAC address, because it is difficult to
> relate to anything meaningful - I wouldn't know that my primary
> interface is 00:0E:A6:CE:D6:85, but I do know it's called "eth0".
> I've had the same problem for the SNMP data collection, so I have come
> up with an "rrd.meta" file that can map the ID of the network
> interface into a text that appears on the graph. The code isn't
> pretty, 
> and it is
> static data that must be maintained by hand - if anyone has a better
> suggestion, please speak up. 

The default name of an ethernet network connection on Windows is 'Local Area
Connection' with ' #1', etc. when there is more than one. Is that too long?
If so, it is extremely easy to rename the network connection within Windows
to something shorter e.g. LAN1, LAN2, etc. or whatever one wants. It seems
to me that using this name would be most appropriate, since it would be
guaranteed to correspond to what is visible in the machine 'Network
Connections' GUI, or am I missing something? Obviously, as Henrik implies,
the actual data will need to be associated with the MAC address, so that
renaming the NIC wouldn't screw up historical data.

Kind regards,

Sebastian




More information about the Xymon mailing list