Interfaces

The system supports the port types listed below.

• Cellular

  The cellular interface supports dual SIM operation using major carrier frequency bands in North America, EMEA, and APAC. For more information about cellular ports, see Cellular MDA and ports.

• Ethernet

  The system supports Fast Ethernet (10/100Base-T) ports. The Ethernet ports are typically connected to field devices, such as Intelligent Electronic Devices (IEDs), AMI collectors, supervisory modules, weather monitoring devices, cameras, and other hosts.

  In some cases, an Ethernet port may be connected to a 7705 SAR-18, 7705 SAR-8, 7705 SAR-H, or 7705 SAR-Hc node, which will use the system's cellular port as a backup link.

  For more information about Fast Ethernet ports, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide, '"Port types".

• Serial

  RS-232 asynchronous ports are typically used for connecting to remote SCADA equipment. The ports support full-duplex communication and interface speeds of 600 b/s, 1200 b/s, 2400 b/s, 4800 b/s, 9600 b/s, 19 200 b/s, 38 400 b/s, 57 600 b/s, and 115 200 b/s. The serial ports can be configured to support raw socket transport; see Serial transport over raw sockets for more information.

• Alarm

  For information about the alarm port and the number of supported alarm inputs and outputs, see the SAR-Hm and SAR-Hmc Chassis Installation Guide.

  For information about configuring alarm inputs, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Basic System Configuration Guide.

  Alarm inputs are configured using the config>system>alarm-contact-input command and sub-commands. For information, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.

  To display the status of the alarm inputs, use the show>system>alarm-contact-input all command; see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Clear, Monitor, Show, and Tools CLI Command Reference Guide for information.

• WLAN

  The WLAN interface supports the IEEE 802.11 b/g/n WLAN standard. The interface is enabled as a WLAN access point (AP) that remote WLAN stations can connect to. For more information, see Wireless LAN interface. WLAN traffic that is received from WLAN stations connected to the WLAN AP is transported over a Layer 2 service using an Epipe. See the 7705 SAR-Hm and SAR-Hmc Main Configuration Guide for details about configuring services for the WLAN AP.

For general information about port features, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide, "Port state and operational state".

MTU default and maximum values lists the default and maximum MTU values for Fast Ethernet ports, cellular ports, and the WLAN interface.

For information about how to modify the MTU defaults, see "Modifying MTU defaults" in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide.

The cellular port IP layer MTU is derived from the PDN router interface that is configured for the cellular port. By default, the PDN router interface MTU is not set. To operate the cellular interface without failures, an MTU value that is less than or equal to 1486 bytes must be configured (using the ip-mtu command) for the PDN router interface. For information about configuring the PDN router interface, see "PDN router interface command descriptions" in the 7705 SAR-Hm and SAR-Hmc Main Configuration Guide.

Mobile networks often require a strict IP layer MTU for the LTE interface that is less than or equal to1486 bytes. Consult with the cellular service provider about the correct IP layer MTU value to set for the associated PDN router interface.

The SAP MTU settings must also correctly account for the PDN router interface IP layer MTU, as services that are transported over the cellular interface are impacted by this configuration.

For example, if a cellular provider allows an IP layer MTU of 1486 bytes, the following calculations and values must be considered when setting up services over a cellular port.

For BGP and T-LDP protocols, the MTU of protocol packets must be set to 1486 bytes or less. For information about BGP path MTU discovery and LDP path MTU discovery, see the path-mtu-discovery command in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.

For Layer 3 services over a VPRN service using GRE transport, the SAP MTU must be set as follows:

• SAP MTU = {1486 bytes - (GRE packet overhead) - (VPRN service label)}

• SAP MTU = {1486 bytes- (24 bytes) - (4 bytes)}

• SAP MTU = 1458 bytes

For Layer 3 services over a VPRN service using GRE transport with NGE enabled, the SAP MTU must be set as follows:

• SAP MTU = {1486 bytes - (GRE packet overhead) - (VPRN service label) - (NGE overhead)}

• SAP MTU = {1486 bytes - (24 bytes) - (4 bytes) - (77 bytes)}

• SAP MTU = 1381 bytes

For Layer 2 services over a VPLS service using GRE transport, the SAP (port) MTU must be set as follows:

• SAP MTU = {1486 bytes - (GRE packet overhead) - (VPLS service label)}

• SAP MTU = {1486 bytes - (24 bytes) - (4 bytes)}

• SAP MTU = 1458 bytes

For Layer 2 services over a VPLS service using GRE transport with NGE enabled, the SAP MTU must be set as follows:

• SAP MTU = {1486 bytes - (GRE packet overhead) - (VPLS service label) - (NGE overhead)}

• SAP MTU = {1486 bytes - (24 bytes) - (4 bytes) - (77 bytes)}

• SAP MTU = 1381 bytes

