Node

Summary

The Node record type is the most common record accessed by LNAs. Node records include essential information about networked devices like name and hardware address. This is also where LNAs assign IP addresses.

Node Types

NetDB comes with the following Node types: Regular, Template, IPC, Router, Advanced and Virtual. New types can be added to accommodate changes in networking technology. Most LNAs will only need access to the Regular, Template and Virtual Node types. A Node can be more than one type.

Regular

This is the most common type of Node. Regular Nodes are used for most computers, printers and networking equipment. Regular Nodes have one DNS name assigned.

Template

This Node type does not have an IP address but an address space instead. LNAs can use templates to have one or more standard NetDB entries for their networks, say one for each subnet or building. All NetDB users with Node record access can also create Nodes of type Template.

IPC (IP Connectivity Provider)

This Node type reserves a range of addresses to be handed out and is typically used for terminal servers. Most LNAs do not have access to this Node type.

Router

This Node type has the same fields as a Regular Node. However, router Node types have separate access restrictions. Usually, only staff who maintain routers , on campus or in the Medical Center, have access to router records.

Advanced

This Node type allows nodes to have multiple names, names for their interfaces, and names for their interface IP addresses. This is useful for computers with multiple network adapters and those that host multiple websites. Each Node name (but not Interface or IP address names) may have it's own aliases and MXes. Generally, Advanced Node type access is granted by special request.

Virtual

This Node type represents a node that has no physical presence. All NetDB users with Node record access can use this Node type. It is purely informational and can be useful for creating reports from full search.

Changing Node Type

To change the Node type, simply click on the buttons at the top of the Create Node or Modify Node page. The checkmark on the button means that Node type is selected. A Node can be an Advanced IPC Router. But Template Nodes cannot also be Advanced, IPC or Router types.

Verify Button

Due to the nature of web pages, IP addresses cannot be confirmed as soon as they are entered. The "Verify" button tells NetDB to check for the following:

• If Node name is already assigned, give an error
• If alias name is already assigned, give an error
• If the MX name is not a valid DNS name, give an error
• Reserve the Node and alias names so others cannot use them
• If IP addresses already assigned, give an error
• Reserve IP addresses so others cannot use them

Verification is also done when a Node record is saved.

Fields

Required fields are marked with a red asterisk on the Create Node or Modify Node pages.

Node Section

DNS records are specified in the name section. Below is the list of how NetDB terms map to the equivalent DNS record.

NetDB Term	DNS Record Type
Node Name	A or AAAA (authoritative name)
Alias	CNAME (canonical name)
Mail Alias	MX

These three (3) fields must obey the following Internet naming standards:

• Only numbers, letters and hyphens allowed
• No leading or trailing hyphens allowed
• Fully qualified name (including Domain name) cannot exceed 255 characters

For Node name, alias and mail alias, if no Domain name is specified, your default Domain (set in User Profile) is used. For most Users, the default Domain is stanford.edu.

Note that there are two special domains - .SUNet and .NoDomain. Names in the .SUNet domain are only resolved for Stanford hosts. This is useful for hosts on private address spaces (not reachable from the Internet). Names in the .NoDomain domain are never resolved by DNS servers. They are typically used as placeholders.

Name

Name is simply the name of the Node. An Advanced Node can have multiple names. If no Domain name is specified, your default Domain (set in User Profile) is used. For most Users, the default Domain is stanford.edu

Alias

Alias is the alias for the Node and is equivalent to CNAME record in DNS.

MX

MX or Mail Alias allows email to be redirected. If "box1" is entered as a mail alias for Node "box2", that means that mail sent to anyone@box1 will actually be redirected to box2. A name can only be added as an MX if the node corresponding to that name is in the same group as the user. For instance, if a user tries to enter node2 as an MX for node1 (i.e., node1 will receive mail for node2), the user must have group rights to node2.

For example, suppose Node A has a mail alias B. When SMTP (simple mail transport protocol) server C is asked to send mail to somebody@B.stanford.edu. Server C will ask the Stanford DNS servers for the MX for B.stanford.edu. The DNS servers will return the IP address for A.stanford.edu. Server C then will send the mail to A.stanford.edu. In another example, if server C is asked to send mail to somebody@A.stanford.edu, server C will query the DNS servers for the MX for A.stanford.edu. In this case, there is no MX record for A.stanford.edu. Then server C will query the DNS servers for an A record for A.stanford.edu. The DNS servers will return the IP address for A.stanford.edu.

