Asentria SiteBoss 530, User Manual

Page: 65 / 140

Asentria SiteBoss 530 User Manual
59
Raising a VPN
In SitePath version
< 1.01.000
, a SitePath user clicked the Connect button in the SitePath web UI in order to initate
remote access. The Connect button immediately turned into a Disconnect button (meaning the connection was set up
immediately). This speed is because the VPN to the unit is always up. Now with VPN on-demand (SitePath version >=
1.01.000), the VPN may be down when a SitePath user clicks the Connect button. To raise the VPN there is a delay of
typically 15 seconds while the VPN is negotiated. During this time the Connect button (labeled as "Connect (will entail
a delay)") turns dim. Once the VPN is up the dim Connect button turns into a non-dim Disconnect button.
On units with version
>= 2.04.030
, the vpn can be raised multiple ways:
•
sk net.vpn.1.cmd =2
•
cause an event that has an action that causes the unit to connect to SitePath
•
enter
DOTRAP
, if any of the configured SNMP managers are the address of SitePath
•
enter
DOMAIL
, if the configured SMTP server is the address of SitePath
•
enter
PUSHTEST
or
PUSHNOW
, if the configured FTP push server address is the address of SitePath
•
wait for the unit to raise a VPN on its own (or SitePath's own) accord, which can happen in multiple ways:
•
SitePath user wants access to the unit or any of its configured CPEs that are visible to SitePath
•
unit needs to sync its clock (clock sync is automatically configured during commissioning)
•
unit needs to deliver event actions to SitePath or to a machine via SitePath
•
unit needs to FTP push CDR to SitePath
When raising a VPN via
DOTRAP
,
DOMAIL
, or
PUSHTEST
, the user receives feedback about SitePath connectivity
progress, much like the user receives feedback when they use those commands and cause PPP to be raised. There
are two main factors to consider when the unit sends data to SitePath:
1. the VPN status; if it is down, it needs to be raised.
2. the authorization status; all types of traffic sent over the VPN first needs to be authorized to be able to use
the VPN, and this is negotiated over the VPN with SitePath before that type of traffic (e.g., email, alarms,
etc.) is commenced. Once a type of traffic is authorized for a VPN, it remains authorized until the VPN
goes down.
Once a VPN is raised, it will remain up until it is decided and agreed by both the unit and SitePath that the VPN should
go down. This typically happens due to inactivity timeout, which can controlled by the SitePath key
vpn.idle.timeout
. (3 minutes by default) Note that so long as a SitePath user is connected to a unit or any of its
CPEs, the VPN will not go down, even if there is no activity on the VPN to warrant the inactivity timeout triggering.
Lowering a VPN
A VPN between SitePath and a deployed unit is lowered when no SitePath user has a remote access connection to
the unit or to a CPE attached to the unit, and the inactivity timer for the VPN has expired. The inactivity timer is 3
minutes by default, but can be changed with SitePath key
vpn.idle.timeout
. When the VPN is lowered, a
subsequent operation to raise the VPN has a typical delay of 15 seconds, but can be longer depending on
unpredictable factors such as processor loading and network integrity.
Automatic Data Delivery
Automatic Data Delivery is a general term to describe any data the unit needs to send to SitePath: alarms, emails,
SNMP notifications, polling data, etc., which happens over a VPN. An end user may notice the effect of VOD when
they try to, for example, send an alarm to SitePath and the VPN between the unit and SitePath is down. The attempt
to send a trap causes the unit to raise the VPN, which has an inherent delay. After the VPN is up then the trap is sent.
Therefore sending a trap appears to take as long as it took to raise the VPN under this circumstance.