Turn the power off. The GTH does not require any special preparation before power is turned off.
The GTH can be rebooted using the API
<reset> command.
The realtime clock is set during the boot process, so all items logged before the clock is set show the time since boot instead of "wall time":
Jan 1 00:00:06 (none) syslog.info klogd: Frame Relay RX driver Jan 1 00:00:07 (none) syslog.info klogd: stream_dev Aug 12 14:03:10 (none) user.info fpga: Programming fpga Aug 12 14:03:11 (none) daemon.info klogd: Power 1 on Aug 12 14:03:11 (none) daemon.info klogd: Power 2 off
In the above example, the clock was set immediately before the "Programming fpga" entry.
On GTH 2.0 and GTH 2.1 hardware, the power-on sequence, with approximate elapsed time since power-on, is:
| Time | LED status | Internal state |
| 0 s | All LEDs off | Start of boot sequence |
| 1 s | LEDs in boot state | Boot loader started |
| 13 s | LEDs in normal state | OS booted, loading control system |
| 16 s | Module answers ping and ARP packets | |
| 25 s | Module accepts commands on API port 2089 and HTTP on port 8888 |
This is what the connector-side of a module looks like 2s after power-on, with the LEDs in 'boot' state. The LEDs can only be in this pattern (right LED of the leftmost Ethernet port lit yellow) during the first few seconds of boot:
After about 13s, the LEDs change to their normal powered-on state. Exactly how that looks depends on whether one or two ethernet ports are enabled and on whether those ports are connected. For instance, if the first ethernet port is available and correctly connected, the module will look like this:
If the ethernet cable is then unplugged, the module will have just one yellow LED lit, but not the same one as during the first few seconds of boot:
The Getting Started Guide (part number 10-0005 and 10-0006) has a complete explanation of what various LEDs indicate, as well as pin-out tables.
GTHs send one packet per minute on all activated ethernet interfaces if nothing has connected to the WWW server (at port 8888) or the API (port 2089).
This is useful if you have a GTH and don't know what its IP address is. A network sniffer (such as tcpdump or wireshark) will show these 'chirp' packets.
Wireshark is available for most operating systems from http://www.wireshark.org/.
Whenever the OS sends a packet, it looks at its routing tables to decide which interface to send the packet on. If you have two interfaces on the same subnet, the first interface which matches the subnet will be used to send all the packets, which is probably not what you wanted.
References: RFC 2328 (OSPF)
http://support.microsoft.com/kb/q244268/
There are various (trouble-prone) ways to work around this restriction.
By default, GTH systems are configured without a default gateway (route). You can only reach a GTH which is on the same subnet as the host.
A default gateway can be configured using API commands.
Current model (GTH 2.x, shipping since 2006) hardware supports Ethernet auto-negotiation on both Ethernet interfaces. Depending on the capabilities of the Ethernet port the GTH is connected to, it runs at either 10 or 100Mbit/s, either half- or full-duplex.
The GTH will sense the link speed and run at that speed (either 10 or 100Mbit/s. The GTH will assume half-duplex. This behaviour is required by IEEE 802.3:2000.
Some 10/100Mbit/s Ethernet devices, such as high-end switches, allow auto-negotiation to be disabled and the link speed/duplex setting to be manually configured. Several possible configurations will result in problems:
| Remote port configuration | GTH will use | Comment |
| auto-negotiate | 100Mbit/s full-duplex | Good (recommended) |
| 100Mbit/s full-duplex | 100Mbit/s half-duplex | Not recommended (see below) |
| 100Mbit/s half-duplex | 100Mbit/s half-duplex | Acceptable |
| 10Mbit/s full-duplex | 10Mbit/s half-duplex | Not recommended (see below) |
| 10Mbit/s half-duplex | 10Mbit/s half-duplex | Acceptable |
The not recommended configurations result in network performance problems, including late collisions.
References:
IEEE 802.3:2000 (The "Fast Ethernet" specification)
CISCO tech note 17053: "Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues"
SUN Ethernet Autonegotiation Best Practices
Typical causes:
Typical causes:
Typical cause: incorrect L1 configuration
Typical cause: incorrect L1 configuration
Typical causes when using a monitor point:
Typical causes when using full-duplex (normal operation):
The GTH maintains a number of error counters for each receiver. The counters can be used to help diagnose a number of L1 problems.
Typical causes:
Typical causes:
Typical causes:
This counter is only used when the GTH is configured for multiframe framing.
Typical causes:
E1 (and T1) lines are part of the 'PDH' network. PDH stands for plesiosynchronous digital hierarchy, meaning that the whole network runs with "almost" synchronised clocks.
Every switch in a PDH network must have a source for its 8kHz sync. Possible sync sources are:
PDH requires all switches in a network to run "almost" synchronised. In practice, this is done by specifying master/slave sync relationships between the switches. A simple, correctly structured network is shown in figure 1:
The lines indicate E1 cables between switches. The red lines with arrows indicate a master/slave sync relationship: switch 4 uses switch 2 as its sync master. Switch 1 has no master, it is the sync reference for the whole network.
There are many ways to mis-configure networks such that sync will not work.
In figure 2, neither switch 1 nor switch 2 has a master. Both will generate their frequency reference internally. In practice, these two frequency references will be different, resulting in slips on E1s 1-2, 2-3 and 3-4. This is bad . There will be no slips on 1-3 and 2-4 since the switches on either side of those links are synchronised.
Figure 3 shows another bad configuration. None of the switches are synchronised. There will be slips on all of the E1s.
Figure 4 is the worst of all the examples. It shows a circular sync relationship, where each of the switches chases a sync source which ultimately originates from itself. Such setups are unstable and result in unpredictable behaviour. A common result of such a configuration is that the frequency migrates to the extreme of the sync range the equipment can handle, thus taking it outside the frequency limits allowed by G.703.
The ITU-T standard G.781 contains further information about synchronisation hierarchies in PDH networks.
A slip occurs when a transmitter emits frames at a different rate to the rate the receiver accepts the frames. When the transmitter's rate is greater than the receiver's, the receiver deals with the situation by discarding one frame every so often.
Conversely, when the transmitter's rate is lower than the receiver's the receiver duplicates a frame every so often.
On E1, a frame is 32 octets of data, one octet per timeslot.
On voice circuits, a slip results in an audible 'pop'. On signalling circuits it results in corrupted packets. In MTP-2, a slip will (almost) always result in one corrupted packet.
This is described in detail in section 7.2 of the API manual ("Sync sources"). By default, the GTH will automatically select an E1/T1 input to synchronise to. The GTH will adjust its internal frequency to match the chosen interface, as long as the E1/T1 line's frequency is within the limits specified by G.703. (+/- 50ppm)
The GTH's sync behaviour can also be manually configured, either to use a particular line as its sync source, or to use its internal oscillator. Example: to set the sync source to PCM2A:
<set name="sync">
<attribute name="source" value="pcm2A"/>
</set>
The stability of the GTH's internal oscillator is +/- 1 ppm, within the normal temperature range. This stability determines the performance in situations where the sync source is temporarily lost, in practice it means the GTH can tolerate sync loss for approximately two minutes without having to slip.
ppm means parts-per-million. Thus if one system runs at
8000Hz and another at 8000.2Hz, they differ by 250ppm.
The time between slips is given by 1/(d x R),
where 'd' is the frequency error and R is the frame rate.
Examples:
| d | R | Time between slips |
| 1ppm | 8000 frames/s | 125 seconds |
| 50ppm | 8000 | 2.5 seconds |
In MTP-2, packets are transmitted continuously, so a slip will (almost) always damage a packet. On an "idle" MTP-2 link, the wire has nonstop 5 octet FISUs, a 50ppm frequency error should give about 24 damaged FISUs per minute. These are counted as ESUs.
On a "busy" MTP-2 link, the average packet length will be longer than 5 octets, resulting in fewer ESUs per minute.
10Mbit/s and 100Mbit/s ethernet links re-synchronise at the start of each transmitted packet.
In most applications, this means there are never slips. In applications which transmit fixed-rate data, e.g. a VOIP system, slips still occur. They are usually dealt with in an application-specific way. VOIP systems often use "silence compression/expansion" to hide the slips.
Passive monitoring means connecting a test instrument, such as a GTH, to an E1 or T1 link without disturbing, or being able to disturb, the link. The GTH can listen in on (``sniff'') the signalling and voice traffic on the link, but not change it. Sniffing E1/T1 links is useful in any application that needs to observe without disturbing.
There is a standardised way to monitor E1/T1 links. It is defined in ITU-T G.772 and is formally called a ``Protected Monitoring Point''. A G.772 protected monitoring point connects to a live line in such a way that the test equipment sees a signal attenuated by 20dB (one tenth of the signal voltage). One way to do that is with two resistors:
The diagram shows a 120 ohm installation, which needs 536 ohm resistors. The nearest commonly available resistor is 540 ohm, which is acceptable.
Monitor point systems for various types of E1/T1 patch panels are commercially available, for instance Vierling make both standalone and rack-mounted systems. Many sites have pre-installed monitor points either on the switching equipment or in a cross-connect.
One GTH 2.x module has enough E1/T1 receivers to passively monitor both directions of 8 E1/T1 links.
It does not matter.
A monitor point can be installed at any point between the two systems communicating over an E1/T1 line. Some installations have a patch panel near one of the two systems, this is a good spot. Some systems have built-in monitor points.
There are, however, some restrictions on the monitor point itself. The distance between the E1 line and the resistors must be short, 1m maximum. The distance from the resistors to the GTH system can be 200m maximum.
Intrusive monitoring means unplugging an E1/T1 link and inserting a GTH into the link as an active component. The GTH thus becomes an active part of the network instead of being a passive listener.
As an active participant in the network, the GTH can enable and disable voice traffic for every timeslot it is connected to. In some applications, such as fraud prevention, this is desirable.
One GTH 2.x module has enough E1/T1 transceivers to intrusively monitor both directions of 4 E1/T1 links.
| Ethernet/IP | E1/HDLC | E1/ATM | |
| What happens when there is no data to send? | Electrical silence (no voltage on line) | MTP-2: send FISU, LAPD/FR: send FLAG | Send "idle" cell or "unassigned" cell |
| How does the hardware find the start of a packet? | Watch for the transition from electrical silence to a "preamble" sequence which must come before every packet. The preamble sequence is 80 bits of 101010... It has the secondary function of synchronising clocks. | Find a flag (bit pattern 01111110) followed by a non-flag. Bit stuffing guarantees that FLAG never occurs inside a packet. | Next packet (cell) always comes exactly 53 octets after start of current. At startup, we find the start of a packet by just starting somewhere and computing the header CRC. If it's wrong, we move forward one octet and try again. When we find a correct CRC, we move forward 53 octets and see if that header is also correct. |
| What are the alignment requirements? | (Not relevant) | No alignment requirements at all, not even octet alignment. | Cells are octet aligned, but not frame aligned. A cell must always start on an octet boundary. A cell will usually not start on a frame boundary. |
| How are bit errors detected? | 32-bit CRC after every frame (packet) | 16-bit CRC after every signal unit (packet) | Cell header (5 octets) protected by an 8-bit CRC.
AAL0: No payload protection. AAL2: No payload protection (but 5 bit CRC on secondary header). SSCS sublayer may add a 10-bit CRC. AAL5: 32-bit CRC on payload |
| How is packet length limited? | Ethernet frame is about 1.5k max.
TCP can reassemble frames with no length limit. UDP limits to 64k |
MTP-2: 279 octets.
LAPD: 265 octets by default Frame relay: generally 1.6k |
AAL0: Cells are always 53 octets.
AAL2: 45 octets by default (64 octets optional) AAL5: 64k |
The LOS indication is a warning; it means "the signal is now so weak that correct data extraction cannot be guaranteed". LOS does not itself disable the incoming data stream; the decision whether or not to terminate L2 if L1 indicates LOS is left to the application.
With ESU filtering disabled (ESU="yes"), the GTH delivers all signal units (packets), including signal units which are less than the minimum length. Some examples of input bitstreams which cause signal units with a zero-byte length:
Four-bit signal unit (zero bytes!): 0111 1110 1011 0111 1110
One-bit signal unit (zero bytes!): 0111 1110 1011 1111 0
Instantly aborted signal unit (also zero bytes): 0111 1110 1111 1111
The same applies to LAPD and Frame Relay.
When sending signalling data, for instance in an MTP-2 monitoring application, some information about sockets going down is logged. This is intended for internal use, but they might be of some use when solving problems. The possible messages are:
killed sock N fd M (poll() event: error/input), errno P
There are two possible reasons for this message.
killed sock N fd M (write failed), errno P
This happens if an attempt to write a socket failed with an error. Some values of P indicate specific problems:
| Code | Cause |
| 32 | The reading end of the socket has closed |
| 104 | The remote OS reset the socket (typical behaviour when a remote program is terminated or a server is rebooted) |
| 110 | The remote connection timed out. This is typical of an ethernet network failure, e.g. a cable has been unplugged. |
Most other values do not indicate an error, in particular 0, 4 and 11 are normal.
In all cases, preceding or following error messages may give provide extra information.
There are several identification codes in Corelatus products.
| Name | Location | Purpose |
| Chassis serial number (CSN) | On a metallic silver self-adhesive on the left side of the grey steel chassis, immediately following the text ``Serial:''. | Uniquely identifies each chassis. At delivery time, Corelatus supplies a list of cards in each chassis. |
| Ethernet MAC address | Factory-programmed on GTH modules. Can be viewed via the in-built webserver (on the ``ethernet'' page) | Uniquely identifies each ethernet interface. |
| ROM ID | Factory-programmed on GTH and IEB modules. Can be viewed via the in-built webserver | Uniquely identifies each GTH or IEB module. |
Corelatus maintains a database which cross-references all of the above information for each module.
A straight cable is most often used to connect an Ethernet interface to an Ethernet hub or switch. Shielded CAT-5 cable (STP) must be used, the connectors are RJ45.
| End A | Cable | End B |
| Pin | Wire Colour | Pin |
| 1 | orange-white | 1 |
| 2 | orange | 2 |
| 3 | green-white | 3 |
| 4 | blue | 4 |
| 5 | blue-white | 5 |
| 6 | green | 6 |
| 7 | brown-white | 7 |
| 8 | brown | 8 |
The wire colours have been chosen to follow one of the schemes allowed in EIA/TIA 568 A/B.
A crossed Ethernet cable can be used to connect a GTH directly to a server's Ethernet port, without using a hub or switch. This is sometimes also called a crossover cable. Shielded CAT-5 cable must be used, the connectors are RJ45.
| End A | Cable | End B | ||
| Pin | Name | Wire Colour | Pin | Name |
| 1 | TX+ | orange-white | 3 | RX+ |
| 2 | TX- | orange | 6 | RX- |
| 3 | RX+ | green-white | 1 | TX+ |
| 4 | Termination | blue | 4 | Termination |
| 5 | Termination | blue-white | 5 | Termination |
| 6 | RX- | green | 2 | TX- |
| 7 | Termination | brown-white | 7 | Termination |
| 8 | Termination | brown | 8 | Termination |
A crossed E1/T1 cable can be used to loop back an E1/T1 port, i.e. make a GTH transmit to itself. The connector is RJ45.
E1 lines are specified for 120 ohm cables, so a CAT-5 or CAT-5e cable (100 ohm) is out-of-spec and thus not recommended for anything beyond lab use.
| End A | Cable | End B | ||
| Pin | Name | Wire Colour | Pin | Name |
| 1 | RX A | orange-white | 4 | TX A |
| 2 | RX A | orange | 5 | TX A |
| 3 | RX B | green-white | 7 | TX B |
| 4 | TX A | blue | 1 | RX A |
| 5 | TX A | blue-white | 2 | RX A |
| 6 | RX B | green | 8 | TX B |
| 7 | TX B | brown-white | 3 | RX B |
| 8 | TX B | brown | 6 | RX B |
| Model | GTH 2.x | GTH 1.x |
| Shipping years | 2006 onwards | 2001-2006 |
| Ethernet ports | 2x10/100 | 1x10/100, 1x10 |
| E1/T1 ports (duplex) | 8 | 4 |
| E1/T1 ports (monitoring) | 16 | 4 |
| MTP-2 monitoring | 64 timeslots | 32 |
| MTP-2 Annex A monitoring | 4 channels (124 timeslots) | 2 channels |
| LAPD monitoring | 64 timeslots | 32 |
| Frame relay monitoring | 64 channels, up to 256 timeslots (16Mbit/s) | 32 channels, 4Mbit/s |
| ATM monitoring | 6 channels, 12Mbit/s | 2 channels, 4Mbit/s |
GTH 1.0, GTH 1.1 and GTH 2.x modules use the same software API.
In addition to the above modules, Corelatus also shipped an expansion module, the IEB 1.0, from 2003-2006. The IEB module provided 12 E1/T1 ports, but relied on an adjacent host GTH 1.1 module for processing power and ethernet.
IEB modules each have one rotary switch. The rotary switches on the modules are correctly set at the factory. If IEB systems are expanded in the field, it may be necessary to alter the rotary switch.
The rotary switch on IEB modules identifies the module to the GTH it is connected to.
| IEB position in chassis | Rotary Switch Setting |
| IEB module adjacent to GTH module | arrow points at '1' |
| IEB module furthest from the GTH | arrow points at '2' |
The rotary switch present on some manufacturing runs of GTH modules does not affect the GTH in any way. It is factory preset to zero for compatibility with future software releases.
A Corelatus plywood shipping crate, which is available on request in conjunction with orders.
Packaging material consists of cardboard and polyethylene plastic, both of which are suitable for recycling. Packaging may be returned to Corelatus, in which case items in good condition will be re-used.
Corelatus hardware at end-of-life may also be returned to Corelatus Stockholm for disassembly and recycling of materials.
A fully-equipped 19" chassis, ready for mounting in a rack:
482mm x 342mm x 42 mm (WxDxH) 6kg
A ready-to-ship Corelatus plywood crate packed with two fully-equipped chassis:
610mm x 450mm x 204mm (WxDxH)
18kg
We use the customs classification number 85173000 (Telephonic or telegraphic switching apparatus) and country of origin code 30 (Sweden).