For Layer 2 services using an Epipe VLL/VPWS service with a control word, an additional 4 bytes of overhead is required for the control word. Therefore, the following SAP (port) MTU must be set as follows:

• SAP MTU = {1486 bytes - (GRE packet overhead) - (VLL service label) - (CTL word)}

• SAP MTU = {1486 bytes - (24 bytes) - (4 bytes) - (4 bytes)}

• SAP MTU = 1454 bytes

For Layer 2 services using an Epipe VLL/VPWS service with a control word and NGE enabled, an additional 4 bytes of overhead is required for the control word and 4 bytes of NGE overhead is added. Therefore, the following SAP (port) MTU must be set as follows:

• SAP MTU = {1486 bytes - (GRE packet overhead) - (VLL service label) - (CTL word) – (NGE overhead)}

• SAP MTU = {1486 bytes - (24 bytes) - (4 bytes) - (4 bytes) - (81 bytes)}

• SAP MTU = 1373 bytes

The SAP MTU of Layer 2 services can be increased to accommodate larger packets that are closer to the Ethernet port maximum MTU value by using GRE SDP fragmentation and reassembly. See "GRE SDP tunnel fragmentation and reassembly" in the 7705 SAR-Hm and SAR-Hmc Main Configuration Guide.

The WLAN port MTU value is set to 1500 bytes and cannot be changed. Since cellular ports have a lower MTU with a maximum of 1486 bytes, and WLAN traffic from stations connected to the WLAN AP is carried over an IP/MPLS service that adds additional overhead to traffic traveling over cellular ports, the operator must understand the requirements of the MTU for their applications in order to successfully use the WLAN interface.

For example, when the WLAN interface AP is connected to the Nokia WLAN GW using an Epipe service, there is at most 1454 bytes available to carry a Layer 2 packet for the WLAN AP packet that includes a Layer 2 header of 14 bytes (see MTU considerations over a cellular port for information about the SAP MTU of an Epipe service over a cellular port). In order to successfully send these packets over a cellular port without further modification, the MTU of the IP payload in the WLAN AP Layer 2 packet must be restricted to 1440 bytes.

The MTU of the WLAN interface can be handled in one of two ways:

• by modifying the MTU value on clients that are connecting to the WLAN AP such that they send traffic that conforms to the service MTU of the IP/MPLS transport service, minus the 14 byte Layer 2 overhead

• by configuring GRE SDP fragmentation and reassembly on the node to allow packets that require an MTU greater than that available on the cellular interface to be fragmented and reassembled when carried over the cellular interface

A raw socket IP transport interface can be configured for each RS-232 serial port on a node. This allows the serial port to receive TCP connections or UDP session packets from multiple remote hosts, or to create new sessions to remote hosts in order to send and receive serial data to and from those remote hosts.

There are port-level and service-level configuration requirements for a raw socket serial port to send and receive serial data in either server mode, client mode, or both modes.

Raw socket port-level configuration includes defining the end of packet checking parameters (idle time, length, special character) and the inter-session delay for transmitting session data over the serial link.

At the service level, an IP transport subservice is created within a VPRN service to associate the serial port with the VPRN service. TCP/UDP encapsulated serial data is routed within the corresponding Layer 3 VPRN service. The required configuration includes IP transport subservice local host and remote host configuration, TCP timers, and session control.

See Serial raw socket interface configuration commands for information about the required port-level configuration. For information about how the IP transport subservice operates within a VPRN service, as well as information about the required system-level configuration, see "Raw socket IP transport service" in the 7705 SAR-Hm and SAR-Hmc Main Configuration Guide.

Raw socket packet processing illustrates how raw socket packets are processed over a serial link.

Session data attempting to access the serial port is queued. One queue is maintained per session. The purpose of the session queue is to prevent two different flows of packets from interleaving out the serial port and creating unreadable messages. When data is being transmitted over the serial link for a session, any other session's data is queued until the first session has emptied its queue. The next session's data is transmitted over the serial link only after the inter-session-delay timer expires. Each session's data is sent out in round-robin fashion.

A condition may occur where the end device connected to the serial port continues to send out a continuous stream of data after the normal response period has expired. This can prevent the far-end remote host or master equipment from receiving data from other end devices in the network. To resolve this condition, the squelch command can be used on the raw socket at the port level (it is disabled by default). This stops the socket from receiving any more data from the problematic device.

If the command is enabled, the node will monitor the serial port for a constant character stream. A configurable squelch delay period, using the squelch-delay command, is used to determine how long to measure the constant character stream before initiating the squelch function. If the squelch function is initiated, the port is considered locked up and an alarm is raised indicating the lock-up and that the squelching function has been triggered.

The serial port can be forced out of squelch and put back to normal, either manually using the squelch-reset command or automatically using the unsquelch-delay command. The unsquelch-delay command defines the time to wait after squelch is initiated before it is removed.