Below is the record for A.stanford.edu:

Node Name             a.stanford.edu
   Receive Mail For     b.stanford.edu  Pref:10

Node Type

Select the desired Node types by clicking on the buttons. Selected Node types will have checkmarks on the button. The page will also be refreshed to add the fields associated with additional Node types. Note that a template Node cannot be combined with other Node types.

State

A measure of a node's network behavior.

Most nodes should be in the Good state. Nodes that are misbehaving or compromised in some way can be put into the Dubious, Tainted, or Vile states depending on the nature and/or degree of the malady. These bad states may limit a node's network access various ways. The following table shows how the network treats nodes in the various states:

Good	No state-related restrictions
Dubious	Node becomes unknown to the DHCP service. The DHCP service will not offer the node any statically assigned or roaming DHCP addresses. The DHCP service will offer addresses that are available to unknown nodes where available. See the DHCP help for more info.
Tainted	No state-related restrictions
Vile	Node completely ignored by the DHCP service. The node will not receive DHCP offers for any addresses, even those available to unknown nodes.
Unknown	Same as Dubious
Exempt	No state-related restrictions
Stale	Same as Dubious

The Unknown state should be used when the true state of a node is unknown. Because nodes in the Unknown state could compromised, they are treated as unknown to the DHCP service, just like nodes the Dubious state.

To switch a node into or out of the Exempt state requires a special privilege, generally granted to LNAs of critical nodes. Those LNAs use the Exempt state for nodes that should never suffer the consequences of being moved into the bad states.

Node entries are marked Stale if they and the nodes they represent meet the conditions outlined in the Stale and Useless Nodes SUNet report. Node entries in the Exempt state are immune from being marked Stale. Nodes that remain stale for 90 days are deleted.

Department

department the computer belongs to. Select the desired department from list. To add a new department or to change the list of departments, submit a ticket to HelpSU.

Location

building where the computer is located. Select the desired location from the list. To add a new building or to change the list of buildings, submit a ticket to HelpSU.

Room

room where the computer is located

Make and Model

type of computer it is. Select the Make and Model from the lists. To add a new model, click on the New button. To add a new Make, submit a ticket to HelpSU.

Operating System

Select an operating system from the dropdown list. If the computer has multiple operating systems, click on Add Another. To create a new operating system, click on New.

Groups

Only NetDB Users in the same Group as this record or with All Group access can modify or delete this Node. User must also have record access to Nodes and the appropriate Node types. A Node can be in multiple Groups.

Administrators

Administrators are individual people or Admin Teams that are responsible for a computer. Being listed as an Administrator or Admin Team does not give rights to modify a NetDB record. This field indicates the custodian for the physical or virtual device associated with the record.

List individuals by using their full names or their SUNet IDs. You can click on Verify to have NetDB check and resolve the names before you try to save the record. If you choose to verify, entries will be checked against the online Stanford directory; if they are not found in the directory or if a name matches multiple people in the directory, an error will occur. If an exact match is found, the person will be returned with a checked box. If multiple matches are found, a list of people and associated departments will be returned unchecked. Check to select the right administrator. The verification process is thus especially useful if you use SUNet IDs since it will show you information about the people connected to the SUNet IDs so you'll know if you entered the right SUNet IDs. Note that the directory lookup looks for matches on SUNet IDs, last name and email address. Note that verification is also done when the Node record is saved.

An Admin Team is a set of people who are responsible for the computer. For example, the Computer Resource Center (CRC) may contract with a department to support their computers. Instead of listing all the people in CRC as administrators, it's simpler to list the CRC Admin Team as an administrator. Admin Teams must be followed by a semicolon when entered as a node administrator (e.g., "CRC;").

If the administrator is not associated with Stanford and does not have a SUNet ID, list Admin Team "OUTSIDE;" as the administrator and add contact information in the Comment field.

Users

This optional field lists the user of this computer. List individuals by using their full name or their SUNet IDs. You can click on Verify to have NetDB check and resolve the names before you try to save the record. If you choose to verify, entries will be checked against the online Stanford directory; if they are not found in the directory or if a name matches multiple people in the directory, an error will occur. If an exact match is found, the person will be returned with a checked box. If multiple matches are found, a list of people and associated departments will be returned unchecked. Check to select the right user. The verification process is thus especially useful if you use SUNet IDs since it will show you information about the people connected to the SUNet IDs so you'll know if you entered the right SUNet IDs. Note that the directory lookup looks for matches on SUNet IDs, last name and email address. Note that verification is also done when the Node record is saved.

