NAV's data model should reflect modern reality, with virtual device support

[Morten Brekkevold]

Solutions for virtual stacking (either for true stacking or for redundancy solutions such as Cisco VSS) that are properly modeled in ENTITY-MIB::entPhysicalTable should be modeled by NAV as well.

NAV should have some sort of stack degradation alert - in the case of Cisco VSS, if one of the nodes in a VSS dies, there is a loss of redundancy that should be alerted as a problem.

Also, we suspect that a two-node VSS will change its sysObjectID when degraded (either by shutting down one node or by an actual fault). Such an event would cause NAV to delete much of the data it has on a box.

[Morten Brekkevold (mbrekkevold)]

The suggested proper way of modeling real-life devices is to completely remove the relation between netbox and device, and replace it with a separate table to represent the physical components that an IP address represents. This may in fact be just a shadow image of the ENTITY-MIB::entPhysicalTable (for devices that support this).

A simple switch will have a single chassis entity that would point to the device record (which the netbox record would previously point to). A virtual switch may have multiple chassis entities in this table.

This has **huge** implications for how NAV works in many ways, since the Netbox -> Device relation is quite ingrained in code and other data models.

[Morten Brekkevold (mbrekkevold)]

Based on snmpwalk data provided by a customer, it appears that a VSS does not change its sysObjectID when degraded.