This chapter explains how to establish IP connectivity between your computer and other computers on your network. Connectivity depends upon the network interfaces in your system.
Establishing IP connectivity ensures that users can perform the tasks described in the MultiNet User's Guide, including:
· Obtaining information about remote systems and users with FINGER and WHOIS
· Accessing files on other computers with the FTP, RCP, TFTP, SCP, and SFTP commands
· Logging into other computers with the RLOGIN, TELNET, and SSH commands
· Using remote printers
|
Note: Establishing IP connectivity only ensures you can reach other systems if you know their IP addresses. It does not ensure you can reach other systems by name. For example, there is no guarantee you can send mail to users on remote systems without first configuring host tables or the Domain Name System (DNS) (see Chapter 10).
|
At startup, MultiNet obtains global configuration data (such as the default route) and device-specific network interface configuration data (such as the IP address) from the following files:
· The MULTINET:NETWORK_DEVICES.CONFIGURATION network database file describes the current network configuration, including a list of the device interfaces you have specified. This file is used to determine which devices are present when the network is started.
· The MULTINET:START_MULTINET.COM network initialization command procedure starts and configures the network, and initializes individual device interfaces and global parameters. This file is overwritten each time you use NET-CONFIG to update and save the configuration.
This chapter describes how to modify the startup command procedure and configuration file with NET-CONFIG and related steps required to ensure successful configuration. For details on using these configuration utilities, see Chapter 9.
|
Note: Network interface configuration changes take effect the next time your system reboots. In contrast, most global parameter changes do not require rebooting.
|
Some network interfaces require configuration data that is not accessible through either NET-CONFIG. When configuring such interfaces, additional configuration files are required. For details, see the “Creating a Custom Interface Initialization Procedure” section.
MultiNet allows you to configure multiple interface devices on your network. Each interface is named according to its type (for example, shared Ethernet interfaces are of the type "se").
In general, MultiNet accommodates a maximum of ten devices of each type. This table lists the devices MultiNet supports and the interface names to use when specifying devices to be added or modified.
|
Device |
Interface Name |
|
Raw packet (dbridge) |
rp[0...49] |
|
SLIP (Serial line IP) using any VMS-supported terminal multiplexer |
sl[0...49] |
|
PPP (Point-to-Point Protocol) |
ppp[0...49] |
|
HP VMS Ethernet, FDDI, ATM, or Alpha Token-Ring controller |
se[0...19] |
|
STF (IPv6 encapsulated in IPv4) |
stf0 |
MultiNet contains a driver for each of these device types. The driver either accesses the device directly or is an interface to an appropriate OpenVMS device driver.
You can use the NET-CONFIG SHOW command to display the maximum configuration or the current configuration.
Use the following command to display all interface types supported by MultiNet are displayed, including the default settings for the Adapter, CSR, Flags, and Vector parameters:
$ MULTINET
CONFIGURE /INTERFACE
NET-CONFIG>SHOW MAXIMUM
For example:
NET-CONFIG>SHOW MAXIMUM
Devices Adapter CSR Address FlagsVector
------- ------- ----------- -----------
rp[0-9] (Raw Packet) -NONE- -NONE- -NONE-
ppp[0-49] (Point-to-Point Protocol) -NONE- -NONE- -NONE-
se[0-9] (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE-
sl[0-49] (Serial Line IP) -NONE- -NONE- -NONE-
Use the following command to display global parameter settings and device interfaces currently in your network configuration (including the actual settings for Adapter, CSR, Flags, and Vector):
NET-CONFIG>SHOW [CURRENT]
For example:
NET-CONFIG>SHOW
Interface Adapter CSR Address Flags/Vector
--------- ------- ----------- ------------
se0 (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE-
[TCP/IP: 10.0.0.68, IP-SubNet: 255.255.255.0]
[VMS Device: EZA0, Link Level: Ethernet]
ppp0 (Point-to-Point Protocol) -NONE- -NONE- -NONE-
[VMS Terminal: TTA0]
[ACCM: 0x0, Authentication: None]
[Protocol Compression: Off, Address and Control Field
Compression: Off]
[Idle Timeout: 0, Configuration Timeout: 0]
[MRU: 0, ICMP Allowed: Yes]
[Configuration Retries: 0, Termination Retries: 0]
[TCP Header Compression: Disabled]
Official Host Name: SFO.EXAMPLE.COM
Default IP Route: 10.0.0.129
Domain Nameserver: 127.0.0.1
Timezone: EST
Default TFTP Directory: MULTINET_ROOT:[MULTINET.TFTP]
Anonymous FTP Directory: ANONVILLE:[ANONYMOUS]
Load EXOS $QIO driver: TRUE
Load UCX $QIO driver: TRUE
Load PWIP (Pathworks) driver: TRUE
The SHOW command with no parameters defaults to SHOW CURRENT.
To add a new network interface to your MultiNet configuration, you can use NET-CONFIG (see the Adding Network Interfaces with NET-CONFIG section).
For details about this utility, see Chapter 9.
The tables below list all of the network interface parameters used by MultiNet-supported interfaces, and the parameters required by each type of interface.
The supported network devices can be classified into three categories that determine the parameters you enter when configuring the device:
· Hardware devices with which MultiNet communicates directly. For each of these devices, NET-CONFIG requires that you specify the CSR and the UNIBUS adapter into which the device is plugged. Most of the devices also require you to specify device-specific parameters.
Some of these devices have programmable interrupt vectors that you specify with NET-CONFIG; MultiNet programs these vectors during startup. Others have interrupt vectors that are determined by the hardware. For each of these devices, set the vector and the CSR on the hardware using the DIP switches or jumpers on the card as described in the device's manual. Each interrupt vector must be unique.
· Hardware devices through which MultiNet communicates using a VMS device driver. For these devices, NET-CONFIG requires that you identify the VMS device through which MultiNet is to communicate; for most of these devices, you must also specify device-specific parameters.
· Software, or pseudo, devices whose interfaces communicate with software and for which no hardware is directly associated. These interfaces are typically used to implement special-purpose transports and deliver packets to other software. For example, the IP-over-DECnet interface encapsulates IP packets in DECnet datagrams for transmission over a DECnet network. All parameters for these devices are device-specific.
This table lists the prompts that appear when you run NET-CONFIG. Make sure you respond to at least one network address prompt so the device can be started from the boot process. The following table lists the prompts displayed for each device type.
|
Parameter |
Function |
|
ACCM Mask |
Asynchronous Control Character Map Mask. A 32-bit mask that indicates the set of ASCII control characters to be mapped into two-character sequences for transparent transmission over the line. Default is %x00000000. |
|
Adapter |
Identifies the UNIBUS to which the device is connected. The setting can be the name of a UNIBUS (UBA0, UBA1, UBA2, or UBA3), or ANY, which tells MultiNet to search each UNIBUS until it finds a device at the specified CSR. |
|
Address and Control Field Compression (ACFC) |
When ON, PPP eliminates the address and control fields when they are identical over a series of frames. Default is OFF. |
|
Baud Rate |
Indicates the transmission baud rate. Valid settings are 110, 300, 1200, 2400, 4800, 9600, 19200, and UNSPECIFIED. |
|
BSD Trailer Encapsulation |
For 10Mb/sec Ethernet controllers only. Can be used to enable Berkeley Trailer encapsulation of IP packets on those Ethernets. Two valid settings: NEGOTIATED or DISABLED (the default, which prevents the use of trailer encapsulation). |
|
Communications Mode |
For communications devices that share a dialup line with either a modem or a terminal. Use DTE (Data Transmit Enable, the default) to specify that the line can originate serial communications, or DCE (Data Carrier Enable) to specify the opposite. |
|
CSR |
Control Status Register. Identifies the device's octal bus address. The CSR is usually programmed by setting DIP switches or jumpers on the card as described in the device's documentation. |
|
Flags |
Some devices have a Flags prompt whose meaning is device-dependent. |
|
Hardware Device |
The name of the real Ethernet device; for example, se0. |
|
Header Compression Mode |
For SLIP devices, indicates whether to use Van Jacobson's header compression algorithm. The parameter has three valid settings:
DISABLED - Indicates that headers should never be compressed (default). ENABLED - Indicates that headers should always be compressed. NEGOTIATED - Indicates that headers should not be compressed until a compressed header is received from the other side.
At least one side of a link must be ENABLED for compression to be used; that is, both sides of a link cannot be set to NEGOTIATED. |
|
ICMP |
When ENABLED (the default), PPP allows ICMP packets over the PPP connection. Administrators may want to disable ICMP packets if they are concerned with "service attacks" from dial-up connections. |
|
IP Address |
Indicates the Internet address associated with the interface. |
|
IP Address of Remote System |
Indicates the Internet address of the system to which the interface will connect. |
|
IP Broadcast Address |
Used with devices that support broadcasts. Allows the setting of a non-standard IP broadcast address; defaults to an address with a host portion of all 1's. |
|
IP Over DECnet Peer Host's DECnet Name |
Used with IP-over-DECnet links to indicate the name of the DECnet node on the other end of the connection. |
|
IP SubNet Mask |
Allows setting a non-standard IP subnet mask. |
|
IPv6 global address |
Indicates the global unique address associated with this interface. The interface may also have a link-local address which will be automatically generated when the interface is started. |
|
IPv6 mask length |
The length of the mask for the IPv6 address. |
|
Jumbo Frames |
Used with Ethernet devices to indicate whether to use standard length Ethernet packets (1500 bytes) or larger (9000 bytes) Jumbo frames. Jumbo frames can provide a higher throughput rate because more data is processed on a single interrupt. |
|
Link Level Encapsulation Mode |
Used with Ethernet devices to indicate whether to use the standard Ethernet encapsulation of IP datagrams, or extended 802.2 encapsulation as specified in RFC1042. Valid settings are ETHERNET and 802.2. |
|
Maximum Receive Unit (MRU) Size |
Determines the maximum number of 8-bit bytes for the PPP Information field, including padding, but not including the Protocol field. Because opposite ends of a PPP connection may have different MRU values, PPP negotiates a suitable MRU for both systems. Default: 500. |
|
Point-To-Point Device IP Destination Address |
Used with point-to-point interfaces to indicate the IP address of the system on the other side of the line. |
|
Protocol Compression |
When ON, PPP negotiates with the peer to use one byte instead of two for the Protocol fields to improve transmission efficiency on low-speed lines. Default: OFF. |
|
Retry Count |
Determines the number of attempts PPP makes to configure a connection with "Configure-Request" packets. Default: 0. |
|
Termination Retry Count |
Determines the number of attempts PPP makes to terminate a connection with "Terminate-Request" packets. Default: 0. |
|
Timeout |
Determines the time (in seconds) between successive Configure-Request or Terminate-Request packets. Default: 0. |
|
VMS Device |
Used with devices that use a VMS device driver to interface to the hardware. Indicates the name of the VMS device that MultiNet is to use. This parameter is used with HP Ethernet interfaces and SLIP interfaces. |
|
Vector |
Used with programmable vector devices only. Identifies the interrupt vector that MultiNet assigns to the device during the boot process. Each interrupt vector (both fixed and programmable types) must be unique. Refer to the Displaying Interrupt Vectors section for an example of how to display the current system interrupt vectors. |
|
Note: If your network requires a network interface to be initialized with parameters other than those listed in the above table, create a custom initialization command procedure as described in the Creating a Custom Interface Initialization Procedure section.
|
|
Type |
Description |
|
se |
Interface name: se0, se1, se2, ... se19
Device type: Any HP VMS Ethernet, FDDI, ATM, or Alpha Token-Ring controller
Parameter
Prompt Example Value
The se interface uses any HP Ethernet controller to provide access to a 10/100/1000 Mb/s Ethernet network, any HP FDDI controller to provide access to a 100 Mb/s FDDI network, and any HP Alpha Token-Ring controller to provide access to 4 Mb/s or 16 Mb/s Token-Ring networks.
The se interface uses the standard VMS Ethernet driver to allow MultiNet to share the Ethernet device with other protocols such as LAT, LAVC, and DECnet. |
|
sl |
Interface name: sl0, sl1, sl2, ...sl49
Device type: Any VMS-supported terminal interface
Parameter
Prompt Example Value The MultiNet software supports SLIP with Van Jacobson's header compression algorithm, reducing the size of the headers and increasing the bandwidth available to data. Header compression mode is determined by what both sides can support. |
|
rp |
Interface name: rp0, rp1, rp2, ...rp49
Device type: Raw packet
Parameter
Prompt Example Value The rp interface allows IP packets, normally destined for transmission, to be directed instead to a user process by way of an AF_RAWPACKET socket. |
|
ppp |
Interface name: ppp0, ppp1, ppp2, ...ppp49
Device type: Any supported PPP terminal interface
Parameter
Prompt Example Value |
|
stf |
Interface name: stf0 - only one six to four interface can exist on a system.
Note that the CREATE command is used to create this interface.
Parameter
Prompt Example Value |
You can display the current interrupt vector used by VMS by invoking the SYSGEN utility, then using the SHOW /CONFIGURATION command, as follows:
$ MCR SYSGEN
SYSGEN>SHOW/CONFIGURATION
You can also display the maximum device configuration and the vectors currently used by MultiNet by invoking NET-CONFIG.
To add an interface to the configuration:
1. Start NET-CONFIG:
$ MULTINET CONFIGURE /INTERFACES
2. At the NET-CONFIG prompt, enter:
NET-CONFIG>ADD interface_name
interface_name is the name of a supported network interface device. Do not use an interface name currently in use; to modify an existing interface, see the Modifying Network Interfaces section. For example, to add a third shared Ethernet (se) interface to your network configuration, enter:
NET-CONFIG>ADD SE2
NET-CONFIG prompts you for interface parameter values required by the interface_name interface.
3. Enter interface configuration parameter values at each NET-CONFIG prompt. For descriptions of the required parameters for your network interface, refer to Interfaces and Parameters.
4. When the NET-CONFIG prompt returns, verify the validity of the new interface configuration with the CHECK command.
If the CHECK command produces error messages, view the configuration parameters with the SHOW command to determine the cause of the error. To correct the error, modify the configuration as described in the Modifying Network Interfaces section or abandon your changes with the GET command (which reloads the configuration file) and repeat from Step 2.
6. If the CHECK command produces no error messages, quit NET-CONFIG with the EXIT command.
Your changes take effect the next time your system reboots.
$ MULTINET
CONFIGURE
MultiNet Network Configuration Utility 5.6(nnn)
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>ADD SL0
[Adding new configuration entry for device "sl0"]
VMS Device [TTA0] TTA2
Baud Rate: [UNSPECIFIED]
Header Compression Mode: [DISABLED]
IP Address: [NONE] 10.1.1.1
Point-To-Point Device IP Destination Address: [NONE] 10.1.1.2
IP SubNet Mask: [NONE]
[sl0 (Serial Line IP): Csr=NONE, Flags=%X0]
NET-CONFIG>EXIT
[Writing configuration to MULTINET:NETWORK_DEVICES.CONFIGURATION]
[Writing Startup file MULTINET:START_MULTINET.COM]
[Changes take effect after the next VMS reboot]
$
If your network requires that a device be initialized with parameters not supported by NET-CONFIG, you can create a custom initialization command procedure for the device. At network startup, MultiNet uses this file instead of the commands for the device in the MULTINET:START_MULTINET.COM file.
The device must already be part of the network configuration, and commands to its interface must already exist in the MULTINET:START_MULTINET.COM file. To change the device's initialization, create a command file using a text editor:
1. Create a file named MULTINET:interface_CONFIGURE.COM, interface is an interface in your configuration.
2. Copy the section of MULTINET:START_MULTINET.COM containing the initialization commands into the new file.
3. Edit the new file to specify the new initialization.
To modify the configuration of an existing interface:
1. Start NET-CONFIG:
$ MULTINET CONFIGURE /INTERFACES
2. At the NET-CONFIG prompt, enter:
NET-CONFIG>MODIFY interface_name
interface_name is the name of the network interface you want to modify.
For example, to modify the third shared Ethernet interface in your network configuration, enter:
NET-CONFIG>MODIFY SE2
NET-CONFIG prompts you for interface parameter values required by the specified interface.
3. Enter interface configuration parameter values at each of the NET-CONFIG prompts. For descriptions of the required parameters for your network interface, refer to the table of interface parameters earlier in this chapter.
4. When the NET-CONFIG prompt returns, verify the validity of the new interface configuration with the CHECK command.
5. If the CHECK command produces error messages, view the configuration parameters with the SHOW command to determine what is causing the error. Correct the error by repeating from Step 2, or abandon your changes with the GET command (which reloads the configuration file) and repeat from Step 2.
6. If the CHECK command produces no error messages, quit NET-CONFIG with the EXIT command.
Your changes take effect the next time your system reboots.
You can delete network interfaces from your MultiNet configuration using NET-CONFIG
Use NET-CONFIG to delete one or all interfaces from the current configuration:
1. Start NET-CONFIG:
$ MULTINET CONFIGURE /INTERFACES
2. At the NET-CONFIG prompt, enter:
NET-CONFIG>DELETE interface_name
interface_name is the name of the existing network interface you want to delete.
For example, to delete the third shared Ethernet interface in your network configuration, enter:
NET-CONFIG>DELETE SE2
3. When the NET-CONFIG prompt reappears, verify the validity of the new interface configuration with the CHECK command.
4. If the CHECK command produces error messages, view the configuration parameters with the SHOW command to determine the cause of the error. Correct the error by repeating from Step 2, or abandon your changes with the GET command (which reloads the configuration file) and repeat from Step 2.
5. If the CHECK command produces no error messages, quit NET-CONFIG with the EXIT command.
Your changes take effect the next time your system reboots.
You can disable and re-enable interfaces individually. If you disable a device, it is not configured when the network is started.
To disable a device, use the DISABLE command; for example:
NET-CONFIG>DISABLE SE0
To re-enable a device, use the ENABLE command; for example:
NET-CONFIG>ENABLE SE0
Sometimes it is necessary to assign multiple IP addresses to a single physical interface; for example, when multiple subnets or networks are running on a single network segment.
You do this by using a pseudo device interface (pd). Use NET-CONFIG to add the device as you do other devices (such as se devices). This MultiNet release supports up to 500 pseudo device interfaces. Instead of specifying the OpenVMS device name, however, specify the MultiNet name for the interface (for example, se0). You must reboot the system after adding the pseudo device.
|
CAUTION! Careless assignment of a secondary address can cause network problems. In general, you should assign pseudo devices (pd) addresses on the same network or subnet as the se device to which the pd device is linked.
If the pd interface is not in the same IP network as its associated se interface, some TCP/IP packages (such as early versions of Solaris) retransmit broadcast packets for the other IP network back to the network segment from which they were transmitted. This can cause network storms.
|
|
Note: Some services listen to traffic on se interfaces only and ignore traffic on pd interfaces. One such service is the RIP listener in GATED.
|
The following example shows how to add a pseudo device:
$ MULTINET
CONFIG
MultiNet Network Configuration Utility 5.6
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>SHOW
Interface Adapter CSR Address Flags/Vector
--------- ------- ----------- ------------
se0 (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE-|
[TCP/IP: 10.1.128.20, IP-SubNet: 255.255.255.0]
[NETWARE: A12C8000:0.0.0.0.0.0, Link Level: Ethernet]
[VMS Device: ESA0, Link Level: Ethernet]
|
Official Host Name: bos.example.com
NETWARE Host Name: BOS
Domain Nameservers: 127.0.0.1
Timezone: EST
Timezone Rules: US/EASTERN
Load EXOS $QIO driver: TRUE
Load UCX $QIO driver: TRUE
Load PWIP (Pathworks) driver: TRUE
Nameserver Retrans Timeout: 9 (6 Retries)
WHOIS Default Server: rs.internic.net
NET-CONFIG>ADD PD0
[Adding new configuration entry for device "pd0"]
Hardware Device: [NONE] SE0
IP Address: [NONE] 10.1.128.21
IP SubNet Mask: [NONE] <Return>
Non-Standard IP Broadcast Address: [NONE] <Return>
[pd0 (Secondary Ethernet Address): Csr=NONE, Flags=%X0]
NET-CONFIG>SHOW
Interface Adapter CSR Address Flags/Vector
--------- ------- ----------- ------------
se0 (Shared VMS Ethernet/FDDI) -NONE- -NONE- -NONE-
[TCP/IP: 10.1.128.20, IP-SubNet: 255.255.255.0]
[NETWARE: A12C8000:0.0.0.0.0.0, Link Level: Ethernet]
[VMS Device: ESA0, Link Level: Ethernet]
pd0 (Secondary Ethernet Address) -NONE- -NONE- -NONE-
[TCP/IP: 10.1.128.21]
[Hardware-Device: se0]
Official Host Name: bos.process.com
NETWARE Host Name: BOS
Domain Nameservers: 127.0.0.1
Timezone: EST
Timezone Rules: US/EASTERN
Load EXOS $QIO driver: TRUE
Load UCX $QIO driver: TRUE
Load PWIP (Pathworks) driver: TRUE
Nameserver Retrans Timeout: 9 (6 Retries)
WHOIS Default Server: rs.internic.net
NET-CONFIG>EXIT
Packet filtering is used today in almost all (from basic to sophisticated) security firewalls. Packet filtering firewalls apply filtering rules to each packet received to determine whether to accept or discard it. These filtering rules specify the protocol, source and destination IP addresses, and destination ports (for TCP and UDP) for accepted or discarded packets.
You use packet filtering on routers between an internal network and one or more external networks (such as a connection to the Internet). Packet filter rules restrict what may come in through the interface connected to the external network.
Packet filtering can also be useful on hosts. For example, you can restrict the hosts that are allowed access to services. In particular, these are UDP-based services and services that the MultiNet master server does not activate, and thus cannot use incoming access restrictions.
|
Note: When you use packet filtering, each and every datagram received on the interface is filtered. This increases processing overhead depending on the size of the filter list.
|
Packet filtering can be an effective and useful security mechanism; however, it cannot solve all your security problems. To be effective, you must construct the filtering rules carefully.
Both IPv4 and IPv6 addresses may be filtered.
Observe the following cautions when setting up packet filtering on an interface:
· Packet filtering does not use state information. Each datagram is filtered without any knowledge of packets that preceded it. This means that for UDP-based applications, it is not possible to add a rule that says to accept replies to requests. This also affects connection-oriented protocols, such as FTP, that use two connections: one for commands and the other for data.
· Fragmented datagrams for UDP or TCP are difficult to filter, since only the first fragment has the necessary port information. MultiNet solves this problem by applying the filter rules to only the first fragment of UDP and TCP datagrams. The other fragments are accepted and processed or forwarded, but are eventually discarded because they cannot be reassembled without the first fragment. For all other IP protocols, the filter rules apply to each fragment.
· To set up secure packet filtering lists, you need detailed knowledge of IP, ICMP, TCP, UDP and applications protocols.
Suggested reading includes the protocol RFCs (listed elsewhere in the MultiNet documentation) and books such as Cheswick, William R. & Steven M. Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker.
Packet filtering uses a filter list to determine whether you can receive a datagram. Filter lists are in packet filter files having the .DAT extension by default. Create one of these files first and then edit the file using the formats described in the following table.
|
Note: The format of the individual filter source address and mask, and destination address and mask, has changed. In previous releases, these were specified as an IPv4 address and IPv4 mask (e.g., “192.168.0.11 255.255.255.0”). This has been changed to use addresses and masks specified in CIDR (Classless InterDomain Routing) format (e.g., “192.168.0.11/24”). This not only makes the specification of addresses and masks clearer, it also allows for the implementation of IPv6 addresses which are substantially longer than IPv4 addresses, leading to potential problems with long filter file lines. The FILTER_CONVERT utility is provided to change existing filter files from the old format to the new format.
|
|
Field... |
With valid values... |
Means... |
|
action protocol |
saddr [sport] |
daddr [dport [doption]] |
|
action |
permit |
permit allows the datagram; |
|
protocol |
ip ip-number |
Protocol to check: the values indicated or the numeric IP protocol number. The value ip matches any IP protocol. |
|
saddr |
Example: 192.168.123.123/24 |
Source IP address to check in CIDR format. This may be in ipv4 or ipv6 format. |
|
sport |
operator operand |
Optional source port specification to check (for TCP and UDP entries only). Consists of an operator, space, and port name or number. If port name, must be defined in the MULTINET:HOSTS.SERVICES file. If omitted, any source port is valid. Example: gt 1023 |
|
daddr |
Example: 192.168.123.123/240 |
Destination IP address to check in CIDR format. This may be in ipv4 or ipv6 format, but must be of the same address family as saddr |
|
dport |
operator operand le icmp-msg-type |
Optional destination port (for TCP and UDP entries) or ICMP message type specification consisting of an operator, space, and operand. If a port name, must be in the MULTINET:HOSTS.SERVICES file. If icmp-msg-type, use:
0-Echo Reply |
|
doption |
established |
Matches only established connections (TCP segments with ACK or RST bits set). |
|
start time |
|
VMS-format absolute or delta date/time.
If specified, the filter takes effect starting at the time specified.
By default, a filter takes effect when loaded by MultiNet if the start time is not defined. |
|
end time |
|
Absolute or delta VMS-format date/time.
If specified, the filter is ignored after the time specified is reached if an absolute time is specified, or after the time calculated by adding the end time to the start time if a delta time is specified.
If no start time was specified, the delta time is added to the current time.
If the end time for a non-repeating filter has already passed when the filter definition is parsed, the filter is not loaded and the user is informed of that fact. |
|
repeat |
|
If Y and start/end times are specified, this filter repeats until it is removed. Both a start and end time must be specified in order to specify a repeating filter. |
|
log |
|
Logs events from this filter. |
Each entry specifies a packet filtering condition for a particular protocol type, source or destination address and mask, and destination port and mask specification, with certain additional options. The system looks at each condition in sequence, looks for a match, and takes a permit (accept) or deny (reject) action. The system stops testing conditions after the first match. This means that the order of the entries in the file is important; if the file lists a subsequent condition for an address, the system ignores it.
An implicit deny terminates the list of entries in the packet filter file. This means that if no condition matches, the system rejects the datagram. To use packet filtering:
1. Create address list entries in the packet filter file.
2. Apply the list to interfaces on your system by using packet filtering commands.
To create a packet filter file, edit a file and add address list entries in the format described.
Any number of spaces or tabs can separate each entity. Lines beginning with an exclamation point (!) are comment lines. You can use the dash (-) continuation character at the end of a line that needs to continue onto the next.
To apply the list to a particular network interface or interfaces on your system, use the MULTINET SET/INTERFACE/FILTER command, as described in MultiNet Administrator's Reference.
Constructing an address filter list requires care in that you want to allow only the packets you need. Here are some recommendations in setting up an address filter list for an interface:
· Add an entry to prevent IP "spoofing"-having an external host send a datagram as if it came from a local machine. For a router, this makes sense because no datagram received from an external network should ever have a local source address. Add the following entry to the filter list for the external interface:
deny ip local-network
· Be careful with services that use "unprotected" port numbers (greater than 1024). Some examples are NFS (port 2049) and X Windows (port 6000 and higher). Explicitly denying these services is a good idea:
deny udp 0/0 0/0 eq
2049
deny tcp 0/0 0/0 eq 2049
deny tcp 0/0 0/0 eq 6000
deny tcp 0/0 0/0 eq 6001
· Prevent broadcast and loopback packets from entering your network. It is best to restrict the broadcast (the first two of the following entries) to an external interface; apply the loopback restriction (the last entry) to any interface:
drop ip 0.0.0.0/32
drop ip 255.255.255.255/32
drop ip 127.0.0.0/8
· Guard against datagrams from invalid source addresses when connected to the Internet (provided you are not using these network numbers for internal-only traffic purposes). Add the following to the filter list for the external interface:
drop ip 10.0.0.0/8
drop ip 172.16.0.0/12
drop ip 192.168.0.0/16
· You generally need to allow domain name (DNS) requests using:
permit udp 0/32 eq 53 0 0
Whether to allow TCP DNS traffic (usually used for zone transfers) is also something to consider. To disallow TCP DNS traffic, add:
deny tcp 0/32 eq 53 0 0
· You should not be concerned with what services local users use in the external world. You would want to add:
permit tcp 0/32 0/32 gt 1023 established
This allows all TCP datagrams in to ports greater than 1023 that have either the ACK or RST bits set in the TCP flags. Connection establishment requests have just the SYN bit set, so they are not allowed by this entry.
You might want to drop the established option if you want to allow incoming connections to unprotected ports. This would allow use of the FTP PASV capability.
· You may offer services to the external world such as a World Wide Web or anonymous FTP server. Add the following entries:
permit tcp 0/32
web-server-address/32 eq 80
permit tcp 0/32 ftp-server-address/32 eq 21
If you have several hosts for each service, add an entry for each.
|
Note: For the FTP Server, the data connections are normally outgoing and thus the earlier permit tcp 0 0 0 0 gt 1023 established configuration works to allow these. However, if users switch to PASV mode, the connections will be incoming (to unprotected port numbers) and therefore the permit tcp 0 0 0 0 gt 1023 configuration (without the established option) might be more effective.
|
· Allow all ICMPs except ICMP redirects:
deny icmp 0/32 0/32
eq 5
permit icmp
This is useful for informing hosts about problems. But it can open up denial of service attacks, especially if hosts are not careful about the ICMP redirects they accept. That is why discarding them is recommended.
· Watch the order of the entries in the table carefully.
permit tcp 0/32 0/32
gt 1023
deny tcp 0/32 0/32 eq 2049
This entry would not work since the permit entry allows the datagram and processing stops as soon as a match is found. MultiNet processes the entries in the order in which you specify them.
· Remember that an implicit "deny everything" is added to the end of the filtering list. This means that to permit a datagram, you need to have a permit entry in the list.
· Once you applied your filter list, test it first. Get an account on a host on an outside network that you can use to connect to your local hosts. Check that you are not allowing any access you do not want, and that you are allowing access that you do want. If something is not right, modify the filter list, reload it, and retest.
While packet filtering is very useful, it is by no means the only step you should take to secure your network. You must take special care to secure the system to assure that it cannot be compromised. One way to do this is to greatly limit the services it offers.
Filters may be set to be active only during a specified time period. These filters may be specified as a one-time filter or as a filter that repeats. For example, a filter may be set up to filter all traffic from a specific address during the hours of 5am to 5pm each day, or a filter may be specified that filters traffic starting from the time the filter is loaded and for the next 3 hours.
Time-based filtering is done by specifying a start time, an end time, or both start and end times for a filter in the filter definition file. For repeating filters, both start and end times must be specified. Note that all time values for start and end times must be specified in VMS absolute or delta time format. For example, the following are all valid:
|
“29-DEC-2003” |
would be interpreted as "29-DEC-2003 <current time> |
|
“29-DEC-2003 18:03” |
would be interpreted as "29-DEC-2003 18:03:00.00" |
|
18:03:00 |
would be interpreted as "<current date> 18:03:00.00" |
|
“1 15:00” |
would be interpreted as a delta time of 1 day, 15 hours |
Note that if an absolute time is specified that contains both a date and time (example 2 above), it MUST be enclosed by double quotes. For example:
deny icmp 0 0 eq 5 start 17:00:00 end "29-Sep-2003 6:00:00"
Given the following filter file:
deny tcp 15.1.94.2/32
2.22.2.5 255/32 start 15:20 end 18:30 repeat
deny tcp 1.1.94.2/32 207.225.29.51/32 end "1-JAN-2004 18:30"
deny tcp 195.101.94.209/32
207.225.29.51/32 start 18:00 end "1 00:30" repeat
deny tcp 195.101.94.209/32 207.225.29.51/32
deny tcp 195.101.94.209/32 207.225.29.51/32 start 17:00 end 18:30
deny tcp 15.1.94.2/32 2.22.2.5/32 start "2 00:00" end 3 00:00"
Line 1 will filter from 15:20 to 18:30 each day.
Line 2 will filter from the time the filter is loaded through 18:30 on January
1, 2004
with no logging. After that time, if the filters are reloaded, this filter will
not be loaded.
Line 3 will filter from 18:00 to 19:30 each day.
Line 4 has no time limits on it.
Line 5 will log from 17:00 through 18:30 today.
Line 6 will filter starting 2 days from the time the filter is loaded, through
3 days after that.
Filter "hits" may be logged, either to OPCOM or to a file defined by the user. Logging is enabled on a filter-by-filter basis, by using the "log" keyword on the end of a filter definition line. For example:
deny tcp 192.10.9.209/32 207.225.29.51/32 log
Logging for the interface is controlled via the MULTINET SET/INTERFACE command. The actual logging is performed by the MULTINET_FLOG process, which is started the first time a MULTINET SET/INTERFACE /LOG command is issued (a single MULTINET_FLOG process handles logging for all interfaces defined on the system).
The MULTINET SET/INTERFACE command switches used to support logging are
|
Qualifier |
Values |
Default |
Description |
|
/[NO]LOGGING |
OPCOM or a valid filename |
None |
Used to turn logging on or off. Filter events may be logged to OPCOM or to a specified file. Only those events with the LOG qualifier in their definition are affected by this qualifier. |
|
/FORMAT |
COMMA or NORMAL |
NORMAL |
If NORMAL, then the normal formatting as seen by |
|
/INTERVAL |
Number of seconds, between 5 and 2^31 |
5 seconds |
Reporting interval. The minimum reporting interval is 5 seconds, so that a flood of filter events doesn’t drag the system down. When reporting events, a count of missed events will be included for each event where the event couldn’t be reported before the next event occurred. |
When filter logging is enabled, the MULTINET_FLOG process will be started. This process checks each interface at the interval defined by the /INTERVAL qualifier for the MULTINET SET/INTERFACE command. As unlogged filter hits are found, it will log them to OPCOM or to a file, according on the parameters set by the /LOG and /FORMAT qualifiers for the MULTINET SET/INTERFACE command.
When logging to OPCOM, only NORMAL formatting is allowed. An OPCOM message, formatted as the filter output from MULTINET SHOW/INTERFACE /FILTER, will be displayed for each filter with unlogged hits on it.
When logging to a file, the output will be identical to that
of the filter displays from MULTINET SHOW/INTERFACE
/FILTER command, if /FORMAT=NORMAL is
specified. If
/FORMAT=COMMA is specified, the data will be
recorded as comma-delimited fields, one line per filter, to the file. The first
line of this file will contain the field names (comma-delimited) to aid in
interpreting the contents of the file.
Examples:
$ MULTINET SET /INTERFACE SE0 /LOG=OPCOM/INTERVAL=10
enables logging to OPCOM, with a reporting interval of 10 seconds.
$ MULTINET SET /INTERFACE SE0 /LOG=FOO.DAT/FORMAT=COMMA
enables logging to the file FOO.DAT in comma-delimited format, and a reporting interval of 5 seconds (the default).
$ MULTINET SET /INTERFACE SE0 /NOLOG
This disables all logging for the interface, closing all open log files.
When you start MultiNet, the START_MULTINET procedure looks for a MULTINET:FILTER-interface.DAT file for each interface it starts. If the file exists, START_MULTINET issues the following command to set the filter list for the interface:
$ MULTINET SET/INTERFACE interface /FILTER=MULTINET:FILTER-line-id.DAT
You can also add the necessary MultiNet commands to the MULTINET:LOCAL_ROUTES.COM file.
If you want to know if filtering is enabled and what the
settings are, use the MULTINET SHOW
/INTERFACE/FILTER SE0 command.
MultiNet also supports the use of a LOCAL_INITIALIZATION command procedure during startup. As with the MULTINET:LOCAL_ROUTES.COM file, you can put the necessary MultiNet filter commands in the MULTINET:LOCAL_INITIALIZATION.COM file to have them executed as MultiNet starts.
The FILTER_CONVERT utility is provided to convert from the old-format filter file (one which uses separate adress/mask fields) to the new-format filter file (one which uses CIDR format address specification). To use this:
$ FILTER_CONVERT :== $MULTINET:FILTER_CONVERT
$ FILTER_CONVERT infile outfile
When a filter file has been converted, the resulting output file should be checked for correctness prior to using it.
MultiNet supports remote IP transport over serial lines with SLIP (Serial Line IP) or PPP (Point-to-Point Protocol).
Both SLIP and PPP use a simple framing protocol to transfer datagrams over a terminal line. Both require an RS232-C serial line, or one that looks like an asynchronous line to VMS.
MultiNet SLIP interfaces (identified by the name sl) and PPP interfaces (identified by the name ppp) can send and receive packets over any asynchronous terminal line (OpenVMS device of types TTcn or TXcn) connected to other systems that support the SLIP and PPP protocols, respectively.
As a result, MultiNet systems can communicate asynchronously with other MultiNet systems (or UNIX and other systems) that support SLIP or PPP.
With SLIP or PPP, users on one system can connect with another system using modems over telephone lines or over hardwired connections. To use SLIP or PPP over modems, the modems must be 8-bit transparent so all 256 ASCII codes can be sent and received.
If the remote system is configured as a gateway to a network, local users can also reach other systems on that network. MultiNet supports SLIP and PPP running over any VMS-supported terminal multiplexer. MultiNet does not support SLIP or PPP over LAT.
You must know the IP address of the serial interface on every remote host with which you establish serial communications. If you configure MultiNet with PPP interfaces for multiple remote hosts, the remote hosts can obtain their IP addresses when they connect. Similarly, you can configure a PPP interface on MultiNet without knowing your own IP address, and obtain it when you connect to a remote system.
The two methods of connecting hosts via PPP or SLIP are dynamic and static. The following sections explain these methods.
The usual SLIP or PPP configuration consists of two systems connected by serial line only when needed. For these situations, configure a dynamic SLIP or PPP interface. Dynamic interfaces are not associated with a specific OpenVMS device until the remote host connects to a device.
For a dynamic interface, you do not specify an OpenVMS device name when configuring the interface. When MultiNet starts, new dynamic interfaces are available for serial communication; however, an administrator must attach the interfaces to VMS devices.
Large organizations often use SLIP and PPP to connect separate LANs into a single wide area network (WAN) with dedicated serial lines. The host at each end of the serial connection is always the same, and no other hosts are allowed to connect to either serial device. In these situations, configure a static SLIP or PPP interface. Static interfaces are attached to a specific OpenVMS device, which prevents the serial device from being used for any other purpose.
For a static interface, you specify an OpenVMS device name when configuring the interface.
As soon as you connect two static interfaces via modem or hardwired connection, they can communicate over the chosen serial protocol; no user authentication is required.
|
Note: Because IP connectivity is established as soon as the two serial interfaces connect, do not configure static interfaces for public dial-in access.
|
To configure a static SLIP interface:
1. Use NET-CONFIG to add the SLIP interface as described in the Adding Network Interfaces section. The SLIP Configuration Parameters section describes the interface parameters you must define for basic SLIP operation. Be sure to specify an OpenVMS device name.
2. If desired, create a custom startup command procedure for the new interface. For details, see the Configuring Permanent SLIP and PPP Interfaces section.
3. Reboot your system.
When MultiNet starts, you can connect your serial device to a remote system.
To configure a dynamic SLIP interface:
1. Use NET-CONFIG to add the SLIP interface as described in the Adding Network Interfaces section. The SLIP Configuration Parameters section describes the interface parameters you must define for basic SLIP operation. Do not specify an OpenVMS device name.
2. If desired, create a custom startup command procedure for the new interface as described in the Configuring Permanent SLIP and PPP Interfaces section.
3. Reboot your system.
4. The new dynamic interfaces are created when MultiNet starts, but they are not yet connected to a VMS device. See the Attaching Dynamic SLIP or PPP Interfaces to VMS Devices section for instructions.
The below table lists the configuration parameters for configuring static and dynamic SLIP interfaces.
|
Parameter |
Description |
|
|
SLIP interface name |
Determines the interface name. Must be of the form sln, · n is a positive integer. · sl0 is a suitable interface name for the first SLIP interface. · sl1 is a suitable interface name for the second one. |
|
|
OpenVMS device name |
For a static SLIP interface (one that uses a hardwired terminal line or dedicated modem and telephone line), specify a device name.
For a dynamic SLIP interface (one to which you assign a device name when the connection is made, for example, by modem dial-up), do not specify a name. When a modem hangs up on a dynamic SLIP interface, each end of the SLIP interface automatically reverts to a normal terminal line.
Use a value of "none" to override any specified device name. Doing so might be useful to make a previously configured interface dynamic. |
|
|
Baud rate |
Data transfer baud rate (110, 300, 1200, 2400, 4800, 9600, 19200, or UNSPECIFIED) of the SLIP interface. |
|
|
SLIP compression mode |
MultiNet SLIP supports the Van Jacobson header compression algorithm to reduce the bandwidth required for the TCP and IP headers. If both sides of a SLIP interface support compression, turnaround improves significantly.
Compression modes are: · ENABLED - Headers should always be compressed. · DISABLED - Headers should never be compressed. · NEGOTIATED - Headers should not be compressed until a compressed header is received from the other side. Negotiated compression is useful on dialup gateways that do not know if the other side of SLIP interfaces support compression.
|
|
|
IP address |
IP address associated with the SLIP interface on the local system. |
|
|
Point-to-point IP destination address |
IP address associated with the SLIP interface on the target system. |
To define a static PPP interface:
1. Use NET-CONFIG to add a PPP interface to your network configuration as described in the Adding Network Interface section. The PPP Configuration Parameters section describes the interface parameters you must define for basic PPP operation. Be sure to define an OpenVMS device for the interface.
2. If desired, create a custom startup command procedure for the new interface. For details, see the Configuring Permanent SLIP and PPP Interfaces section.
3. Reboot your system.
After rebooting, the interfaces are attached to VMS terminal lines.
To define a dynamic PPP interface:
1. Use NET-CONFIG to add a PPP interface to your network configuration as described in the Adding Network Interfaces section. PPP Configuration Parameters describes the interface parameters you must define for basic PPP operation. Do not define an OpenVMS device for the interface.
2. Enable virtual terminal (VTA) devices for your dynamic PPP interfaces. For information on configuring virtual terminals, see your OpenVMS system management documentation.
|
Note: Dynamic PPP interfaces require CMKRNL, LOG_IO, and SYSPRV privileges. Because these privileges are potentially dangerous, login name and password information should be safeguarded carefully.
|
3. If desired, create a custom startup command procedure for the new interface. For details, see the Configuring Permanent SLIP and PPP Interfaces section.
4. Reboot your system.
The dynamic interfaces are created when MultiNet starts, but they are not associated with a VMS terminal line. The interfaces must now be attached to terminal lines; see the Attaching Dynamic SLIP or PPP Interfaces to VMS Devices section.
The table below lists the configuration parameters for static and dynamic PPP interfaces.
|
Parameter |
Description |
|
PPP interface name |
Determines the interface name. Must be of the form pppn, · n is a positive integer. · ppp0 is a suitable interface name for a first PPP interface. |
|
OpenVMS device name |
Dedicates the device name to a static PPP interface (one that uses a hardwired terminal line or dedicated modem and telephone line).
To configure a dynamic PPP interface (one to which you assign a device name when a connection is made-for example, by modem dial-up), do not specify a name. When a modem hangs up on a dynamic PPP interface, each end of the PPP connection automatically reverts to a normal terminal line.
Use a value of none to override any specified device name. Doing so might be useful to make a previously configured interface dynamic. |
|
Baud rate |
Determines the data transfer baud rate (110, 300, 1200, 2400, 4800, 9600, 19200, or UNSPECIFIED) of the PPP interface. |
|
Asynchronous Control Character Map (ACCM) Mask |
A 32-bit mask that indicates the set of ASCII control characters to be mapped into two-character sequences for transparent transmission over the line. Default: %x00000000.
The map is sent the most significant 8 bits first. Each numbered bit corresponds to the ASCII control character of the same value. If the bit is cleared to zero, the corresponding ASCII control character need not be mapped. If the bit is set to one, the corresponding ASCII control character must remain mapped.
For example, if bit 19 is set to zero, the ASCII control character 19 (DC3, Control-S) can be sent in the clear.
The least significant bit of the least significant 8 bits (the final 8 bits transmitted) is numbered bit 0, and corresponds to the ASCII control character "NUL." |
|
Protocol Compression |
When ON, PPP negotiates with the peer to use one byte instead of two for the Protocol fields to improve transmission efficiency on low-speed lines. Default: OFF. |
|
Address and Control Field Compression (ACFC) |
When ON, PPP eliminates the address and control fields when they are identical over a series of frames. Default: OFF. |
|
Retry Count |
Determines the number of attempts PPP makes to configure a connection with "Configure-Request" packets. Default: 10. |
|
Idle Timeout |
Determines how long (in seconds) the connection must remain idle before PPP attempts to close the connection with "Terminate-Request" packets. Default: 300. |
|
Maximum Receive Unit (MRU) Size |
Determines the maximum number of 8-bit bytes for the PPP Information field, including padding, but not including the Protocol field. Because opposite ends of a PPP connection may have different MRU values, PPP negotiates a suitable MRU for both systems. Default: 1500. |
|
ICMP |
When ENABLED, PPP allows ICMP packets over the PPP connection. Administrators may want to disable ICMP packets if they are concerned with "service attacks" from dial-up connections. Default: ENABLED. |
|
TCP Header Compression |
When ENABLED, requests the IPCP driver to employ Van Jacobson TCP header compression to improve performance. Default: DISABLED. |
|
Termination Retry Count |
Determines the number of attempts PPP makes to terminate a connection with "Terminate-Request" packets. Default: 10. |
|
Timeout |
Determines the time (in seconds) between successive Configure-Request or Terminate-Request packets. Default: 30. |
|
IP Address |
The IP address of the local PPP interface in dotted-decimal format. You may also specify 0.0.0.0 (the default) to indicate that the local IP address will be specified by the remote peer when the serial connection is established. |
|
Point-To-Point Device IP Destination Address |
The IP address of the peer PPP interface in dotted-decimal format. Default: 0.0.0.0. |
|
SubNet Mask |
The subnet mask of the local PPP interface in dotted-decimal format. The default depends on the local PPP interface IP address. For example, a class A address results in a default subnet mask of 255.0.0.0. |
When you configure an interface, the following line is added to your START_MULTINET.COM file to initialize the device:
$ SET TERM/PERM/NOTYPE_AHEAD/NOAUTOBAUD/SPEED=config_speed dev_name
· config_speed is the baud rate for transmitting and receiving data.
· dev_name specifies a SLIP or PPP interface such as TTA1:.
This setting is used for permanent interfaces to prevent LOGINOUT from gaining control of the device because of extraneous noise on the line.
If you want to override this behavior, create a custom command procedure, MULTINET:dev_name_CONFIGURE.COM, for that interface. If you have an IP address assigned to the device, you custom command procedure is invoked at startup instead of the command line described previously.
After a remote host connects to a MultiNet system over a serial line, the remote system administrator must log into the MultiNet system and attach the appropriate MultiNet dynamic interface to the VMS terminal line to which the remote host is connected.
For example, if your system provides serial access via two modems, but you need to provide access to three or more hosts, configure a dynamic interface for each host you plan to accommodate. Then make sure the administrator on each remote host knows the name of the serial interface you have configured and the commands to execute to attach SLIP or PPP interfaces to the appropriate terminal lines.
To convert a terminal line into a SLIP or PPP interface:
1. Log into an account with CMKRNL, LOG_IO, and SYSPRV privileges.
2. Determine the name of the serial interface corresponding to the remote host. If the administrator knows the remote IP address or host name, the corresponding serial interface name can be determined from the MULTINET SHOW command output. For example:
$ MULTINET SHOW /STATISTICS
MultiNet Network Interface
statistics:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis
---- --- ------- ------- ----- ----- ----- ----- ------
se0 1500 ABC-NET FOO.BAR.COM 120360 0 143384 1 4
sl0 296 ABC-NET FOO.BAR.COM 0 0 1 0 0
lo0 1536 LOOPBACK-NET LOCALHOST 917 0 917 0 0
$ MULTINET SHOW /INTERFACE
_Network Device: SL0
Device sl0: flags=71<UP,POINTOPOINT,NOTRAILERS,RUNNING>
IP Address = 10.41.228.78
IP Sub-Net Mask = 255.255.255.192
IP Point to Point Destination = 10.41.228.80
3. Attach the serial interface to the VMS device with the following DCL command:
$ MULTINET SET /INTERFACE interface_name /DYNAMIC /VMS_DEVICE /LINK_LEVEL=protocol
protocol is SLIP or PPP, according to the type of serial interface.
|
Note: If the remote host is also a MultiNet system, the remote administrator must also attach the remote serial interface to the remote VMS device.
|
The following example illustrates how to establish
connectivity between two MultiNet systems over dynamic SLIP interfaces. The
first MULTINET SET /INTERFACE command converts the
remote host's dial-in port into a SLIP interface. After the user types the
control-backslash
Ctrl/\ escape key sequence to return to a local
DCL command line, the second MULTINET SET /INTERFACE
command converts the local terminal line into a SLIP interface. The MULTINET PING command confirms IP connectivity.
WHARFIN$ ALLOCATE TTA1:
%DCL-I-ALLOC, _WHARFIN$TTA1: allocated
WHARFIN$ SET TERMINAL/SPEED=2400 TTA1:
WHARFIN$ SET HOST/DTE TTA1:
%REM-I-TOEXIT, connection established, type ^\ to exit
ATDT1415555-1212
RRING
CONNECT 2400
BIGBOOTE SLIP Gateway — VAX/VMS V5.5-2
Username: SYSTEM
Password: ********
Welcome to the BIGBOOTE SLIP Gateway
Last interactive login on Monday, 28-FEB-2020 14:47
Last non-interactive login on Monday, 28-FEB-2020 13:16
BIGBOOTE$ MULTINET SET/INTERFACE
SL1/DYNAMIC/LINK_LEVEL=SLIP/VMS_DEVICE
The line you are logged in over is now a SLIP line.
[You now type the Ctrl/\escape sequence to return to WHARFIN.]
%REM-S-END, control returned to node _WHARFIN::
WHARFIN$ MULTINET SET/INTERFACE
SL1/DYNAMIC/LINK_LEVEL=SLIP/VMS_DEVICE=TTA1:
WHARFIN$ MULTINET PING 192.0.0.3
PING 192.0.0.3 (192.0.0.3): 56 data bytes
64 bytes from 192.0.0.3: icmp_seq=0 time=860 ms
64 bytes from 192.0.0.3: icmp_seq=1 time=860 ms
64 bytes from 192.0.0.3: icmp_seq=2 time=860 ms
Ctrl+C
----192.0.0.3 PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms) min/avg/max = 860/860/860
WHARFIN$
To bring down an interface, issue the following command:
$ MULTINET SET /INTERFACE interface_name /LINK_LEVEL=protocol /VMS_DEVICE=device /DOWN
MultiNet maintains a set of global parameters that affect the behavior of all network interfaces. For example, your system's default route (see Chapter 13) is specified as a global parameter and affects how all network interfaces direct data packets over the network.
You can configure global parameters with NET-CONFIG, using the SET parameter_name command. See the MultiNet Administrator's Reference for a complete list of SET commands.
You can modify all global parameters without rebooting your system with the following exceptions:
LOAD-EXOS-DRIVER
LOAD-UCX-DRIVER
WINS-COMPATIBILITY
Changes to these parameters take effect after you reboot the system.
The following subsections describe how to modify global parameters to perform the following tasks:
· Configuring DECwindows support (see the Using the HP TCP/IP Transport Over UCX section)
· Configuring the cluster alias feature, which permits another VMScluster node to continue to provide some connectionless network services if the primary node that provides those services fails (see the Configuring VMScluster Aliasing section)
· Ensuring PATHWORKS 5.0 support is enabled (see the Ensuring PATHWORKS Support is Enabled section)
You can configure the DECwindows server and X clients to use the HP TCP/IP Transport over MultiNet's UCX driver. MultiNet supports DECwindows over TCP/IP under VMS V5.5-2 and later versions by emulating the HP TCP/IP Services for the VMS $QIO interface.
The MultiNet UCX driver is enabled by default.
1. Edit your system startup command procedure to invoke MultiNet before starting DECwindows.
2. Reboot your system to start MultiNet with the UCX $QIO driver loaded.
3. To create a display, issue the following command:
$ SET DISPLAY/CREATE/NODE=ip-node-name /TRANSPORT=TCPIP
For complete information on the SET DISPLAY command and running remote DECwindows applications, see the VMS DECwindows User's Guide.
Each user must enable TCP/IP access on a host-by-host basis using the DECwindows Session Manager Customize Security menu so they can run applications over the TCP/IP transport.
From that menu, specify:
· TCP/IP as the Transport
· The remote host's Internet host name as the Node
· A question mark (?) for the Username
The DECwindows chapter of the MultiNet User's Guide contains information about running DECwindows applications over MultiNet.
If you have the cluster alias feature configured on more than one node in a VMScluster, the nodes negotiate among themselves so that only one node at a time answers requests to the cluster alias.
If the node serving the cluster alias fails and more than one node has the cluster alias configured, the service provided by the failed node is provided by another node in the cluster. Without the cluster alias feature, the services provided by the failed node are not available.
To use cluster aliasing, you provide a list of addresses to which each node will answer. If the node currently serving the cluster alias fails, one of the other nodes takes over the connectionless services for that address.
This feature lets you specify one or more nodes in the cluster as having an additional IP address, so only one of the nodes will use that additional IP address at any one time.
Enable cluster aliases with the NET-CONFIG SET IP-CLUSTER-ALIASES command. Specify the extra IP addresses for which this node should also answer requests. Disable cluster aliases by invoking the command without addresses. You can change the value of IP-CLUSTER-ALIASES without rebooting by also defining or redefining the system-wide logical name MULTINET_IP_ CLUSTER_ALIASES and restarting the MULTINET_SERVER process.
Since this service is disabled by default, you must enable it in this way:
$ MULTINET
CONFIGURE /SERVER
SERVER-CONFIG>ENABLE CLUSTERALIAS
SERVER-CONFIG>EXIT
Now you can enable cluster failover as shown in the following example:
$ MULTINET
CONFIGURE
MultiNet Network Configuration Utility 5.6(nnn)
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>SET IP-CLUSTER-ALIASES 10.1.1.2
NET-CONFIG>EXIT
[Writing configuration to MULTINET:NETWORK_DEVICES.CONFIGURATION]
[Writing Startup file MULTINET:START_MULTINET.COM]
[Changes take effect after the next VMS reboot]
$ DEFINE /SYSTEM /EXECUTIVE
MULTINET_IP_CLUSTER_ALIASES "10.1.1.2"
$ @MULTINET:START_SERVER
By default, MultiNet is configured to support Pathworks 5.0 running concurrently. To ensure this support is enabled:
1. Verify the presence of the PWIP (Pathworks over IP) device:
$ SHOW DEV PWIP
2. Invoke NET-CONFIG and enter the SHOW command. Check the "Load PWIP (Pathworks) driver:" line.
3. If MultiNet is not configured to load the PWIP driver, enter the SET LOAD-PWIP-DRIVER command.
4. Save the configuration to ensure it is loaded the next time your system reboots.
To enable multicast packet reception under OpenVMS V5.5-2, create a custom SE0_CONFIGURE.COM file that adds the /MULTICAST=ALL qualifier to the MULTINET SET /INTERFACE command line in that command procedure.
Multicast reception is enabled automatically in OpenVMS VAX V6.0 or later and in all versions of OpenVMS Alpha. The file MULTINET_ROOT:[MULTINET.EXAMPLES]SE0_CONFIGURE.COM is a template for such command procedures.
Maximum Transmission Unit (MTU) discovery determines the maximum size of a TCP packet that can be sent through the network between two hosts. Performance improves when the largest, most efficient packet size possible with the hardware at each hop is enabled. RFC-1191 describes this feature, which is enabled by default.
When MTU discovery becomes active for a remote host, it places a host route in the routing table with the MTU set to the appropriate size. This feature is potentially useful for tracing unusual routes.
MTU discovery sets the Don't Fragment (DF) bit in IP packets. It is difficult to predict how routers from different vendors will handle the DF bit; some handle it correctly, some do not, some work until they need to fragment a packet, and some simply drop the packet. If you suspect a routing problem is affecting communications, disable MTU discovery by issuing the following command:
$ MULTINET SET/KERNEL TCP_PMTU 0
To enable it again, issue this command:
$ MULTINET SET/KERNEL TCP_PMTU 1
Both of these commands take effect immediately.
The Address Resolution Protocol (ARP) dynamically maps addresses between Internet and Ethernet. ARP is used by all MultiNet Ethernet interface drivers and HP Computer FDDI drivers.
ARP caches Internet-Ethernet address mappings. When an interface requests a mapping for an address not in the cache, ARP queues the message requiring the mapping and broadcasts an ARP request on the associated network requesting the address mapping.
If a response is provided, the new mapping is cached in the ARP table and any pending messages are transmitted. ARP queues no more than one packet while waiting for a mapping request to be responded to; only the most recently "transmitted" packet is kept.
To enable communications with systems that do not use ARP, the MULTINET SET /ARP utility allows you to add and delete entries in the Internet-to-Ethernet tables.
|
CAUTION: Adding or modifying entries in the ARP table can seriously affect TCP/IP communications. Do not create or modify ARP table entries unless you are sure of their effects on your network.
|
The SET/ARP qualifiers are:
|
Qualifier |
Description |
|
/ADD |
Adds a specified host-to-Ethernet address translation to the ARP tables |
|
/DELETE |
Deletes a specified host-to-Ethernet address translation from the ARP tables |
|
/FLUSH |
Flushes temporary entries in the ARP tables |
|
/PERMANENT |
Used with /ADD or /FLUSH to specify whether an entry is added or flushed permanently |
|
/PROXY |
Used with /ADD to indicate that the translation of the local host's Ethernet address should be published on behalf of another host |
|
/PUBLISH |
Used with /ADD to indicate that the translation to be added is to be published on behalf of another host |
|
/TEMPORARY |
Used with /ADD or /FLUSH to specify whether an entry should be added or flushed temporarily. This is the default. |
The GIF interface allows for the creation of Virtual Private Networks (VPNs) by encapsulating the traffic directed to the interface's remote address to within an additional IP header, creating a virtual network. If the traffic over this interface is subject to IPSEC, then the virtual network is private.
Each GIF interface has four IP addresses that need to be configured:
1. The local address for the interface
2. The remote (point to point peer) address for the interface
3. The gateway address for this side of the tunnel
4. The destination address for the remote side of the tunnel.
The GIF is configured with the following commands on the local system:
$ MULTINET
SET/INTERFACE/CREATE GIFn
$! n is unit number, compile time limited
$ MULTINET SET/INTERFACE GIFn/PROTOCOL=IP/ADDRESS=A.B.C.D
/POINT_TO_POINT=E.F.G.H
$ MULTINET
SET/ROUTE/ADD=(DESTINATION=A.B.C.D,GATEWAY=127.0.0.1)
$ MULTINET
SET/ROUTE/ADD=(DESTINATION=E.F.G.H,GATEWAY=A.B.C.D)
$ MULTINET SET/INTERFACE
GIFn/TUNNEL=(DESTINATION=I.J.K.L, GATEWAY=M.N.O.P)
remote system:
$ MULTINET
SET/INTERFACE/CREATE GIFn
$! n is unit number, compile time limited
$ MULTINET SET/INTERFACE GIFn/PROTOCOL=IP/ADDRESS=E.F.G.H
/POINT_TO_POINT=A.B.C.D
$ MULTINET
SET/ROUTE/ADD=(DESTINATION=E.F.G.H,GATEWAY=127.0.0.1)
$ MULTINET SET/ROUTE/ADD=(DESTINATION=A.B.C.D,GATEWAY=E.F.G.H)
$ MULTINET SET/INTERFACE
GIFn/TUNNEL=(DESTINATION=M.N.O.P, GATEWAY=I.J.K.L)
M.N.O.P is a public IP address (interface) on the local system. I.J.K.L is a public IP address (interface) on the remote system. A.B.C.D is the private network address on the local system. E.F.G.H is the private network address on the remote system. Routing can be set up to pass traffic for other systems through the tunnel. A command procedure could be written to create the tunnel and be used on each side with some minor exchanging of parameters. IPSEC traffic could be statically configured, or managed with the RACOON IPSEC Daemon.
To get rid of the tunnel:
$ MULTINET
SET/INTERFACE/DELETE GIFn !delete tunnel and interface
$ MULTINET SET/ROUTE/DELETE=(DESTINATION=A.B.C.D,
GATEWAY=127.0.0.1)
The VPN encapsulates IPv4 traffic within another IPv4 packet (RFC 1853, RFC 2003).
This VPN is not compatible with Microsoft VPN which uses either PPTP (Microsoft Proprietary) or L2TP/IPSec (RFC 2661).