ComOS 4.1b15 Open Beta Release Note 1999/03/25 Introduction The new Lucent Technologies ComOS(R) 4.1b15 software release is now available for open beta for the PortMaster(R) 4 Integrated Access Server. This release note applies only to the PortMaster 4. This open beta release is provided at no charge to all Lucent customers. This open beta release is recommended only for customers who wish to test the new functionality before the release of ComOS 4.1. This release note documents commands and features added between ComOS 4.0 and ComOS 4.1b15 on the PortMaster 4. Command syntax for new commands may change between this open beta release and the general availability (GA) release of ComOS 4.1. Before upgrading, thoroughly read "Limitations" and "Upgrade Instructions." Contents Introduction Bugs Fixed in ComOS 4.1b15 Bugs Fixed in ComOS 4.1b14 New Features T3 Mux Board Dual and Single Ethernet Boards Non-Facility Associated Signaling (NFAS) RIP Version 2 Enhanced OSPF Area Range Signaling System 7 Inter Machine Trunk (SS7 IMT) Layer Two Tunneling Protocol (L2TP) L2TP Network Server (LNS) Board Named IP Address Pools Crossbar IP NAS Port Details Multilink Accounting Session ID Unique Accounting Session ID Local IP Interface IGMP Proxy IPX Support Modem Enhancements Call-Check on MFR2 MFR2 for Saudi Arabia Temperature Threshold Setting "show bootlog" Command "set Line0 off" Command "show isdn" and "reset D0" Commands "set M0 off" Command New Board Identifiers Enhanced "show" Commands "set chassis-type" Command New SNMP Trap Information Enhanced PMVision support Configuring the T3 Mux and Quad T1 Boards Configuring NFAS Configuring RIP-2 Configuring SS7 IMT Configuring L2TP Configuring Named IP Pools Configuring Crossbar IP Limitations Upgrade Instructions Technical Support Bugs Fixed in ComOS 4.1b15 The following bugs are fixed in ComOS 4.1b15. Multiple Dial-In Fixed In ComOS 4.1b14, PPP dial-in users sometimes had to dial in multiple times before obtaining a successful connection. This problem is fixed in ComOS 4.1b15. Ether00 Conflict with Ether0 ComOS 4.1b14 could not distinguish the Ether00 interface created by a single Ethernet board inserted into slot 0 from an Ether0 interface. As a result, any configuration changes made to Ether00 were applied to Ether0. This is fixed in ComOS 4.1b15. Bugs Fixed in ComOS 4.1b14 The following bugs are fixed in ComOS 4.1b14 and ComOS 4.1b15. Improved Modem Support The same modem improvements made in ComOS 4.0.3 are also included in ComOS 4.1b15. * A timing problem with V.32 modems is fixed. * A rate renegotiation and retrain issue with U.S. Robotics (USR) V.90 modems is fixed. * A disconnect problem that occurred when V.90 falls back to V.34 is fixed. * A timing problem with LT WinModems is fixed. * A USR V.90 "No Connect" problem is fixed. * A latency problem is fixed, improving ping times and reducing game latency. * A V.34 renegotiation issue is fixed (including the upstream part of V.90 and K56flex). * An A-law rate renegotiation problem is fixed. * The LAPM retransmitter in V.90 is improved. European PRI Net5 Layer 2 Bug Fixed The Net5 Layer 2 bug fixed in ComOS 4.0.3 is also fixed in ComOS 4.1b15. When using the Net5 ISDN switch type, the PortMaster 4 now attempts to activate Layer 2 if it is inactive during a dial-out attempt or when an inbound call arrives. In ComOS 4.0, if a Net5 ISDN switch initiated a Layer 2 inactive state, the PortMaster 4 did not activate Layer 2 again before attempting an outbound call, and the call failed. Likewise, if Layer 2 was down and an inbound call arrived, the PortMaster 4 did not activate Layer 2 and did not answer the call. "show sessions" Output Corrected In a previous release the "show sessions" command sometimes incorrectly displayed the start or idle timer as 99 days. This problem is fixed. RADIUS User-Password fixed The RADIUS User-Password sent in an access-request packet is no longer corrupted. Corrected E1 Numbering Fractional E1 channel numbering is now correct. Station ID and Rate in L2TP Corrected The Calling-Station-Id, Called-Station-ID, and baud rate values are now forwarded properly from a Layer 2 Tunneling Protocol (L2TP) access concentrator (LAC) to an L2TP network server (LNS). New Features in ComOS 4.1b15 The following commands and features have been added in ComOS 4.1b15. T3 Mux Board ComOS 4.1b15 supports the T3 Mux board (PM4-T3-MUX, Channelized T3 Multiplexer Board). The T3 Mux board demultiplexes DS-3 signals into 28 individual DS-1 signals and terminates them at the framers of the Quad T1 board. Seven Quad T1 boards are needed to terminate an entire DS-3 line. See the section titled "Configuring the T3 Mux and Quad T1 Boards" for configuration information. Dual and Single Ethernet Board The Dual Ethernet board (PM4-100E-2P, Dual 10/100 Ethernet Board) provides an additional two 10/100Mbps Ethernet interfaces. The Dual Ethernet board must be inserted into slot 3. The configuration is the same as for ether0 or ether1 and supports the same routing protocols. Interface numbering for the Dual Ethernet board is Ether30 and Ether31. The Single Ethernet board (PM4-100E-1P, Single 10/100 Ethernet Board) provides an additional 10/100Mbps Ethernet interface. It can be inserted into any available slot except slot 4, which is reserved for the primary system manager module (SMM). Interface numbering is as follows: ether00 Single Ethernet board in slot 0 ether10 Single Ethernet board in slot 1 ether20 Single Ethernet board in slot 2 ether30 Single/Dual Ethernet board in slot 3 ether31 Dual Ethernet board in slot 3 ether50 Single Ethernet board in slot 5 ether60 Single Ethernet board in slot 6 ether70 Single Ethernet board in slot 7 ether80 Single Ethernet board in slot 8 ether90 Single Ethernet board in slot 9 Non-Facility Associated Signaling (NFAS) Non-facility associated signaling (NFAS) is a service offered by telephone companies that permits a single D channel to provide the signaling for a group of PRIs. This service allows the channel that is normally used for signaling on the remaining PRIs to be used as a B channel. Because combining the signaling onto a single D channel increases the consequences if communication with that channel fails, some telephone companies use the D channel backup (DCBU) system. DCBU requires two D channels per NFAS group, one as a primary and one as a secondary. The Lucent ComOS implementation of NFAS supports both standard NFAS and NFAS with DCBU across up to 20 PRIs. See the section titled "Configuring NFAS" for NFAS configuration information. RIP Version 2 ComOS 4.1b15 adds support for RIP version 2 (RIP-2). RIP-2 adds netmasks, next-hop information, and authentication to RIP. While OSPF is often a better choice of routing protocol, some environments prefer RIP-2. See the section titled "Configuring RIP-2" for RIP-2 configuration information. Enhanced OSPF Area Range OSPF areas now support 16 OSPF range entries. Signaling System 7 Inter Machine Trunk (SS7 IMT) ComOS 4.1b15 on the PortMaster 4 can communicate with a signaling system 7 (SS7) signaling gateway through Q.931+ protocol to receive calls over an inter machine trunk (IMT). See the section titled "Configuring SS7 IMT" for SS7 IMT configuration information. Layer Two Tunneling Protocol (L2TP) ComOS 4.1b15 on the PortMaster 4 supports Layer 2 Tunneling Protocol (L2TP) as both an L2TP access concentrator (LAC) and an L2TP network server (LNS). A PortMaster 4 can support up to 100 tunnels. A Quad T1 board supports up to 94 L2TP sessions when configured as a LNS. Note that the number of L2TP tunnels is for the entire PortMaster 4, while the number of L2TP sessions is for each board. Multiple sessions can be sent through a single tunnel. See the section titled "Configuring L2TP" for L2TP configuration information. L2TP Network Server Board The PortMaster 4 now supports the LNS board (PM4-LNS, L2TP Network Server Board). The LNS board terminates up to 500 concurrent L2TP sessions over multiple L2TP tunnels. Up to nine LNS boards can be used in a PortMaster 4 chassis. The LNS board can be used in any slot except for slot 4 (which is reserved for the SMM). The LNS board is similar to a Quad T1 or Tri E1 board but has no modems or line ports. The LNS board is connected to the network by the backplane of the PortMaster 4 chassis. See the section titled "Configuring L2TP" for L2TP configuration information. Named IP Address Pools The IP pool table allows for multiple dynamically assigned address pools within the PortMaster. Each entry in the IP pool table contains a name, a starting base IP address with a subnet mask, and a crossbar IP. A RADIUS access-accept packet can indicate to the PortMaster which IP pool to assign a user's address from. See the section titled "Configuring Named IP Pools" for configuration information. Crossbar IP Crossbar IP is a per-interface-directed gateway. Instead of comparing the IP packet's destination address to the routing table for traffic coming in on an interface, the PortMaster 4 instead looks up the configured crossbar IP address in the routing table and sends the packet to that next hop. This affects the packet's routing to the next hop only. Crossbar IP can come from a user profile or from the IP pool table. When both are used, the crossbar IP setting in the user profile takes precedence over the gateway in the IP pool table. Crossbar IP can also be configured on Ethernet ports, network hardwired ports, dial-out locations, the local user table, and in RADIUS. See the section titled "Configuring Crossbar IP" for configuration information. Local IP Interface The PortMaster 4 now supports up to 4 internal routable IP addresses. When a local IP address is configured this becomes the PortMaster 4's global address used by all network handles such as RADIUS, DNS, SNMP, IMT, and BOOTP. These IP addresses are host-based, with no configuration options other than the address itself. The "ifconfig" command displays the logical interface(s) when local IP addresses are configured. The interface names are local1, local2, local3, and local4. Use the following command to globally assign to the PortMaster 4 IP addresses that are not limited by network interface. set local-ip-address [1|2|3|4] Ipaddress 1|2|3|4 Up to four local IP addresses can be set on the PortMaster. The default is 1. Ipaddress IP address or hostname of up to 39 characters used by the PortMaster to identify itself. Set the IP address to 0.0.0.0 to clear the setting. The local IP address feature has two main purposes. First, the PortMaster can advertise its local IP addresses as host routes through configured routing protocols. In this way, PortMaster services can be referenced to a particular IP address and are not dependent on any one network interface. The second use for local IP addresses is to determine how the PortMaster identifies itself. IPCP Negotiation. During PPP negotiations for the IP Control Protocol (IPCP), the PortMaster 4 identifies itself with an address chosen in the following order: The local IP address configured in the user profile, if set. The global reported IP address, if set. The first global local IP address, if set. The second global local IP address, if set. The third global local IP address, if set. The fourth global local IP address, if set. The IP address of Ether1, if set. The IP address of Ether0. Main IP Address. When the PortMaster creates an IP packet, it must identify itself by placing a source address in the IP header. To do so, the PortMaster chooses either the main IP address or the nearest IP address, depending on the service used. The main IP address is chosen in the following order: The first global local IP address, if set. The second global local IP address, if set. The third global local IP address, if set. The fourth global local IP address, if set. The IP address of Ether1, if set. The IP address of Ether0. The following services use the main IP address: * syslog * traceroute * telnet * DNS * RADIUS authentication and accounting * ChoiceNet The nearest IP address is the IP address of the interface on which the packet exits the PortMaster. The following services use the nearest IP address: * ping * OSPF * RIP * rlogin * L2TP The global local IP address settings can be displayed with the "show global" and "show routes" commands. Example: Command> set local-ip-address 10.112.34.17 Local IP Address (1) changed from 0.0.0.0 to 10.112.34.17 Command> set local-ip-address 2 192.168.54.6 Local IP Address (2) changed from 0.0.0.0 to 192.168.54.6 NAS Port Details The value reported by the PortMaster 4 for NAS-Port in RADIUS accounting-request packets has been enhanced to encode the slot number (0-9), line number (0-31, although only 0-3 are used now), and channel number (0-31). The NAS-Port Number Format in network byte order is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel | Line | Slot | All zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So channel 4 of line 1 in slot 2 is, for example, NAS-Port = 2084 (4 + 1 * 32 + 2 * 1024). Multilink Accounting Session ID The PortMaster 4 now sends the Acct-Multi-Session-Id in RADIUS accounting-request packets using attribute 50 as described in RFC 2139. The Acct-Multi-Session-Id associates all the sessions comprising a multilink connection. The PortMaster uses the Acct-Session-Id of the first connection as the Acct-Multi-Session-Id for all connections in the multilink session. Add the following line to your RADIUS dictionary file, then stop and restart your RADIUS server. ATTRIBUTE Acct-Multi-Session-Id 50 string Unique Accounting Session ID The Acct-Session-ID that the PortMaster 4 sends in a RADIUS Accounting-Request packet now includes the slot number of the board where the session is running. The first two hexadecimal digits are incremented on each reboot. The next hexadecimal digit is the number of the slot the board is in, and the final five hexadecimal digits are incremented for each user login on that board. NOTE! The encoding of the Acct-Session-ID is subject to change in future releases and RADIUS server implementers should minimize dependence on the format of the Acct-Session-ID and treate it only as a string to be used when matching accounting start and stop records. In particular, the length of the string is likely to be increased in a future release, and the practice of converting the 8 hexadecimal digits into a 32-bit integer is strongly discouraged. IPX IPX was not supported on the PortMaster 4 in ComOS 4.0 and ComOS 4.0.3, but is now supported in ComOS 4.1b15. Modem Enhancements Modem performance under high load is improved through enhancements to the modem driver software. Call-Check on MFR2 Call-check is now supported with MFR2 signaling. Refer to the "PortMaster 4 Configuration Guide" for complete line configuration details. MFR2 for Saudi Arabia MFR2 profile 0 is now supported in Saudi Arabia. Refer to the "PortMaster 4 Configuration Guide" for complete line configuration details. Profile 0 is the ITU-T standard. ITU Reference: - Q.422 Standard R2 signaling - Q.441 & Q.442 Multifrequency (MFR2) IGMP Proxy The PortMaster 4 supports Internet Management Group Protocol version 2 (IGMP) multicast proxy as described in RFC 2236. The PortMaster 4 looks like a multicast router to clients and like a multicast host to routers. To enable multicast IGMP, configure either Ether0 or Ether1 to have multicast proxy enabled. The Single and Dual Ethernet boards do not support multicast proxy in this release. The following command starts the Ethernet interface listening for IGMP traffic. It also sends out an IGMP member report for the ALL_SYSTEM group. set Ether0 mproxy on Users enable multicast by setting the RADIUS vendor-specific attribute LE-Multicast-Client to 1. Add the following two lines to your RADIUS 2.1 server dictionary file: ATTRIBUTE LE-Multicast-Client 23 integer Livingston VALUE LE-Multicast-Client On 1 When the PortMaster 4 creates the interface for this user, the PortMaster 4 turns multicast on for that interface, and sends an IGMP member report for the ALL_SYSTEM group. When the user joins a group, the rest is handled by the IGMP protocol. The following command displays current dynamic multicast groups, including local and dial-in client group members. This is a dynamic group table only. Static groups cannot be added. show igmp Command 1> show igmp Multicast Source: ether1 Group: 224.0.0.1 ether1 Group: 224.0.0.99 ether1 IGMP Multicast Heartbeat: You can monitor IGMP multicast traffic from a heartbeat group of multicast routers. To do so, you set time slots during which a multicast-enabled host must receive multicast traffic for the heartbeat group. You can establish five time slots of 120 seconds each, for example, and set the minimum number of time slots that must receive traffic to three. The PortMaster 4 then keeps track of multicast messages from the heartbeat group by checking five time slots every 120 seconds. If the number of time slots receiving a heartbeat is less than three out of five, the PortMaster 4 sends an SNMP trap to indicate a problem with multicast traffic. Example: set ether1 mproxy addr 224.0.0.99 # Multicast heartbeat group. set ether1 mproxy port 2000 # Port number to listen. set ether1 mproxy src-add 192.168.20.1 # Source of heartbeat. set ether1 mproxy src-netmask 255.255.255.255 # Netmask for source. set ether1 mproxy slot 120 # Length of each time # slot (0 to 120) set ether1 mproxy num 5 # Number of time slots # (1 to 6) set ether1 mproxy timeout 360 # Timeout for IGMP clients # (60 to 600 seconds) set ether1 mproxy alarm 3 # Minimum number of slots # to receive heartbeat # (1 to 6) Example: Command> show alarms Alarm Id Age Severity Alarm Message -------- ------ --------- ------------------------------------------ 6263196* 16:10 0 No Multicast Heart beat 224.0.0.99 Temperature Threshold Setting The following command sets the temperature (in degrees Celsius) above which the SMM starts to turn off boards. The "show global" command displays the current temperature threshold setting. set shutdown Temperature Temperature A temperature in degrees Celsius. Example: Command> set shutdown 60 Setting Shutdown Temperature to 60C Command> show global Shutdown Temp: 60C / 140F "show bootlog" Command Reboots and stack traces on the system manager module and line boards are now saved to a boot log file. ComOS reserves an area in memory for storing stack traces and the last process ID. When a board reboots, ComOS checks for information in the reserved area and sends it to the console and the boot log. If power to the board is lost, memory is reset and the information in the reserved area is not logged. The boot log is stored in the nonvolatile RAM file system in a file named "bootlog", a circular buffer up to 64KB in length. You can display the boot log with the "show bootlog" command. Each entry in the boot log contains the following information: * Time stamp: Time elapsed since the board was last rebooted. * Slot: Slot in which the reboot occurred. * Description: Indicates if the unit was turned on, soft booted, or crashed. - For soft boots and crashes, the last process to run before the crash is identified. - For crashes the stack trace is displayed. The boot log can be erased with the "erase file bootlog" command. If a board crashes, provide the stack trace to Lucent for analysis. Example: Command> show bootlog [000:00:00:00:25] Slot4 - Power On [000:00:00:42:65] Slot3 - Power On [000:00:00:00:25] Slot4 - Soft Boot - Last Process 0x138b30 [000:00:00:42:65] Slot3 - Power On [000:04:26:49:10] Slot3 - Crash Boot - Last Proc 0x158264 - Trace: 1bb727 (8 202 32a6ac 22c068) 1414aa (1 0 626 0) 134787 (32c5a4 32a6ac 22c068 1fb830) 118371 (32c5a4 2052e822 0 0) 117e12 (32c5a4 1db070 330fa4 2052e822) 14f5b4 (330fa4 1db070 228 800) 14d2c2 (1db070 228 1063 2c00) 158351 (2422f0 40 ffff000 1) 1bdb51 (1f4 10cdb7 0 0) 10cded (0 0 0 0) "set Line0 off" Command The following command allows the administrator to "busy out" a T1 or E1 line by turning off the transmitter. The result is a yellow alarm, which causes the switch to advance to the next line in the hunt group if configured. The "show Line0" command shows the status of a disabled port as ADMIN. The "show isdn" command never shows a disabled line as ACTIVE. The result of "set Line0 off" is not saved by "save all." set Line0 on | off Line0 line0, line1, line2, or line3. on Enables the transmitter on the specified line. off Disables the transmitter on the specified line. "show isdn" and "reset D0" Commands The "show isdn" command displays the current status of the D channels and their associated B channels on a Quad T1 or Tri E1 board. Set the view to the slot containing the board. show isdn Example: Command> set view 0 View changed from 4 to 0 Command 0> show isdn D Ports State L1 L2 Change init Up Down -- ------- ------------- ------- ----- ----- ----- 0 S0-S22 UP Active 2 3 3 0 1 S24-S46 UP Active 0 2 2 0 2 S48-S70 UP Active 0 2 2 0 3 S72-S94 UP Active 0 2 2 0 The following command resets individual D channels for troubleshooting purposes. Set the view to the slot containing the Quad T1 or Tri E1 board. reset D0 D0 d0, d1, d2 or d3. Example: Command> set view 0 View changed from 4 to 0 Command 0> reset d0 Send reset (9) Board ISDN channel D0 RESET "set M0 off" Command The following command disables and enables modems for troubleshooting and maintenance. This command was not found in ComOS 4.0 and ComOS 4.0.3 for the PortMaster 4. set M0 on | off M0 A modem from m0 to m95. Example: Command> set m0 off Modem M0 changed from on to off Command> show modems Mdm Port Status Speed Compression Protocol Calls Retrain Disconnect --- ---- ------ ----- ----------- -------- ------ ------- ------------ M0 ADMIN UNKNWN NONE NONE 0 0 NORMAL M1 READY UNKNWN NONE NONE 0 0 NORMAL M0 now displays "ADMIN" under the "Status" column. Command> set m0 on Modem M0 changed from off to on New Board Identifiers The "show slots" and "show boards" commands show new board identifiers for the Single and Dual Ethernet boards. Enhanced "show" Commands The "show sessions", "show all", and "show modems" commands have been enhanced to search on a specified string. If entered from the manager view, these commands show output, by board, for any output that matches the specified string. If the command is entered from a particular slot view, only output for the board in that slot is shown. show sessions [ String ] show all [ String ] show modems [ String ] "set chassis-type" Command The following command determines how PMVision(TM) displays the PortMaster 4: set chassis-type pm4 | msm pm4 Normal PortMaster 4 operating mode. msm Set if within a 5ESS switch. The "show global" command displays the chassis type only when it is set to msm, because pm4 is the default. New SNMP Trap Information The PortMaster now sends an SNMP "coldstart" trap if the SMM reboots. Example: Command> show alarms Alarm Id Age Severity Alarm Message -------- ------ --------- ------------------------------------------ 3657108 40 99 ColdStart Host: 192.168.9.214 Enhanced PMVision support Additional support has been added to ComOS 4.1b15 to allow PMVision to monitor and configure PortMaster 4 features. See the upcoming PMVision 1.4 release notes for details. Configuring the T3 Mux and Quad T1 Boards ComOS 4.1b15 supports the T3 Mux board (PM4-T3-MUX, "Channelized T3 Multiplexer Board"). The T3 Mux board demultiplexes DS-3 signals into 28 individual DS-1 signals and terminates them at the framers of the Quad T1 board. Seven Quad T1 boards are needed to terminate an entire DS-3 line. The T3 Mux board supports the M13 framing format and converts bipolar 3-zero substitution (B3ZS) line encoding to nonreturn to zero (NRZ) digital DS-3 signaling. The T3 Mux board can receive clock externally at a rate of 44.736Mbps. DS-1 clocking rate is 1.544Mbps. The T3 Mux board does not provide internal clocking in this release of ComOS. WARNING! Do not remove the T3 Mux board while it is powered on. Doing so might cause the system manager module ATM matrix to suspend operation, requiring you to reboot the PortMaster 4 to restore operation. Before removing the T3 Mux board, use the "set Slot0 off" command to turn off power to the board. Replace "Slot0" with the number of the slot in which the board is installed. T3 Mux Installation The T3 Mux board can insert into any slot except slot 4 which is reserved for the primary manager module. CAUTION - Lucent Technologies recommends the use of a grounding strap to prevent electrostatic discharge. When the PortMaster 4 is powered on, the system manager module (SMM) boots first, then the T3 Mux board followed by the Quad T1 board(s). Internal DS-3 and DS-1 clocking are not supported in this release; external clocking is required. New Quad T1 Board Commands set Line0 source local | Slotnumber:Channel * set Line0 source local This command configures the line for external DS-1 termination via the RJ-45 connector located on the front of the Quad T1 board. Command 7> set line0 source local line0 source set to local Command 7> show line0 ---------------------- line0 - T1 Primary Rate ISDN --------------- Status: UP Framing: ESF Encoding: B8ZS PCM: u-law Receive Level: +2dB to -7.5dB Clock Source: External NFAS Not Configured Alarms Violations ----------------------------- ----------------------------- Blue 0 Bipolar 0 Yellow 0 CRC Errors 0 Receive Carrier Loss 0 Multiframe Sync 0 Loss of Sync 0 The following command configures the line for internal DS-1 termination, disabling the Quad T1 board's physical RJ-45 connector for the DS-1 specified. * set Line0 source Slotnumber:Channel Line0 line0, line1, line2, or line3 Slotnumber 0 to 9 (but never 4), for the physical location of the T3 Mux board within the PortMaster 4 chassis. Channel 1 to 28, for the DS-1 channel from the T3 Mux to be assigned to this line. Command 7> set line1 source 8:26 line1 source set to T3 stream 26 in slot 8 * set Line0 clock backplane | external | internal This command determines the clock source for each DS-1. Line0 line0, line1, line2, or line3. Backplane Clocking derived from the T3 Mux board. External External clocking source needed. Internal Clocking supplied by the Quad T1 board's internal clock source. (Not supported in this release.) Quad T1 clocking defaults to backplane clocking when a DS-1 is configured for source from a T3 Mux board channel. Internal DS-3 and DS-1 clocking are not supported in this release; external clocking is required. Do not configure internal clocking for any DS-1 line on a Quad T1 board that already has one or more active DS-1 lines configured to receive their clocking from an external source or the backplane. Example: In the following example, the T3 Mux board is in physical slot 8, with its 25th DS-1 assigned to the first line on slot 7's Quad T1 board. Clocking is derived from the T3 Mux board (which must get it from the telephone company). Command 4> set view 7 View changed from 4 to 7 Command 7> set line0 clock backplane line0 clocking changed to backplane Command 7> set line0 source 8:25 line0 source set to T3 stream 25 in slot 8 Command 7> show line0 ---------------------- line0 - T1 Primary Rate ISDN --------------- Status: UP Framing: ESF Encoding: B8ZS PCM: u-law Data Source: T3 slot 8 channel 25 Clock Source: Backplane NFAS Not Configured Alarms Violations ----------------------------- ----------------------------- Blue 0 Bipolar 0 Yellow 1 CRC Errors 0 Receive Carrier Loss 0 Multiframe Sync 0 Loss of Sync 0 T3 Mux Board Commands The following commands configure the T3 Mux board: set mux backplane-clock disable | enable. set mux channel-loop Channel on | auto | off. set mux line-clock external | internal. set mux line-loop on | off. * set mux backplane-clock disable | enable. disable Disables backplane clocking as supplied from the T3 Mux board. enable Enables backplane clocking, clocking source is the T3 Mux board. * set mux channel-loop Channel on | auto | off. Channel Number from 1 to 28. on Manually enables DS-1 loopback. auto DS-1 enters or exits loopback mode if a loop-up or loop-down sequence is detected from an external source such as the telephone company. This is the default. off Disables DS-1 loopback. The DS-1 ignores external loop-up or loop-down commands. * set mux line-clock external | internal. external T3 Mux, DS-3 line uses an external 44.736Mbps clocking source. internal T3 Mux internally generates a 44.736Mbps clocking source. (Not supported in this release.) Internal DS-3 and DS-1 clocking are not supported in this release; external clocking is required. * set mux line-loop on | off. on Manually enables DS-3 line loopback. off Disables DS-3 loopback. Ignores external loop-up or loop-down commands. "show mux" Command: Command 8> show mux MUX Line Status: Up Line Clock: External Backplane Clock: Enabled Mux Line Line Line Channel Slot Line Status Type Sync Loss X-Connect ------- ---- ---- -------- ------ --------- --------- 1 7 0 Up Inband 0 Ok 2 7 1 Up Inband 0 Ok 3 7 2 Up Inband 0 Ok 4 7 3 Up Inband 0 Ok 5 1 0 Up Inband 0 Ok 6 1 1 Up Inband 0 Ok 7 1 2 Up Inband 0 Ok 8 1 3 Up Inband 0 Ok 9 2 0 Up Inband 0 Ok 10 2 1 Up Inband 0 Ok 11 2 2 Up Inband 0 Ok 12 2 3 Up Inband 0 Ok 13 3 0 Up Inband 0 Ok 14 3 1 Up Inband 0 Ok 15 3 2 Up Inband 0 Ok 16 3 3 Up Inband 0 Ok 17 5 0 Up Inband 0 Ok 18 5 1 Up Inband 0 Ok 19 5 2 Up Inband 0 Ok 20 5 3 Up Inband 0 Ok 21 6 0 Up Inband 0 Ok 22 6 1 Up Inband 0 Ok 23 6 2 Up Inband 0 Ok 24 6 3 Up Inband 0 Ok 25 0 0 Up ISDN 0 Ok 26 0 1 Up ISDN 0 Ok 27 0 2 Up ISDN 0 Ok 28 0 3 Up ISDN 0 Ok The "show mux" command displays the following information: * Mux Channel - DS-1 display, channels 1 through 28. * Slot - The physical slot of the Quad T1 board this DS-1 is going to. * Line - The line (0 to 3) on the Quad T1 board that this DS-1 is going to. * Line Status - Up Active T1 line. - DOWN Inactive T1 line. - Carrier T3 Mux board detects the signal for the channel. The Quad T1 board might be turned off or not in the chassis. - No Signal No signal detected for the channel. - Alarm An alarm condition detected for the channel. * Line Type - Inband Line configuration is Channelized T1 with robbed bit signaling. - ISDN Line configuration is ISDN Primary Rate Interface (PRI). * Line Sync Loss - This is an incremental counter that records the number of times synchronization was lost for the specified channel. * X-Connect displays the internal T3 Mux to Quad T1 board connection status: - Ok ATM connection made and channels assigned. - Connected ATM connection made, no channels assigned. - Connecting ATM connection is in the process of being made. - T3 Not Ready T3 Mux board is not up and running yet. - T1 Not Ready Quad T1 board is not up and running yet. - n/a Quad T1 board is turned off or absent. "show mux status" Command: Command 8> show mux status -------------------- Statistics for Mux0 in slot0 --------------------- Rx Loss of Signal: 0 Rx Out of Frame: 0 Rx AIS alarm: 0 Rx IDLE Pattern: 0 Rx Clock Failure: 0 Tx Clock Failure: 0 F&M Bit Errors: 0 M Bit Errors: 0 Parity Errors: 0 * Rx Loss of Signal A receive loss-of-signal (LOS) alarm occurs when the incoming DS-3 data is stuck low for more than 1022 clock cycles. Recovery occurs when two or more ones are detected in the incoming data bit stream. * Rx AIS alarm Detection mechanism to ensure that the M13E is detecting DS-3 framing. * Rx Clock Failure A receive DS-3 clock failure alarm occurs when the receive clock is stuck high or low for from 30 to 100 DS-3 clock periods. Recovery occurs on the first clock transition. * F&M Bit Errors An 8-bit saturation counter that counts the number of DS-3 F-bits and DS-3 M-bits that are in error since the last read cycle. This counter is not incremented during DS-3 loss-of-signal or out-of-frame errors. * Parity Errors This counter counts the number of P-bit parity errors received since the last read cycle. This counter is not incremented during DS-3 loss-of-signal or out-of-frame errors. * Rx Out of Frame A receive out-of-frame (OOF) alarm occurs when three out of 16 F-bits are in error in a sliding window of 16 bits, or one or more M-bits are in error in two consecutive frames. Recovery occurs when the F framing pattern of 1001 is detected and the M framing pattern of 010 is detected for two consecutive frames. Recovery takes approximately 0.95 milliseconds. * Rx IDLE Pattern This error occurs if the M13E detects 6 or more 4-bit groups with errors of the 1100 pattern per DS-3 frame. The M13E exits the RX idle pattern state. A DS-3 idle signal as defined in ANSI T1.107a-1990 is being received by the M13E device if this bit and bits 1 and 0 of this register are all set to 1. * Tx Clock Failure A transmit DS-3 clock failure alarm occurs when the transmit input clock is stuck high or low for from 30 to 100 DS-3 clock periods. Recovery occurs when the first clock transition is detected. * M Bit Errors An 8-bit saturation counter that counts the number of M-bits in error since the last read cycle. The counter is not incremented when DS-3 loss-of-signal or out-of-frame errors occur. T3 Specifications * Receiver Specifications: - Interface Cable: AT&T 728A or 734A coaxial - RX Connector: External BNC - DS-3 Clocking rates: 44.736Mbits/s +/- 20 ppm - Input Signal Amplitude: 100 millivolts peak to peak (mVp) to 950mVp AC (differential input) - Input Return Loss: >26dB at 22.368MHz with an external 75 ohm resistor - Input Resistance: >5000 ohms - Cable Length 0 to 900 feet (0 to 274 meters), adaptive equalization. * Transmitter Specifications: - TX Connector: External BNC - Cable Length: 50 - 450 feet Configuring NFAS Non-facility associated signaling (NFAS) is a service offered by telephone companies that permits a single D channel to provide the signaling for a group of PRIs. This service allows the channel that is normally used for signaling on the remaining PRIs to be used as a B channel. Because combining the signaling onto a single D channel increases the consequences if communication with that channel fails, some telephone companies use the D channel backup (DCBU) system. DCBU requires two D channels per NFAS group, one as a primary and one as a secondary. Upon failure of the primary channel, the secondary channel switches roles and takes the signaling responsibility for the group. When the failed primary channel returns to service, it becomes a backup for the secondary. The Lucent ComOS implementation of NFAS supports both standard NFAS and NFAS with DCBU across up to 20 PRIs. Configuration You must set the view to enter the NFAS configuration into the Quad T1 board. To configure a line for NFAS operation, use the following command: set Line0 nfas Mode Identifier Group Line0 line0, line1, line2, or line3. Mode: primary This PRI contains the primary D channel. secondary This PRI contains the secondary D channel. slave This PRI contains no D channel. disabled Clear this PRI's NFAS configuration. Identifier Number between 0 and 19 that is unique among all PRI interfaces in the same NFAS group. Group Number between 1 and 99 identifying which NFAS group this PRI belongs to. The following example is for a single PortMaster 4 with two NFAS groups, one with DCBU and one without. Each group contains two Quad T1 boards. Use the following commands to configure the PortMaster 4: NFAS bundle #1 (with DCBU) Slot0 (Line0 contains the primary D channel. Line1, line 2, and line3 are slave lines): set view 0 set line0 nfas primary 0 1 set line1 nfas slave 1 1 set line2 nfas slave 2 1 set line3 nfas slave 3 1 save all reset slot0 Slot1 (Line0 is a slave line, and line1 contains the secondary D channel): set view 1 set line0 nfas slave 4 1 set line1 nfas secondary 5 1 save all reset slot1 NFAS bundle #2 (without DCBU) Slot3 (Line0 contains the primary D channel, and line1 is a slave line): set view 3 set line0 nfas primary 0 2 set line1 nfas slave 1 2 save all reset slot3 Slot6 (Line0 and line1 are slave lines): set view 6 set line0 nfas slave 2 2 set line1 nfas slave 3 2 save all reset slot6 Displaying General Information Several commands are available to display statistics and information specific to NFAS operation. Set the view to the appropriate slot before using these commands. show nfas The "show nfas" command displays Quad T1 boards in the same NFAS group as this slot and shows in-service D channel information and slave status. Displaying Debugging Information A new debug command has been added to aid in diagnosing problems that might occur in testing. You must set the view to a Quad T1 board to use this command. set debug nfas on | off This command enables or disables the logging of NFAS events to the console. Remember to use "set console" before using this command. Configuring RIP-2 ComOS 4.1b15 adds support for RIP version 2 (RIP-2). RIP-2 adds netmasks, next-hop information, and authentication to RIP. While OSPF is often a better choice of routing protocol, some environments prefer RIP-2. RIP-2 Command Summary The command split across three lines must be entered on one line. It is split here for legibility. set rip-password Password set Ether0|C0|S0|W1|user User|location Locname rip broadcast|listen|off|v2 broadcast|listen|on|v1-compatability set Ether0|C0|S0|W1 rip cost Cost set user User rip cost Cost set location Locname rip cost Cost set default broadcast | listen | on | off set debug rip on | off set debug rip-detail on | off Password A string 0 to 16 characters in length. Ether0 ether0, ether1 or other ethernet interface. C0 c0 or c1. S0 s0, s1, or another serial port. W1 w1 or another synchronous serial port. User A user in the user table. Locname A location name in the location table. Cost A cost from 0 to 16. RIP-2 Authentication The following command sets up simple password authentication in each RIP-2 packet: set rip-password Password | none Password String of up to 16 characters. The first character cannot be a ?. If quotation marks are used around the password they are dropped. none Removes the RIP-2 password. RIP authentication is used to administrate an autonomous system using RIP-2. The password is sent in the packet as clear text, so no security is provided. The purpose of the authentication is to prevent any RIP packets from being accepted unless the router they come from has been explicitly configured to be part of the routing protocol. This feature can help the administrator protect against misconfiguration, but not intruders. This feature adds an additional 20 bytes of overhead for every 24 routes sent by RIP-2, because the authentication occupies the first route slot in every RIP-2 packet sent. The RIP-2 password takes effect as soon as it is set. If authentication is configured, any RIP version 1 (RIP-1) packet and any RIP-2 packet without a matching password are dropped on receipt. Command> set rip-password test RIP Password Updated Propagating Default Route Information Use the following command to set the way default route information is propagated with RIP and OSPF. set default broadcast | listen | on | off broadcast Advertise default route information through OSPF or RIP. listen Listen for default route information being received through OSPF or RIP. on The same as broadcast and listen. off Do not send or listen to default route information. Command> set default on Default routing changed from on (broadcast,listen) to on (broadcast,listen) RIP Interface Settings You must configure RIP on an interface-by-interface basis. The following command gives the syntax for configuring RIP on various interface types. Enter the command on a single line, although it is split across several lines here for legibility. NOTE: Changed RIP settings take effect the next time the interface comes up. set Ether0 | C0 | S0 | W1 | username User | location Locname rip broadcast | listen | on | off | v2 broadcast | v2 listen | v2 on | v2 v1-compatability Ether0 ether0, ether1 or other ethernet interface. C0 c0 or c1. S0 s0, s1, or another serial port. W0 w1 or another synchronous serial port. User A user in the user table. Locname A location name in the location table. broadcast RIP-1 packets are sent to the interface's broadcast address every 30 seconds, and any RIP packets received are ignored. listen RIP packets received on the interface are interpreted as RIP-1 updates. Any subnet mask or next-hop information is ignored. off Turns RIP routing off on the interface. on Sets the interface to send and receive RIP-1 updates. v2 Sets the interface to use RIP-2. One of the following options is required: broadcast Send RIP-2 updates using the interface's broadcast address every 30 seconds. Any RIP packets received on the interface are ignored. listen No RIP updates are sent, but RIP updates are listened for via the interface's broadcast address. on RIP-2 updates are sent every 30 seconds via multicast, and RIP updates are listened for on the multicast address, or on the interface's broadcast address. v1-compatability This compatibility switch sends RIP-2 updates on the broadcast address of the interface every 30 seconds. RIP updates are listened for coming from the broadcast address. Setting RIP Cost per Interface: set Ether0 | C0 | S0 | W1 | user User | location Locname rip cost Cost Cost A decimal value between 0 and 16 that is added to the metric of RIP routes sent over the interface. Command> set ether1 rip cost 10 Routing for ether1 changed to RIP On (Broadcast, Listen) Cost 10 Configuring SS7 IMT ComOS 4.1b15 on the PortMaster 4 can communicate with a signaling system 7 (SS7) signaling gateway through Q.931+ protocol to receive calls over an inter machine trunk (IMT). set imt-parms Ipaddress Tport1 Tport2 [ default | 1a ] set Line0 imt set Line0 signaling rbs | norbs show imt * set imt-parms This command sets the SS7 signaling gateway address, the listening port on the SS7 gateway, the PortMaster 4 base port, and the switch type. These settings support an IMT that uses out-of-band signaling to control the channels on a trunk. set imt-parms Ipaddress Tport1 Tport2 [ default | 1a ] Ipaddress The SS7 gateway IP address in dotted decimal notation. This address is provided by the SS7 gateway administrator. Tport1 The TCP port in the SS7 gateway that listens for SS7 clients. This socket is provided by the SS7 gateway administrator. Tport2 The local TCP port on slot 0 of the PortMaster 4, used to communicate with the SS7 gateway. Use the same local port value for all slots on any single PortMaster 4. The actual value a board on the PortMaster 4 uses as the local port value is obtained by adding the slot number of the board to the base value specified by Tport2. default 1a Sets the switch type to either default or 1A. Default is used for all switch types other than 1A. This setting enables the PortMaster 4 to interpret the loopback command from the SS7 gateway as either a default or 1A continuity check request. If no argument is specified, default is the default. NOTE: If you set the switch type to 1a, you must also set robbed bit signaling (RBS) on the lines attached to the switch. Use the "set Line0 signaling rbs" command. The PortMaster 4 supports only one SS7 gateway at this time. The PortMaster 4 supports 96 modems per Quad T1 board when used with an IMT. Because modem pools are managed on a slot-by-slot basis, each slot on the PortMaster 4 connected to an SS7 gateway is an independent SS7 client and establishes an independent session with the SS7 gateway. To configure a line for IMT out-of-band signaling, you must first select a Quad T1 board with the "set view" command. Then configure the lines of the Quad T1 board using the "set Line0 imt" command. To save the SS7 settings and activate them, use the "save all" and "reset slot" commands. Example: Command> set view 0 View changed from 4 to 0 Command> set imt-parms 192.168.100.10 10000 7000 Changed gateway IP address from 192.168.100.10 to 192.168.100.10 Changed gateway port from O to 10000 Changed local port from 0 to 7000 If you configure any other slots on this PortMaster to use IMT, they must also use port 7000 as the local port. * set Line0 imt This command sets the line connected to an IMT to use the out-of-band IMT signaling provided by the SS7 gateway. This command requires that you configure the slot being used for this line with the "set imt-parms" command. set Line0 imt Line0 line0, line1, line2, or line3. Example: Command> set view 0 View changed from 4 to 0 Command 0> set line1 imt line1 changed to imt * set Line0 signaling rbs | norbs Line0 line0, line1, line2, or line3. rbs Sets the PortMaster 4 to recognize the IMT as a line with twenty-four 56Kbps channels using robbed bit signaling. This setting is used for 1A IMT lines only. norbs Sets the PortMaster 4 for all other switch types, and is the default. If the switch type is 1a, you must configure the line for robbed-bit signaling using the "set Line0 signaling rbs" command. To save and activate the new settings, you must use "save all", and reset every slot affected. Example: Command> set view 0 View changed from 4 to 0 Command 0> set line0 signaling rbs line0 signaling changed to rbs * show imt This command displays settings for a slot configured for IMT signaling. You must select a slot using the "set view" command before using the "show imt" command. Command> set view 0 View changed from 4 to 0 Command 0> show imt Gateway IP address: 192.168.100.10, gateway port: 10000, local port: 7000 Switch type: Default Configuring L2TP ComOS 4.1b15 on the PortMaster 4 supports Layer 2 Tunneling Protocol (L2TP) as both an L2TP access concentrator (LAC) and an L2TP network server (LNS). The implementation of L2TP in ComOS 4.1b15 is based on the latest IETF L2TP draft (revision 12 and 13 as of this writing). For specific details of operation and protocol implementation of L2TP, refer to the IETF Internet-Drafts. A PortMaster 4 can support up to 100 tunnels. A Quad T1 board supports up to 94 L2TP sessions when configured as a LNS. Note that the number of L2TP tunnels is for the entire PortMaster 4, while the number of L2TP sessions is for each board. Multiple sessions can be sent through a single tunnel. L2TP allows PPP frames to be tunneled from one PortMaster that answers an incoming call (LAC) to another PortMaster that processes the PPP frames (LNS): End user--->incoming call--->LAC--->LNS--->network access Description and Applications The Layer 2 Tunneling Protocol (L2TP) provides tunneling of PPP connections, allowing for the separation of the functionality normally provided by a single NAS into two parts: * The L2TP access concentrator (LAC) provides the "physical" connection point between the telephone network (and therefore the dial-in user) and the host network. * The L2TP network server (LNS) terminates the PPP sessions and handles the "server-side" of the connection, such as authentication of the user, routing network traffic to and from the PPP user, and so forth. The LNS does not have any actual physical ports, only virtual interfaces. An outsourcer can use L2TP to provide dial-up ports to customers using a central and "shared" common physical dial-up pool. The pool resides in a shared access server (the LAC). The outsourcer's customers maintain a home gateway (the LNS) and some type of IP connectivity to the outsourcer. L2TP provides virtual dial up ports to the outsourcer's customers. This is sometimes referred to as a Virtual Private Dial-up Network (VPDN). The service is transparent to the customer, because users still terminate PPP sessions on the customer network via the LNS. RADIUS authentication, accounting, and IP address assignment are all done by the customer. The LAC does no PPP processing unless it is using partial authentication for determining the tunnel endpoint. It only accepts the call and establishes a tunnel to the LNS for that PPP session. The tunnel can be established based upon Called-Station-Id or User-Name (where partial authentication occurs on the LAC before tunnel establishment). For example, if you use Called-Station-Id (and Call-Check) with L2TP, the session follows these steps: First, the end user places a call. The LAC detects the incoming call. The LAC using call-check sends an authentication request to a RADIUS server containing the Called-Station-Id and Calling-Station-Id before answering the call. If the RADIUS server accepts the user, an accept message is returned to the LAC along with information on how to create the L2TP tunnel for this session: the type of tunnel, IP address of the LNS, and so on. The LAC then creates a tunnel to the LNS by encapsulating the PPP frames into IP packets and forwarding those packets to the LNS. The LNS negotiates PPP normally with the end user. RADIUS Dictionary Updates for L2TP Add the following lines to your RADIUS dictionary: VALUE Service-Type Call-Check 10 VALUE NAS-Port-Type Virtual 5 ATTRIBUTE Tunnel-Type 64 integer ATTRIBUTE Tunnel-Medium-Type 65 integer ATTRIBUTE Tunnel-Server-Endpoint 67 string ATTRIBUTE Tunnel-Password 69 string VALUE Tunnel-Type L2TP 3 VALUE Tunnel-Medium-Type IP 1 The RADIUS server must be stopped and restarted to read the new dictionary. RADIUS User Profiles for L2TP The user profiles for the LNS are the same as for your users who do not use L2TP. For the LAC, some new user profiles are required. Exactly which ones are dependent on whether you are using Call-Check or partial username-based tunneling on the LAC. The following profiles can be used on the RADIUS server serving the LAC for each scenario: # Using Called-Station-Id with Call-Check to route callers that dial # 555-1313 to the LNS "172.16.1.221" # Note that the LNS address must be enclosed in double quotes because # it is sent as a string, not as a 32-bit integer. DEFAULT Called-Station-Id = "5551313", Service-Type = Call-Check Service-Type = Framed-User, Framed-Protocol = PPP, Tunnel-Type = L2TP, Tunnel-Medium-Type = IP, Tunnel-Server-Endpoint = "172.16.1.221" # Same as the previous profile, but use a shared secret to authenticate # the session to the LNS. DEFAULT Called-Station-Id = "5551313", Service-Type = Call-Check Service-Type = Framed-User, Framed-Protocol = PPP, Tunnel-Type = L2TP, Tunnel-Medium-Type = IP, Tunnel-Password = "mrsparkle", Tunnel-Server-Endpoint = "172.16.1.221" In both these user profiles, the first line contains the RADIUS check item, with the Called-Station-ID being used to match the entry before the call is answered. The L2TP tunnel parameters from the matching entry are then sent in the RADIUS access-accept message. The Tunnel-Type specifies the tunneling protocol to be used. The Tunnel-Medium-Type specifies the transport medium over which the tunnel is created, IP for now. Tunnel-Server-Endpoint indicates the other end of the tunnel, the LNS in the case of L2TP. Note that the LNS address must be enclosed in double quotation marks because it is sent as a string, not as a 32-bit integer. If you are not using Call-Check and are instead providing partial authentication based on User-Name, the following user profile works. The user "bgerald" dials in to the LAC, which initiates a L2TP tunnel on the user's behalf to LNS 172.16.1.55. bgerald Password = "wackamole" Tunnel-Type = L2TP, Tunnel-Medium-Type = IP, Tunnel-Server-Endpoint = "172.16.1.55" L2TP and RADIUS Accounting The LAC and LNS both log user sessions to RADIUS accounting, but different accounting data is available from each. If you are using call-check to establish the tunnel, the LAC's accounting data shows the Calling-Station-Id, but not the user's name because that information has not been passed over the link yet. The LNS accounting data shows both the Calling-Station-Id and the User-Name along with the assigned IP address. If partial authentication (instead of call-check) is taking place on the LAC, then the username might be available to it and in that case, the username shows up in the RADIUS accounting logs for both the LNS and the LAC. In both cases, the LNS shows the NAS-Port-Type as "Virtual", while the LAC shows the NAS-Port-Type set to the actual physical interface's connection type. Redundant Tunnel Server Endpoints To increase the robustness of L2TP, a user profile can be configured to contain redundant tunnel server endpoints. If the primary LNS goes down, inbound L2TP tunnels can be redirected to other machines. Up to three redundant tunnel server endpoints can be specified. Any more than three are ignored by the LAC. The following example shows a RADIUS user profile with multiple redundant tunnel server endpoints. Each tunnel server endpoint is preceded by the tunnel medium type for that tunnel. DEFAULT Service-Type = Call-Check, Called-Station-Id = "5551234" Service-Type = Framed-User, Framed-Protocol = PPP, Tunnel-Type = L2TP, Tunnel-Medium-Type = IP, Tunnel-Server-Endpoint = "192.168.11.2", Tunnel-Medium-Type = IP, Tunnel-Server-Endpoint = "192.168.11.17", Tunnel-Medium-Type = IP, Tunnel-Server-Endpoint = "192.168.230.97" This feature provides redundant LNS backup, not load balancing. L2TP Command Summary set l2tp noconfig | disable | enable lac | enable lns set l2tp authenticate-remote on | off set l2tp secret [ String15 | none ] show l2tp global | sessions | stats | tunnels reset l2tp [ stats | tunnel ] create l2tp tunnel udp Endpoint [ Password | none] set l2tp choose-random-tunnel-endpoint on | off set debug l2tp max | packets | rpc | setup | stats Use the following command to have the PortMaster load the L2TP feature on startup: set l2tp noconfig | disable | enable lac | enable lns noconfig Sets the board to have no configuration for L2TP. A PortMaster 4 board configured for "noconfig" inherits its configuration from the SMM. A SMM configured for "noconfig" cannot provide L2TP configuration to any line boards. disable Sets L2TP off. L2TP is not used, and L2TP configuration is not inherited from the SMM. enable lac Sets the board to be a LAC. enable lns Sets the board to be an LNS. When a Quad T1 board is configured to be an LNS, the line ports are configured for T1 and cannot be used for dial-in. The virtual S0 ports follow the W1 ports. Example: Command 0> set l2tp enable lns L2TP LNS will be enabled after next reboot After using the "set l2tp" command, you must use the "save all" command to save the configuration and the "reboot" or "reset slot" command for the L2TP module to load. You reset the slot for a line board and reboot the PortMaster 4 if the command is set on the manager board. On a PortMaster 4 you can configure the global setting on the manager board to be either LAC or LNS. This global setting is used by each slot that is not configured individually. So if the manager board is configured as an LNS and slot 0 has no setting, then slot 0 is an LNS. If the manager board is configured as an LNS and slot 0 is configured as a LAC, then slot0 is a LAC. Local slot configuration of LAC or LNS overrides the global setting for that slot. If a slot is configured with "set l2tp disable", then that slot does not inherit its configuration from the manager board. Configuring L2TP to Initiate Authentication The following command configures L2TP to initiate tunnel authentication: set l2tp authenticate-remote on | off on The PortMaster initiates authentication with the other endpoint of the tunnel before a tunnel is established. off The PortMaster does not initiate authentication. This command determines only whether the PortMaster initiates the authentication. It does not determine how the PortMaster responds to an authentication request. The "set l2tp authenticate-remote" command functions the same on both a LAC and an LNS. Configuring an L2TP Secret The "set l2tp secret" global command configures the L2TP password that the PortMaster uses to respond to all L2TP tunnel authentication requests. set l2tp secret String15 | none String15 0 to 15 character string used as a password when responding the L2TP tunnel authentication requests. none Removes the L2TP secret. This is the default. The "set l2tp secret" command sets the L2TP secret for the entire PortMaster. If a PortMaster configured as a LAC receives a tunnel authentication request, it uses the Tunnel-Password from the RADIUS access-accept packet, if present, instead of the global L2TP secret. Displaying L2TP Information The following command shows information on how L2TP is functioning: show l2tp global | sessions | stats | tunnels The formats shown here are subject to change for the general availability release of ComOS 4.1. Command> show l2tp global debug packets debug stats debug setup Tunnel Authentication Enabled Initiation of Authentication Remote Tunnel Disabled Default Board Configuration Command> show l2tp sessions Id Assign-Id Tunnel-Id Portname 2305 1 1 S0 Command> show l2tp stats NEW_SESSION 1 NEW_TUNNEL 4 TUNNEL_CLOSED 3 HANDLE_CLOSED 3 L2TP_STATS_MEDIUM_HANDLE 3 INTERNAL_ERROR 14 CTL_SEND 9 CTL_REXMIT 1 CTL_RCV 10 MSG_CHANGE_STATE 4 WRONG_AVP_VALUE 3 EVENT_CHANGE_STATE 3 Command> show l2tp tunnels Id Assign-Id Hnd State Server-Endpoint Client-Endpoint 1 1 24 L2T_ESTABLISHE 192.168.6.13 192.168.10.28 Resetting L2TP Use the "reset l2tp" command to reset an L2TP tunnel or the L2TP statistic counters. reset l2tp [ stats | tunnel Id ] stats Resets the L2TP counters displayed by "show l2tp stat" to zero. tunnel If no tunnel ID is specified all the L2TP tunnels are destroyed. This is likely to be changed for the ComOS 4.1 release. Id A tunnel ID from 1 to 100. If a tunnel ID is specified, then only that one tunnel is destroyed. The "show l2tp tunnels" command displays a list of active tunnel IDs. Creating an L2TP Tunnel Manually The following command manually brings up a L2TP tunnel for testing and troubleshooting: create l2tp tunnel udp Endpoint [ Password | none ] Endpoint IP address of the L2TP tunnel endpoint. Password Password to use when responding to a tunnel authentication request from the peer. If none is specified, the global L2TP secret is used if configured. Example: Command> create l2tp tunnel udp 149.198.110.19 OK Selecting a Tunnel Endpoint The following command determines in what order to choose an endpoint when multiple tunnel endpoints are returned in a RADIUS access-accept packet. set l2tp choose-random-tunnel-endpoint on | off on Causes the tunnel endpoint to be chosen randomly from the list of tunnel endpoints returned by RADIUS. off Selects the first tunnel endpoint that can be reached. Normally, when L2TP is configured with multiple tunnel endpoints the endpoints are chosen serially, always beginning with the first. If a tunnel cannot be established with the first, then the second is tried, and then the third. When this feature is on, a random tunnel endpoint is selected from those returned in the RADIUS access-accept packet. Debugging L2TP The following command is used to troubleshoot L2TP problems: set debug l2tp max | packets Size | rpc | setup | stats max Provides the same debugging as rpc, setup, and stats, combined. packets Shows a representation of the L2TP packets, similar to the "ptrace dump" command. Size 0 to 1500, number of bytes to display. rpc Shows L2TP remote procedure call communications between the SMM and the line boards. setup Shows L2TP control messages and errors. stats Displays information that appears in "show l2tp stats" in more detail. When you are using debug commands on the PortMaster 4, the debug output matches the current view. If your view is set to the manager board you see debug output for the entire PortMaster. If the view is set to one Quad T1 board, you see debug information for just that board. Configuring Named IP Address Pools The IP pool table allows for multiple dynamically assigned address pools within the PortMaster. Each entry in the IP pool table contains a name, a starting base IP address with a subnet mask, and a crossbar IP. This feature also introduces a new vendor-specific RADIUS attribute, which takes a string that corresponds to a name in the IP pool table. A user profile can be configured for IP pool only through RADIUS. The local user table on the PortMaster does not support IP pools. If the RADIUS access-accept packet indicates that the user receives a dynamically assigned address and also includes the vendor-specific LE-IP-Pool attribute, the PortMaster assigns an address for the user from the specified IP pool. If no LE-IP-Pool is specified, the PortMaster checks for a named IP pool called "default". If the "default" pool exists, it is used. Otherwise the PortMaster 4 uses the line board pool settings to get its address, as configured by the "set assigned" and "set pool" commands. Assigning and Reclaiming Addresses The PortMaster assigns the address during IPCP negotiation for PPP. Because the PPP negotiation might fail after the address has been assigned from the address pool, the PortMaster waits one minute before verifying the address is in use. If the address is not in use then it is recycled back into the address pool. When an interface is destroyed, the IP address is reclaimed back into the pool. Duplicate Addresses If a nonmultilink user logs on multiple times and asks for a dynamically assigned address, that user receives a different address each time. The PortMaster never assigns the same address to two users that are running at the same time. The PortMaster checks for duplicate addresses only among the dynamically assigned users. If another interface is using an address from within the address pool, a conflict occurs when the PortMaster assigns that address. RADIUS for Named IP Pools Add the following lines to the RADIUS 2.1 dictionary to enable the LE-IP-Pool feature: ATTRIBUTE LE-IP-Pool 6 string Livingston The following example shows a RADIUS user profile with the IP pool feature. homers Password = "kwyjibo" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, LE-IP-Pool = "livermore" Command Summary for IP Pools The following commands are used for configuring IP Pools. show table ippool add ippool Poolname set ippool Poolname address-range Ipaddress/Mask [ Gateway ] set ippool Poolname address-range Ipaddress Ipnetmask [ Gateway ] delete ippool Poolname address-range Ipaddress | all reset ippool set ippool Poolname default-gateway Gateway Poolname Name of IP pool, up to 31 characters in length. Ipaddress The base address of the pool. Mask A subnet mask in bits, from 8-30. Ipnetmask A subnet mask expressed in dotted decimal form. Gateway A gateway address for addresses in this range. Displaying IP Pools The following command displays the IP pool table: show table ippool Example: Command> show table ippool Name: livermore Default Gateway: 10.23.45.56 Address/netmask Gateway ------------------ -------------------- 192.168.1.0/29 0.0.0.0 192.168.2.253/30 0.0.0.0 192.168.3.50/25 0.0.0.0 10.4.5.0/24 192.168.222.3 Adding IP Pools The following command adds a named IP pool. There is no preset limit to the number of IP pool entries that can be configured. add ippool Poolname Poolname Name of IP pool, up to 31 characters in length. Example: Command> add ippool livermore IP pool livermore successfully added Setting Address Ranges Address ranges represent the addresses that are assigned to users. Up to eight ranges can be specified within a single IP pool. The first ranges are preferred over the latter ranges. Each range has a base address and netmask associated with it. The base address is incremented to assign addresses. The number of addresses that are assigned is determined by the netmask. The first and last address in each range are not assigned to avoid possible conflicts with broadcast addresses. After creating an IP pool with the "add ippool" command, set address ranges for the IP pool with the following command. The command can be entered in either format: set ippool Poolname address-range Ipaddress/Mask [ Gateway ] set ippool Poolname address-range Ipaddress Ipnetmask [ Gateway ] Poolname Name of IP pool. Ipaddress The base address of the pool. Mask A subnet mask in bits, from 8-30. Ipnetmask A subnet mask expressed in dotted decimal form. Gateway A gateway address for addresses in this range. Example: Command> set ippool livermore address-range 192.168.1.0/24 Range 192.168.1.0/24 256 with gateway 0.0.0.0 add to livermore OR Command> set ippool livermore address-range 192.168.1.0 255.255.255.0 Range 192.168.1.0/24 256 with gateway 0.0.0.0 add to livermore The "256" in the previous output indicates that 256 addresses are covered by the 24-bit mask. Of these 256 addresses, 254 are available to be assigned. The first and last addresses are not assigned. Each range can optionally be assigned a gateway address (also referred to as a crossbar IP). When a packet comes in from a user assigned a gateway address, the PortMaster forwards the packet to the gateway address instead of checking the forwarding table. If a gateway address is not assigned to a range, addresses in the range use the default gateway of the IP pool. If neither the address range nor the IP pool has a gateway, then the forwarding table is used. Command> set ippool livermore address-range 192.168.1.0/24 10.34.56.78 Range 192.168.1.0/24 256 with gateway 10.34.56.78 add to livermore Deleting IP Pools The following command removes an address range from an IP pool or removes the IP pool entirely: delete ippool Poolname address-range Ipaddress | all Poolname Name of the IP pool. Ipaddress Specifies an address range to remove. all Removes the entire IP pool entry. Command> delete ippool livermore address-range 192.168.1.0 Range 192.168.1.0 in livermore successfully deleted Command> delete ippool livermore all Pool livermore successfully deleted Resetting IP Pools Use the following command after any changes to the IP pool settings. Changes do not take effect until you use the "reset ippool" command. reset ippool The "reset ippool" command causes any new changes to take effect and converts the address ranges into routes to be propagated through the routing protocols. NOTE: Even after the "reset ippool" command has been issued, the routing protocols might take a while to replace the old routes with the new changes. Setting the Default Gateway for an IP Pool Use the following command to specify a default gateway for the named IP pool: set ippool Poolname default-gateway Gateway Poolname Name of an IP pool. Gateway Specifies the gateway address (crossbar IP address) for the IP pool. The default gateway functions as a crossbar IP. When a packet comes in from a user assigned an address from this pool, the PortMaster forwards the packet to the gateway address instead of consulting the forwarding table. If a gateway address is not assigned to a range, the range uses the default gateway of the IP pool. Configuring Crossbar IP Crossbar IP is a per-user-directed gateway. Instead of comparing the IP packet's destination address to the routing table, the PortMaster 4 instead looks up the configured crossbar IP address in the routing table to determine the packet's next hop. This affects the packet's routing to the next hop only. Crossbar IP can come from a user profile or from the IP pool table. When both are used, the crossbar IP setting in the user profile takes precedence over the gateway in the IP pool table. Crossbar IP can also be configured on Ethernet ports, network hardwired ports, dial-out locations, the local user table, and in RADIUS. The vendor-specific RADIUS attribute for crossbar IP is called LE-IP-Gateway: ATTRIBUTE LE-IP-Gateway 7 ipaddr Livingston The following example shows a RADIUS user profile with crossbar IP: kodos Password = "kangroo" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, LE-IP-Gateway = 192.168.72.3 The "ifconfig" command displays the keyword CROSSBAR for any interface where crossbar IP is active. Command Summary for Crossbar IP The new commands for crossbar IP are: set Ether0 crossbar-ip Ipaddress set S0 crossbar-ip Ipaddress set location Locname crossbar-ip Ipaddress set user User crossbar-ip Ipaddress Setting Crossbar IP on Ethernet The following command configures an ethernet interface to use the specified IP address instead of the packet destination field to determine the next hop to route the packet to: set Ether0 crossbar-ip Ipaddress Ether0 ether0 or ether1. Ipaddress A dotted decimal IP address or a hostname of up to 39 characters. An address of 0.0.0.0 removes the crossbar IP. For the crossbar IP setting to take effect on the Ethernet interface, the slot containing the Ethernet board must be reset. Example: Command> set ether1 crossbar-ip 192.168.96.78 Changing crossbar ip address from 0.0.0.0 to 192.168.96.78 Setting Crossbar IP on Dial-out Locations The following command allows dial-out locations and Frame-Relay subinterfaces to use the crossbar IP feature: set location Locname crossbar-ip Ipaddress Locname A location name. Ipaddress A dotted decimal IP address or hostname of up to 39 characters. An address of 0.0.0.0 removes the crossbar IP. The crossbar IP setting takes effect the next time the location is used. Example: Command> set location krabappel crossbar-ip 192.168.96.69 Changing crossbar ip address from 0.0.0.0 to 192.168.96.69 Setting Crossbar IP for Network Users The following command configures a user with the crossbar IP feature: set user User crossbar-ip Ipaddress User A user in the local user table. Ipaddress A dotted decimal IP address or hostname of up to 39 characters. An address of 0.0.0.0 removes the crossbar IP. User profiles can be configured by RADIUS or from the local user table of the PortMaster. The PortMaster always checks the local user table before querying RADIUS. The crossbar IP setting takes effect the next time the user connects. Example: Command> set user skinner crossbar-ip 192.168.1.2 Changing crossbar ip address from 0.0.0.0 to 192.168.1.2 Setting Crossbar IP on Network Hardwired Ports The following command configures a network hardwired port with the crossbar IP feature: set S0 crossbar-ip Ipaddress S0 s0, w1, or any other serial port configured as network hardwired. Ipaddress A dotted-decimal IP address or hostname of up to 39 characters. An address of 0.0.0.0 removes the crossbar IP. The crossbar IP setting takes effect the next time the port is reset. Example: Command 2> set w70 crossbar-ip 192.168.123.4 Changing crossbar ip address from 0.0.0.0 to 192.168.123.4 Limitations * Multichassis PPP (MCPPP) is not supported in this release. MCPPP is currently planned for an update release (ComOS 4.1.1), which will be available for beta testing soon. * The redundant system manager module is not supported in this release, but is currently planned for an update release (ComOS 4.1.1), which will be available for beta testing soon. * Internal DS-3 and DS-1 clocking are not supported in this release; external clocking is required on the Quad T1 board and T3 Mux board. * The "erase configuration", "erase comos", and "erase partition" commands must not be used. The configuration is now stored in files in subdirectories of the nonvolatile file system, not in partitions. * When using a line board (Quad T1 or Tri E1) you must plug in any lines from the telephone company that use telephone company clocking into the lower-numbered line ports starting with Line0. Lines that do not have telephone company clocking must be plugged into the higher-numbered line ports starting with Line3 and counting down. The line board uses the clock signal of the first line port that comes up, starting with Line0, for its transmit clock signal which is shared among all the line ports. If the frequency of the clock signal is shifted, as it is in the case of clock generated by non-telephone company sources, then analog modems encounter problems and might not answer calls. ISDN and hardwired connections are mostly immune to shifts in clock frequency. * The PortMaster 4 manager board reboots if an snmpwalk is done at the same time that BGP is loaded. * A ptrace dump works only on outbound traffic. * Ethernet subinterfaces can be configured on Ether0 only. * The modem table is not supported. This limitation only affects users that wish to connect modems to C0 or C1. * You must reboot the PortMaster 4 after deleting an Ethernet subinterface. * The "show mux" command sometimes shows the DS-1s in loopback when they are not. This can be cleared by using the "set mux-loop Channel off" command. * The "show l2tp stats" command works only from the manager view. At this time you cannot view l2tp status for boards other than the manager. * The "show l2tp sessions" command truncates output after about 58 sessions. The "show sessions" command shows all sessions including all the L2TP sessions. * The output of the "show ospf neighbor" command on a Single or Dual Ethernet board truncates the last character of the ether interface. * In some cases ISDN 56Kbps users, including data over voice (DOV) and V.120, may experience difficulties in connecting. * When the PortMaster is configured for L2TP, resetting many (approximately 150) L2TP sessions at once might cause L2TP control messages to be lost resulting in sessions that are not torn down. If this state arises, you must reset the board in order to reset the hung L2TP sessions. * Username does not appear in the 'show l2tp session' output on LNS, and PMVision cannot see the users. * Boards configured as LNS report the NAS-Port incorrectly to RADIUS accounting. * The console message "slot1: S88: Received PAP on down LCP" and or "LCP reopening" is sometimes, but not always, caused by a failed analog PPP dial-in attempt. Upgrade Instructions You can upgrade your PortMaster 4 using PMVision 1.3, or pmupgrade 4.0 from PMTools. Alternatively, you can upgrade using the older programs pminstall 3.5.3, PMconsole 3.5.3, or PMconsole for Windows 3.5.1.4, or later releases. You can also upgrade using TFTP with the "tftp get comos" command from the PortMaster command line interface. See ftp://ftp.livingston.com/pub/le/software/java/pmvision13.txt for installation instructions for PMVision 1.3. *** CAUTION! If the upgrade fails, do NOT reboot! Contact *** Lucent InterNetworking Systems Technical Support without rebooting. The upgrade process on the PortMaster 4 erases the configuration area from nonvolatile memory and saves the current configuration into nonvolatile memory. Never interrupt the upgrade process, or loss of configuration information can result. This upgrade does not otherwise affect your stored configuration in the PortMaster 4. The installation software can be retrieved by FTP from ftp://ftp.livingston.com/pub/le/software/, and the upgrade image can be found at ftp://ftp.livingston.com/pub/le/upgrades: ComOS Upgrade Image Product _________ _____________ _____________________________________ 4.1b15 pm4_4.1b15 PortMaster 4 Technical Support Copyright and Trademarks Copyright 1999 Lucent Technologies. All rights reserved. PortMaster, ComOS, and ChoiceNet are registered trademarks of Lucent Technologies, Inc. RADIUS ABM, PMVision, IRX, and PortAuthority are trademarks of Lucent Technologies, Inc. All other marks are the property of their respective owners. Notices Lucent Technologies, Inc. makes no representations or warranties with respect to the contents or use of this publication, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Lucent Technologies, 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 Lucent InterNetworking Systems Technical Support Lucent Technologies InterNetworking Systems (previously Livingston Enterprises) provides technical support via voice, fax, electronic mail, or through the World Wide Web at http://www.livingston.com/. Specify that you are running ComOS 4.1b15 when reporting problems with this release. Internet service providers (ISPs) and other end users in Europe, the Middle East, Africa, India, and Pakistan should contact their authorized Lucent InterNetworking Systems sales channel partner for technical support; see http://www.livingston.com/International/EMEA/distributors.html. For North and South America and Asia Pacific customers, technical support is available Monday through Friday from 7 a.m. to 5 p.m. U.S. Pacific Time (GMT -8). Dial 1-800-458-9966 within the United States (including Alaska and Hawaii), Canada, and the Caribbean, or 1-925-737-2100 from elsewhere, for voice support. Otherwise, fax to 1-925-737-2110, or send email to support@livingston.com (asia-support@livingston.com for Asia Pacific customers).