INTRODUCTION
The new Livingston Enterprises ComOS 3.5.1b17 software prerelease is
now available for the PortMaster 2, 25, 2E, 2ER, 2R, IRX, and Office
Router.
ComOS 3.5.1b17 is NOT available for open beta at this time for the
PortMaster 3.
This Open Beta release is provided at no charge to all Livingston
customers. It has been running at selected sites without problems, so
we are making it available to Livingston customers who would like to
test it in their environment before the full release of ComOS 3.5.1.
Interested customers are invited to upgrade to 3.5.1b17 and report any
problems to Livingston Technical Support. Please mention 3.5.1b17 in
your call. After ComOS 3.5.1 is released, be sure to upgrade from
3.5.1b17 to 3.5.1 promptly.
This release note documents commands and features added between ComOS
release 3.5 and 3.5.1b17.
Note - You must use PMconsole 3.5.3 when upgrading to ComOS 3.5.1b17;
see "Upgrade Instructions" below. If you are running Windows 95 or
Windows NT 4.0 you must use PMconsole for Windows 3.5.1.4. Read
"Memory Requirements" and "Upgrade Instructions" thoroughly before
upgrading.
CONTENTS
Introduction
New Features in ComOS 3.5.1b17
Bugs Fixed in ComOS 3.5.1b17
OSPF and Frame Relay
Multiple Subscriber Network for S/T Interfaces
Memory Requirements
Upgrade Instructions
NEW FEATURES IN ComOS 3.5.1b17
BGP Routing
The PortMaster IRX now supports BGP (Border Gateway Protocol) routing.
For more information on configuring BGP see "Configuring BGP" on
Livingston's web site http://www.livingston.com/ or the upcoming
revision of the "Configuration Guide for PortMaster Products" and
"Command Line Administrator's Guide".
A full BGP routing table for the entire Internet (44,000 routes)
requires seven (7) megabytes of memory, so before using BGP for that
you should upgrade your IRX to 16 megabytes of memory. For more
information on upgrading memory consult the Installation Guide for your
product, or see "Memory Requirements" below.
Route Propagation Control
The PortMaster IRX now has commands to control how routes are
propagated between routing protocols. For more information see
Livingston's web site http://www.livingston.com/ or the upcoming
revision of the "Configuration Guide for PortMaster Products" and
"Command Line Administrator's Guide".
Idle Time special value
In ComOS 3.5, setting an idle time of 1 second on a port times
out the username, password or host prompt in 5 minutes, but imposes
no timeout once the user is logged in. In previous releases an idle
time of 1 minute was used for this purpose, but since many customers
would like to have a real 1 minute idle timeout for ISDN, the special
setting has been changed from 1 minute to 1 second.
Multiple Subscriber Network
ComOS 3.5.1b17 on the PortMaster 2 and PortMaster Office Router with
BRI S/T interfaces now supports the Multiple Subscriber Network (MSN)
ISDN feature used in Europe and Japan to attach multiple ISDN devices
to the same BRI line. For more information on the "set isdn-msn on"
command see "Multiple Subscriber Network for S/T Interfaces" below.
Improved Synchronous Port Performance
Performance improvements have been implemented in the synchronous port
device driver on the PortMaster IRX, PortMaster 2ER, and PortMaster
Office Router. Previously, small gaps between frames on heavily loaded
interfaces running at speeds of 1.544Mb/s or higher caused
aggregate throughput to be slower than the full interface speed. This
has been enhanced to keep single flag spacing between frames to achieve
100 percent line utilization.
Improved Routing
OSPF has been enhanced to support the draft OSPFv2 specification of
'Point-to-Multipoint'. This feature is especially useful over Frame Relay
connections that are not fully meshed. For more information see "OSPF
and Frame Relay" below.
OSPF link state exchanges have been enhanced so that large link state
databases can now be transferred in a few seconds instead of several
minutes. The time required for OSPF to achieve full adjacency with a
neighbor that has more than one thousand routes to give to the
PortMaster has been significantly reduced.
When IPX is enabled on the Ethernet interface the PortMaster will
automatically enable IPX RIP even if RIP is configured off. This
feature allows IPX to be used successfully on networks that are using
only OSPF for IP routing.
Easier-to-manage Frame Relay DLCI lists
The "add dlci" and "delete dlci" commands now work with ports as well as
locations, using the port name in place of the location name.
In addition to the "set S1 dlci Dlci_list" command, you can now add a
DLCI on a synchronous port configured for Frame Relay by using the "add
dlci S1 Dlci [Ipaddress]" command and delete a DLCI with the "delete
dlci S1 Dlci" command. Note that the list of DLCIs used on a port
will always include both those created with "set S1 dlci" command AND
those created with "add dlci s1". To avoid confusion, Livingston
recommends using either one or the other method of setting DLCIs.
For more information see the "DLCI Table Configuration" section in the
"Location Table" chapter of the Command Line Administrator's Guide.
Frame Relay Subinterfaces Increased
ComOS 3.5.1b17 supports Frame Relay subinterfaces on all PortMaster
products, including the PM-2R, PM-2ER, OR-LS, OR-HS, and IRX.
In releases before ComOS 3.5.1b17, these were only supported on the IRX.
In ComOS 3.5.1b17, each Frame Relay port can now have up to 32
subinterfaces. In releases before ComOS 3.5.1b17, a synchronous port
configured for Frame Relay could have one primary subinterface and one
secondary subinterface configured on it, splitting DLCIs between the
two subinterfaces.
There is a limit of 512 total active interfaces, further limited by
available memory.
For more information see the "DLCI Table Configuration" section in the
"Location Table" chapter of the Command Line Administrator's Guide.
Improved Multilink PPP
Enhancements to Multilink PPP negotiation have been implemented to
match the latest proposed standard, improving interoperability with
other vendors.
Simultaneous Multilink PPP (MP) session establishment is now
supported. Previously, if multiple MP connections were being
established for the same end point before the first authentication was
completed, the additional links appeared to be seperate users. This
behavior has been corrected.
Improved Packet Tracing
The "ptrace Filtername extended" command will show each packet that
matches the filter as it enters the PortMaster, and as it leaves the
Portmaster, and the interface used for entry and exit. "ptrace Filtername"
operates the same as earlier releases, and does not show the interface.
ChoiceNet Debugging
You can now enable and disable ChoiceNet debugging with the "set debug
choicenet on|off" command.
Packet Filtering
Packet filters have been enhanced to allow any IP protocol to appear in
the filter rules. This change allows PortMaster filters to permit or deny
packets accordin to their protocol number. A complete list of protocol
numbers appears in RFC 1700, "Assigned Numbers."
You may specify the keyword "protocol" followed by a number, or use the
keywords tcp, udp, esp, ah, or ipip. ipip is protocol type 4, esp is
protocol type 50, ah is protocol type 51.
set filter Filtername RuleNumber permit|deny [Ipaddress/NM
Ipaddress(dest)/NM] protocol Number [log] [notify]
set filter Filtername RuleNumber permit|deny [Ipaddress/NM
Ipaddress(dest)/NM] esp|ah|ipip [log] [notify]
SNMP improvements
Livingston's SNMP Enterprise Management Information Base (MIB) has been
enhanced to deliver the most requested extensions, including showing
which users are currently active. Check the new MIB file on
ftp://ftp.livingston.com/pub/le/snmp/livingston.mib for a complete
listing.
BUGS FIXED IN ComOS 3.5.1b17
Idle timer, Directory, SPID, and OSPF port settings that sometimes had
to be saved twice with "save all" in ComOS 3.5 are now correctly saved
the first time.
Static routes stored in the PortMaster configuration in releases before
ComOS 3.5 are now properly added to the Variable Length Subnet Mask
(VLSM) routing table after upgrading.
The PortMaster no longer reboots when trying to deliver IPX RIP routes
over Frame Relay.
Guaranteed delivery of LMI (Local Management Interface) sequence
exchanges on Frame Relay interfaces now keeps links from terminating
and restarting when loading is heavy.
Static routes are now properly injected into OSPF if RIP route
injection has been disabled. The behavior of the "ospf accept-rip"
command on Ethernet interfaces has been corrected. The intended
behavior of this command has always been to control whether RIP
routes learned on this Ethernet interface were propagated into the OSPF
link state database so that OSPF could advertise these RIP-learned
routes to its OSPF neighbors. However, before release 3.5.1b17, the
command also had the undesirable effect of determining if static routes
whose next hop gateways were reached via this Ethernet interface were
propagated into the OSPF link state database. This release
ensures that static routes are always propagated into
OSPF independent of the setting of the "ospf accept-rip" command.
The Telnet echo bug has been fixed. Now when you use Telnet to log in
to the PortMaster as the administrator, the PortMaster properly echoes
all your keystrokes.
The "attach" command has been fixed to allow access to IDLE ports only.
The "set all host default" command now works correctly.
The PortMaster now guarantees delivery of LCP Echo Replies for systems
that use this mechanism to verify link quality.
SNMP now properly reports interface speeds.
V.25bis dialing now works correctly with the new synchronous device driver.
OSPF AND FRAME RELAY
Frame Relay networks now have three choices for OSPF connectivity in
ComOS 3.5.1b17. The new option is a parameter to the command used to
enable OSPF on a synchronous WAN interface:
set W1 ospf on nbma|point-to-multipoint|wan-as-stub-ptmp
For example:
Command> set s1 ospf on cost 5 hello 10 dead 40 point-to-multipoint
nbma - is used when there is full mesh connectivity, and all OSPF
speakers on the Frame Relay network can communicate with each other. In
these cases, a designated router is elected on the Frame Relay network,
and overall OSPF traffic overhead is reduced. 'nbma' stands for
'non-broadcast, multi-access', a standard term to describe a Frame
Relay network. This is the default setting, and is the only behavior
available in the previous release, ComOS 3.5.
point-to-multipoint - is used when there is partial mesh connectivity,
or when all OSPF speakers on the Frame Relay network cannot communicate
with each other. In these cases, the partial mesh Frame Relay network
is modelled as a series of point-to-point interfaces.
To determine whether to set point-to-multipoint instead of nbma, use
the "show route"and "show ospf links" commands. If the output of "show
route" shows no routes learned over the Frame Relay interface, and
"show ospf links" shows a large number of routes that have been
available for more than one minute, configure the interface for
point-to-multipoint.
wan-as-stub-ptmp - is used when interoperating with routers from other
vendors which implement a variant of point-to-multipoint where the
Frame Relay network is advertised as a stub network in the router link
state advertisement (LSA), instead of as a host route. (The host route
is the IETF draft behavior.)
To determine whether to configure a Frame Relay interface as
point-to-multipoint or wan-as-stub-ptmp, use the "show ospf links"
command to look at the Router LSAs of your neighbors on the Frame Relay
cloud. If the LSAs show stub link entries with the Frame Relay network,
with a netmask that is not 255.255.255.255, configure the interface as
wan-as-stub-ptmp. If the LSAs show single host addresses on the Frame
Relay network with a mask of 255.255.255.255, configure the interface
as point-to-multipoint.
MULTIPLE SUBSCRIBER NETWORK FOR S/T INTERFACES
ComOS 3.5.1b17 on the PortMaster 2 and PortMaster Office Router now
supports the Multiple Subscriber Network (MSN) ISDN feature available
in Europe and Japan.
Background
When a PortMaster receives an ISDN call on a BRI or PRI, it tries to
find a port to accept the call on. The PortMaster builds a list of all
possible ports allocated to that ISDN line interface:
BRI 2 ports
PRI 24 for T1, 30 for E1
The PortMaster attempts to find a port to accept the call on, as
follows:
1. Using the number called, as set in the CalledParty Information
Element (IE), the list of ports associated with that ISDN interface is
traversed. If a match is found with a port Directory Number and the
port can accept a call, the search ends and that port is used to accept
the call.
2. If no match is found in the first pass, the list is again
traversed. This time the first port that can accept the call is selected.
Once a port is found, the call may still be rejected due to unsupported
call type, such as unrestricted digital, voice, etc.
If no port is found to accept the call on, the PortMaster rejects the
call with an appropriate cause code.
MSN
The Multiple Subscriber Network (MSN) feature is available in countries
that use the S/T BRI interface for ISDN. The S/T interface can be
thought of as a bus as opposed to the BRI U interface which is
point-to-point. Multiple ISDN devices (such as a phone, fax, computer
with ISDN card, or PortMaster) may be connected to the S/T bus at the
same time. They all share the D signaling channel and have separate
addresses on it, called Terminal Endpoint Identifiers (TEI). When an
incoming call arrives, its Setup message is broadcast on the D channel
of the S/T bus to all listening devices. Each device on the S/T bus
looks at the call to decide if it is for them.
With MSN the criteria used by a device to decide if the call is
intended for it is:
1. The CalledParty IE matches the device's Directory Number, OR
2. The Called service (from Bearer Capabilities IE) matches my device
type, such as voice, unrestricted data, etc.
If neither criteria is met, the listening device silently ignores the
incoming call. Devices can have the same Directory Number or separate
Directory Numbers as each other.
By default, the PortMaster always tries to accept a call regardless of
the Directory Number set (because of its second pass), and if it can't
accept the call, rejects it. Therefore, when there are multiple
devices on a S/T bus including a PortMaster, the PortMaster always
accepts or rejects all incoming calls, and the other devices can never
receive calls.
To change this behavior, ComOS 3.5.1b17 adds a new global configuration
command called "set isdn-msn on" is available on the PortMaster 2 and
PortMaster Office Router when they have a BRI S/T interface.
set isdn-msn on|off
When set to off, the PortMaster always accepts the call.
When set to on, the PortMaster only accepts the call if the port
Directory Number matches the CalledParty IE. If no port is found that
matches the CalledParty IE, the PortMaster silently ignores the call
(instead of rejecting it), so that other devices on the S/T bus may
accept it. If the Directory Number matches but the call type is not
supported, the call is not rejected, so that other devices of that type
sharing the Directory number may accept the call.
The current MSN setting may be seen by using the "show global"
command. Any change to the ISDN-MSN setting requires a "save all" to
be saved to the nonvolatile configuration memory of the PortMaster.
The change takes affect immediately, no reboot is required.
MEMORY REQUIREMENTS
At least 4 MB of memory is recommended for ComOS 3.5.1b17 on the
PortMaster 2E or 2ER. Some configurations may be able to run in 1 MB
of memory. Future releases will require 4 MB of memory on the
PortMaster 2E and 2ER.
The PortMaster 2, 2R, IRX, and Office Router only require one megabyte
of memory.
A full BGP routing table for the entire Internet (44,000 routes)
requires seven megabytes of memory, so before using BGP for that
you should upgrade your IRX to 16 megabytes of memory.
To expand the memory in a PortMaster 2 or IRX, replace the four 256KB
by 9 (parity) 30-pin 70ns SIMMs with four 1MB SIMMs (providing 4MB of
memory) or four 4MB SIMMs (providing 16MB of memory). Mixing SIMMs is
not supported. The PortMaster will auto-detect the amount of memory at
boot time. You can use either 3 chip or 9 chip SIMMs.
The PortMaster Office Router comes with 1MB of non-upgradable memory.
For more detailed instructions on upgrading memory refer to the
Installation Guide for your product.
UPGRADE INSTRUCTIONS
WARNING! YOU MUST USE PMINSTALL VERSION 3.5.3 OR LATER TO PERFORM THIS
UPGRADE! If you are upgrading using PMconsole for Windows, you must use
PMconsole for Windows version 3.5.1.3 or later.
If you are upgrading from ComOS 2.3 or 2.4 to ComOS 3.5.1b17, you must
first upgrade to ComOS 3.0.4, reboot, and then upgrade to ComOS 3.5.1b17.
If you have any port speeds set to 115200 and upgrade to ComOS
3.5.1b17. and then downgrade to any release before ComOS 3.3.2, you
must set the port speeds again after downgrading.
The upgrade does not affect your stored configuration in the
PortMaster. If you want to back up your PortMaster configuration
before upgrading, choose the Backup PortMaster button in PMconsole for
Windows, or on UNIX enter:
cd /usr/portmaster
./pmreadconf pmname pmpassword data/pmname.conf
chmod 600 data/pmname.conf
The installation software can be retrieved by FTP from
ftp://ftp.livingston.com/pub/le/software/system/tarfile.tar.Z,
replacing system and tarfile.tar.Z with the names of the files. You
can retrieve the upgrade image at the same time. The following example
shows an administrator retrieving the SunOS pminstall and PortMaster 2
upgrade image.
umask 22
mkdir /usr/portmaster
cd /usr/portmaster
ftp ftp.livingston.com
(Enter anonymous)
(Enter your email address; it will not echo.)
binary
cd /pub/le/software/sun4
get pm_3.5.3_sun4.tar.Z pm.tar.Z
cd /pub/le/upgrades
get pm2_3.5.1b17
quit
uncompress pm.tar.Z
tar xvf pm.tar
rm pm.tar
mv pm2_3.5.1b17 data
./pminstall
PMconsole 3.5.1.4 for Windows 95 and Windows NT 4.0 is available on
ftp://ftp.livingston.com/pub/le/software/pc/pmw3514.exe in a
self-extracting file. Transfer that file via FTP, run the file to
install PMconsole for Windows, move the upgrade file into the data
directory, run PMconsole for Windows, and click on the Upgrade icon.
PMconsole for the following operating systems can be found under
ftp://ftp.livingston.com/pub/le/software/
bsdi/pm_3.5.3_BSDOS_2.0.tar.Z BSD/OS 2.0 and 2.1
sgi/pm_3.5.3_IRIX_5.2.tar.Z SGI Irix 5.2
linux/pm_3.5.3_Linux.tar.Z Linux 1.2.13 ELF
rs6000/pm_3.5.3_RS6000_4.1.tar.Z RS6000 AIX 4.1
alpha/pm_3.5.3_alpha_T3.0.tar.Z Digital Alpha OSF/1 T3.0
hp/pm_3.5.3_hp9000_10.01.tar.Z HP 9000 HP/UX 10.01
sun4/pm_3.5.3_sun4.tar.Z SunOS 4.1.4, 5.5.1 on Sparc
sun86/pm_3.5.3_sun86_5.5.tar.Z Solaris x86 2.5.1
pc/pmw3514.exe Windows 95 and Windows NT 4.0
The followin upgrade images are available at
ftp://ftp.livingston.com/pub/le/upgrades/
ComOS Upgrade Image Product
_________ _____________ _____________________________________
3.5.1b17 pm2_3.5.1b17 PortMaster 2, 2E, 2ER, 2R, 2i, 2E-10I
3.5.1b17 pm25_3.5.1b17 PortMaster 25
3.5.1b17R irx_3.5.1Rb14 IRX-111, 112, 114, 211
3.5.1b17L or_3.5.1Lb14 OR-M, U, ST, LS and HS
Copyright and Trademarks
Copyright 1997 Livingston Enterprises, Inc. All rights reserved.
The Livingston logo and the names Livingston, PortMaster, ComOS,
RADIUS, ChoiceNet, PMconsole, IRX, True Digital, and RAMP are
trademarks belonging to Livingston Enterprises, Inc.
All other marks are the property of their respective owners.
Notices
Livingston Enterprises, Inc. makes no representations or warranties
with respect to the contents or use of this manual, and specifically
disclaims any express or implied warranties of merchantability or
fitness for any particular purpose. Further, Livingston Enterprises,
Inc. reserves the right to revise this publication and to make changes
to its content, any time, without obligation to notify any person or
entity of such revisions or changes.
Contacting Livingston Technical Support
Livingston provides technical support via voice, FAX, and electronic
mail. Technical support is available Monday through Friday from 6 a.m.
through 5 p.m. Pacific Time (GMT-8). Please specify that you are
running ComOS 3.5.1b17 if you are reporting problems with this open
beta release.
To contact Livingston Technical Support by voice, dial 1-800-458-9966
within the US or 1-510-737-2100 outside the US; by FAX, dial
1-510-737-2110; by electronic mail, send mail to
support@livingston.com; and through the World Wide Web, access
http://www.livingston.com/.