homesite mapcontact search
Newsroom   
Careers   
Solutions     
Products & Services    
Support    
Whitepapers     
Case Studies    
Alliances     
Sales     
Offices     

Support
Datacryptor®
 
Datacryptor® Link

This document is intended to bring together various sources of information on the Datacryptor® Link units. It covers common configuration issues and suggestions for troubleshooting.

  • Datacryptor® Link Introduction

This section gives some background information on how the Datacryptor® Link unit fits into common networking environments.


Click on picture thumbnails to view diagrams

The diagram above illustrates a circuit without the Datacryptor® in situ. On the left there is a DTE (Data Terminating Equipment) device - this could be a PC, a terminal etc. On the right there is a DCE (Data Circuit Terminating Equipment) device - this could be a modem, a router, a multiplexor etc. The arrows beneath the diagram indicate which devices drive which lines on the cable (or other communications medium). These are:
  • DTR - Data Terminal Ready
  • RTS - Request To Send
  • DSR - Data Set Ready
  • CTS - Clear To Send
  • DCD - Data Carrier Detect

Using these lines the DCE and DTE negotiate handshaking, data transfer, flow control etc.


Click on picture thumbnail to view diagram

The Datacryptor® is now put into the circuit. If you imagine the setup above mirrored on the other side of the cloud we would have an encrypted tunnel set between the Datacryptor® and the data from one DTE to the other would be encrypted. You can see in the diagram that the Datacryptor® presents a DCE interface on its host side and a DTE interface on its network port. The Datacryptor® controls the communication between the DTE Terminal and the DCE modem/router but also transparently encrypts the line data.

There is another issue to consider here; the Datacryptor® is operating transparently here - the DTE terminal believes it is connected directly to the DCE modem/router. However, there are occasions when the Datacryptor® must interrupt this communication flow between the two devices. When the Datacryptor® performs a key exchange or peer management (the management of a remote unit via a local unit) it communicates directly with the remote Datacryptor®. This activity temporarily prevents the Datacryptor® from passing user data from the DTE Terminal. In its default mode the Datacryptor® will drop CTS (Clear To Send) on its host port to tell the DTE Terminal to hold off sending data whilst the Datacryptor® performs its key exchange etc. Different DTE devices may react differently to this behaviour but may start generating errors (as it is trying to send data but it is being told that it cannot). The configuration options to change this behaviour are discussed in the next section.

  • Datacryptor® Link Comms Tab Options

This section contains information on the FPV configuration options for using the Datacryptor® Link unit. The first tab is the Comms tab. Note that this tab only appears when using v.24, v.35 or x.21 interfaces (not E1/T1).


Click on picture thumbnail to view diagram

As discussed above the Datacryptor® controls the communication lines between the DTE and DCE device. The Comms tab allows you to configure this behaviour to take into account different device behaviour. The page is divided into two columns - Normal and Safetalk. The Normal column allows you to configure the line state during normal operation (i.e. when user data is being sent/received). The Safetalk column allows you to configure the line state during key exchange/peer management operation.

The diagram above illustrates the default settings on the Datacryptor® (which can be recalled by pressing the "Default" button). You can see that the default is for all the signals to remain the same during normal/safetalk operation except for the CTS/Indicate. You can see that during safetalk the Datacryptor® will drop CTS on its host side. This is the behaviour discussed above where the Datacryptor® will drop CTS during key exchange to tell the DTE device on the host side to stop sending data. It is possible to change this behaviour to tell the Datacryptor® to keep CTS high during safetalk. You may wish to do this if your DTE device relies on seeing CTS high at all times. If you do this then the DTE device will just continue sending data even though it will not reach the intended destination. This configuration relies on higher level protocols to recover from such loss of data.

The Network Delay option allows you to configure the amount of time the Datacryptor® will wait whilst doing a key exchange before reporting "No response from peer" - you may need to increase this on slow data lines.

  • Datacryptor® Link Advanced Comms Options

By clicking on the Advanced button you will see this window:

See the section below on Datacryptor® clocking issues for information about clock polarities. By clicking on the Data Gating tab you will see this window:

