devel:device_data_model
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
devel:device_data_model [2007/07/03 19:51] morten cluster doc |
devel:device_data_model [2007/07/04 13:08] (current) morten one more diagram |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| 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. | 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. | ||
| + | |||
| Line 20: | Line 21: | ||
| {{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. | {{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 ^ | + | ^ Device ^ NAV Mapping ^ |
| - | | Standalone box | netbox | | + | | Standalone box | netbox & module | |
| ==== Chassis devices ==== | ==== Chassis devices ==== | ||
| Line 42: | Line 43: | ||
| | Commander | netbox & module | | | Commander | netbox & module | | ||
| | Member | module | | | Member | module | | ||
| + | |||
| Line 47: | Line 49: | ||
| ==== Virtual stacks and clusters ==== | ==== 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. 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. | + | {{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. |
| - | Stack members can optionally also take each their IP address, but will mostly function fine without one. | + | {{ 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 ;-) | 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 ;-) | ||
| Line 59: | Line 61: | ||
| | Commander | netbox & module | | | Commander | netbox & module | | ||
| | Member | 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. | ||
devel/device_data_model.1183492268.txt.gz · Last modified: 2007/07/03 19:51 by morten
Page Tools
