This document discusses natural attributes that describe a subnet (or vlan) and introduces NAV's guidelines for router interface descriptions.
The NAV database models subnets and vlans as they are set up in the production network. A vlan defines a broadcast domain that may consist of zero, one or more IP subnets, one being the most “normal” case. zero subnets means that this is a private network (i.e. a sunray vlan). By using secondary IP addresses (Cisco terminology) it is also possible to have more than one IP subnet running on the same broadcast domain (vlan). Since vlan is the common denominator we will refer to vlans, not subnets, in the following.
It makes sense to describe the vlans that are running in your network. In NAV the following attributes may be registered with a vlan:
|Vlan number||The vlan number that is used for this vlan.|
|Network type||Describes the topology. More on network types below.|
|Organization||Describes the organizational unit using the vlan. Organizational units are registered from editDatabase. A hierarchical structure is supported.|
|Usage||Describes the category of users within the organization. Examples are: students, staff, administration. User categories are also registered from editDatabase.|
|Netident||This is a historical parameter. The idea is that the netident gives a compact description of the vlan. The netident is typically a sum of organization and usage. If there are more than one vlan for an org/usage tuple, the netident introduces a numbering scheme.|
|Further description||Any further comments you may want to use to describe the vlan.|
Please note that the vlan information is not compulsory in NAV. There are a number of advantages of having this information, however, the most vital components of NAV will operate fine without.
There are two subsystems in NAV that can fill in vlan information: the background process ipdevpoll and the tool seedDatabase. ipdevpoll will attempt as far as possible to automatically fill in this information. This is easily achieved if you are using the NAV guidelines for configuring router interface descriptions (again - not a requirement - anyway - more below).
the Edit Vlan component of SeedDatabase lets you complete missing information after ipdevpoll has done its job. To be precise you can manually edit the organization, usage and vlan values.
As mentioned, a network type seeks to give information on the topology of the vlan in question. This is useful for informational purposes, but it is also used directly in the traffic map tool. On the top level the traffic displays the traffic pattern of the core network; thus only the network types core, link and elink are shown. All network types are predefined in NAV. There are a total of nine types:
|lan||yes||A local area networks with end users connected. This is the most common network type. Typically a lan has one connected router. If it has two, it is typically running hsrp for fault-tolarance. A lan is not meant to serve transit traffic.|
|core||yes||A core network, typically meant for transit traffic. A core network has at least three routers connected.|
|link||yes||A core network with two routers connected, i.e. a point to point network between to routers.|
|elink||yes||Also a point to point network between to routers. The remote router is not managed by this network domain. Typically this is the ISP or some other 3d party.|
|loopback||yes||A loopback net of a router.|
|closed||yes||A closed network, i.e. a network without any IP prefixes defined, no connectivity to the rest of the network. An example is a sunray network.|
|static||yes||A statically routed IP prefix. The subnet typically resides behind a device you do not monitor, i.e. a third party firewall.|
|reserved||no||A reserved IP prefix/vlan (not in production yet, but reserved).|
|scope||no||Defines the whole address scope for the network domain. You may define more than one scope. The scope is used by the IP address block map.|
By detected=yes we mean that NAV attempts to classify all live subnets and vlans into one of these categories. This classification can be done by two separate means:
Since the classification is not bullet proof, editDatabase allows you to alter the network type value.
The detected=no network types are manually entered by the NAV administrator using add/edit prefix in editDatabase.
NAV has defined guide lines for configuring router interface descriptions (use the description-command in interface config mode on a cisco router). You may follow these guide lines if you like, ipdevpoll will then take advantage of this and have an easy task filling in vlan attributes. The description setting also serves as a sensible documentation in the configurations of your running routers.
The variables in the syntax are explained below:
|$org||The organizational unit that is using the subnet/vlan in question. Organization are defined in editDatabase.|
|$usage||The user group within the organization. I.e. students, staff, adminstration. User groups (categories) are defined in editDatabase.|
|$n||Supported for historical reasons. The netident is derived from $org,$usage$n. If you want the netident to be unique within your network, and you have cases of i.e. two math-staff-subnets you may use this numbering scheme.|
|$comment||Any further (unstructured) description you may want to add (btw: also a way of distinguishing two math-staff-subnets from one another).|
|$vlan||The vlan number for this broadcast domain. Please note: This information may be derived from the interface name itself, if this is a virtual interface or it may be derived from the connected switch, using CDP. It may also be added (or changed) in editDatabase.|
|$to_router||The router that this router interface is connected to. Please note: This information is easily derived automatically by ipdevpoll and is thus superficial.|
|$to_org||The organizational unit that this external link is peering with.|