The following is taken from the Datacryptor® help file on Data Gating;
In situations where the line may become inactive, in data terms, but may still be transmitting a holding pattern, e.g. Mark or Space which will continue to be encrypted (or decrypted) and passed to other equipment. This encrypted data may cause connected equipment to believe it is receiving erroneous data. Data Gating can be used to transmit a stream of 1’s in place of the erroneous data. To enable Data Gating decide on the direction the data gating is required and select the line signal which must go "low" in order to start the data gating, e.g.: DTR or RTS.

  • Datacryptor® Link Safetalk Options

Note that this tab only appears when using v.24, v.35 or x.21 interfaces (not E1/T1).
This section contains information on the configuration options on the Safetalk tab. Safetalk is the name given to data sent between Datacryptor® Link units for key exchanges, peer management etc (as opposed to user data). This tab allows you configure how the Datacryptor® decides what preconditions must be met before it will go into Safetalk mode. This allows you to configure how much precedence is given to Safetalk data in relation to user data.
As you can see below, the default setting is "Don't care" for all preconditions - this means that if the Datacryptor® has some Safetalk data to send it will send it regardless of the status of the line signals on the network/host side. This effectively means that the Datacryptor® will always interrupt user data when it wishes to send data in Safetalk mode.

Click on picture thumbnail to view diagram

You may not wish this happen, you may wish for certain preconditions to be met before entering Safetalk mode, for example you may want to wait for CTS/Indicate to be high before entering Safetalk mode (see below). This means that the Datacryptor® will wait for the CTS signal on its network side to go high before entering Safetalk mode.


Click on picture thumbnail to view diagram


The Operator section at the bottom allows you to combine different combinations of settings using the AND or OR operators. For example you could specify that CTS must be high AND DCD must be high before Safetalk mode can be entered into. Or you could specify that that CTS must be high OR RTS must be low before Safetalk mode can be entered into. These settings assume that you have a good knowledge of the attached DCE/DTE devices and how they behave.

The Time Out setting at the top is a value in seconds which describes how long the Datacryptor® will wait for these pre-conditions to be met. If this time limit is exceeded the Datacryptor® will enter Safetalk mode regardless of the preconditions specified.

  • Datacryptor® setup using Cisco routers

The example below shows how to set up a Datacryptor® Link circuit using Cisco routers and a null modem device.


Click on picture thumbnail to view diagram


The null modem acts as the WAN link between the two Datacryptor®s and the routers act as the LAN interface at each end of the link. The only configuration of the routers that is needed is to add the IP addresses on the diagram above and also to add static routes (e.g. ip route 192.168.0.0 255.255.255.0 s0/0 on Router_01 and the equivalent on Router_02). If you find that the Serial interface on the routers flap (i.e. go up and down constantly) you can try turning off keepalives on the Serial interface with the command no keepalive.

  • Datacryptor® clocking issues

When two synchronous devices (such as two Datacryptor®s) are connected to each other a clock signal is required to synchronize the sending and receiving of data between the two devices. The two devices need to be synchronized to the same clock speed so that they send and receive at the same rate (measured in bits per second). DTE devices will often provide their own clock but the Datacryptor® does not and relies on the existence of an external clock source. It is usual to derive the clock source from the network side of the Datacryptor® although it is possible to derive the clock source via the host port (see "get clock sync from host" mode on the Comms tab). If the Datacryptor® Link does not see a clock signal on the network LED will flash on and off, a solid network LED means that Datacryptor® has detected a clock signal. The network LED will also flash if the clock speed is out of range (too fast) for the Datacryptor® - e.g. if you presented a clock speed of 4Mb/sec to a Standard speed Datacryptor® Link. You would also see an error in the Datacryptor® log saying something like "Encrypt clock out of range".
In our test example above we use an x.21 null modem to generate the clock signal, in a real network environment the clock would probably be provided by a router, modem or mux.

Problems can occur when the clock is generated at one end of the link and, because of the delay caused by the link, the clock signal is delayed when it reaches the other end. This can cause the Datacryptor®s to become out of sync because they are not using the same clock signal to sample the data. This is where the "invert clock" settings (see Advanced settings on the Comms tab) come in - by inverting the clock on either the network/host port tells the Datacryptor® to sample the data on the opposite transition of the clock signal. There are no hard and fast rules for how the "invert clock" settings should be used as it is dependant on how the system is set up (where the delay is, speed of the link etc.).

 
Pages 1 / 2



 

 

 


 
 
 
 
           © Thales 2007         Legal Notice