NAV Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Mapping the physical reality of devices into NAV's data model ======

This page tries to summarize the different physical ways that network devices are internally organized, and how this is mapped into NAV's data model.  If you disover factual errors in the device descriptions used here, please don't hesitate to fix them (Disclaimer: I am not a network engineer!) :)


===== NAV's data model =====

  * A //Netbox// is a device with an IP address and possibly an SNMP community.
  * A //module// is a device that is somehow related to a netbox.  A module is either a physical expansion card or some kind of other IP-less device managed by the Netbox device, such as in the case of stacked switches.
  * A module can have a set of //switch ports// (swport) and/or //router ports// (gwport).


===== Let's get physical =====

Different vendors use different terminology to describe their own implementations of these concepts.  We will use our own terminology here, but attempt to translate into the names used by the vendors best known to us.



==== Standalone devices ====

{{devel:standalone_device.png |Diagram of standalone device}} Standalone devices are the simplest kind.  A standalone device consists of a single physical box with few or no options for expansion.  This is your typical simple N-port switch.  All vendors provide something like this.

^ Device         ^ NAV Mapping     ^
| Standalone box | netbox & module |

==== Chassis devices ====

{{devel:chassis_device.png |Diagram of a chassis device}}A chassis devices doesn't provide much functionality in itself, it is mostly just a container with slots to fill with expansion cards that make up the important functions of the box.

Most large Cisco routers or switches with router functionality are of this kind.

^ Device         ^ NAV Mapping ^
| Chassis        | netbox      |
| Expansion card | module       |

==== Physical stacks ====

{{devel:stacked_device.png |Diagram of stacked devices}}Some vendors provide a way to combine multiple standalone devices into a single functional unit, through the use of a special stacking cable.  The stacking cable connects to a stacking port on each device, and functions as a backplane for communication between the devices.  Usually, one of the devices in the stack is assigned the role of //commander//; this device takes an IP address, manages the stack as a whole and presents the stack as single device to SNMP management stations.

Both 3Com and Cisco are known to have products that are capable of this kind of stacking.

^ Device         ^ NAV Mapping     ^
| Commander      | netbox & module |
| Member         | module          |




==== Virtual stacks and clusters ====

{{devel:virtual_stack.png |Diagram of a virtual stack}}Some vendors provide a way to virtually stack multiple standalone devices by connecting them by their regular ethernet ports.  Typically, one device in such a stack is assigned the role of //commander//, while the other devices take the role of //members//.  The commander will have an IP address and provide management facilities for the stack as a whole.  **BUT**, the commander will not present the stack as a single physical unit to the management station.

{{ devel:virtual_stack2.png|Another example of how to connect virtually stacked devices}} Each device in this stack operates independently of one another; the commander will allow the management station to communicate with each stack member by addressing them with a modified SNMP community string - in essence relaying SNMP communication between the members and the management station.  Stack members can optionally also take each their IP address, but will mostly function fine without one.

HP has many products that stack in this way, they call it HP Switch Stacks.  Some Cisco devices also support this type of stacking, but they call it //clustering//.  According to Cisco documentation, physical 3750 switch stacks can also participate in switch clusters, making the chaos complete ;-)

NAV does not currently support Cisco Clustering (NAV 3.2). If a cluster is added to NAV, NAV will only see the commander device of the cluster.  For more information about Cisco Clustering, please go to [[http://www.cisco.com/univercd/cc/td/doc/product/lan/cat3750/12119ea1/3750scg/swclus.htm|this page on Cisco's web site]].


^ Device         ^ NAV Mapping     ^
| Commander      | netbox & module |
| Member         | module          |


===== Future changes =====

The way in which NAV supports HP switch stacks today is a bit contrived (read: hackish), and is, IMNSHO, implemented at the wrong code layer.
There are some ideas to change the way NAV models virtual stacks, which would also make it easier to implement support for Cisco Clustering.  These ideas concern themselves with modelling the members of such stacks as automatically generated netboxes with a dependency on the commander netbox.  This will enable NAV to view these members for what they are: Operationally independent devices, who happen to share an IP address with another device, but with a different SNMP community. 

Administratively, one still wishes to view a virtual stack as a whole, which means the bulk of changes would be in the web user interface to make sure these stacks are presented mostly as before.

These ideas aren't fully fleshed out yet, but more work will be put into that around late August 2007.