Custom Fields

These four (4) custom fields allow NetDB Users to create their own fields for searching and reporting. Some examples: Asset Tag #, Lab Name, or Department Division. Each field has a label and a value; for example "Label: Lab Name" and "Value: Smithfield Lab" would make one custom field.

Custom field views present complex custom field data in a user-friendly fashion.

When a custom field view is selected the custom fields related to that view are rendered in HTML. If those custom fields didn't exist when the view was selected they are created at that time. With a view selected, switching to a different view or no view at all stores the data corresponding to the current view selections in the appropriate custom fields. The Blast It button removes the custom fields (labels and data) associated with the currently selected view.

Custom views provide their own documentation. After a view is selected, check for a link - either in the gray Custom Fields bar or in the custom view itself - to get more information about that particular custom view.

Here's the documentation provided by the currently installed custom views:

• Property Management
• Res Firewall
• SU Firewall
• SUNet Monitoring

Interface Section

The association between IP addresses, hardware addresses, DHCP/BootP and Roaming DHCP is quite flexible in NetDB. Each interface can have the following:

• Zero or one hardware addresses
• Zero or many IP addresses
• DHCP on or off
• Roaming DHCP on or off

Add Another Interface

Interfaces roughly correspond to network cards. If a Node has multiple network cards (for example, docking station at office, PCMCIA card at home), assigning multiple interfaces allows the Node to get different IP addresses based on what hardware address is seen. To add another interface, click on the "Add Another Interface" button in the Interface Information bar (about halfway down the Create Node or Modify Node page).

Hardware Address

This 12-character hexadecimal number can be entered in the common hardware address formats below but will always be shown in the dotted format (1234.5678.9abc). Hardware addresses must be unique throughout NetDB. Hardware addresses are also required in order to enable DHCP/BootP and Roaming DHCP.

No punctuation	123456789abc
Dotted	1234.5678.9abc
Dashed	12-34-56-78-9a-bc
Colon	123456:789abc
Colons	12:34:56:78:9a:bc

Interface Name (Advanced Node)

Interface names would probably be used for computers that host multiple websites or services.

DHCP/BootP

Checking the DHCP/BootP box tells the DHCP servers to respond to DHCP requests from the associated hardware address. This flag cannot be set without a hardware address. This flag is also required to enable Roaming DHCP. For more information about DHCP, see DHCP Help.

Roaming

Checking the Roaming box enables Roaming DHCP. Roaming DHCP is usually used for laptops that move from location to location. To set Roaming, a valid hardware address and the DHCP/BootP flag are also required. For more information, see DHCP Help.

IP Address

IP addresses can be assigned in a number of ways. The address box overrides the address space dropdown list.

• If a Node or template Node is used as a template, NetDB will attempt to assign an IP address in the same address space as the template
• If the User has a default address space (set in User Profile), NetDB will attempt to assign an IP address from that address space
• If the User selects an address space from the select box (shows only those address spaces that User is allowed to assign addresses from) or enter in an address space, NetDB will attempt to assign an IP address from that address space
• If the User specifies a particular IP address, NetDB will use that address if available.

Otherwise, NetDB will look for the next available address in the address space, starting from the specified address.

Valid IP Address format is in dotted octet form: 171.64.60.10.

Valid Address space formats are shown below:

• w.x.y.z/n - existing address space with prefix, e.g. 171.64.60.0/24
• w.x.y/n - existing address space without trailing zeroes, e.g. 171.64.60/24
• w.x.y.z - existing address space without prefix, e.g. 171.64.60.0

For more information, see Address Spaces.

Because of the nature of web pages, IP addresses cannot be confirmed as soon as they are entered. The "Verify address" button tells NetDB to see check if the addresses are already used. Note that verification is also done when the Node record is saved

IP Address Name (Advanced Node)

IP address names would probably be used for computers that host multiple websites or services. To check if the names are already used, click on the "Verify address & name" button.

PTR Pref (Advanced Node)

This controls what the DNS returns for reverse lookups of the IP address. If set to All, then all existing IP address, Interface, and Node names will be returned in no particular order. If set to Closest, then the first existing IP address name, Interface name, or Node name will be returned. Closest is the default and generally recommended since many applications are confused by multiple answers to a reverse lookup.

For example, given this Node entry:

    Node Name: noventa
    Interface 1's Name: cilantro
    IP address 171.64.60.10  Name: www PTRpref: Closest
    Interface 2's Name: arriva
    IP address 171.64.60.11   Name: www.stanford.org PTRpref: All

reverse DNS lookups for the two IP addresses yield:

    % host 171.64.60.10
    171.64.60.10 has name www.stanford.edu

    % host 171.64.60.11
    171.64.60.11 has name noventa.stanford.edu
    171.64.60.11 has name www.stanford.org
    171.64.60.11 has name arriva.stanford.edu

DHCP Options

Because DHCP Options are rare in Nodes, this window is normally hidden. Click the Display button to reveal it. If a Node has DHCP options, this window will already be open. Enter DHCP options one per line, using the syntax <dhcp option> = <value>. For more information about DHCP options, see the DHCP Help.

Interface Comment

This searchable field is for any additional information, like whether the interface is wireless, ethernet, or a dock. Only printable characters are valid for comments. The printable character set consists of the alphabet, any numbers, all punctuation and spaces. For example, the carriage return is a non-printable character.

IPC Section (IPC Node)

IPC addresses are addresses that this Node will pass out. The easiest way to assign a block of IPC addresses is to select an address space (usually the same as the address space of the IPC) and put the number of desired addresses in the Count box. NetDB will try to find a contiguous block of IP addresses to assign. To see these addresses before saving the Node record, click on "Verify address & name" in the IPC section. Note that IPC addresses are automatically assigned names. Verification is also done when a Node record is saved.

IPC Address

List of addresses that an IPC Node will pass out.

IPC Address Name

Automatically assigned to an IPC address, this name is generated as DN<IPC address in hex>

For example, for IPC address 171.64.3.5, the automatic name would be "dnab400305" (hex AB = 171, hex 64 = 40, etc.) This name can be changed, but that is not generally recommended.

Count

Count is the number of requested IPC addresses. If Count is not specified, Count is assumed to be 1.

Record Information

Expiration Date

This is an informational field provided for the convenience of LNAs. Setting node expiration dates allows LNAs to use full search to find expired nodes to delete or update. This can be quite powerful in combination with the full search CSV export format and the NetDB command-line interface. NetDB does not take any action based on the expiration date; it is purely an informational field for LNAs to use as they see fit.

Comment

This searchable field is for any additional information. Only printable characters are valid for comments. The printable character set consists of the alphabet, any numbers, all punctuation and spaces. For example, the carriage return is a non-printable character.

Created By

This field gives the full name and SUNet ID of the NetDB User who created this Node and the date it was created.

Last Modified By

This field gives the full name and SUNet ID of the NetDB User who last modified this Node and the date it was last modified.

Special Configuration Examples (Wireless, Multiple Locations, Etc.)

1. Computer with multiple network cards - Create a node record with one interface per network card. Assign IP addresses and hardware addresses appropriately.

    Name: mylaptop.stanford.edu
    Interface 1: (wireless card)
        Hardware address = 0000.0000.1111   DHCP ROAM
    Interface 2: (office network- wired Ethernet)
        Hardware address = 0000.0000.2222   DHCP
        IP address: 171.64.60.10

2. Computer used in two on-campus locations with one network card - Assign 2 IP addresses to one interface with DHCP. DHCP will hand out IP address based on location.

    Name: mylaptop.stanford.edu
    Interface 1:
        Hardware address = 0000.0000.1111   DHCP
        IP address: 171.64.60.10
        IP address: 171.64.20.123

3. Computer used in office and roaming - Assign one IP addresses to an interface with roaming DHCP. DHCP will give the fixed IP if the machine is on the office net and will give a roaming DHCP address otherwise.

    Name: mylaptop.stanford.edu
    Interface 1:
        Hardware address = 0000.0000.1111   DHCP ROAM
        IP address: 171.64.60.10

4. Laptop only roams on campus (no fixed address) - Create a record with the hardware address, DHCP, roaming and no IP address.

    Name: mylaptop.stanford.edu
    Interface 1:
        Hardware address = 0000.0000.1111   DHCP ROAM

5. Laptop used between dorms/Stanford West and campus - The student should register the machine in the dorms. The LNA then requests access to that record through HelpSU or Residential Computing (appropriate group access will be added to that record). The LNA assigns a campus IP address.

    Name: mylaptop.stanford.edu
    Groups:  Residential Computing, MyDepartment
    Interface 1:
        Hardware address = 0000.0000.1111   DHCP
        IP address: 171.64.60.10 (campus IP address)
        IP address: 128.12.75.2 (dorm IP address)