User Guide
Nodegrid Serial Console™
Nodegrid Services Router™
Nodegrid Gate SR™
Nodegrid Bold SR™
Nodegrid Link SR™
Nodegrid Manager™
This document supports versions 4.1.x.
U.S. Notification
WARNING: Changes or modifications to this unit not expressly approved by the party responsible for compliance could void the user’s authority to operate the equipment.
NOTE: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user will be required to correct the interference at his/her own expense.
Canadian Notification
This Class A digital apparatus complies with Canadian ICES-003.
Cet appareil numérique de la classe A est conforme à la norme NMB-003 du Canada.
European Union Notification
This is a class A product. In a domestic environment, this product may cause radio interference in which case the user may be required to take adequate measures.
Japan Notification
この装置は、クラスA情報技術装置です。 この装置を 家庭環境で使用すると電波妨害を引き起こすことが あります。
この場合には使用者が適切な対策を講ずるよう要求されることがあります。VCCI - A
All other marks are the property of their respective owners. This document may contain confidential and/or proprietary information of ZPE Systems, Inc., and its receipt or possession does not convey any right to reproduce, disclose its contents, or to manufacture or sell anything that it may describe. Reproduction, disclosure, or use without specific authorization from ZPE Systems, Inc. is strictly prohibited.
©2013-2019 ZPE Systems, Inc. All rights reserved.
Table of Content
IntroductionProduct OverviewNodegrid Serial ConsoleNodegrid Serial Console - S SeriesNodegrid Serial Console - R SeriesNodegrid Serial Console - T SeriesNodegrid Services Router FamilyNodegrid Services RouterNodegrid Services Router Expansion ModulesExpansion Module Compatibility ChartNodegrid Gate SRNodegrid Bold SRNodegrid Link SRNodegrid ManagerInstallation Hardware InstallationWhat is in the boxInstallation of Modules for Nodegrid Services RouterRack MountingNetwork ConnectionConnecting power cord(s)Connecting target devicesConnecting serial target devicesConnecting IP target devicesConnecting to a Nodegrid Connection through the Console portConnecting through ETH0Connection through Wi-FiConnection through KVM PortI/O Ports (GPIO)Nodegrid Manager InstallationCreating a Virtual Machine - VMWareInstalling Nodegrid ManagerInitial Network ConfigurationIdentify the current IP addressIdentify current IP address - WebUIIdentify current IP address - CLIDefine Static IP AddressDefine Static IP Address - Web UIDefine Static IP Address - CLIInterfacesWebUICLIShellDevice AccessDevice SessionsDevice Sessions - Web UICopy & PasteDevice Sessions - CLIDevice InformationDisplay Device Information - Web UIDisplay Device Information - CLIDevice ViewsTable ViewTree ViewNode ViewMap ViewImage ViewSearchDevice SearchGlobal SearchDevice Management (Managed Devices)Configuration of Managed DevicesSerial DevicesConfigure Serial Devices - WebUIConfigure Serial Devices - CLIService Processor DevicesAdd Service Processor Devices - WebUIAdd Service Processor Devices - CLIDevices with SSHAdd Devices with SSH - WebUIAdd Devices with SSH - CLIConsole ServersAdd Console Servers - WebUIAdd Console Server Ports - WebUIAdd Console Servers - CLIAdd Console Server Ports - CLIKVM SwitchesAdd KVM Switches - WebUIAdd KVM Switch Ports - WebUIAdd KVM Switches - CLIAdd KVM Switch Ports - CLIRack PDU's Rack PDUs - WebUIAdd Rack PDU - CLICisco UCSAdd Cisco UCS - WebUIAdd Cisco UCS - CLINetappAdd Netapp - WebUIAdd Netapp - CLIInfraboxAdd Infrabox - WebUIAdd Infrabox - CLIVirtual MachinesAdd VMWare Virtual Machines - WebUIInstall VMRC - WebUIAdd VMWare Virtual Machines - CLIAdd KVM Virtual Machines - WebUIAdd KVM Virtual Machines - CLINodegrid DevicesUSB SensorsKVM DongleBluetoothAuto-DiscoveryAuto Discovery of Console Server and KVM Switch PortsAuto Discovery of Console Server and KVM Switch ports - WebUIAuto Discovery of Console Server and KVM Switch ports - CLIAuto Discovery of Network DevicesAuto Discovery of Network Devices - WebUIAuto Discovery of Network Devices - CLIAuto Discovery of Virtual MachinesAuto Discovery of Virtual Machines - WebUIAuto Discovery of Virtual Machines - CLIAuto Discovery of DHCP ClientsAuto Discovery of DHCP Clients - Web UIAuto Discovery of DHCP Clients - CLIDevice SettingsHostname DetectionConfigure Hostname DetectionGlobal Settings for Hostname DetectionCreate a Probe or MatchMulti SessionsBreak SignalEscape SequencesDisable User Authentication SSH / Telnet PortBinary SocketIP AliasesLocationWeb URLIconModeExpirationDevice State DetectionSerial DevicesIP DevicesRun Custom Scripts on Device Status ChangeData LoggingEvent LoggingAlert Strings and Custom ScriptsCustom FieldsCommands and Custom CommandsTree View SettingsDevice TypesPreferencesPower Menu PreferencesSession PreferencesTrackingOpen SessionsEvent ListSystem UsageDiscovery LogsNetwork StatisticsDevice StatisticsSchedulerHW MonitorI/O Ports (GPIO)SystemLicensesSystem PreferencesNodegrid LocationSession Idle TimeoutNodegrid ConfigurationLogin logo imageLogin BannerUtilization RateConsole PortPower SuppliesNetwork BootPXE BootDate and TimeNTP AuthenticationCellular Tower SynchronizationLoggingCustom FieldsDial-Up SchedulerSystem MaintenanceReboot & ShutdownSoftware UpgradeSave SettingsApply SettingsRestore to Factory Default SettingsSystem Configuration ChecksumSystem CertificateNetwork ToolsAPIRESTful APIgRPCSMS Triggered ActionsSMS SettingsSMS Actions and Messages ExamplesSMS WhitelistDigital I/O NetworkSettingsHostname and Domain NameNetwork FailoverIPv4 and IPv6 ProfileIP ForwardingLoopback AddressReverse Path FilteringMultiple Routing TablesNetwork Connection ConfigurationBonding InterfacesEthernet InterfacesMobile Broadband GSM InterfaceVLAN InterfaceWIFI InterfaceWIFI Access PointWIFI ClientWIFI SettingsBridge InterfaceAnalog Modem InterfaceStatic RoutesManual HostnamesDHCP ServerNetwork Switch ConfigurationSwitch InterfacesVLAN ConfigurationUnttaged/Access PortsTagged/Trunk PortsBackplane PortsVPNSSL VPNSSL VPN CLIENT SSL VPN SERVERIPSEC VPNAuthentication Methods Pre-shared Keys RSA Keys X.509 Certificates Connection Scenarios Host to Host Host to Site Site to Site Host to Multi-Site Site to Multi-Site Configuration of IPSec Advanced Network FeaturesVRRP (Virtual Router Redundancy Protocol) SupportAuthenticationAdd a serverAdd a groupLocal AccountsManage Local UsersHash Format PasswordPassword RulesGroupsManage GroupsCreate a User GroupAdd local users to a groupAssign system permissions and settings to a groupAssign external groupsAssign device permissionsAssign power outlet permissionsExternal Authentication ProviderLDAP and Active DirectoryTACACS +RADIUSKerberosRSA SecurID 2-factor authenticationNodegrid Setup: Web InterfaceAdd SecurID ServerSet Certificate to access SecurID ServerAssign the 2-factor authentication to an Authentication methodUsersAuthenticate App (for Cloud Authentication Services only)LoginSSHKey AuthenticationSecurityFirewallNATServicesZPE CloudUsage of zpe_cloud_enrollNo argumentsArguments (Customer Code and Enrollment Key)Active ServicesManaged DevicesIntrusion PreventionSSHWeb ServiceCryptographic ProtocolsClusterPeers OverviewCluster SettingsEnable ClusterAutomatic EnrollmentLicense PoolPeer ManagementAuditing SettingsData LoggingEventsDestinationsFileSyslogSNMP TrapEmail NotificationMonitoringCustomizing a Monitoring TemplateSNMP TemplateIPMI Discovery TemplateEnabling MonitoringDashboardExploring Data PointsCreating a VisualizationLine ChartsArea ChartsCreating a DashboardInspecting a DashboardApplicationsDocker ApplicationsDocker ImagesDocker ContainersApplication LinksNetwork Function VirtualizationAppendixTechnical SupportSubmit a Support TicketUpdates and PatchesConfiguring Virtual Serial Port (vSPC) on VM ServersDC PowerFundamentalsCase of -48VDC supply Case of +48VDC supplyAC PowerSerial Port PinoutSafety Quick Install Guide RoHS Data PersistenceSoft RemovalHard Removal - Secure EraseCredits
The Nodegrid 4.1 User manual covers the Nodegrid Platform version 4.1 and the supporting units like the Nodegrid Serial Console Series, Nodegrid Services Router, Nodegrid Gate SE, Nodegrid Bold SR and Nodegrid Link SR.
Nodegrid Serial Console product line consolidates and manages attached devices via Serial Port Connection including servers, network routers and switches, storage, PDUs, UPSs, and any other device with a serial port.
NODEGRID SERIAL CONSOLE (S Series) is made to fit any modern and legacy mixed environment. With auto-sensing ports, you can use the S Series Console Servers within any environment whether using straight-through cables or with legacy adapters.
Hardware Specifications
Item | Description |
---|---|
CPU | Intel x86_64 dual core CPU |
Memory & Storage | 4 GB of DDR3 DRAM, 32 GB mSATA SSD |
Interfaces | 2 Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 or 2 SFP+ Fiber interfaces compatible with 1GB / 2.5GB / 10GB modules 16, 32, 48 RS-232 serial ports on RJ45 @ 230,400 bps max/port. 1 RS-232 serial console port on RJ45 1 USB 3.0 Host,1 USB 2.0 Host and 12 USB 2.0 Hosts on Type A connector 1 HDMI |
Power | Single/Dual AC 100-240 VAC, 50/60 Hz Dual DC: 40-63 VDC Power consumption 45 W typical |
Physical | Front-Rear mounting brackets Size (L x W x H): 443 x 312 x 43 mm (17.4 x 12.3 x 1.7 in), 1U Weight: 4.9 kg (10.8 lb), depending on options Front-to-Back or Back-to-Front Fans (Swappable) |
Environmental | Operation: 0 to 50° C (32 to 122° F), 5-95% RH, non-cond. Storage: -20 to 67° C (-4 to 153° F), 10-90% RH, non-cond. |
Interfaces Front
Port | Description |
---|---|
HDMI | HDMI Interface |
USB | USB 2.0 Port |
PWR | Power LED Green: · Solid - normal, · Off - power is off |
SYS | System LED Green: · Blinking - normal · Fast Blink - RST button Acknowledgment · Off or Solid - no activity |
RST | Reset button: <3s system reset, >10s configuration factory reset and system reset |
FAN | Fan's |
USB | 1 x USB 2.0 Port, 12 x USB 1.1 Ports |
Interfaces Back
Port | Description |
---|---|
Power | Single or Dual Power Sockets |
Serial | Serial Interfaces ·Right/Orange DCD/DTR - On: port open and/or cable connected, Off: not ready ·Left/Green RX/TX - Blinking: data activity, Off: no activity |
ETH0/SFP0 | Network Interface Copper: ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault SFP 1Gb/10Gb: |
ETH1/SFP1 | Network Interface Copper: ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault SFP 1Gb/10Gb: |
Console | Console MGMT Interface ·Right/Orange LED Power Failure - Blinking: Power supply failure/off (for dual power supply models), Off: normal ·Left/Green LED System Activity - Blinking: normal, Off or Solid: no activity |
USB | 1 x USB 3.0 |
NODEGRID SERIAL CONSOLE (R Series) is made to fit into major hardware environments like Cisco, Arista, Dell, Palo Alto Networks, and Juniper. R Series Serial Consoles are perfect for retrofits and to upgrade Rack Standards of existing builds.
Hardware Specifications
Item | Description |
---|---|
CPU | Intel Atom x86_64 dual core @ 1.75 GHz CPU |
Memory & Storage | 4 GB of DDR3 DRAM, 32 GB mSATA SSD |
Interfaces | 2 Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 or 2 SFP+ Fiber interfaces compatible with 1GB / 2.5GB / 10GB modules 16, 32, 48, 96 RS-232 serial ports on RJ45 @ 230,400 bps max/port. 1 RS-232 serial console port on RJ45 1 USB 3.0 Host and 2 USB 2.0 Hosts on Type A connector 1 HDMI |
Power | Single/Dual AC 100-240 VAC, 50/60 Hz Dual DC: 40-63 VDC Power consumption 45 W (on 96 ports) |
Physical | Front-Rear mounting brackets Size (L x W x H): 443 x 312 x 43 mm (17.4 x 12.3 x 1.7 in), 1U Weight: 4.9 kg (10.8 lb), depending on options |
Environmental | Operation: 0 to 50° C (32 to 122° F), 5-95% RH, non-cond. Storage: -20 to 67° C (-4 to 153° F), 10-90% RH, non-cond. |
Interfaces Front
Port | Description |
---|---|
HDMI | HDMI Interface |
USB | 2 x USB 2.0 Port |
PWR | Power LED Green: · Solid - normal, · Off - power is off |
SYS | System LED Green: · Blinking - normal · Fast Blink - RST button Acknowledgment · Off or Solid - no activity |
RST | Reset button: <3s system reset, >10s configuration factory reset and system reset |
Interfaces Back
Port | Description |
---|---|
Power | Single or Dual Power Sockets |
Serial | Serial Interfaces ·Right/Orange DCD/DTR - On: port open and/or cable connected, Off: not ready ·Left/Green RX/TX - Blinking: data activity, Off: no activity |
ETH0/SFP0 | Network Interface Copper: ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault SFP 1Gb/10Gb: |
ETH1/SFP1 | Network Interface Copper: ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault SFP 1Gb/10Gb: |
Console | Console MGMT Interface ·Right/Orange LED Power Failure - Blinking: Power supply failure/off (for dual power supply models), Off: normal ·Left/Green LED System Activity - Blinking: normal, Off or Solid: no activity |
USB | USB 3.0 |
NODEGRID SERIAL CONSOLE (T Series) is made to fit into environments still utilizing legacy devices and can be a direct replacement of the legacy console server.
Hardware Specifications
Item | Description |
---|---|
CPU | Intel Atom x86_64 dual core @ 1.75 GHz CPU |
Memory & Storage | 4 GB of DDR3 DRAM, 32 GB mSATA SSD |
Interfaces | 2 Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 or 2 SFP+ Fiber interfaces compatible with 1GB / 2.5GB / 10GB modules 16, 32, 48, 96 RS-232 serial ports on RJ45 @ 230,400 bps max/port. 1 RS-232 serial console port on RJ45 1 USB 3.0 Host and 2 USB 2.0 Hosts on Type A connector 1 HDMI |
Power | Single/Dual AC 100-240 VAC, 50/60 Hz Dual DC: 40-63 VDC Power consumption 45 W (on 96 ports) |
Physical | Front-Rear mounting brackets Size (L x W x H): 443 x 312 x 43 mm (17.4 x 12.3 x 1.7 in), 1U Weight: 4.9 kg (10.8 lb), depending on options |
Environmental | Operation: 0 to 50° C (32 to 122° F), 5-95% RH, non-cond. Storage: -20 to 67° C (-4 to 153° F), 10-90% RH, non-cond. |
Interfaces Front
Port | Description |
---|---|
HDMI | HDMI Interface |
USB | 2 x USB 2.0 Port |
PWR | Power LED Green: · Solid - normal, · Off - power is off |
SYS | System LED Green: · Blinking - normal · Fast Blink - RST button Acknowledgment · Off or Solid - no activity |
RST | Reset button: <3s system reset, >10s configuration factory reset and system reset |
Interfaces Back
Port | Description |
---|---|
Power | Single or Dual Power Sockets |
Serial | Serial Interfaces ·Right/Orange DCD/DTR - On: port open and/or cable connected, Off: not ready ·Left/Green RX/TX - Blinking: data activity, Off: no activity |
ETH0/SFP0 | Network Interface Copper: ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault SFP 1Gb/10Gb: |
ETH1/SFP1 | Network Interface Copper: ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault SFP 1Gb/10Gb: |
Console | Console MGMT Interface ·Right/Orange LED Power Failure - Blinking: Power supply failure/off (for dual power supply models), Off: normal ·Left/Green LED System Activity - Blinking: normal, Off or Solid: no activity |
USB | USB 3.0 |
The Nodegrid Services Router is a platform appliance designed for software-defined networking (SDN), out of band (OOB) management, DevOps, cellular failover, docker, SD-WAN, remote/branch offices, retail locations, and network function virtualization (NFV) capabilities.
NODEGRID SERVICES ROUTER is a modular open platform appliance designed for software-defined networking (SDN), out of band (OOB) management, DevOps, cellular failover, docker, SD-WAN, remote/branch offices, retail locations, and network function virtualization (NFV) capabilities.
Hardware Specifications
Item | Description |
---|---|
CPU | Intel Multi-core x86_64 CPU |
Memory & Storage | 8 GB of DDR4 DRAM, 32 GB mSATA SSD (Factory upgradable) |
Interfaces | 2 SFP+ Ethernet 2 Gigabit Ethernet 1 RS-232 serial console port on RJ45 1 USB 3.0 1 USB 2.0 1 HDMI |
Power | Single/Dual AC 100-240 VAC, 50/60 Hz Dual DC: 36-75 VDC Power Consumption 90W typical |
Physical | Front-Rear mounting brackets Size (L x W x H): 438 x 332 x 43mm (17.2 x 13.1 x 1.7 in), 1U Weight: 4.9 kg (10.8 lb), depending on options Air Exhaust or Air Intake Fans (swappable) |
Environmental | Operation: 0 to 45° C (32 to 113° F), 5-95% RH, non-cond. Storage: -20 to 67° C (-4 to 153° F), 10-90% RH, non-cond. |
Interfaces Front
Port | Description |
---|---|
Slot 1 | Slot for Module |
Slot 2 | Slot for Module |
Slot 3 | Slot for Module |
SFP+ 0 | Network Interface ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 10Gb link speed ·Right/Orange - 1Gb link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
SFP+ 1 | Network Interface ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 10Gb link speed ·Right/Orange - 1Gb link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
ETH0 | Network Interface ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
ETH1 | Network Interface ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
Console | Console MGMT Interface ·Right/Orange LED Power Failure - Blinking: Power supply failure/off (for dual power supply models), Off: normal ·Left/Green LED System Activity - Blinking: normal, Off or Solid: no activity |
USB | USB 3.0 |
RST | Reset button: <3s system reset >10s configuration factory reset and system reset |
Interfaces Back
Port | Description |
---|---|
Slot 4 | Slot for Module (depending on the Model) |
Slot 5 | Slot for Module (depending on the Model) |
USB | 2 x USB 2.0 Port |
HDMI | HDMI Interface |
PWR | Power LED Green: · Solid - normal, · Off - power is off |
SYS | System LED Green: · Blinking - normal · Fast Blink - RST button Acknowledgment · Off or Solid - no activity |
FAN | Fan's |
Power Socket | Dual Power Sockets |
Power | Single or Dual Power Sockets |
Nodegrid Services Router has up to five slots for modules that provides extreme flexibility for function expansion.
Module | Picture | Specification |
---|---|---|
16-Port 1GbE | 1000BASE-T Cat5e or better | |
16-Port SFP 1GbE | Supports all SFP Modules | |
8-Port SFP+ 10GbE | Supports all SFP+ Modules | |
8-Port PoE+ | 25.5W max power per port Total max 150W PoE+ available Configurable power budget | |
16-Port Serial | RJ45 Serial Rolled port max 230,400 bps | |
16-Port USB | USB 2.0 interfaces Type A | |
M.2 Cellular + Antenna | For up to 2x 4G/LTE modems | |
M.2 SATA | For up to 2x mSATA storage modules | |
Storage | For 2.5" SATA (HDD/SDD) storage | |
Compute | Compute module (server on a card), provides independent compute capabilities. |
Expansion Card | Slot 1 | Slot 2 | Slot 3 | Slot4 | Slot5 |
---|---|---|---|---|---|
16-Port GbE Ethernet | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
16-Port SFP | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
16-Port Serial | ✔ | ✔ | ✔ | ✔ | ✔ |
16-Port USB | ✔ | ✔ | ✔ | ✔ | ✔ |
M.2 Cellular / Wi-Fi | ✔ | ✔ | ✔ | ✔ | ✔ |
8-Port SFP+ | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
8-Port POE+ | ✔ | ✔ | ✔ | – | – |
Compute | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
Storage * | – | – | – | ✔ | ✔ |
M.2 SATA * | – | – | – | ✔ | ✔ |
Note:
(*) The Nodegrid Services Router supports a maximum of 2 SATA drives, which can be divided into 2 Storage cards or in one M.2 SATA card
(**) The Secure Isolated Mode allows for the management of the cards as if they would be located in a normal Slot, but the network traffic is isolated from any other slot.
Nodegrid Gate SR brings agility to the network. Perfect for both the data center and branch, Nodegrid Gate SR packs tremendous power in a small form factor, resulting in a truly robust and dynamic, secure infrastructure management solution. Configure and manage Nodegrid Gate SR via the ZPE Cloud.
Hardware Specifications
Item | Description |
---|---|
CPU | Intel Multi-core x86_64 CPU |
Memory & Storage | 8-32 GB of DDR4 DRAM, 32 GB SATADOM SSD (Upgradeable) |
Interfaces | 4 PoE+ Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 with Built-in Switch 4 Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 with Built-in Switch 8 RJ45 serial ports 2 SFP+ (10G) 1 Console port on RJ45 2 USB 3.0 Hosts on Type A 2 USB 2.0 Hosts on Type A 2 GPIO 1 Digital Out Port 1 Relay Port 1 Wi-Fi slot (client or server) optional 2 Cellular Slots (4G/LTE) with Dual SIM - optional 1 HDMI port |
Power | 36V - 75VDC dual power input - redundant active/passive input, the highest voltage will be active. AC Power adapter (add-on) 100-240V ~50-60Hz, 1.2A, Operating Temperature -25 to 60°C Power consumption 45 W typical |
Physical | Front-Rear mounting brackets Size (L x W x H): 241.3 x 260.4 x 44.5 mm (9.5 x 10.25 x 1.75 in) Weight: .9 kg (2 lb) Shipping weight: 3.6 kg (8.0 lb) Shipping (L x W x H): 349.2 x 374.7 x 177.8 mm (13.75 x 14.75 x 7 in) |
Environmental | Operating: -20°C to 60°C (-4 to 140° F), 5-95% RH, non-cond. Storage: -20 to 67° C (-4 to 153° F), 10-90% RH, non-cond. |
Interfaces Front
Designation | Description |
---|---|
DIO0 | Digital I/O TTL level 5.5V max @ 64mA |
DIO1 | Digital I/O TTL level 5.5V max @ 64mA |
OUT0 | Signal MOSFET Digital Output 2.5V to 60V @ 500mA max |
Relay Output | NC relay contact max 24V @ 1A |
Console | Console MGMT Interface |
USB | 2 x USB 2.0 |
HDMI | Monitor Interface |
Channel A | Signal Strength indicator for Channel A |
Channel B | Signal Strength indicator for Channel B |
PWR | Power LED Green: · Solid - normal · Off - power is off |
SYS | System LED Green: · Blinking - normal · Fast Blink - RST button Acknowledgment · Off or Solid - no activity |
RST | Reset button: <3s system reset >10s reset to factory default and system reset |
Power Switch | Power on/off Switch |
Interfaces Back
Port | Description |
---|---|
PWR | Power LED Green: · Solid - normal · Off - power is off |
V2- / GND / V2+ | Power Connector for External Power Supply 36V - 75VDC dual power input (redundant) |
V1- / GND / V1+ | Power Connector for External Power Supply 36V - 75VDC dual power input (redundant) |
PoE+ | 4 x PoE+ Network Interface numbered 1 to 4 ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
NET | 4 x Network Interface numbered 5 to 8 ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
SFP+ 0 | SFP+ Network Interface 0 ·Left/Yellow - Solid: Link UP, Off: no link/cable disconnected ·Right/Green - Solid: Link UP, Blinking: Activity, Off: no link/cable disconnected |
SFP+ 1 | SFP+ Network Interface 1 ·Left/Yellow - Solid: Link UP, Off: no link/cable disconnected ·Right/Green - Solid: Link UP, Blinking: Activity, Off: no link/cable disconnected |
ETH0 | Network Interface ·Left/Yellow - Solid: Link UP, Blinking: data activity, Off: no link/cable disconnected/Ethernet fault ·Right/Green - Solid: 1000BaseT link speed, Off: 100/10BaseT link speed or off |
USB | 2 x USB 3.0 Port |
Serial | Serial Interfaces 1-8 ·Right/Orange DCD/DTR - On: port open and/or cable connected, Off: not ready ·Left/Green RX/TX - Blinking: data activity, Off: no activity |
Nodegrid Bold SR is an open platform appliance designed for secure access and control over remote and IoT devices at the EDGE of your network. Bold SR supports cellular failover, Network Function Virtualization (NFV) and Software Defined Networking with a focus on SD-WAN.
Hardware Specifications
Item | Description |
---|---|
CPU | Intel Multi-core x86_64 CPU |
Memory & Storage | 4 GB of DDR3 DRAM, 32 GB SATADOM SSD (Upgradeable) |
Interfaces | 1 Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 4 Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 with Built-in Switch 8 RS-232 serial ports on RJ45 1 RS-232 console port on RJ45 USB 3.0 Host on Type A 2 USB 2.0 Hosts on Type A 1 Wi-Fi – optional 2 Cellular Slots with Dual SIM – Optional 1 VGA port |
Power | 12 VDC via external 100–240 VAC, 50/60 Hz adapter 12 VDC via external 48 VDC adapter Power consumption 25 W typical |
Physical | Front-Rear mounting brackets Size (L x W x H): 142 x 201 x 44 mm (5.5 x 7.9 x 1.73 in) Weight: 1.2 kg (2.6 lb) |
Environmental | Operation: -20°C to 50°C (-4 to 122° F), 20-90% RH, non-cond. Storage: -20 to 67° C (-4 to 153° F), 10-90% RH, non-cond. |
Interfaces Front
Port | Description |
---|---|
Channel A | Signal Strength indicator for Channel A |
Channel B | Signal Strength indicator for Channel B |
Console | Console MGMT Interface |
PWR | Power LED Green: · Solid - normal, · Off - power is off |
SYS | System LED Green: · Blinking - normal · Fast Blink - RST button Acknowledgment · Off or Solid - no activity |
RST | Reset button: <3s system reset, >10s configuration factory reset and system reset |
Power Switch | Power on/off Switch |
Interfaces Back
Port | Description |
---|---|
PWR IN | Power Socket for external Power Supply |
Monitor | VGA Interface |
ETH0 | Network Interface ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
USB | 2 x USB 2.0 Port 2 x USB 3.0 Port |
ETH1 | Network Interface(NET) ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
ETH2 | Network Interface(NET) ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
ETH3 | Network Interface(NET) ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
ETH4 | Network Interface(NET) ·Left/Green - Blinking: data activity, Solid: ready, Off: no link/cable disconnected/Ethernet fault ·Right/Green - 1000BaseT link speed ·Right/Orange - 100BaseT link speed ·Right/Off - no link/cable disconnected/Ethernet fault |
Serial | Serial Interfaces 1-8 ·Right/Orange DCD/DTR - On: port open and/or cable connected, Off: not ready ·Left/Green RX/TX - Blinking: data activity, Off: no activity |
Nodegrid Link SR brings agility to the branch network, packing tremendous power in a compact design – Truly robust and dynamic, secure infrastructure management – Configure and manage Link SR via the ZPE Cloud to get your Branch / IoT / M2M / Kiosk / ATM / Remote Locations up and running quickly and easily.
Hardware Specifications
Item | Description |
---|---|
CPU | Intel Multi-core x86_64 CPU |
Memory & Storage | 4-8 GB of DDR3 DRAM, 32 GB SATADOM SSD (Upgradeable) |
Interfaces | 1 Gigabit (10/100/1000BT) Ethernet interfaces on RJ45 with PoE in 1 SFP (1G) Ethernet 1 RJ45 serial ports 1 Console port on RJ45 2 USB 2.0 Hosts on Type A 2 GPIO 2 Digital Out Port 1 Wi-Fi slot (client or server) optional 1 Cellular Slot (4G/LTE) with Dual SIM - optional 1 VGA port |
Power | 10V - 57VDC power input AC Power adapter (add-on) 100-240V~ 50-60Hz, 1.5A PoE power input Power consumption 15 W typical |
Physical | DIM Rail and Wall Mountable Size (L x W x H): 170 x 130 x 55 mm (6.69 x 5.11 x 2.16 in) Weight: 1.58 kg (2.3 lb) Shipping weight: 1.58 kg (3.5 lb) Shipping (L x W x H): 228.6 x 342.9 x 88.9 mm (9 x 13.5 x 3.5 in) |
Environmental | Operating: 0 to 60°C (32 to 140° F), 5-95% RH, non-cond. Storage: -20 to 67° C (-4 to 153° F), 10-90% RH, non-cond. |
Top
Designation | Description |
---|---|
BARS | Signal Strength indicator |
PWR | Power LED Green: · Solid - normal · Off - power is off |
SYS | System LED Green: · Blinking - normal · Fast Blink - RST button Acknowledgment · Off or Solid - no activity |
Interfaces Front
Designation | Description |
---|---|
SFP 0 | SFP Network Interface 0 ·Left/Yellow - Blinking: data activity, Solid: link up, Off: no link/cable disconnected ·Right/Green - Solid: 1000BaseT link speed, Off: no link/cable disconnected |
Serial | Serial Interface 1 ·Right/Orange DCD/DTR - Solid: port open and/or cable connected, Off: not ready ·Left/Green RX/TX - Blinking: data activity, Off: no activity |
Console | Console MGMT Interface |
USB | 2 x USB 2.0 |
VGA | Monitor Interface |
Interfaces Back
Designation | Description |
---|---|
Power Switch | Power on/off Switch |
V1- / GND / V1+ | Power Connector for External Power Supply 10V - 57VDC power input |
ETH0 | 1 Gigabit (10/100/1000BT) Ethernet with PoE in ·Left/Yellow - Solid: link up, Blinking: data activity, Off: no link/cable ·Right/Green - Solid: 1000BaseT link speed, Off: 10/100BaseT link speed |
DIO0 | Digital I/O TTL level 5.5V max @ 64mA |
DIO1 | Digital I/O TTL level 5.5V max @ 64mA |
OUT0 | Signal MOSFET Digital Output 2.5V to 60V @ 500mA max |
OUT1 | Signal MOSFET Digital Output 2.5V to 60V @ 500mA max |
RST | Reset button: <3s system reset >10s reset to factory default and system reset |
Nodegrid Manager provides you with a unified solution to control compute, network, storage, and smart power assets.
Hardware Requirements
Item | Description |
---|---|
CPU | min. 2 x Intel Multi-core x86_64 CPU |
Memory & Storage | 4 GB RAM, min 32 GB HDD |
Interfaces | min 1 Gigabit Ethernet interface |
Supported Hypervisors | VMWare ESX, Linux KVM, Oracle Virtualbox -- Linux OS |
Please refer to Appendix - Quick Install Guide provided along with the unit in the box for quick instructions on how to start your box.
Each unit is shipped with multiple accessories. The below table lists the content of the box.
Model | Mounting Brackets | Power Cables | Loop-Back Adapter | Console Adapter | Network Cable | QuickStart Guide & Safety Sheet |
---|---|---|---|---|---|---|
Nodegrid Serial Console - T Series | Yes | Yes | Legacy | Z000036 | Yes | Yes |
Nodegrid Serial Console - R Series - TxxR | Yes | Yes | Cisco | Z000015 | Yes | Yes |
Nodegrid Serial Console - S Series - TxxS | Yes | Yes | Legacy/Cisco | Z000015 Z000036 | Yes | Yes |
Nodegrid Services Router | Yes | Yes | Legacy/Cisco | Z000014 Z000015 | Yes | Yes |
Nodegrid Bold Services Router | No | External Power Supply | Legacy/Cisco | Z000014 Z000015 | Yes | Yes |
The Nodegrid Services Router supports different modules. These need to be installed before the unit is powered up. The modules should be installed in an ESD protected environment, to avoid damage to any of the components. To install a card follow the following steps.
Note: The blanking panel should be kept for later use. For thermal efficiency and safety, each unused slot needs to be covered with a blanking panel.
Expansion Card | Slot 1 | Slot 2 | Slot 3 | Slot 4 | Slot 5 |
---|---|---|---|---|---|
16-Port GbE Ethernet | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
16-Port SFP | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
16-Port Serial | ✔ | ✔ | ✔ | ✔ | ✔ |
16-Port USB | ✔ | ✔ | ✔ | ✔ | ✔ |
M.2 Cellular / Wi-Fi | ✔ | ✔ | ✔ | ✔ | ✔ |
8-Port SFP+ | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
8-Port POE+ | ✔ | ✔ | ✔ | – | – |
Compute | ✔ | ✔ | ✔ | Secure Isolated Mode ** | Secure Isolated Mode ** |
Storage * | – | – | – | ✔ | ✔ |
M.2 SATA * | – | – | – | ✔ | ✔ |
Note:
(*) The Nodegrid Services Router supports a maximum of 2 SATA drives, which can be divided into 2 Storage cards or in one M.2 SATA card
(**) The Secure Isolated Mode allows for the management of the cards as if they would be located in a normal Slot, but the network traffic is isolated from any other slot.
All units which are shipped with rack mounting brackets can be mounted to fit in the standard 19" rack. Two rack mounting brackets are provided in the box as outlined in Section (What is in the box). The remainder of this document will refer to "rack or cabinet" as "rack".
Note: Some units are actively cooled by fans, these units must be properly mounted into the rack, to ensure that the fans blow into the correct direction. The fan direction can be determined from the part number of the unit.
Model | Part Number | Cooled | Air Flow | |
---|---|---|---|---|
Nodegrid Serial Console - T Series | NSC-Txx-xxxx-xxx | Passive | N/A | |
Nodegrid Serial Console - R Series | NSC-TxxR-xxxx-xxx | Passive | N/A | |
Nodegrid Serial Console - S Series | NSC-TxxS-xxxx-xxx-F | Active | Front-Back (air in) | |
Nodegrid Serial Console - S Series | NSC-TxxS-xxxx-xxx-B | Active | Back-Front (air out) | |
Nodegrid Services Router | NSR-xxxx-xxx | Active | Front-Back (air out) | |
Nodegrid Services Router | NSR-xxxx-xxx | Active | Back-Front (air in) | |
Nodegrid Bold Services Router | BSR-xx-xxxx | Passive | N/A |
Depending on the model and version the unit will either have a minimum of 2 copper Ethernet ports or 2 SFP+ ports. Connect the desired network cables (CAT5e, CAT6, CAT6A) from your network switch port to any of the available network ports of the unit. For models with SFP+ ports install the SFP+ module before the unit is turned on and connect the appropriate cables.
The Nodegrid unit includes one or multiple power supplies (AC or DC). Connect all the power supplies with appropriate cables to an available power source, like a Rack PDU. In case your unit is shipped with one power supply then no redundancy for power failure is available. unit with two power supplies provides redundancy against power failures. Both power supplies should be connected to two independent power sources.
Note - Nodegrid Services Router with PoE: On the Nodegrid Services Router with PoE support, the 2nd power supply is used to provide power for the PoE feature and can not be used to provide redundancy for a power outage.
After all the power supplies are appropriately connected to a power source turn the power supplies on.
(See Appendix - DC Power for information on the DC power supply ports).
Note: To avoid EMC issues use good quality network cable for all port connections.
The cabling and adapters that you may need to use between the unit serial ports and the serial devices’ console port will depend on their pinouts.
Latest serial devices such as routers, switches, and servers will have either a DB9, RJ45 or USB port as their console ports. See the manufacturer’s manual of your serial device console for the port pinout. In case of an RJ45 port console port, it will likely use the Cisco-like pinout.
See table below for cabling you need to use depending on your unit serial ports and Serial Devices’ console port.
Model | Port Type | Pinout | Device Port - RJ45 (Legacy) | Device Port - RJ45 (Cisco) | Device Port - DB9 | Device Port - USB |
---|---|---|---|---|---|---|
Nodegrid Serial Console - T Series | RJ45 | Legacy | CAT5e cable | CAT5e cable plus Z000039 crossover adapter | CAT5e cable plus Z000036 crossover adapter | USB |
Nodegrid Serial Console - R Series | RJ45 | Cisco | - | CAT5e cable | CAT5e cable plus Z000015 crossover adapter | USB |
Nodegrid Serial Console - S Series | RJ45 | Auto-Sensing (Legacy/Cisco) | CAT5e cable | CAT5e cable | CAT5e cable plus Z000015 crossover adapter | USB |
Nodegrid Services Router | RJ45 | Cisco | - | CAT5e cable | CAT5e cable plus Z000015 crossover adapter | USB |
Nodegrid Bold Services Router | RJ45 | Cisco | - | CAT5e cable | CAT5e cable plus Z000015 crossover adapter | USB |
If the serial device’s RJ45 does not have the Cisco-like pinout, or if you have any questions on connecting your serial device to the unit, please contact ZPE Systems Technical Support for assistance.
Note: To avoid EMC issues use good quality network cable for all port connections.
All IP based target device can be either directly connected to a network interface on a Nodegrid unit or through an existing network infrastructure. In case target devices are directly connected, standard network cables (CAT 5, CAT6, CAT6e) can be used for Ethernet connections or appropriate fiber cables can be used.
Use the provided CAT5e and RJ45-DB9 Z000036 adapter/cable to communicate with the Nodegrid unit. Connect one end of the CAT5e cable to the Nodegrid console port. Connect the other end to the RJ45-DB9 adapter, and then plug it to your laptop or PC's DB9 COM port (if your laptop or PC does not have DB9 COM port, use a USB-DB9 adapter (not provided)).
Have a serial application (such as xterm, TeraTerm, Putty, SecureCRT) running on your laptop/PC to open a terminal session to that COM port (see the system information about the COM port to be used) with 115200bps, 8 bits, No parity, 1 stop bit, and no flow control settings.
The ETH0 interface is by default configured to listen to DHCP requests. In case no DHCP Server is available, the unit will use a default IP address of 192.168.160.10. The unit can be accessed using a browser on https://[DHCP ASSIGNED IP] or on https://192.168.160.10, alternatively, can the unit be accessed with an ssh client.
Setting | Value |
---|---|
DHCP | enabled |
fallback IP | yes |
Default IP | 192.168.160.10/24 |
Default URL | https://192.168.160.10 |
Default ssh | ssh [email protected] |
The Nodegrid is pre-configured to act as a Wi-Fi hotspot in case an appropriate Wi-Fi device is connected. This can either be a built-in Wi-Fi module or a USB Wi-Fi adapter.
The Nodegrid will automatically be presenting a Wi-Fi network with the SSID Nodegrid. The default WPA Shared key is Nodegrid. The Nodegrid will not automatically provide an IP address to clients. Configure the client to have a valid IP address in the 192.168.162.1/24 range. The unit can now be accessed using a browser on https://192.168.162.1 or through ssh.
Setting | Value |
---|---|
SSID | Nodegrid |
WPA Shared key | Nodegrid |
Default Network | 192.168.162.1/24 |
Default URL | https://192.168.162.1 |
Default ssh | ssh [email protected] |
The Nodegrid unit can be directly configured and managed through it's KVM interfaces. Connect a Monitor with an HDMI cable to the units HDMI interface.
The Nodegrid Bold SR provides a VGA port instead of an HDMI interface.
Note: HDMI to DVI-D adapters can be used and allow the connections of a DVI-D Monitor.
Connect a USB Keyboard and Mouse to the available USB ports.
Note: The keyboard and mouse need to be supported under Linux, Windows only devices are not supported. This limitation mostly affects devices which use a USB wireless dongle.
The login prompt will be presented.
The Nodegrid Gate SR supports two digital I/O ports (DIO0, DIO1), one digital output port (OUT0) and one relay port (1A@24V).
The Nodegrid Link SR supports two digital I/O ports (DIO0, DIO1) and two digital output port (OUT0, OUT1).
Both DIO0 and DIO1 can be independently configured as input or output. The DIO0 and DIO1 are open-drain digital I/O ports with TTL level (5.5V max @ 64mA) and ESD protection exceeding JESD 22.
When DIO port is configured as an input, it will sense:
Note: Configuring DIO0 and DIO1 ports as input are ideal for dry contact applications like door close, vibration, water, smoke sensors.
When DIO port is configured as an output, it will output:
Note: Configuring DIO0 and DIO1 ports as output can be used to control low voltage/current applications.
The OUT0 and OUT1 are high voltage digital output. Each port is internally attached to a Signal MOSFET. The output port is normally open (NO) and capable of supporting voltage range from 2.5V to 60V @ 500mA. When OUT port is:
Note: The OUT0 and OUT1 can be used to pull a power connected line to ground, like a relay circuit.
The RELAY port on Nodegrid Gate SR is a normally closed (NC) relay, with derated values of max 24V @ 1A. However, per RELAY's specification, it supports maximum switching power of 60W, 125VA; maximum switching voltage of 220VDC, 250VAC; maximum switching current of 2A, with restive load.
The primary function of the RELAY is to work as a Power Source Control Alarm. When the RELAY is close, it indicates that Nodegrid Gate SR is either being powered by a single power source or it does not have power at all. Therefore, if the Nodegrid Gate SR is being powered by both power input sources, when this RELAY is close, it indicates FAILURE on at least one of the power input sources.
Optionally, the RELAY function can be changed to follow software control (Open / Close), in order to control an external device. The following are the possible relay states:
The I/O Port configuration is under System :: I/O Ports
. The status of the I/O Ports, along with other hardware information is under Tracking :: HW Monitor
.
For Safety Reasons, do not exceed max voltage or current defined on each port.
Nodegrid Manager software is installed from an ISO file. The installation procedure is a three-stage process:
Minimum Requirements
Note: the values are minimum settings and should be adjusted as needed
To install your Nodegrid Manager software:
After the Nodegrid Platform is turned on, boot messages will be displayed, and the login prompt will be displayed.
The default administrator username is admin and the default password is admin. Admin users can access the Nodegrid Platform via a console port, through the web interface (HTTPS) or CLI (SSH). Other access methods can be enabled.
The superuser is root and the default password is root. The root user has SHELL access to the Linux OS, but not to the Web Interface.
By default, Nodegrid Platform is set up with DHCP IP configuration enabled.
Note: The Nodegrid Platform will respond on ETH0 at 192.168.160.10 if your DHCP server fails or is unavailable.
To identify the currently assigned IP address/es login to the Nodegrid Platform as an admin user and navigate to the Network Connections screen.
show /system/network_statistics/
Example Output:
[admin@nodegrid /]# show /settings/network_connections/
name status type interface carrier state ipv4 address ipv6 address mac address description
========== ========== ======== ========== ============= ================= =========================== ================= ===========
BACKPLANE0 connected ethernet eth0 up 192.168.10.252/24 fe80::290:fbff:fe5b:72bc/64 e4:1a:2c:5b:72:bc
ETH0 connected ethernet backplane0 up 192.168.29.3/24 fe80::290:fbff:fe5b:72bd/64 e4:1a:2c:5b:72:bd
hotspot not active wifi down
Note: The below examples use IPv4 for communication. IPv6 is fully supported on the Nodegrid Platform and appropriate settings are available in the same menus.
xxxxxxxxxx
[admin@Nodegrid /]# cd settings/network_connections/ETH0/
xxxxxxxxxx
[admin@Nodegrid ETH0]# set ipv4_mode=static
[admin@Nodegrid ETH0]# set ipv4_address=<IP_ADDRESS> ipv4_bitmask=<BITMASK> ipv4_gateway=<GATEWAY>
[admin@Nodegrid ETH0]# commit
Example:
xxxxxxxxxx
[admin@Nodegrid /]# cd settings/network_connections/ETH0/
[admin@Nodegrid ETH0]# set ipv4_mode=static
[admin@Nodegrid ETH0]# set ipv4_address=10.0.0.10 ipv4_bitmask=24 ipv4_gateway=10.0.0.1
[admin@Nodegrid ETH0]# show
name: ETH0
type: ethernet
ethernet_interface = eth0
connect_automatically = yes
set_as_primary_connection = no
enable_lldp = no
ipv4_mode = static
ipv4_address = 10.0.0.10
ipv4_bitmask = 24
ipv4_gateway = 10.0.0.1
ipv4_dns_server =
ipv4_dns_search =
ipv6_mode = address_auto_configuration
ipv6_dns_server =
ipv6_dns_search =
[admin@Nodegrid ETH0]# commit
Follow the same steps for other interfaces as required.
The Nodegrid platform can be accessed via its build in WebUI. The interface allows for full access to all target devices and configuration and management of the platform.
The Web UI supports all modern browsers with HTML5 support including mobile browsers. Regularly tested browsers include Internet Explorer 11, Edge, Chrome and Firefox.
The WebUI provides the following general structure.
Menu | Icon | Description |
---|---|---|
Access | The access menu provides easy access for all users to managed devices. It allows users with the appropriate permissions to start sessions, control power and review the device logging details | |
Tracking | The tracking menu provides an overview of general statistics and system information, like system utilization and serial port statistics besides others. | |
System | The system's menu allows administrators to perform general administrative tasks on the Nodegrid Platform, for example, Firmware updates, backups and restores and licenses | |
Network | The Network menu allows access and administration to all network interfaces and features | |
Managed Devices | Through this menu can administrators add, configure and remove devices which should be managed through the Nodegrid platform | |
Cluster | The Cluster menu allows administrators to administrate the Nodegrid Cluster feature | |
Security | The Security menu provides configuration options which control user access and general security of the Nodegrid platform | |
Auditing | This menu allows administrators to administrate auditing levels and locations as well as some global logging settings. | |
Dashboard | The Dashboard allows users and administrators to create and view dashboards and reports. | |
Applications | The applications' menu is only visible if a valid Virtualization license is available. With a proper license, it allows administrators to manage and control NFV's and Docker applications |
The Nodegrid platform can be accessed through a CLI interface. The CLI is accessed by connecting to the platform using an ssh client or through its console port. The interface allows for access to all console target sessions and configuration and management of the platform. The CLI structure follows mostly the structure of the WebUI.
The CLI provides the following general structure.
Folder | Description |
---|---|
/access | The access menu provides easy access for all users to managed devices. It allows users with the appropriate permissions to start sessions, control power and review the device logging details |
/system | The folder provides the combined functions of the Tracking and System menu from the web UI. The tracking features provide an overview of general statistics and system information, like system utilization and serial port statics beside others. The system's features allow administrators to perform general administrative tasks on the Nodegrid Platform, for example, Firmware updates, backups and restores and licenses |
/settings | The folder provides access to the system, security, auditing, and managed devices settings and configuration options |
While the CLI provides many commands and options, can the general usage of the CLI be broken down to a few basic commands from where a user or administrator can start from.
CLI Command | Description |
---|---|
TAB TAB | The key combination of a double TAB provides a list of all available commands, settings or options which are currently valid |
ls | The ls command list the current folder structure |
show | The show command when valid will display the current settings in a tabular view |
set | All changes and settings are initiated with the set command in the general form of set option=value multiple setting can be combined by providing additional option=value pairs, like set option1=value1 option2=value2 |
commit | Most changes are not directly saved and activated, changes to the configuration can be reviewed with the show command before they get saved and activated with the commit command. That changes are not active yet and require to be saved is indicated in the CLI by a + sign in front of the command prompt, like [+admin@nodegrid /]# |
cancel or revert | In case setting should not be committed and saved, the cancel or revert command can be used to revert the changes. |
Examples
xxxxxxxxxx
[admin@nodegrid /]# ls
access/
system/
settings/
[admin@nodegrid /]# show
[admin@nodegrid /]# show /access/
name status
===================== =========
Device_Console_Serial Connected
[admin@nodegrid /]# set settings/devices/ttyS2/access/ mode=on-demand
[+admin@nodegrid /]# set settings/devices/ttyS2/access/ rs-232_signal_for_device_state_detection=
CTS DCD None
[+admin@nodegrid /]# set settings/devices/ttyS2/access/ rs-232_signal_for_device_state_detection=DCD enable_hostname_detection=yes
[+admin@nodegrid /]# commit
[admin@nodegrid /]#
The Nodegrid platform provides direct access to the operating systems shell. This access is by default only available to the root user (directly) and admin user (from CLI). Direct shell access can be granted to users of specific groups (See Groups section). This can be useful for users which are used for system automation processes and which require direct shell access for this. The Nodegrid supports for these uses as well authorization through ssh key authorization. It is recommended to review the requirement for shell access and to limit access to it as required. Shell access is provided for advanced use cases and should be used with caution. Changes made to the configuration of the Nodegrid platform through the Shell can have a negative impact on the general workings of the platform.
The Access
page provides an overview of all available target devices. It allows users to easily connect to managed devices as well as review their current device status and search for target devices. The displayed target devices will be determent by the user's permissions as well as by the current state of Nodegrid Cluster nodes.
The first view which is available to a user after login into the Web UI is the Access
View. This view provides an overview of all available targets to which the user has access to. Each target will indicate its current connection status as well as the available connection types.
Connection Status is:
State | Indicator Color | Icon | Description |
---|---|---|---|
Connected | Green | Nodegrid can successfully connect to the target device and it is available for sessions | |
In-Use | Blue | The Device is currently in use | |
Disconnected | Orange | Nodegrid could not successfully connect to the target device and it is not available for sessions | |
Unknown | Grey | The connection status is unknown. This is the default state for target devices with the connection mode On-Demand or for new target devices for which the discovery process is not completed. |
Device sessions can be directly be started from this location.
A user has multiple options to start a device session from the WebUI. In the Access
screen, the user will directly see the available target sessions and can start a new session by just clicking on the connection button.
This will start a new window in which the target session will be established.
At the bottom of the window, the user is presented with buttons which allow the user to further control the target session and target device. The options available will depend on the connection type and device configuration.
Options | Description |
---|---|
The Info option will display the current device details | |
The Fullscreen will expand the window to use the full screen. The session window itself will not expand beyond its maximum size change size | |
The Power Off option will perform a power off on the target devices through a connected Rack PDU or IPMI device | |
The Power On option will perform a power on on the target devices through a connected Rack PDU or IPMI device | |
The Reset option will perform a power cycle on the target devices through a connected Rack PDU or IPMI device | |
The Power Status will display the current power status of a device as returned by a connected Rack PDU or IPMI device | |
This option closes the currently active session | |
The plus sign expands or minimizes the command line options at the bottom of the screen |
By closing the window with the session to the target device will be closed.
Nodegrid supports Copying & Pasting text between the HTML5 graphical device session window and the desktop environment, similar to any other application.
Notice, however, that due to peculiarities of Operating Systems, the copy and paste operations require a distinct combination of keys to activate the copy and paste functions, as below.
Ctrl+Ins
to copy and Shift+Ins
to paste.Cmd+C
to copy, and Cmd+V
to paste.Highlight the text and right-click to open the menu, or use the shortcuts.
The access view is available in the CLI through the access
menu, a user can directly navigate to this menu with cd /access
. To see the currently available targets the user can use the command show
.
Example:
xxxxxxxxxx
[admin@nodegrid access]# show
name status
===================== =========
Device_Console_SSH Connected
Device_Console_Serial InUse
IPMI Connected
RPDU Connected
usbS2 Connected
A device session can be directly started from here with the connect
command.
Use:
connect <target name>
Example:
x[admin@nodegrid access]# connect Device_Console_Serial
[Enter '^Ec?' for help]
[Enter '^Ec.' to cli ]
login:
Note: Only console sessions or sessions which provide a text-based interface can be started from the CLI.
After a connection is established the user use the Escape sequence ^Ec
or ^O
to further control the session.
Note: the Escape sequences can be changed in the device settings.
The following options are available.
Option | Escape Sequence | Description |
---|---|---|
. | ^Ec. | disconnect the current session |
g | ^Ecg | displays the current user group information |
l | ^Ecl | sends the break signal as defined in the device settings |
w | ^Ecw | displays the currently connected users |
<cr> | ^Ec<cr> | sends a ignore/abort command signal |
k | ^Eck | serial port(speed data bits parity stop bits flow) |
b | ^Ecb | sends a broadcast message, a message can be typed after the escape sequence sent. |
i | ^Eci | displays the current serial port information |
s | ^Ecs | changes the current session to read-only mode |
a | ^Eca | changes the current session to read-write mode |
f | ^Ecf | forces the current session to read-write mode |
z | ^Ecz | disconnect a specific connected user session |
? | ^Ec? | print this message |
Power Control options are available on targets which are connected to a managed Rack PDU or provide power control through IMPI. The power menu can be started with ^O
xxxxxxxxxx
Power Menu - Device_Console_Serial
Options:
1. Exit
2. Status
3. On
4. Off
5. Cycle
Enter option:
Each device maintained by the Nodegrid platform has a multitude of device information stored in the system. This information is visible to users and fully searchable in the system. This is specifically useful when users are trying to identify specific targets.
The stored information is a combination of automatically discovered values, values which have been set during the device configuration and additional information which have been associated with a device by an administrator.
The device information can be displayed in the Access view for a specific device, by clicking on a target name in the WebUI or by navigating to the device in the CLI.
Access:: Table
cd /access/
show
command to display the device detailsxxxxxxxxxx
[admin@nodegrid /]# cd /access/
[admin@nodegrid access]# show Device_Console_Serial/
name: Device_Console_Serial
status: Connected
The WebUI offers multiple ways to view and access target devices. By default, all users have displayed the Table view, which provides easy access to all targets. Other views are available and improve the accessibility or visualization of the current device status easier. The following views are available:
Each user can change the default view which will be displayed after login. For this, the user opens the preferred view and uses the Pin It
button.
Note: The Table view is the only view which is available on the CLI.
The table view allows for easy access to all target device and their device sessions. It provides a table view which outlines easily the current status for each device. The view will display all devices currently connected to the unit as well as all other targets which are available through the Cluster feature.
The view supports filtering the current list by current device status and other search criteria. In order to filter by current device status Click on the device status icons in the top right-hand corner. The following example filters the devices by Connection State (Connected and In-Use)
More advanced search options are available through the Search field. See Device Search for more details.
The Tree view displays all targets based on the physical hierarchies of the Nodegrid setup and allows starting connections for each target. It allows for easy access to targets devices based on their location, like Nodegrid name, city name, data center name, row and rack, and others. The View section offers filters, based on location and device types.
More advanced search options are available through the Search field. See Device Search for more details.
The Node View arranges all target devices around their connected Nodegrid units and makes it easy to get a complete overview of all targets and Nodegrid units in a Cluster. The View allows access to target device information and connections by clicking on the target nodes.
More advanced search options are available through the Search field. See Device Search for more details.
The Map View allows you to see the current status of your devices on a global map to get a complete overview of all targets and Nodegrid units in a Cluster. The Map View allows displaying precise location details down to a building level. The View allows accessing target device information and connections by clicking on the target nodes.
Global View
Street View
More advanced search options are available through the Search field. See Device Search for more details.
The Image View allows customers to display a custom view of there Nodegrid units and target devices and associated information. The implementation requires Professional Services implementation. Contact Customer Support [email protected] for additional information.
The Nodegrid Platform provides advanced search capabilities which allow users to easily search and access the information and target devices they require.
The Device Search is available on all Device views and provides an easy method to search and filter the Target devices in each view.
The Device Search can be accessed in the WebUI through the search field in the top left-hand corner of each view and on the CLI with the search
command in the access menu. The NodeIQ™ Natural Language Search allows users to search for device property fields, including custom fields. This function works naturally with stand-alone units as well across all Nodegrid units in a Cluster configuration. The System automatically updates all the information about device changes and newly added devices and their properties in the background.
The Search filed supports the following keywords:
Keyword | Description |
---|---|
[Search String] | a search string which represents part of or a complete string to be searched for |
AND | Combines multiple search strings with an AND |
OR | Combines multiple search strings with an OR. Default search behavior for more than one search string |
NOT | Any targets matching the search string will NOT be returned |
[Field Name] | Allows limit of the Search String to a specific Field Name |
Note: The keywords AND, OR and NOT are case-sensitive "and", "or", "not" will be identified as search strings.
To search for standard and custom field data (including groups, such as “admin” group), IP addresses or a specific device, follow the examples below:
Example with AND
“PDU AND IPMI”
xxxxxxxxxx
[admin@nodegrid search]# search "PDU AND IPMI"
search: PDU AND IPMI
results: 1 result
page: 1 of 1
[admin@nodegrid search]# show
name status action
==== ====== ======
IPMI -
Example with OR
"PDU OR IPMI"
xxxxxxxxxx
[admin@nodegrid access]# search "PDU OR IPMI"
search: PDU OR IPMI
results: 4 results
page: 1 of 1
[admin@nodegrid search]# show
name status action
===================== ====== ======
IPMI -
RPDU -
Device_Console_SSH -
Device_Console_Serial -
"PDU IPMI"
xxxxxxxxxx
[admin@nodegrid access]# search "PDU IPMI"
search: PDU IPMI
results: 4 results
page: 1 of 1
[admin@nodegrid search]# show
name status action
===================== ====== ======
IPMI -
RPDU -
Device_Console_SSH -
Device_Console_Serial -
Example with NOT
"PDU AND NOT IPMI"
xxxxxxxxxx
[admin@nodegrid search]# search "PDU AND NOT IPMI"
search: PDU AND NOT IPMI
results: 3 results
page: 1 of 1
[admin@nodegrid search]# show
name status action
===================== ====== ======
RPDU -
Device_Console_SSH -
Device_Console_Serial -
Example with Field Name
"name:PDU"
xxxxxxxxxx
[admin@nodegrid search]# search "name:PDU"
search: name:PDU
results: 1 result
page: 1 of 1
[admin@nodegrid search]# show
name status action
==== ====== ======
RPDU -
A Global Search option is available in the WebUI. The Search field is located at the top of the screen beside the current user information and logs out option. The global search works in the same way as the Device Search and supports the same keywords. The Search is available from all screens and allows easy access to all target devices and target sessions.
The Managed Devices Section allows users to configure, create and delete target devices. The Nodegrid Platform supports target devices which are connected through a serial, USB, or network connection. The following protocols are currently supported for network-based devices Telnet, SSH, HTTP/S, IMPI variations and SNMP.
The user has multiple options to enable or create and new target devices. They can be manually enabled/created or can be discovered.
Each managed device added in the system uses one license from the pool. Each unit is shipped with enough perpetual licenses to cover the number of physical ports and no further licenses are required to utilize the physical ports. Additional licenses can be added to a unit to allow it to manage additional devices. If licenses expire or are deleted from the system, the devices exceeding the total licenses will have their status changed to “unlicensed”. While their information will be retained in the system, the unlicensed devices will not show up in the access page preventing the user from connecting to them. Only licensed devices are listed on the access page and are available for access and management. The top right corner of the Managed Devices view shows the total licenses in the system, total in use and total available licenses. See Licenses for more details.
The Nodegrid platform supports the following managed device types.
Console connections utilizing RS232 protocol. Supported on Nodegrid Console Server and Nodegrid Services Router family.
Service Processor Devices using:
Console Server connections utilizing ssh protocol
Console Server connections utilizing
KVM (Keyboard, Video, Mouse) Switches utilizing
Rack PDUs from
Cisco UCS
Netapp
Infrabox
Virtual Machine sessions from
Sensors
New devices can be added to the Devices menu. The menu offers the options to:
enable
, disable
, configure
and reset
devices connected to physical portsadd
, delete
and configure
devices connected through a network connectionrename
existing devices/portsclone
existing devicesOn-Demand
Bounce DTR
signal for serial portsTo perform any of these tasks either click on the button or select first a device and then click the button in the WebUI or use the command in the CLI.
WebUI Enable Port 1 example
CLI rename port 2 example
xxxxxxxxxx
[admin@nodegrid devices]# rename ttyS2
[admin@nodegrid {devices}]# set new_name=Port2
[admin@nodegrid {devices}]# commit
The Nodegrid Platform supports RS-232 Serial connections thought the available Serial and USB interfaces. The ports are automatically detected and displayed in the Devices menu and can directly be used. Each port needs to be enabled and configured to provide access to the target device.
Before configuring the Nodegrid port check the console port settings of the target device with the manufacturer. Most devices use settings of 9600,8,N,1, which is the default for the port
The Nodegrid Console Server S Series supports advanced auto-detection which simplify the configuration process, by automatically detecting the cable pinout (Legacy and Cisco) and connection speed.
Navigate to Managed Devices:: Devices
Click on the port or select the port and click on Edit
. Multiple Ports can be selected
Confirm the values for:
Baud Rate
set it to the correct speed matching the target device settings or to Auto
Parity
possible values are: None (default), Odd, or EvenFlow Control
possible values are: None (default), Software, Hardware Data Bits
possible values are: 5,6,7,8 (default)Stop Bits
possible values are: 1RS-232 signal for device state detection
possible values are: DCD (default), None, CTSMode
possible values are: Enabled, On-Demand, DisabledOptional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details
Navigate to /settings/devices
use the edit
command with the port name to change the port configuration. Multiple ports can be defined
use the show
command to display the current values
use the set
command adjust the values for:
baud_rate
set it to the correct speed matching the target device settings or to Auto
parity
possible values are: None (default), Odd, or Evenflow_control
possible values are: None (default), Software, Hardwaredata_bits
possible values are: 5,6,7,8 (default)stop_bits
possible values are: 1rs-232_signal_for_device_state_detection
possible values are: DCD (default), None, CTSmode
possible values are: Enabled, On-Demand, DisabledOptional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details
use the commit
command to change the settings.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# edit ttyS2
[admin@nodegrid {devices}]# show
name: ttyS2
type: local_serial
address_location =
coordinates =
web_url =
launch_url_via_html5 = yes
baud_rate = 9600
parity = None
flow_control = None
data_bits = 8
stop_bits = 1
rs-232_signal_for_device_state_detection = DCD
enable_device_state_detection_based_in_data_flow = no
enable_hostname_detection = no
multisession = yes
read-write_multisession = no
icon = terminal.png
mode = disabled
skip_authentication_to_access_device = no
escape_sequence = ^Ec
power_control_key = ^O
show_text_information = yes
enable_ip_alias = no
enable_second_ip_alias = no
allow_ssh_protocol = yes
ssh_port =
allow_telnet_protocol = yes
telnet_port = 7002
allow_binary_socket = no
data_logging = no
[admin@nodegrid {devices}]# set mode=enabled baud_rate=Auto
[admin@nodegrid {devices}]# commit
The Nodegrid platform supports multiple IPMI based Service Processors like IPMI 1.5, IMPI 2.0, Hewlett Packard ILO's, Oracle/SUN iLOM's, IBM IMM's, Dell DRAC and iDRAC.
In order to manage these devices, the Nodegrid requires a valid network connection to the target device. This can be through a dedicated network interface on the Nodegrid itself or through an existing network connection.
The Nodegrid supports the following features for Service Processors.
Note: Some features might not be available depending on the Service Processor capabilities.
For console access via SOL, you must also enable BIOS console redirect and OS console redirect (typically for Linux OS) on the server.
Managed Devices:: Devices
, Add
button to add a device to the system. For the purpose of this example, provide the following information:Type
field, select a type that matches the service processor in use. Possible values are: ipmi1.5,ipmi2.0, ilo, ilom, imm, drac, idrac6 username
and password
of the service processor, or select Ask During Login
option if you want to provide user credentials during the login time Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: ipmi1.5,ipmi2.0, ilo, ilom, imm, drac, idrac6 ip_address
username
and password
of the service processor, or select Ask During Login
option if you want to provide user credentials during the login timesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=IPMI
[admin@nodegrid {devices}]# set type=ipmi_2.0
[admin@nodegrid {devices}]# set ip_address=192.168.10.11
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
The Solution supports the management of target devices through SSH. The Nodegrid supports the following features for these devices:
Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the ssh or telnet in use. Possible values are: device_console username
and password
of the ssh server, or select Ask During Login
option if you want to provide user credentials during the login time Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: device_consoleip_address
username
and password
of the device, or select Ask During Login
option if you want to provide user credentials during the login timesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Device_Console_SSH
[admin@nodegrid {devices}]# set type=device_console
[admin@nodegrid {devices}]# set ip_address=192.168.10.252
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
The Solution supports multiple 3rd party Console Servers from different vendors, including console servers from Avocent and Servertech. These devices can be added to the Nodegrid Platform and the system will then allow using the connected targets as if they had been directly connected to a Nodegrid appliance. Adding 3rd party Console Servers is a two-step process, in the first step the 3rd party appliance is added to the Nodegrid and in a 2nd step, all enabled ports will be added to the platform.
The Nodegrid supports the following features for these devices:
Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the console server. Possible values are: console_server_nodegrid,console_server_acs,console_server_acs6000,console_server_lantronix,console_server_opengear,console_server_digicp_username
and password
of the console server, or select Ask During Login
option if you want to provide user credentials during the login time Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the console server. Possible values are: console_server_nodegrid,console_server_acs,console_server_acs6000,console_server_lantronix,console_server_opengear,console_server_digicpusername
and password
of the console server, or select Ask During Login
option if you want to provide user credentials during the login time End Point
Serial Port and enter the port numberNote: Ports can be automatically detected and added see Auto Discovery Section for details
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: console_server_acs, console_server_acs6000,console_server_lantronix,console_server_opengear,console_server_digicp_ip_address
username
and password
of the device or select Ask During Login
option if you want to provide user credentials during the login timeendpoint
should be defined as appliancesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Console_Server
[admin@nodegrid {devices}]# set type=console_server_acs6000
[admin@nodegrid {devices}]# set ip_address=192.168.2.151
[admin@nodegrid {devices}]# set end_point = appliance
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: console_server_acs, console_server_acs6000,console_server_lantronix,console_server_opengear,console_server_digicp_ip_address
username
and password
of the device, or select Ask During Login
option if you want to provide user credentials during the login timeendpoint
should be defined as serial_portport_number
should be defined as the port numbersave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
Note: Ports can be automatically detected and added see Auto Discovery Section for details
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Console_Server_Port_5
[admin@nodegrid {devices}]# set type=console_server_acs6000
[admin@nodegrid {devices}]# set ip_address=192.168.2.151
[admin@nodegrid {devices}]# set end_point = serial_port
[admin@nodegrid {devices}]# set port_number = 5
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
The Solution supports multiple 3rd party KVM Switches from different vendors, including products from Avocent and Raritan. These devices can be added to the Nodegrid Platform and the system will then allow using the connected targets as if they had been directly connected to a Nodegrid appliance. Adding 3rd party KVM Switches is a two-step process, in the first step the 3rd party appliance is added to the Nodegrid and in a 2nd step, all enabled ports will be added to the platform.
The Nodegrid supports the following features for these devices:
Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the KVM switch. Possible values are: kvm_dsr, kvm_mpu,kvm_aten,kvm_raritanusername
and password
of the KVM switch, or select Ask During Login
option if you want to provide user credentials during the login time Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the KVM switch. Possible values are: kvm_dsr, kvm_mpu,kvm_aten,kvm_raritanusername
and password
of the KVM switch, or select Ask During Login
option if you want to provide user credentials during the login time End Point
KVM Port and enter the port numberNote: Ports can be automatically detected and added see Auto Discovery Section for details
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: kvm_dsr, kvm_mpu,kvm_aten,kvm_raritanip_address
username
and password
of the device, or select Ask During Login
option if you want to provide user credentials during the login timeendpoint
should be defined as appliancesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=KVM_Switch
[admin@nodegrid {devices}]# set type=kvm_aten
[admin@nodegrid {devices}]# set ip_address=192.168.2.151
[admin@nodegrid {devices}]# set end_point = appliance
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: kvm_dsr, kvm_mpu,kvm_aten,kvm_raritanip_address
username
and password
of the device, or select Ask During Login
option if you want to provide user credentials during the login timeendpoint
should be defined as serial_portport_number
should be defined as the port numbersave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
Note: Ports can be automatically detected and added see Auto Discovery Section for details
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Console_Server_Port_5
[admin@nodegrid {devices}]# set type=kvm_aten
[admin@nodegrid {devices}]# set ip_address=192.168.2.151
[admin@nodegrid {devices}]# set end_point = kvm_port
[admin@nodegrid {devices}]# set port_number = 1
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
The Solution supports multiple 3rd party Rack PDUs from different vendors, including products from APC, Avocent, Baytech,CPI, Cyberpower, Eaton, Enconnex, Geist, Liebert, Raritan, Rittal, and Servertech. These devices can be added to the Nodegrid Platform and the system will then allow users to connect to the Rack PDU and control the power outlets should this function be supported by the Rack PDU. Outlets can then be associated to specific target devices, which allows users to directly control the specific power outlets for this target device.
The Nodegrid supports the following features for these devices:
Note: The Power Control feature needs to be supported by the Rack PDU. Check the manual of the Rack PDU if the feature is available on a specific model.
Managed Devices:: Devices
Add
button to add a device to the system. Type
field, select a type that matches the Rack PDU. Possible values are: pdu_apc, pdu_baytech,pdu_eaton,pdu_mph2,pdu_pm3000,pdu_cpi,pdu_raritan,pdu_geist,pdu_servertech,pdu_enconnex,pdu_cyberpower,pdu_rittalusername
and password
of the Rack PDU, or select Ask During Login
option if you want to provide user credentials during the login time Note: By default will Nodegrid communicate with the Rack PDU using ssh/telnet. The reaction time of Rack PDUs using these interface is typically very slow. It is therefore recommended to use SNMP for the communication with the Rack PDU if possible.
Managed Devices:: Devices
Name
of the newly added Rack PDUCommands
menu and click on OutletsProtocol
to SNMP and click on SaveManagement
menu and update the SNMP values to match the settings on the Rack PDU, click on Save
Note: Use SNMP details which provide read and write access. With Read-Only credentials can the Nodegrid Platform not control the power outlets.
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: pdu_apc, pdu_baytech,pdu_eaton,pdu_mph2,pdu_pm3000,pdu_cpi,pdu_raritan,pdu_geist,pdu_servertech,pdu_enconnex,pdu_cyberpower,pdu_rittalip_address
username
and password
of the device, or select Ask During Login
option if you want to provide user credentials during the login timeendpoint
should be defined as appliancesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
Note: By default will Nodegrid communicate with the Rack PDU using ssh/telnet. The reaction time of Rack PDUs using these interface is typically very slow. It is therefore recommended to use SNMP for the communication with the Rack PDU if possible.
/settings/devices/<device name>/commands/outlet
/settings/devices/<device name>/management
commit
Note: Use SNMP details which provide read and write access. With Read-Only credentials can the Nodegrid Platform not control the power outlets.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Rack_PDU
[admin@nodegrid {devices}]# set type=pdu_servertech
[admin@nodegrid {devices}]# set ip_address=192.168.2.39
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
[admin@nodegrid /]# cd /settings/devices/Rack_PDU/commands/outlet
[admin@nodegrid outlet]# set protocol=snmp
[admin@nodegrid outlet]# cd /settings/devices/Rack_PDU/management/
[admin@nodegrid management]# set snmp=yes
[+admin@nodegrid management]# snmp_version = v2
[+admin@nodegrid management]# snmp_commmunity = private
[+admin@nodegrid management]# commit
The Solution supports the management of Cisco UCS through there Console Ports as well as there management interfaces. The Nodegrid supports the following features for these devices:
Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the appliance. Possible values are: cimc_ucs Chassis ID
and the Blade ID
which represent the bladeusername
and password
of the Blade Chassis, or select Ask During Login
option if you want to provide user credentials during the login time Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
of the blade to be addedtype
, possible values are: cimc_ucsip_address
of the blade chassischassis_id
of the blade chassisblade_id
of the blade server username
and password
of the blade chassis, or select Ask During Login
option if you want to provide user credentials during the login timesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Cisco-UCS
[admin@nodegrid {devices}]# set type=cimc_ucs
[admin@nodegrid {devices}]# set ip_address=192.168.10.151
[admin@nodegrid {devices}]# set chassis_id=1 blade_id=1s
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
The Solution supports the management of Netapp appliances through there management interfaces. The Nodegrid supports the following features for these devices:
Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the NetApp appliance. Possible values are: netapp username
and password
, or select Ask During Login
option if you want to provide user credentials during the login time Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: netappip_address
username
and password
of the device, or select Ask During Login
option if you want to provide user credentials during the login timesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Netapp
[admin@nodegrid {devices}]# set type=netapp
[admin@nodegrid {devices}]# set ip_address=192.168.10.250
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
The Solution supports the Smart Access Control for Rack's solution appliances (Infrabox) from InfraSolution. The Nodegrid supports the following features for these devices:
Note: Communication to the appliances requires SNMP to be configured on the appliances
Managed Devices:: Devices
, Add
button to add a device to the system. Type
field, select a type that matches the Infrabox appliance. Possible values are: infrabox Ask During Login
and do not provide user credentials Management
menu and update the SNMP values to match the settings on the applianceSave
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: infraboxip_address
username
and password
of the device, or select Ask During Login
option if you want to provide user credentials during the login timesave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
Navigate to /settings/devices/<Device>/management/
use the set
command to define the SNMP values
snmp_version
snmp_community
save the changes with commit
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Infrabox
[admin@nodegrid {devices}]# set type=infrabox
[admin@nodegrid {devices}]# set ip_address=192.168.10.250
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# commit
[admin@nodegrid outlet]# cd /settings/devices/Infrabox/management/
[admin@nodegrid management]# set snmp=yes
[+admin@nodegrid management]# snmp_version=v2
[+admin@nodegrid management]# snmp_commmunity=private
[+admin@nodegrid management]# commit
The solution supports the management of VMWare virtual machines as well a KVM Virtual Machines. The Nodegrid supports the following features for these devices:
The system supports connection to ESX directly or VSphere servers. In case a connection is made directly the ESX server has to support the "vCenter agent for VMware Host" feature, which can be enabled through an ESX server license. To check if the ESX server supports this feature, login to the ESX host and navigate to the License Feature section. Here are the available licenses and features listed which are supported by the host.
Note : In order to utilize the vSPC option with VMWare virtual machines the port needs to be configured on the Virtual Machine. See Appendix A: Configuring Virtual Serial Port (vSPC) on VM Servers
Define a VM Manager
Managed Devices :: Auto Discovery :: VM Managers
Add
to define a new VM ManagerVM Server
fieldUsername
and Password
for the serverHTML console port
if neededSave
Click on "Install VMRC" (VMware Remote Console) in Managed Devices::Auto Discovery::VM Managers to provide properly working graphical device connection and console access to virtual machines.
Create a Device
Managed Devices:: Devices
Add
button to add a device to the system. Type
field, select a type that matches the Virtual Machine type. Possible values are: virtual_console_vmwareVM Manager
field select the correct hypervisor o which the machine runs Define a VM Manager
Navigate to /settings/auto_discovery/vm_managers/
use the add
command to create a VM Manager
use the set
command to define the following settings
vm_server
: Provide the vCenter/ESXi IP or FQDNusername
and password
html_console_port
if neededsave the changes with commit
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/auto_discovery/vm_managers/
[admin@nodegrid vm_managers]# add
[admin@nodegrid {vm_managers}]# set vm_server=vCenter
[admin@nodegrid {vm_managers}]# set username=admin
[admin@nodegrid {vm_managers}]# set password=password
[admin@nodegrid {vm_managers}]# commit
Create a Device
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: virtual_console_vmwareip_address
as of the target devicevm_manager
, set to a existing VM Managersave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Virtual_Machine
[admin@nodegrid {devices}]# set type=virtual_console_vmware
[admin@nodegrid {devices}]# set ip_address=192.168.2.151
[admin@nodegrid {devices}]# set vm_manager=192.168.10.11
[admin@nodegrid {devices}]# commit
Create a Device
Managed Devices:: Devices
Add
button to add a device to the system. Type
field, select a type that matches the Virtual Machine type. Possible values are: virtual_console_kvmCreate a Device
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
or the virtual machine, this has to match the name of the machine on the hypervisortype
, possible values are: virtual_console_kvmip_address
of the KVM hypervisorusername
and password
for the KVM hypervisorsave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=virtual_machine_kvm
[admin@nodegrid {devices}]# set type=virtual_console_vmware
[admin@nodegrid {devices}]# set ip_address=192.168.10.11
[admin@nodegrid {devices}]# set username=root
[admin@nodegrid {devices}]# set password=password
[admin@nodegrid {devices}]# commit
Nodegrid USB Temperature and Humidity Sensors are automatically discovered by the Nodegrid system. The system will automatically Adjust the device type to usb_sensor
. After the device was detected needs the device to be enabled. After this, the device is ready and can be used for monitoring and alarm management.
The USB KVM dongle allows customers to establish a KVM session to a legacy server through VGA and USB connection. The Dongle is automatically detected by the system as soon as it is connected. The device needs only be enabled.
The Nodegrid Platform supports Bluetooth devices, primarily for monitoring and IoT applications. The Bluetooth functionality is provided through the Nodegrid WiFi module which is available for the Nodegrid Service Router family.
By default, the Bluetooth functionality is disabled and it needs to be manually enabled before it can be used.
The service can be currently enabled through the shell by an admin user by running the following commands.
xxxxxxxxxx
[admin@nodegrid /]# shell sudo su -
root@nodegrid:~#sed -i s/^BLUETOOTH_ENABLED=0/BLUETOOTH_ENABLED=1/g /etc/default/bluetooth
root@nodegrid:~#sed -i s/^#AutoEnable=true/AutoEnable=true/g /etc/bluetooth/main.conf
root@nodegrid:~#sed -i s/^#InitiallyPowered=true/InitiallyPowered=true/g /etc/bluetooth/main.conf
After that, Bluetooth devices can be paired to the Nodegrid and then used for monitoring or exposed to an IoT application.
The bluetoothctl
command can be used to pair a device
xxxxxxxxxx
root@nodegrid:~#bluetoothctl bluetoothctl
[bluetooth]# devices
Device 00:16:94:1A:EA:2C Sensor
[bluetooth]# pair 00:16:94:1A:EA:2C
Attempting to pair with 00:16:94:1A:EA:2C
Pairing successful
[bluetooth]# connect 00:16:94:1A:EA:2C
Attempting to connect to 00:16:94:1A:EA:2C
Connection successful
[bluetooth]# quit
The Nodegrid Platform is able to automatically discover and add network devices, enabled ports on console servers, KVM switches and Virtual Serial Ports (VMWare) and Virtual Machines (VMWare).
This feature clones discovered devices from existing devices matching their profile and build dynamic access groups. For best results with this feature, make sure the device to be used as a reference in the cloning process is correctly configured. Verify that username, password and IP address are correct by accessing the device. Verify that the data logging and event logging settings are correct by auditing the log files. Verify that events are being detected based on data logging and event logging by simulating events and checking if any notification was created. Verify that the device is in the desirable authorization group with correct access rights.
The Auto Discovery follows the below general process:
Note: For each target device type a template device needs to be created.
Network Scan
Virtual Manager
Discovery Rule
, this step will link the template device with the discovery rules, which makes the decision which action will be taken with every discovered deviceManaged Devices:: Auto Discovery:: Discover Now
in the WebUI or /settings/auto_discovery/discover_now/
from CLIThe Auto Discovery process can be used to automatically add and configure managed devices for 3rd party console server ports and KVM Switch ports. The process will discover all enabled ports on a managed appliance. The Console Server appliance and KVM Switches can be discovered using the Network Devices process see Auto Discovery of Network Devices.
Create Template Device
Managed Devices:: Devices
Add
button to add a device to the system. Type
field, select a type that matches the console server. Possible values are: console_server_acs, console_server_acs6000,console_server_lantronix,console_server_opengear,console_server_digicp_Ask During Login
End Point
as either Serial Port or KVM Port and enter the port numberMode
Disabled, this will ensure that the device is not displayed in the access page
Create Discovery Rule
Managed Devices:: Auto Discovery:: Discovery Rules
Add
to add a new Discovery RuleName
for the Discovery RuleStatus
for the discovered rule, possible values are: Enabled, DisabledDiscovery Method
select either Console Server Ports or KVM PortsPort List
provide a list of ports which should be scanned, examples are 1,3,5,10-20Host or VM Identifier
parameter can be used to further apply a filter if a value is provided then part of the port name has to match the valueAction
select an action which should be performed when a new device is discovered, possible values are: Clone (Mode:Enabled),Clone (Mode:On-Demand),Clone (Mode:Discovered),Discard discovered DevicesClone from field
select the template device which was created earlierSave
to create the rule
Discovery Rules
. This process will take a few minutes to complete.
Create Template Device
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: console_server_acs, console_server_acs6000,console_server_lantronix,console_server_opengear,console_server_digicp_ip_address
as 127.0.0.1Ask During Login
endpoint
should be defined as serial_port or kvm_portport_number
should be defined as the port numbermode
to disabledsave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Console_Server_Port_Template
[admin@nodegrid {devices}]# set type=console_server_acs6000
[admin@nodegrid {devices}]# set ip_address=192.168.2.151
[admin@nodegrid {devices}]# set end_point=serial_port
[admin@nodegrid {devices}]# set port_number=1
[admin@nodegrid {devices}]# set credential=ask_during_login
[admin@nodegrid {devices}]# set mode=disabled
[admin@nodegrid {devices}]# commit
Create Discovery Rule
Navigate to /settings/auto_discovery/discovery_rules/
use the add
command to create a Discovery Rule
use the set
command to define the following settings
rule_name
for the Discovery Rulestatus
for the discovered rule, possible values are: enabled, disabledmethod
set to either console_server_ports or kvm_portsport_list
provide a list of ports which should be scanned, examples are 1,3,5,10-20host_identifier
parameter can be used to further apply a filter, if a value is provided then part of the port name has to match the valueFor action
select an action which should be performed when a new device is discovered, possible values are: clone_mode_enabled,clone_mode_on-demand,clone_mode_discovered,discard_device
clone_from
set to the template device which was created earlier
save the changes with commit
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/auto_discovery/discovery_rules/
[admin@nodegrid discovery_rules]# add
[admin@nodegrid {discovery_rules}]# set rule_name=Console_Server_Ports
[admin@nodegrid {discovery_rules}]# set status=enabled
[admin@nodegrid {discovery_rules}]# set method=console_server_ports
[admin@nodegrid {discovery_rules}]# set port_list=1-48
[admin@nodegrid {discovery_rules}]# set action=clone_mode_enabled
[admin@nodegrid {discovery_rules}]# set clone_from=Console_Server_Ports_Template
[admin@nodegrid {discovery_rules}]# commit
Discovery Rules
. This process will take a few minutes to complete.Network appliances can be automatically discovered and added to the Nodegrid Platform. This includes appliances which support Telnet, SSH, ICMP, Console Servers, KVM Switches or IMPI protocols besides others. Appliances can be discovered through 3 separate method's, which can be combined or used independently:
Create Template Device
Managed Devices:: Devices
Add
button to add a device to the system. Type
field, select a type that matches the console server. Possible values are: device_console, ilo,imm,drac,idrac6,ipmi1.5,impi2.0,ilom,cimc_ucs,netapp,infrabox,pdu*username
and password
, or select Ask During Login
option if you want to provide user credentials during the login time Mode
Disabled, this will ensure that the device is not displayed in the access pageCreate a Network Scan
Navigate to Managed Devices:: Auto Discovery:: Network_Scan
click on Add
to create a new Network Scan
Enter a name for Scan ID
Define an IP Range to be scanned with IP Range Start
and IP Range End
Select and define one or more of the three scan methods:
Similar Devices
select an existing template which will be used to identify devicesPort Scan
define a list of ports which should be reachable on the deviceping
no further settings are requiredEnable Scanning
to enable the rule and define a Scan Interval
which can range in minutes
Create Discovery Rule
Managed Devices:: Auto Discovery:: Discovery Rules
Add
to add a new Discovery RuleName
for the Discovery RuleStatus
for the discovered rule, possible values are: Enabled, DisabledDiscovery Method
select Network ScanScan ID
select the Network Scan ID which was createdHost or VM Identifier
parameter can be used to further apply a filter if a value is provided then part of the port name has to match the valueAction
select an action which should be performed when a new device is discovered, possible values are: Clone (Mode:Enabled),Clone (Mode:On-Demand),Clone (Mode:Discovered),Discard discovered DevicesClone from field
select the template device which was created earlierSave
to create the rule
Discovery Rules
. This process will take a few minutes to complete.Create Template Device
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: device_console, ilo,imm,drac,idrac6,ipmi1.5,impi2.0,ilom,cimc_ucs,netapp,infrabox,pdu*ip_address
as 127.0.0.1username
and password
, or select Ask During Login
option if you want to provide user credentials during the login time mode
to disabledsave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Network_Template
[admin@nodegrid {devices}]# set type=device_console
[admin@nodegrid {devices}]# set ip_address=127.0.0.1
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# set mode=disabled
[admin@nodegrid {devices}]# commit
Create a Network Scan
Navigate to /settings/auto_discovery/network_scan/
use the add
command to create a Network Scan
use the set
command to define the following settings
scan_id
enter a name for the Network Scan
define a Network range which should be scanned with ip_range_start
and ip_range_end
set enable_scanning
to yes to enable the scan
define one or more of the three scan methods:
similar_devices
set device
to match one of the existing devices or templatesport_scan
set port_list
to a list of ports which should be reachable on the deviceping
no further settings are requiredset scan_interval
which can range in minutes
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/auto_discovery/network_scan/
[admin@nodegrid network_scan]# add
[+admin@nodegrid {network_scan}]# set scan_id=SSH_Console
[+admin@nodegrid {network_scan}]# set ip_range_start=192.168.10.1
[+admin@nodegrid {network_scan}]# set ip_range_end=192.168.10.254
[+admin@nodegrid {network_scan}]# set enable_scanning=yes
[+admin@nodegrid {network_scan}]# set similar_devices=yes
[+admin@nodegrid {network_scan}]# set device= network_template
[+admin@nodegrid {network_scan}]# set port_scan=yes
[+admin@nodegrid {network_scan}]# set port_list=22
[+admin@nodegrid {network_scan}]# set ping=no
[+admin@nodegrid {network_scan}]# set scan_interval=100
[+admin@nodegrid {network_scan}]# commit
Create Discovery Rule
Navigate to /settings/auto_discovery/discovery_rules/
use the add
command to create a Discovery Rule
use the set
command to define the following settings
rule_name
for the Discovery Rulestatus
for the discovered rule, possible values are: enabled, disabledmethod
set to network_scanscan_id
select a Network Scan ID which was created earlierhost_identifier
parameter can be used to further apply a filter if a value is provided then part of the port name has to match the valueFor action
select an action which should be performed when a new device is discovered, possible values are: clone_mode_enabled,clone_mode_on-demand,clone_mode_discovered,discard_device
clone_from
set to the template device which was created earlier
save the changes with commit
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/auto_discovery/discovery_rules/
[admin@nodegrid discovery_rules]# add
[admin@nodegrid {discovery_rules}]# set rule_name=Network_Scan
[admin@nodegrid {discovery_rules}]# set status=enabled
[admin@nodegrid {discovery_rules}]# set method=network_scan
[admin@nodegrid {discovery_rules}]# set scan_id=SSH_Console
[admin@nodegrid {discovery_rules}]# set action=clone_mode_enabled
[admin@nodegrid {discovery_rules}]# set clone_from=Network_Template
[admin@nodegrid {discovery_rules}]# commit
Discovery Rules
. This process will take a few minutes to complete.Virtual Machines which are managed by VMWare vCenter or run on ESXi can be discovered and managed. The process will regularly scan vCenter or the ESXi host and detect newly added Virtual Machines. The virtual machines can either be added as type virtual_console_vmware or virtual_serial_port. See Appendix A: Configuring Virtual Serial Port (vSPC) on VM Servers
Note: ESXi free version is not supported.
Create Template Device
Managed Devices:: Devices
Add
button to add a device to the system. Type
field, select a type that matches the Virtual Machine type. Possible values are: virtual_console_vmwareusername
and password
, or select Ask During Login
option if you want to provide user credentials during the login time Mode
Disabled, this will ensure that the device is not displayed in the access pageCreate Discovery Rule
Managed Devices:: Auto Discovery:: Discovery Rules
Add
to add a new Discovery RuleName
for the Discovery RuleStatus
for the discovered rule, possible values are: Enabled, DisabledDiscovery Method
select VM ManagerDatacenter
and Cluster
to filter the scan to these specific entriesHost or VM Identifier
parameter can be used to further apply a filter if a value is provided then part of the port name has to match the valueAction
select an action which should be performed when a new device is discovered, possible values are: Clone (Mode:Enabled),Clone (Mode:On-Demand),Clone (Mode:Discovered),Discard discovered DevicesClone from field
select the template device which was created earlierSave
to create the ruleDefine a VM Manager
Managed Devices :: Auto Discovery :: VM Managers
Add
to define a new VM ManagerVM Server
fieldUsername
and Password
for the serverHTML console port
if neededSave
Enable Discover Virtual Machines
VM Manager
Discover Virtual Machines
option to configure the Virtual Machine discovery option, define as a minimum a Data Center
and Discovery Polling Interval
.Save
Create Template Device
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: virtual_console_vmwareip_address
as 127.0.0.1mode
to disabledsave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Virtual_Machine_Template
[admin@nodegrid {devices}]# set type=virtual_console_vmware
[admin@nodegrid {devices}]# set ip_address=192.168.2.151
[admin@nodegrid {devices}]# set mode=disabled
[admin@nodegrid {devices}]# commit
Create Discovery Rule
Navigate to /settings/auto_discovery/discovery_rules/
use the add
command to create a Discovery Rule
use the set
command to define the following settings
rule_name
for the Discovery Rulestatus
for the discovered rule, possible values are: enabled, disabledmethod
set to vm_managerdatacenter
and cluster
to define filters based on Data Center and or Cluster host_identifier
parameter can be used to further apply a filter, if a value is provided then part of the port name has to match the valueFor action
select an action which should be performed when a new device is discovered, possible values are: clone_mode_enabled,clone_mode_on-demand,clone_mode_discovered,discard_device
clone_from
set to the template device which was created earlier
save the changes with commit
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/auto_discovery/discovery_rules/
[admin@nodegrid discovery_rules]# add
[admin@nodegrid {discovery_rules}]# set rule_name=Virtual_Machine
[admin@nodegrid {discovery_rules}]# set status=enabled
[admin@nodegrid {discovery_rules}]# set method=vm_manager
[admin@nodegrid {discovery_rules}]# set action=clone_mode_enabled
[admin@nodegrid {discovery_rules}]# set clone_from=Vitual_Machine_Template
[admin@nodegrid {discovery_rules}]# commit
Define a VM Manager
Navigate to /settings/auto_discovery/vm_managers/
use the add
command to create a VM Manager
use the set
command to define the following settings
vm_server
: Provide the vCenter/ESXi IP or FQDNusername
and password
html_console_port
if neededsave the changes with commit
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/auto_discovery/vm_managers/
[admin@nodegrid vm_managers]# add
[admin@nodegrid {vm_managers}]# set vm_server=vCenter
[admin@nodegrid {vm_managers}]# set username=admin
[admin@nodegrid {vm_managers}]# set password=password
[admin@nodegrid {vm_managers}]# commit
Enable Discover Virtual Machines
VM Manager
Discover Virtual Machines
option to configure the Virtual Machine discovery option, define as a minimum a Data Center
and Discovery Polling Interval
.Save
xxxxxxxxxx
[admin@nodegrid 192.168.2.217]# show
vm server: 192.168.2.217
username = [email protected]
password = ********
type = VMware
html_console_port = 7331,7343
discover_virtual_machines = yes
interval_in_minutes = 15
discovery_scope = Demo-DC!
The Nodegrid Platform can be used as a DHCP Server for Clients within the management network. These devices can be automatically discovered and added to the Nodegrid platform. This feature only supports DHCP Clients which receive their DHCP lease from the local Nodegrid platform, see DHCP Server for details on how to setup the DHCP Server feature.
Create Template Device
Managed Devices:: Devices
Add
button to add a device to the system. Type
field, select a type that matches desired device type.username
and password
, or select Ask During Login
option if you want to provide user credentials during the login time Mode
Disabled, this will ensure that the device is not displayed in the access pageCreate Discovery Rule
Managed Devices:: Auto Discovery:: Discovery Rules
Add
to add a new Discovery RuleName
for the Discovery RuleStatus
for the discovered rule, possible values are: Enabled, DisabledDiscovery Method
select DHCPMAC Address
to filter to these specific entriesHost or VM Identifier
parameter can be used to further apply a filter if a value is provided then part of the port name has to match the valueAction
select an action which should be performed when a new device is discovered, possible values are: Clone (Mode:Enabled),Clone (Mode:On-Demand),Clone (Mode:Discovered),Discard discovered DevicesClone from field
select the template device which was created earlierSave
to create the ruleAfter the rule was created will device be automatically added to the system as soon as they receive an DHCP address or renew there DHCP address lease, default value for the address lease renewal is every 10min.
Create Template Device
Navigate to /settings/devices
use the add
command to create a new device
use the set
command to define the following settings
name
type
, possible values are: device_console, ilo,imm,drac,idrac6,ipmi1.5,impi2.0,ilom,cimc_ucs,netapp,infrabox,pdu*ip_address
as 127.0.0.1username
and password
, or select Ask During Login
option if you want to provide user credentials during the login time mode
to disabledsave the changes with commit
Optional, settings which control the display and behavior of the device can be adjusted at this time. See Device Settings for more details.
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/devices
[admin@nodegrid devices]# add
[admin@nodegrid {devices}]# set name=Network_Template
[admin@nodegrid {devices}]# set type=device_console
[admin@nodegrid {devices}]# set ip_address=127.0.0.1
[admin@nodegrid {devices}]# set credential=ask_during_login
or
[admin@nodegrid {devices}]# set credential=set_now
[admin@nodegrid {devices}]# set username=admin password=admin
[admin@nodegrid {devices}]# set mode=disabled
[admin@nodegrid {devices}]# commit
Create Discovery Rule
Navigate to /settings/auto_discovery/discovery_rules/
use the add
command to create a Discovery Rule
use the set
command to define the following settings
rule_name
for the Discovery Rulestatus
for the discovered rule, possible values are: enabled, disabledmethod
set to dhcpmac_address
field to filter to these specific entrieshost_identifier
parameter can be used to further apply a filter if a value is provided then part of the port name has to match the valueFor action
select an action which should be performed when a new device is discovered, possible values are: clone_mode_enabled,clone_mode_on-demand,clone_mode_discovered,discard_device
clone_from
set to the template device which was created earlier
save the changes with commit
xxxxxxxxxx
[admin@nodegrid /]# cd /settings/auto_discovery/discovery_rules/
[admin@nodegrid discovery_rules]# add
[admin@nodegrid {discovery_rules}]# set rule_name=Network_Scan
[admin@nodegrid {discovery_rules}]# set status=enabled
[admin@nodegrid {discovery_rules}]# set method=dhcp
[admin@nodegrid {discovery_rules}]# set mac_address=00:0C:29
[admin@nodegrid {discovery_rules}]# set action=clone_mode_enabled
[admin@nodegrid {discovery_rules}]# set clone_from=Network_Template
[admin@nodegrid {discovery_rules}]# commit
Most devices support additional configuration options and settings. This section will explain these settings and how they can be configured.
This feature allows the automatic discovery of a target devices hostnames (network or serial), base on its login prompt, prompt or a banner.
By default, it has already some probes and matches for most of the following devices types: PDUs, NetApp, Console Servers, Device Consoles, and Service Processors.
Nodegrid will send the first probe, and wait for a match. If there is no match, it will send the second probe, and so on. Once there is a match, the probing stops for that device.
In most case, the only configuration required is to enable the feature on the target device. For this navigate to the device in the Managed Devices
(WebUI) or settings/devices/
(CLI) section and enable the feature.
WebUI
Managed Devices:: Devices
Enable Hostname Detection
CLI
/settings/devices/<Device Name>/access
enable_hostname_detection
to yesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set enable_hostname_detection=yes
[+admin@nodegrid /]# commit
Further, to enable the feature for each target device can the following settings be adjusted under Managed Devices:Auto Discovery:Hostname Detection
(WebUI) or /settings/auto_discovery/hostname_detection
(CLI)
The following global settings can be configured
General Settings
WebUI
Managed Devices:Auto Discovery:Hostname Detection
String Type
Note: For Matches RegEx expressions are allowed. Use the variable
%H
to indicate the location of the hostname
CLI
Navigate to /settings/auto_discovery/hostname_detection/string_settings
type add
use the set
command to define string_type
as either match or probe
use the set
command to define a probe or match string
Active and save the change withcommit
Note: For Matches RegEx expressions are allowed. Use the variable
%H
to indicate the location of the hostname
Multisessions
allow multiple users to access the same device at the same time. All users will be able to see the same output. By default, the first user has read-write access, all other users have read access to the session. By enabling the option Read-Write Multisession
can this behavior be changed so that all connected users have read-write access to the session. In this case, only one user at a time has write access, the system automatically switches to the first user who is trying to enter keystrokes in the session.
It is possible to see during a session all connected users through the console session menu (see: Break Signal). This feature is available for device console sessions.
WebUI
Managed Devices:: Devices
Multisessions
Read-Write Multisession
CLI
/settings/devices/<Device Name>/access
multisession
to yeswrite_multisession
to yescommit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set multisession=yes
[+admin@nodegrid /]# set read-write_multisession=yes
[+admin@nodegrid /]# commit
This option allows users to send a break signal via the ssh console session. The function can be enabled on a per device basis and the break sequence be set.
WebUI
Managed Devices:: Devices
Enable Send Break
Break Sequence
as neededCLI
/settings/devices/<Device Name>/access
enable_send_break
to yesbreak_sequence
as neededcommit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set enable_send_break=yes
[+admin@nodegrid access]# set break_sequence=~break
[+admin@nodegrid access]# commit
Escape Sequences allow users to escape from the current session and to bring up a menu or to directly perform specific tasks like bring up the power menu.
The Nodegrid supports two escape sequences. One for the normal session menu and second for the power menu which allows for direct power control of a target device if this is set up accordingly. (See: Power Control)
Both escape sequences are preset with a default value which can be changed if needed.
Default Sequence | ||
---|---|---|
Escape Sequence | ^Ec | CTRL+SHIFT+E c |
Power Control Key | ^O | CTRL+SHIFT+O |
WebUI
Managed Devices:: Devices
Escape Sequence
or Power Control Key
as neededCLI
/settings/devices/<Device Name>/access
escape_sequence
or power_control_key
as neededcommit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set escape_sequence=^Ec
[+admin@nodegrid access]# set power_control_key=^O
[+admin@nodegrid access]# commit
By default, when accessing a target device, the user has to authenticate first against the Nodegrid unit and is then connected through to the device. If this is not required for a specific reason then this features allows to disable the Nodegrid authentication for the specific devices.
Note: This will disable any Nodegrid authentication method for this device. Ensure that appropriate authentication mechanism are setup on the target device.
WebUI
Managed Devices:: Devices
Skip authentication to access device (NONE authentication)
CLI
/settings/devices/<Device Name>/access
skip_authentication_to_access_device
to yes to disable authenticationcommit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set skip_authentication_to_access_device=yes
[+admin@nodegrid access]# commit
These features allow administrators to define a specific ssh or telnet port for target devices.
By default, each target device has a unique telnet port assign which uses port 7000 as basis port plus the port number. For ssh connections the default port will be used for all connections by default.
SSH and Telnet ports can be adjusted as needed.
Note: SSHv1 is deprecated. We only support SSHv2 now.
WebUI
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings
Tick the box beside Allow SSH protocol
or Allow Telnet protocol
.
Note: Both options are enabled by default.
CLI - SSH
/settings/devices/<Device Name>/access
set
command set allow_ssh_protocol
to yesset
command to define a ssh_port
numbercommit
the changesCLI - Telnet
/settings/devices/<Device Name>/access
set
command set allow_telnet_protocol
to yesset
command to define a telnet_port
numbercommit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set allow_ssh_protocol=yes
[+admin@nodegrid access]#set ssh_port=17001
[+admin@nodegrid access]#set allow_telnet_protocol=yes
[+admin@nodegrid access]#set telnet_port=7001
[+admin@nodegrid access]#commit
The Binary Socket Feature allows for 3rd party systems to directly access the device as if it would be physically connected. Signals will be transmitted directly and will not be encapsulated in the telnet or ssh protocol. A specific port needs to be assigned.
WebUI
Managed Devices:: Devices
Allow Binary Socket
CLI
/settings/devices/<Device Name>/access
set
command set allow_binary_socket
to yesset
command to define a tcp_socket_port
numbercommit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set allow_binary_socket=yes
[+admin@nodegrid access]#set tcp_socket_port=15001
[+admin@nodegrid access]#commit
Console sessions can be started from the WebUI, CLI or directly through a ssh/telnet client. In case a ssh client is used the default method to access a specific target device is to pass the target device name through as a parameter.
Port Aliases allow users to connect instead to a target device by using an IP Addresses. Each IP Alias supports the definition of a telnet and binary port as desired.
The Nodegrid solution supports the allocation of up to 2 IP address alias for each target device. The feature supports IPv4 as well as IPv6 Addresses.
WebUI
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings
Tick the box beside Enable IP Alias
Provide a valid IP address
Select a valid network interface through which the IP address will be accessible.
Allow the Telnet
protocol for the interface if desired
Allow Binary Socket
for direct access if desired
Repeat these steps for Enable Second IP Alias
CLI
Navigate to /settings/devices/<Device Name>/access
use the set
command set enable_ip_alias
to yes
use the set
command to define the following values as required
repeat these steps for enable_second_ip_alias
commit
the changes
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set enable_ip_alias=yes
[+admin@nodegrid access]#set ip_alias=192.168.10.249
[+admin@nodegrid access]#set interface=eth0
[+admin@nodegrid access]#set ip_alias_telnet=yes
[+admin@nodegrid access]#set ip_alias_telnet_port=23
[+admin@nodegrid access]#set ip_alias_binary=no
[+admin@nodegrid access]#set ip_alias_binary_port=15001
[+admin@nodegrid access]#commit
Each Device can be associated with a location. The location details are used to display the device and its status on the map view.
The location can be defined through address details or directly through Longitude and Latitude values. In case the location values are provided through an address, the unit does require a internet connection, for the translation into longitude and latitude.
WebUI
Managed Devices:: Devices
Address Location
field and press the locator icon to the right to identify the latitude and longitude coordinates.CLI
Note: The CLI does not support the function to look up a address and convert it to valid latitude and longitude coordinates.
/settings/devices/<Device Name>/access
set
command to provide valid latitude and longitude coordinatesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]# set coordinates="37.5418582,-121.9750624"
[+admin@nodegrid access]#set address_location="46757 Fremont Blvd, Fremont, CA 94538, USA"
[+admin@nodegrid access]#commit
A Web URL can be defined for each device. The URL will be used for the Web
command which is available for each device by default.
The default URL defined for all IP based sessions is http://%IP
whereby %IP
will be replaced by the IP Address values defined for each device.
By default, will the URL be opened inside an HTML5 frame which is forwarded to the client. This allows passing through unsecured device web interfaces without exposing the devices to the network.
This can be controlled by disabling the feature Launch URL via HTML5
WebUI
Managed Devices:: Devices
WEB URL
value as neededLaunch URL via HTML5
CLI
/settings/devices/<Device Name>/access
set
command to adjust the web_url
launch_url_via_html5
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]#set web_url="https://%IP"
[+admin@nodegrid access]#set launch_url_via_html5=yes
[+admin@nodegrid access]#commit
For each device can an icon be defined, which represents its device type.
WebUI
Managed Devices:: Devices
Select Icon
and selecting the desired iconCLI
/settings/devices/<Device Name>/access
set
command to adjust the icon
to a valid value. Use tab-tab at this point to see a list of valid values.commit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]#set icon=switch.png
[+admin@nodegrid access]#commit
The device Mode
defines how the device is managed by the Nodegrid platform and how the device status is confirmed. The system supports 4 different modes.
Mode | Description |
---|---|
Disabled | In this mode is a device disabled. No sessions can be opened to it and Nodegrid does not check if the device is reachable. |
Enabled | In this mode is a device enabled and sessions can be started. Nodegrid actively checks if a device is reachable. |
On-Demand | In this mode is a device enabled and a session can be started. Nodegrid does not check if a device is reachable |
Discovered | In this mode is a device disabled. No sessions can be opened to it and Nodegrid does not check if the device is reachable. This mode indicates that the device was added to the system through a discovery process. |
WebUI
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings
Set the device mode by selecting a valid mode from the drop-down list
Note: Discovered can not be selected as this is a system status only
CLI
Navigate to /settings/devices/<Device Name>/access
use the set
command to adjust the mode
to either
commit
the changes
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]#set mode=enabled
[+admin@nodegrid access]#commit
For each device can a expiration date or days be defined after which a device will automatically become unavailable. The default value is Never
in which case the device and its data will stay in the system until
admin user removes it.
Date – the device will be available until the date specified. After that date, it will set to Disabled
mode and admin user has 10 days to take an action. After the 10 days, the device and its data will be removed from the system.
Days – this is similar to timeout – if there is no update on the device’s configuration, after the specified days, the device and its data will be removed from the system. This is independent of the use of the device.
Both Date and Days will be mostly applied to VM devices in order to get in sync with the ESXi Servers where the VMs are constantly being added, moved, and deleted, and the Nodegrid managed device license may become available.
NOTE: This feature is only available for IP based devices
WebUI
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings
Select either Never
, Expiration Date
or Expiration Days
and provide an appropriate value.
CLI
Navigate to /settings/devices/<Device Name>/access
use the set
command to adjust the expiration
to either
never
date
set
command to provide a valid expiration date in expiration_date
days
set
command to provide a valid number of days between 0 and 9999999999 in expiration_days
commit
the changes
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]#set expiration=date
[+admin@nodegrid access]#set expiration_date=2020-01-01
[+admin@nodegrid access]#commit
or
[admin@nodegrid /]#set expiration=days
[+admin@nodegrid access]#set expiration_days=5
[+admin@nodegrid access]#commit
or
[admin@nodegrid /]#set expiration=never
Nodegrid supports for all devices which are in enabled mode a device state detection which indicates if the device is currently available.
By default uses Nodegrid for serial devices the DCD or CTS signals. In case these signal do not exist for a specific device can the device state detection be changed to use the data flow instead. In this case the state will be determent based on actual data be transmitted by the device.
To use this feature the function Enable device state detection based in data flow
needs to be enabled.
The default mechanism for IP based devices is to establish and monitor an active ssh session to a device.
Additionally to this can an ICMP (ping) check be enabled to establish if the device is active.
To use this feature the function Enable device state detection based on network traffic (icmp)
needs to be enabled.
WebUI
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings
Enable device state detection by ticking the box
for serial: Enable device state detection based in data flow
for other devices: Enable device state detection based on network traffic (icmp)
CLI
Navigate to /settings/devices/<Device Name>/access
use the set
command to enable the device state detection
enable_device_state_detection_based_in_data_flow
enable_device_state_detection_based_on_network_traffic
commit
the changes
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/access/
[admin@nodegrid /]#set enable_device_state_detection_based_in_data_flow=yes
or
[admin@nodegrid /]#set enable_device_state_detection_based_on_network_traffic=yes
[+admin@nodegrid access]#commit
This feature allows users to assign custom scripts to specific device status changes. This feature is mostly used in cases specific actions need to be performed on status changes which go beyond event notifications.
The following status changes can be used:
The scripts need to be written and provided either by the customer or through a Professional Services engagement.
The scripts need to be copied to the Nodegrid before they can be assigned to a device status. Scripts need to be placed in the /etc/scripts/access
folder. Each script needs to be executable with user privileges.
WebUI
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings and Navigate to Management
In the Scripts
section assign available scripts to a device status
Run on Session Start
Run on Session Stop
Run on Device UP
Run on Device Down
CLI
Navigate to /settings/devices/<Device Name>/management
use the set
command to assign a script to a device status
on_session_start
on_session_stop
on_device_up
on_device_down
commit
the changes
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/management/
[admin@nodegrid /]#set on_session_start=sessionstart.sh
[+admin@nodegrid management]#commit
Note: This feature is available to all text-based sessions, like serial sessions or ssh based sessions.
Through enabling of the Data Log
feature will the system be configured to collect data logs from a device. Data logs will capture all information which are sent to a device and are coming from a device. If a device is in enabled mode will the data logs collect data even if no user is currently connected to the device. This enables logging of system messages which are pushed to console sessions.
The collected data logs will be stored locally to the Nodegrid or remotely depending on the Auditing
settings.
WebUI
Managed Devices:: Devices
Logging
Data Logging
CLI
/settings/devices/<Device Name>/logging
set
command to change the data_logging
value to yes
or no
commit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/logging/
[admin@nodegrid /]#set data_logging=yes
[+admin@nodegrid logging]#commit
Note: This feature is available to Service Processor and IPMI sessions.
By enabling this feature will the system be configured to collect Service Processor Event Log data. The type of collected data will depend on the abilities and configuration of the Service Process.
With the settings Log Frequency
and Log unit
can be controlled how often the information can be collected. Collection intervals range from 1 min to 9999 hours.
The collected data logs will be stored locally to the Nodegrid or remotely depending on the Auditing
settings.
WebUI
Managed Devices:: Devices
Logging
Event Logging
Event Log Frequency
or Event Log Unit
as neededCLI
Navigate to /settings/devices/<Device Name>/logging
use the set
command to change the event_logging
value to yes
or no
use the set
command to adjust event_log_frequency
and event_log_unit
as needed
event_log_frequency
range from 1 - 9999event_log_unit
options hours
or minutes
commit
the changes
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/ipmi/logging/
[admin@nodegrid /]#set event_logging=yes
[+admin@nodegrid logging]#set event_log_frequency=1
[+admin@nodegrid logging]#set event_log_unit=hours
[+admin@nodegrid logging]#commit
The Data and Event Logging features can additionally to collecting information as well create event notifications and based on these events execute custom scripts. This is archived by defining alert strings. Alert strings can be a simple text match or a regular expression pattern string that is evaluated against the data source stream as the data is collected. Events are generated for each match.
The scripts need to be written and provided either by the customer or through a Professional Services engagement.
The scripts need to be copied to the Nodegrid before they can be assigned to a device status. Scripts need to be placed in the /etc/scripts/datalog
folder for data log events or /etc/scripts/events
folder for event logs. Each script needs to be executable with user privileges.
WebUI - Data Logging Alerts
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings and Navigate to Logging
Enable the option Data Logging
Enable the option Enable data logging alerts
Define a min of one Data String
which will be matched against the data stream
Select an available script for the defined Data Script
in case a custom script should be executed
WebUI - Event Logging Alerts
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings and Navigate to Logging
Enable the option Event Logging
Enable the option Enable event logging alerts
Define a min of one Event String
which will be matched against the data stream
Select an available script for the defined Event Script
in case a custom script should be executed
CLI - Data Logging Alerts
/settings/devices/<Device Name>/logging
set
command to change the data_logging
value to yes
set
command to change the enable_data_logging_alerts
value to yes
data_string_1
string or regular expression which will be matched against the data streamdata_script_1
an available script in case a custom script should be executedcommit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Device_Console_Serial/logging/
[admin@nodegrid /]#set data_logging=yes
[+admin@nodegrid logging]#set enable_data_logging_alerts=yes
[+admin@nodegrid logging]#set data_string_1="String"
[+admin@nodegrid logging]#set data_script_1=ShutdownDevice_sample.sh
[+admin@nodegrid logging]#commit
CLI - Event Logging Alerts
Navigate to /settings/devices/<Device Name>/logging
use the set
command to change the event_logging
value to yes
use the set
command to adjust event_log_frequency
and event_log_unit
as needed
event_log_frequency
range from 1 - 9999event_log_unit
options hours
or minutes
use the set
command to change the enable_event_logging_alerts
value to yes
define for event_string_1
string or regular expression which will be matched against the data stream
define for event_script_1
an available script in case a custom script should be executed
commit
the changes
xxxxxxxxxx
[admin@nodegrid /]# /settings/devices/ipmi/logging/
[admin@nodegrid /]#set event_logging=yes
[+admin@nodegrid logging]#set event_log_frequency=1
[+admin@nodegrid logging]#set event_log_unit=hours
[+admin@nodegrid logging]#set enable_event_logging_alerts=yes
[+admin@nodegrid logging]#set event_string_1="String"
[+admin@nodegrid logging]#set event_script_1=PowerCycleDevice_sample.sh
[+admin@nodegrid logging]#commit
Custom Fields allow users to assign additional information to devices. This information will be visible for each device in the device overview page and are fully searchable.
Custom information is stored as a key/value pair.
WebUI
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings and Navigate to Custom Fields
Click on Add
to create a new Custom Field
CLI
/settings/devices/<Device Name>/custom_fields
add
command to create a new custom fieldset
command to define a field_name
and field_value
commit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Serial_Console/custom_fields/
[admin@nodegrid /]#add
[+admin@nodegrid custom_fields]#set field_name=Custom_Field_Example
[+admin@nodegrid custom_fields]#set field_value="A Value"
[+admin@nodegrid custom_fields]#commit
Each device type offers a collection of commands, which allow users to access and interact with a device. The default configuration is sufficient for most users and is, therefore, the recommended option. If the default configuration is not sufficient can admin users disable or change existing commands, add existing commands which are not enabled by default or assign custom commands to a device. Changes made in the Command feature affect all users and should be taken with care. If an admin user wishes to not have specific commands available to certain users or groups, this can be accomplished via user and group authorization.
The available commands for a device will depend on the device type, for example, is KVM
command (which enable Service Processor KVM session support) is only available to Service Processor devices while the Outlet command is available to all device types.
Custom Commands are available to all device types and are provided through custom scripts. Custom commands can provide support for a wide range of different functions, starting from additional session options to specific custom tasks which should be performed on a device.
The scripts need to be written and provided either by the customer or through a Professional Services engagement.
Note: While Custom Commands can be executed through the WebUI and CLI, can Custom Commands currently only provide feedback and output to the CLI and not the WebUI
WebUI - Generic
Managed Devices:: Devices
Commands
Add
to and select the Command to associate it to a deviceWebUI - Custom Commands
Navigate to Managed Devices:: Devices
Click on the Target Device to access its settings and Navigate to Commands
Click on Add
to and Select Custom Commands
Script
from a list of available scripts
CLI - Custom Commands
/settings/devices/<Device Name>/commands
add
command to create a new custom fieldset
command to define a field_name
and field_value
commit
the changesxxxxxxxxxx
[admin@nodegrid /]# /settings/devices/Serial_Console/commands/
[admin@nodegrid /]#add
[+admin@nodegrid commands]#set command=custom_commands
[+admin@nodegrid commands]#set custom_command_enabled1=yes
[+admin@nodegrid commands]#set custom_command_script1=SSH.py
[+admin@nodegrid commands]#set custom_command_label1=SSH
[+admin@nodegrid commands]#commit
In Managed Devices :: Views can an admin adjust and create and tree structure, to which devices can be associated. The feature is useful to reflect specific organizational or physical structures which help users to find and access their devices.
Further, can Groups be used to aggregate monitoring values like a Rack or room level.
Device Type settings allow administrators to adjust or create customized versions of existing device types. This is beneficial in cases where the default value for a device type does not match a customer's current default values.
By either Cloning, Editing or Deleting existing device types, can these values, like the default communication protocol be adjusted as needed. These setting will take effect automatically for all devices which currently utilize the specific device type.
The Preference
menu allows administrators to define Power Menu
and Session Preferences
options further. These are global settings and will affect all sessions.
The power menu preferences options allow administrators to define the order and labeling of the power menu as it appears in a console session.
The session preference section allows users to define a session Disconnect HotKey
for console sessions. This feature is beneficial when users typically start console sessions from within console sessions, as well called cascaded console session. In this case, it can be difficult to exit a specific console session without closing all sessions in the chain. The hotkey will provide a user the option to specifically disconnect from a specific amount of the console session within the chain. Starting from the current session working its way back up the chain.
The value is by default undefined.
The Tracking features provide information about the system and connected devices like Open Sessions, Event List, Routing Table, System Usage, Discovery Logs, LLDP and Serial Statistics.
The Open Sessions
page provides an overview of connected users and devices sessions.
The Sessions Table
menu shows all users actively connected to the system, from where they are connecting from, and for how long.
In the Device Table
menu shows information about active device sessions, the amount of connected session and the users which are connected.
If a user has permission based on an authorization group, he/she can terminate sessions.
The Event List
menu provides statistical information on the system events
occurrences. Events can be selected and the current counters reset.
The complete list for registered events in the Nodegrid system follows. New events may be added as needed.
Event Number | Description | Occurrences | Category | |
---|---|---|---|---|
100 | Nodegrid System Rebooting | 0 | System Event | |
101 | Nodegrid System Started | 1 | System Event | |
102 | Nodegrid Software Upgrade Started | 0 | System Event | |
103 | Nodegrid Software Upgrade Completed | 0 | System Event | |
104 | Nodegrid Configuration Settings Saved to File | 0 | System Event | |
105 | Nodegrid Configuration Settings Applied | 0 | System Event | |
106 | Nodegrid ZTP Started | 0 | System Event | |
107 | Nodegrid ZTP Completed | 0 | System Event | |
108 | Nodegrid Configuration Changed | 0 | System Event | |
109 | Nodegrid SSD Life Left | 0 | System Event | |
110 | Nodegrid Local User Added to System Datastore | 0 | System Event | |
111 | Nodegrid Local User Deleted from System Datastore | 0 | System Event | |
112 | Nodegrid Local User Modified in System Datastore | 0 | System Event | |
115 | Nodegrid Session Terminated | 0 | System Event | |
116 | Nodegrid Session Timed Out | 0 | System Event | |
118 | Nodegrid Power Supply State Changed | 0 | System Event | |
119 | Nodegrid Power Supply Sound Alarm Stopped by User | 0 | System Event | |
120 | Nodegrid Utilization Rate Exceeded | 0 | System Event | |
121 | Nodegrid Thermal Temperature ThrottleUp | 0 | System Event | |
122 | Nodegrid Thermal Temperature Dropping | 0 | System Event | |
123 | Nodegrid Thermal Temperature Warning | 0 | System Event | |
124 | Nodegrid Thermal Temperature Critical | 0 | System Event | |
126 | Nodegrid Fan Status Changed | 0 | System Event | |
127 | Nodegrid Fan Sound Alarm Stopped by User | 0 | System Event | |
128 | Nodegrid Total number of local serial ports mismatch | 0 | System Event | |
130 | Nodegrid License Added | 0 | System Event | |
131 | Nodegrid License Removed | 0 | System Event | |
132 | Nodegrid License Conflict | 0 | System Event | |
133 | Nodegrid License Scarce | 0 | System Event | |
134 | Nodegrid License Expiring | 0 | System Event | |
135 | Nodegrid Shell Started | 0 | System Event | |
136 | Nodegrid Shell Stopped | 0 | System Event | |
137 | Nodegrid Sudo Executed | 0 | System Event | |
138 | Nodegrid SMS Executed | 0 | System Event | |
139 | Nodegrid SMS Invalid | 0 | System Event | |
150 | Nodegrid Cluster Peer Online | 0 | System Event | |
151 | Nodegrid Cluster Peer Offline | 0 | System Event | |
152 | Nodegrid Cluster Peer Signed On | 0 | System Event | |
153 | Nodegrid Cluster Peer Signed Off | 0 | System Event | |
154 | Nodegrid Cluster Peer Removed | 0 | System Event | |
155 | Nodegrid Cluster Peer Became Coordinator | 0 | System Event | |
156 | Nodegrid Cluster Coordinator Became Peer | 0 | System Event | |
157 | Nodegrid Cluster Coordinator Deleted | 0 | System Event | |
158 | Nodegrid Cluster Coordinator Created | 0 | System Event | |
159 | Nodegrid Cluster Peer Configured | 0 | System Event | |
160 | Nodegrid Search Unavailable | 0 | System Event | |
161 | Nodegrid Search Restored | 0 | System Event | |
200 | Nodegrid User Logged In | 3 | AAA Event | |
201 | Nodegrid User Logged Out | 1 | AAA Event | |
202 | Nodegrid System Authentication Failure | 4 | AAA Event | |
300 | Nodegrid Device Session Started | 0 | Device Event | |
301 | Nodegrid Device Session Stopped | 0 | Device Event | |
302 | Nodegrid Device Created | 0 | Device Event | |
303 | Nodegrid Device Deleted | 0 | Device Event | |
304 | Nodegrid Device Renamed | 0 | Device Event | |
305 | Nodegrid Device Cloned | 0 | Device Event | |
306 | Nodegrid Device Up | 0 | Device Event | |
307 | Nodegrid Device Down | 0 | Device Event | |
308 | Nodegrid Device Session Terminated | 0 | Device Event | |
310 | Nodegrid Power On Command Executed on a Device | 0 | Device Event | |
311 | Nodegrid Power Off Command Executed on a Device | 0 | Device Event | |
312 | Nodegrid Power Cycle Command Executed on a Device | 0 | Device Event | |
313 | Nodegrid Suspend Command Executed on a Device | 0 | Device Event | |
314 | Nodegrid Reset Command Executed on a Device | 0 | Device Event | |
315 | Nodegrid Shutdown Command Executed on a Device | 0 | Device Event | |
400 | Nodegrid System Alert Detected | 0 | Logging Event | |
401 | Nodegrid Alert String Detected on a Device Session | 0 | Logging Event | |
402 | Nodegrid Event Log String Detected on a Device Event Log | 0 | Logging Event | |
410 | Nodegrid System NFS Failure | 0 | Logging Event | |
411 | Nodegrid System NFS Recovered | 0 | Logging Event | |
450 | Nodegrid Datapoint State High Critical | 0 | Logging Event | |
451 | Nodegrid Datapoint State High Warning | 0 | Logging Event | |
452 | Nodegrid Datapoint State Normal | 0 | Logging Event | |
453 | Nodegrid Datapoint State Low Warning | 0 | Logging Event | |
454 | Nodegrid Datapoint State Low Critical | 0 | Logging Event | |
460 | Nodegrid Door Unlocked | 0 | Logging Event | |
461 | Nodegrid Door Locked | 0 | Logging Event | |
462 | Nodegrid Door Open | 0 | Logging Event | |
463 | Nodegrid Door Close | 0 | Logging Event | |
464 | Nodegrid Door Access Denied | 0 | Logging Event | |
465 | Nodegrid Door Alarm Active | 0 | Logging Event | |
466 | Nodegrid Door Alarm Inactive | 0 | Logging Event | |
467 | Nodegrid PoE Power Fault | 0 | Logging Event | |
468 | Nodegrid PoE Power Budget Exceeded | 0 | Logging Event |
The System Usage
page presents information about Memory Usage
, CPU Usage
, and Disk usage
for the current system.
The Discovery Logs
page shows the logs of the discovery processes set on the Managed Devices’ setting for auto discovery.
The Network
statistics page displays network Interface
information, LLDP
and the Routing Table
details.
The Interface
page displays the network interface statistics, like state, package counters, collisions, dropped and errors.
The LLDP
page shows the devices that are advertising their identity and capabilities on the LAN. You may want to enable LLDP advertising and reception through this connection
in your Nodegrid by setting it up in network connections.
The Routing Table
page shows the routing rules that Nodegrid follows for network communications. It also included any static network routes which were added.
The Devices
page shows connection statistics for physically connected devices, like serial and USB devices, and wireless modems. The available options will depend on the specific Nodegrid unit.
The Serial Statistics
page provides statistical information on the serial ports connectivity such as transmitted and received data, RS232 signals, errors.
The USB devices
page provides details about connected USB devices and initialized drivers.
The Wireless Modem
page displays information about slot, SIM status, and signal strength.
The Scheduler
page provides information about scheduled tasks when they ran, by whom and any events or errors are displayed.
The HW Monitor
page displays Nodegrid system information. Thermal
displays the current CPU temperature, System temperature as well as FAN speeds if available. Power
section displays information about the current Power sources like current state and power consumption. The section I/O Ports
is only available on devices with GPIO ports, like the Nodegrid Gate SR and Nodegrid Link SR. It will show the current status of GPIO ports.
(example NSR is shown)
This page shows the status of GPIO ports. It is only available on models with GPIO ports, like Nodegrid Gate SR and Nodegrid Link SR.
(example Nodegrid Gate SR shown)
The system settings allow the configuration of system-specific settings like license keys, general system settings, firmware updates, backup and restore and others.
Clicking on "System" brings you straight to the "Licenses" tab. This tab displays all licenses enrolled in this Nodegrid, along with other relevant information, a license key, expiration date, application, etc. The upper right corner shows the number of licenses, used and available. Licenses can be added or deleted in this page. If licenses expire or are deleted, the devices exceeding the total licenses will change the status to "unlicensed", but their information will be retained in the system. However, unlicensed devices will not show up in the access page.
A license is required for each managed device for Nodegrid access and control. The required license for each serial port of the Nodegrid is included with the product.
A managed device is any physical or virtual device defined under Nodegrid for access and control.
Main system preferences are configured in this tab.
Enter a valid address location for this Nodegrid, and click on the small compass icon/button on the right of this field to populate the "Coordinates" field below with Latitude and Longitude of that address.
The "Help Location" field is an alternate URL location for the user manual. The administrator can download the user manual and post to a specific location reachable by Nodegrid. When the small "Help" icon/button on the top right of the Nodegrid WebUI is clicked, a new web page opens with the file referenced by this URL.
This is the number of seconds for open sessions to time out due to inactivity; enter a zero value for new sessions to never expire. Configuration changes on this field will be effective for new sessions only. Existing sessions will continue following their timeout value specified at session start. This setting applies to all telnet, SSH, HTTP, HTTPS, and console sessions.
The Revision Tag
field allows to define a free format string which will be used as a configuration reference tag. This field can be manually updated by user or through an automated change management process.
The Latest Profile Applied
informs which profile was last applied through a ZTP process or the ZPE Cloud.
Use this feature to change the logo image to be used on Nodegrid's WebUI login page. The new image file has to be a .png or .jpg and can be uploaded from your local desktop or a remote server (FTP, TFTP, SFTP, SCP, HTTP, and HTTPS). Enter the respective URL format, username and password may be required. <PROTOCOL>://<ServerAddress>/<Remote File>
.
After uploading, refresh the browser cache to show the new image.
Nodegrid can be configured to show a login banner on Telnet, SSHv2, HTTP, HTTPS and Console login, to display the user a message before logging into the system. The default banner (below) can be edited and customized by the admin.
Default login banner:
xxxxxxxxxx
WARNING: This private system is provided for authorized use only and it may be monitored for all lawful purposes to ensure its use. All information including personal information, placed on or sent over this system may be
monitored and recorded. Use of this system, authorized or unauthorized, constitutes consent to monitoring your session. Unauthorized use may subject you to criminal prosecution. Evidence of any such unauthorized use may be used for administrative, criminal and/or legal actions.
Click and check respective boxes and enter the desired usage percentage to enable monitoring the utilization rate of licenses and local serial ports. An event will be generated when the percentage is reached. The default value is 90%.
Set the baud rate of the local console port. The default value is set to 115,200 bps.
Displays the state of dual power supplies (ON/OFF) and to enable alarm sound (check the appropriate box) when one power supply go down.
To acknowledge the alarm state, click on Acknowledge Alarm State
on the top left of this page System::Preferences
.
Nodegrid can be set to boot from an ISO image from the network. Enter the unit's IPv4 address and netmask, the ethernet interface to be used (eth0 or eth1), and the URL where the ISO image is http://ServerIPAddress/PATH/FILENAME.ISO
The Nodegrid supports PXE boot (Pre-Boot Execution Environment). PXE forms part of the UEFI (Unified Extensible Firmware Interface) to boot an appropriate software image retrieved at boot time from a network server. It is one of the most preferred methods in data centers for OS booting, installation, and deployment.
PXE boot is enabled by default in Nodegrid but it can be disabled via Web page under Security::Services
or via CLI within /settings/services
scope.
The example below shows how to configure the DHCP/PXE server in Linux (Ubuntu) with installed Apache web server, tftpd-hpa service and Nodegrid 4.1.x. The PXE, DHCP and TFTP servers must have been installed.
xxxxxxxxxx
Example:
root@ubuntu-srv1:~# cd /var/lib/tftpboot/
root@ubuntu-srv1:/var/lib/tftpboot# ls -l
drwxrwxr-x 2 root root 4096 Apr 24 03:20 nodegrid-4.1.xx
root@ubuntu-srv1:/var/lib/tftpboot# ls -l nodegrid-4.1.xx
total 558468
-rw-r--r-- 1 root root 22270823 Apr 24 03:19 initrd
-rw-rw-r-- 1 root root 544343672 Apr 24 03:19 rootfs.img.gz
-rw-rw-r-- 1 root root 7 Apr 24 03:19 version
-rw-r--r-- 1 root root 5242832 Apr 24 03:19 vmlinuz
root@ubuntu-srv1:/var/lib/tftpboot#
hardware ethernet
value has to match the MAC address of the Nodegrid unit, and the fixed-address
is the IP of the Nodegrid unit.xxxxxxxxxx
host PXEboot_NSC {
hardware ethernet e4:1a:2c:56:02:9e;
fixed-address 192.168.22.61;
option tftp-server-name "192.168.22.201";
next-server 192.168.22.201;
option bootfile-name "PXE/boot/grub/i386-pc/core.0";
# option bootfile-name "nodegrid-4.1.xx/boot/grub/i386-pc/core.0";
option domain-name "zpesystems.com";
option domain-name-servers 192.168.22.205, 75.75.75.75, 75.75.76.76;
option routers 192.168.22.202;
}
xxxxxxxxxx
Example:
root@ubuntu-srv1:/var/www# pwd
root@ubuntu-srv1:/var/www#
root@ubuntu-srv1:/var/www# ln -sf /var/lib/tftpboot/PXE/nodegrid-4.1.xx/ nodegrid-4.1.xx
xxxxxxxxxx
sudo service isc-dhcp-server restart
Set the Network Time Protocol (NTP) server for automatic retrieval of accurate time or set manually the date and time. NTP is the default configuration and it will try to retrieve the date and time from any server in the NTP pool. In manual configuration mode, Nodegrid will use its own clock to provide date and time information. Refresh the page to see the current system time.
Nodegrid supports NTP Authentication
and Cellular Tower Synchronization
.
NTP authentication provides an extra safety measure for the Nodegrid to ensure that a timestamp it receives has been generated by a trusted source, protecting it from malicious activity or interception.
Date and time synchronization from cell tower also provides an additional convenience for obtaining exact time directly from the carrier network.
The local time zone can also be set from the drop-down menu, the default is UTC.
Note: All timestamps in Event Logs are in UTC.
NTP provides a number of measures to reduce security risks associated with time synchronization. Authentication is one such measure. It allows a client to be sure that a response has indeed been generated from an expected source, rather than being maliciously generated or intercepted. Authentication is based on a list of agreed keys, or passwords, between a server and a client. Any communication between server and client has an encrypted version of one of the agreed keys appended to the messages. The server or client can then un-encrypt the key appended to any received communication to ensure it matches one of the agreed keys before taking appropriate action.
In the webUI as admin, navigate to System :: Date and Time :: NTP Authentication
to provide the following information:
Add each key number under System > Date and Time > NTP Authentication
Link the NTP server and its key number
Link is provided in System :: Date and Time :: Local Settings
or under System > Date and Time > Local Settings.
Use separator '|' (pipe) between server address and its key number.
This functionality is supported by units that have Wireless Modem card installed with valid SIM card. It will allow Nodegrid to get date and time from the cellular tower when the SIM card is registered to the carrier network. Check the appropriate box to enable this functionality.
It is possible to have both NTP and Cellular Tower Synchronization enabled. The last date and time received from either source will be applied. This approach allows to receive date/time information in connection failover configuration as well.
The System Logging feature enables data logging of all CLI session to the Nodegrid to be logged for later inspection and auditing.
The collected data logs will be stored locally to the Nodegrid or remotely depending on the Auditing
settings.
The Data Logging features can create event notifications in addition to collect information. This is archived by defining alert strings. Alert strings can be a simple text match or a regular expression pattern string that is evaluated against the data source stream as the data is collected. Events are generated for each match.
This section adds searchable custom fields to the unit.
Use this feature to add pieces of information that are not available by default. Nodegrid system allows the creation of custom fields so that they become part of information of the device.
Parameters for dialing to the device and callback users are configured here. Login and PPP connection features are also defined using the drop-down menu.
The Scheduler allows administrators to execute tasks and scripts on a scheduled basis. This can be used for maintenance tasks or automation tasks including end devices.
The tasks which should be executed need to be part of a cli
file or script file located on the Nodegrid. The file needs to be accessible and executable by the user.
Setting | Value | Description |
---|---|---|
Task Name | String | a Task Name |
Task Description | String | a task description will be displayed on the overview |
User | String | has to be a valid local user who has access to the script file. Default: daemon |
Command to Execute | String | Shell command which will be executed. To execute a cli file the following setting can be usedcli -f <path><cli file name> |
Minute | Integer | Minute (0-59) when the task should be executed. Default: * (any) |
Hour | Integer | Hour (0-23) when a task should be executed. Default: * (any) |
Day of Month | Integer | Day of the Month (1-31) when a task should be executed. Default: * (any) |
Month | Integer | Month (1-12) when a task should be executed. Default: * (any) |
Day of Week | Integer | Day of the Week (0-6 Sunday to Saturday) when a task should be executed. Default: * (any) |
Note: a cli file is a text file which only contains Nodegrid cli commands.
Scheduler Date and Time examples:
Run a task every day at (00:01)
Minute | 1 |
---|---|
Hour | 0 |
Day of Month | * |
Month | * |
Day of Week | * |
Run a task at 23:45 every Saturday
Minute | 45 |
---|---|
Hour | 23 |
Day of Month | * |
Month | * |
Day of Week | 6 |
Run every hour on the hour
Minute | 0 |
---|---|
Hour | * |
Day of Month | * |
Month | * |
Day of Week | * |
System maintenance features are available in System::Toolkit
page. This toolkit is used to run the followings:
Reboot and Shutdown commands allow the graceful shutdown and reboot of the Nodegrid, the system will show a warning message that all active sessions will be dropped.
During a reboot of the unit will the operating system be automatically restarted. On a shutdown will the operating system be brought into a halt state. At this point, it is safe to drop the power supply to the unit, by either turning off the power supplies or removing the power cords from the unit. To turn the unit back on the power supply will need to be stopped and then restored.
There are three methods for upgrading software; from the device itself, from the computer connected to the device or from a remote server. The ISO image of the new software must be previously loaded on those specific places.
To upgrade from the Nodegrid device itself, place the new software ISO file in /var/sw
.
To upgrade from your local computer connected to the Nodegrid, click on the Local Computer
radio button and select the file to be used for upgrading.
To upgrade from a remote server, click on Remote Server
radio button and enter the URL of the server, as well as username and password as required. FTP, TFTP, SFTP, SCP, HTTP, and HTTPS protocols are supported. The Server address can be the IP address or hostname/FQDN. If using IPv6, use brackets [ ]. For example, use
ftp://192.168.22.21/downloads/Nodegrid_v4.1.0_20191225.iso
If downgrading, you can choose to apply factory default configuration or to restore a saved configuration.
The current configuration can be saved in the Nodegrid itself, to the local computer connected to the device, or to a remote server. Give any (meaningful) name to the configuration, it will be saved to the "/backup" directory.
The server address can be the IP address or hostname/FQDN. If using IPv6, use brackets [ ... ].
FTP, TFTP, SFTP, and SCP protocols are supported.
Saved configuration can be loaded from the Nodegrid itself, from the local computer connected to the device, or from a remote server and applied on Nodegrid, which becomes the new configuration of the unit. The server address can be the IP address or hostname/FQDN. If using IPv6, use brackets [ ... ].
FTP, TFTP, SFTP, SCP, HTTP and HTTPS protocols are supported.
This option is used to restore all configuration to factory default, you can choose to clear all log files or not.
Use this feature to create a checksum baseline of a specific current configuration. This provides administrators a quick tool to verify periodically if the configuration has changed. Click to compare running configuration to the saved baseline; the main result will be "Passed" if all configuration matches (all "OK"), and will fail if there is a change detected, pinpointing the altered place.
MD5 and SHA256 are currently supported.
A certificate can be loaded from the local computer connected to the Nodegrid or from a remote server. If loading from the local computer, select the file, otherwise enter the URL of the remote server, as well as pertinent username and password.
Notice that when the certificate is applied, the web server is restarted and may disconnect active sessions.
The protocols FTP, TFTP, SFTP, SCP, HTTP, and HTTPS are supported.
This page provides essential network tools of "ping", "traceroute" and "DNS lookup", exactly as using the command line. Command output is displayed in the lower part of the page.
The Nodegrid platform provides a RESTful API, which can be used to read and change and Nodegrid configuration. The API documentation is embedded on Nodegrid and it is available under System > Toolkit > API or from the pull-down USER menu in the top right corner of the main WEB page (pull-down and click on "API Documentation").
Scroll down to reveal several examples of API requests and responses.
Example "get auditing email destination configuration"
Note: The API documentation can be found on each Nodegrid platform under
https://<Nodegrid IP>/api_doc.html
The Nodegrid Platform supports the gRPC framework. The service is disabled by default. To enable the gRPC support, review the System - Security section.
gRPC is very scalable and performance-based RPC framework which uses simple service definitions and structured data.
The Nodegrid implements 4 service definitions:
All APIRequest expect 3 arguments:
All 3 arguments follow the same structure as the existing REST API's, see https://<Nodegrid IP>/api_doc.html
for more details
All APIReply return 2 arguments:
Basic Examples:
post_request - Authentication - Returns a session ticket
xxxxxxxxxx
post_request({path: '/v1/Session', data: '{"username": "admin", "password": "admin"}'}, [...]
get_request to get network connection details
xxxxxxxxxx
get_request({path: '/v1/network/connections', ticket: 'xxxxxxxxxxxxx'}, [...]
post_request to add a phone number to the sms whitelist
xxxxxxxxxx
post_request({path: '/v1/system/sms/whitelist', ticket: 'xxxxxxxxxxxxx', data '{"name": "phone1", "phone_number": "+111111111111"}' }, [...]
put_request to update an existing value on the sms whitelist
xxxxxxxxxx
put_request({path: '/v1/system/sms/whitelist/phone1', ticket: 'xxxxxxxxxxxxx', data '{"phone_number": "+122222222222"}' }, [...]
delete_request to delete an existing value on the sms whitelist
xxxxxxxxxx
delete_request({path: '/v1/system/sms/whitelist', ticket: 'xxxxxxxxxxxxx', data '{"whitelists": [ "phone1", "phone2" ]}' }, [...]
Users can run actions remotely on Nodegrid via an SMS incoming message. The SMS message authentication must be valid and only allowed actions are executed. This feature requires a cellular connection capable of SMS messaging and it is available on units with the cellular module installed in.
This feature is supported on SMS capable models such as Nodegrid Services Router, Bold SR, Gate SR and Link SR loaded with M2-Card EM7565 M2/wireless modem.
By default, the Enable Actions via incoming SMS
is Disabled
. When this is enabled in the default state (no password), will the Nodegrid accept SMS triggered Actions from all phone numbers, and uses the MAC address of ETH0 as the default password.
Note: The SMS option requires that the SIM card and plan is SMS enabled, this can be checked with the service provider. It is recommended to check the costs for this service, as some actions can respond with multiple SMS if this is required.
Setting | Value | Description |
---|---|---|
Enable Actions via incoming SMS | String | Disabled by default |
Allowed SMS Action | Actions allowed to be triggered by SMS | |
apn - configure temporary APN | True/False | allows to configure a temporary APN |
simswap - temporary swap SIM card | True/False | triggers a SIM card failover |
connect and disconnect - on/off data connection | True/False | triggers a modem to connect or disconnect |
mstatus - request wireless modem status | True/False | current modem status is returned |
reset - reset wireless modem | True/False | triggers a reset of a modem |
info - request information about Nodegrid | True/False | about information are returned |
factorydefault - factory default Nodegrid | True/False | a factory default of the Nodegrid appliance is triggered |
reboot - reboot Nodegrid | True/False | a reboot of the Nodegrid is triggered |
The format of SMS actions and subsequent response is given in the list below. Some actions may not require a response.
xxxxxxxxxx
Message format: < password >;< action >;< argument >;
Response: <response>;
xxxxxxxxxx
1. connect: try to power on data connection:
< password >;connect;
Connect action started;
xxxxxxxxxx
2. disconnect: drop current data connection
< password >;disconnect;
Disconnect action started;
xxxxxxxxxx
3. reset: reset wireless modem
< password >;reset;
Modem Reset will start soon;
xxxxxxxxxx
4. apn: configure temporary APN
< password >;apn;<new apn>;
xxxxxxxxxx
5. mstatus: request modem status
< password >;mstatus;
Service:< LTE|WCDMA >;RSSI:< value dbm >;SIM:< sim number in use >;State:< status >;APN:< apn in use >;IP addr:< ip address when connected >
xxxxxxxxxx
6. simswap: swap sim card temporary
< password >;simswap;<timeout for sim to register in secs. max 180>;
Modem will reset to swap sim;
xxxxxxxxxx
7. info: request Nodegrid information
< password >;info;
Model: < Nodegrid model >; Serial Number: < Nodegrid serial number >; Version: < firmware version >;
xxxxxxxxxx
8. reboot: reboot Nodegrid
< password >;reboot;
Nodegrid will reboot soon;
xxxxxxxxxx
9. factorydefault: restore Nodegrid configuration to factory default
< password >;factorydefault;
Nodegrid will restore configuration to factory default and reboot;
The SMS Whitelist table allows administrators to add, delete or change phone numbers which are allowed to send SMS action triggers. Requests from all other phone numbers will be ignored. To add an entry to the whitelist click on Add
and enter items to be whitelisted.
Setting | Value | Description |
---|---|---|
Name | String | Name |
Phone Number | Phone Number | Allowed Phone Number |
Note: If the whitelist table is empty then requests from all phone numbers will be accepted.
In the Nodegrid models equipped with GPIO (Digital I/O ports), there will be a I/O Ports
tab in System System :: I/O Ports
.
This page allows setting the state of digital outputs, as well as the configuration of DIO0 and DIO1 as input or output. When DIO0/DIO1 is configured as output, the state can be set to Low or High
The Network menu allows administrators to configure and adjust all network-related settings, like configuring the network, LTE, WIFI interfaces or configuring bounding or VLAN details.
The Network Settings menu allows administrators to define the units host and domain name, configure Network Failover between multiple interfaces, enable IP Forwarding and to configure a loopback address.
The units hostname and domain name can be defined in the Network Settings menu. Provide appropriate values for both settings.
The network failover option allows administrators to automatically failover between two and three different network interfaces.
For each failover setting can an administrator define the following settings:
Setting | Options | Description |
---|---|---|
Primary Connection | Interfaces | List of all available network interfaces. One needs to be selected |
Secondary Connection/Tertiary Connection | Interfaces | List of all available network interfaces. One needs to be selected |
Trigger | Unreachable Primary Connection IPv4 Default Gateway Unreachable IP address | Based on the setting the system will either check the availability of the default gateway or of an address which can be specified |
Number of failed retries to failover | Number | Amount of failed tries to reach the trigger address. This value will be used to trigger a failover. |
Number of successful retries to recover | Number | Number of successful tries to reach the trigger address. This value will be used to trigger a fallback. |
Interval between retries (seconds) | Number | Amount of time which will be waited between tries |
The system supports configuration of Dynamic DNS for the failover interfaces.
IP Forwarding can be used to route network traffic between network interfaces. The behavior of the routing traffic can be further adjusted using firewall settings.
IP Forwarding can be enabled independently for IPv4 and IPv6.
The Nodegrid system allows configuring a Loopback address for IPv4 and IPv6 if required. The address configured is assigned with a bitmask of /32 (IPv4) or /128 (IPv6).
The Reverse Path Filtering
settings allows Administrators to configure the Reverse Path Filtering behavior of the Nodegrid device. By default, Nodegrid sets it to the Strict Mode, which is recommended for most environments as it provides protection against some forms of DDoS attacks.
It might be necessary to change this value in case dynamic routing protocols or in other specific network setup scenarios. The following options are available:
Value | Description |
---|---|
Disabled | No source address validation is performed. |
Strict Mode | Each incoming packet to the Nodegrid is tested against the routing table and if the interface represents the best return path. In case the packet can not be routed or is not the best return path it gets dropped. |
Loose Mode | Each incoming packet is tested against the route table only. In case the packet can not be routed it gets dropped. This allows for asymmetric routing scenarios. |
The Nodegrid has support for multiple routing tables, which allows for assigning specific routing details to specific network interfaces or IP clients. Thise feature is enabled by default. Administrators have the option to disable the feature if required.
The network connection configuration allows administrators to edit, to add and delete existing network configurations. The Nodegrid solution will automatically add all existing physical interfaces. The following physical interfaces exist, depending on the model.
Interface | Model | Physical Interface |
---|---|---|
ETH0 | all | eth0 |
ETH1 | Nodegrid Serial Consoles, Nodegrid Services Router | eth1 |
BACKPLANE0 | Nodegrid Bold SR, Nodegrid Services Router | backplane0 provides the connection to switch ports and sfp0 (Nodegrid Services Router) |
BACKPLANE1 | Nodegrid Services Router | backplane1 provides the connection to sfp1 |
hotspot | all | interface is bound wireless adapter if available |
For each interface can the administrator define the following settings
Settings | Description |
---|---|
Description | Interface Description |
Set as Primary Connection | Defines the interface as the primary connection for the unit, only one interface can be the primary |
Enable LLDP advertising and reception through this connection | Enables LLDP advertisement through the interface |
(IPv4/IPv6) mode | defines the IP mode to be used for the interface, available are No (IPv4/IPv6) Address DHCP (IPv4) Address Auto Configuration (IPv6) Stateful DHCPv6 Static (IPv4/IPv6) |
(IPv4/IPv6) address | Defines a static IP address, if the mode is set to static |
(IPv4/IPv6) bitmask | Defines a static IP bitmask, if the mode is set to static |
(IPv4/IPv6) gateway | Defines a static IP gateway, if the mode is set to static (Optional) |
(IPv4/IPv6) DNS Server | Defines a DNS Server to be used for this connection Defines a static IP gateway, if the mode is set to static (Optional) |
(IPv4/IPv6) DNS Search | Defines a domain name which will be used for DNS lookups |
Also, to the existing physical interfaces, additional interfaces can be defined, which allow for more advanced configuration options. The following interface types are supported.
Interface | Description |
---|---|
Bonding | Allows the Bonding of multiple interfaces for Failover purposes |
Ethernet | Allows the configuration of additional physical interfaces |
Mobile Broadband GSM | Allows the configuration of available LTE modem connections |
VLAN | This option allows the configuration of VLAN interfaces, which are bound to physical interfaces |
WiFi | This option allows the configuration of WIFI interfaces as WIFI client or hotspot. By default, a WiFi interface already exists with the name hotspot |
Bridge | Allows the creation of a Bridge interface of one or multiple physical interfaces |
Bonding interfaces allow the system to bond two physical network interfaces to one interface. All physical interfaces in the bond will then act as one interface. This allows for an active failover between the two interfaces in case a physical connection to an interface is interrupted. The built-in feature Network Failover can be used for the same purpose. The main difference is that the built-in feature Network Failover works on the IP layer and allows for more functionality, instead, a bonding interface works on the link layer.
Note: The build function Network Failover and Bonding can be combined.
For each bonding interface can the administrator define the normal network settings, like IP address, bitmask and the following specific settings.
Setting | Description |
---|---|
Primary Interface | Primary network interface |
Secondary Interface | Secondary network interface |
Bonding Mode | Allows to set the Bond mode to be used, valid options are Active Backup - Packets are only sent through one active interface, this allows for failover Round Robin - Packets are sent in a Round Robin method through both interfaces. This mode allows for load balancing and failover |
Link Monitoring | Allows the Link monitoring mode to be specified, valid options are MII ARP |
Monitoring Frequency (ms) | Allows defining a link-state monitoring frequency in ms for the interfaces. Value is only valid for MII mode. |
Link Up delay (ms) | Allows defining a delay in ms before an interface is brought up after a link is detected. Value is only valid for MII mode. |
Link Down delay (ms) | Allows defining a delay in ms before an interface is brought down after link down is detected. Value is only valid for MII mode. |
ARP target | Allows defining an IP target which will be used to send ARP monitoring requests to. Value needs to be defined for ARP mode. |
ARP validate | Allows defining which interfaces to use for the ARP validation, options are None Active Backup All |
Bond Fail-over-MAC policy | Allows to define the MAC address failover policy, possible values are Primary Interface Current Active Interface Follow Active Interface |
Additional Ethernet interfaces can be added and configured after additional physical interface were added to the system. This might be the case with a Nodegrid Manager installation, where the system might have more than two interfaces to better support network separation.
Mobile Broadband interfaces can be configured when a mobile broadband modem is available to the unit. The Nodegrid Services Router and Nodegrid Bold SR support built-in modems. For all other units, external modems can be used. The created interfaces allow the system to establish an internet connection which is most commonly used for failover options. Users and remote systems can as well directly access the device through a mobile connection if this is supported by the ISP.
Note: The build-in modems support Active-Passive SIM failover. The settings for SIM-2 are only supported for the build-in modems.
For each Mobile Broadband GSM interface can the administrator define the normal network settings, like IP address, bitmask and the following SIM specific settings, these settings are ISP specific and should be requested from the ISP before configuring the modem connection.
Setting | Description |
---|---|
SIM-1 User name | user name to unlock the sim |
SIM-1 Password | password to unlock the sim |
SIM-1 Access Point Name (APN) | Access Point Name |
SIM-1 Personal Identification Number (PIN) | PIN to unlock the sim |
Enable Second SIM card | This option allows a 2nd sim card to be configured. Only supported |
Active SIM card | Allows the definition of the primary SIM card, which will be used |
SIM-2 User name | user name to unlock the sim |
SIM-2 Password | password to unlock the sim |
SIM-2 Access Point Name (APN) | Access Point Name |
SIM-2 Personal Identification Number (PIN) | PIN to unlock the sim |
VLAN Interfaces allow the Nodegrid system to natively tag network traffic with a specific VLAN ID. For this, a VLAN Interface needs to be created. The VLAN interface will behave and allows the same settings as any other network interface on in Nodegrid solution. The new interface will be bound to a specific physical interface and the administrator as the ability to define the VLAN ID.
The Nodegrid solution supports the use of a Nodegrid as a WiFi client or access point. For this, a compatible WiFi module needs to be installed.
By default, a hotspot
interface is defined which will configure the Nodegrid solution as an access point if a WiFi module is present.
To use the Nodegrid as an Access Point change the existing values to the desired new values
To use the Nodegrid a WiFi client is it required to disable the existing hotspot
connection, by navigating to its settings and to disable the option Connect Automatically
. Ensure that the hotspot
interface is down at this point.
After this, a new WiFi interface can be created which will allow the Nodegrid to act as a client
The Wifi configuration currently supports No Security
or WPA2 Personal
security configuration options.
The following WiFi specific settings are available.
Setting | Description |
---|---|
WiFi SSID | SSID to be used |
WiFi BSSID | MAC address of the Access Point to be used |
Hidden Network | When enabled the SSID will not be broadcasted |
WiFi Security | Allows the security to be set up to either No Security WPA2 Personal |
WPA shared key | If WPA2 Personal is defined as security, then a shared key can be defined |
Bridge Interfaces all the system to create a virtual switch which crosses one or more interfaces. The switch is completely transparent to the network interfaces and does not require any additional setup. The most common use for a bridge network is together with NFV's as bridge interfaces provide easy network access for any NFV running on the Nodegrid solution, with the outside as well as with the Nodegrid system itself.
Bridge network interfaces allow the same network configuration options as all Ethernet interfaces, further to this can the following options be defined.
Setting | Description |
---|---|
Bridge Interfaces | a comma-separated list of physical interfaces |
Enable Spanning Tree Protocol | allows to enable the Spanning Tree Protocol for the interface |
Hello Time (sec) | The number of seconds a HELLO packet is sent. The setting is used when Spanning Tree is enabled. |
Forward Delay (sec) | Allows defining a packet forward delay. The setting is used when Spanning Tree is enabled. |
Max Age (sec) | Allows defining maximum age for packages. The setting is used when Spanning Tree is enabled. |
The analog modem interface allows administrators to configure an existing analog modem and the required PPP connection details. To configure this option successfully a supported analog modem needs to be connected to the Nodegrid system.
The following settings can be configured.
Setting | Description |
---|---|
Status | the status defines the connection status, options are Enabled Disabled |
Device Name | name of the detected modem, example ttyUSB0 |
Speed | The serial connection speed to the modem |
PPP Dial-Out Phone Number | |
Init Chat | This option allows defining a specific AT init string if this is required |
PPP Idle Timeout (sec) | The settings define the connection idle timeout after which the connection gets automatically disconnected. 0 sec indicates that the connection does not get automatically disconnected. |
PPP IPv4/IPv6Address | This setting allows the definition of IPv4 addresses for the PPP connection the following options are available No Address Local Configuration - allows the configuration of a local and remote IP address Accept Configuration from Remote Peer |
PPP Authentication | This setting allows the definition of PPP authentication options. Possible options are None By Local System - allows a definition of authentication protocol of PAP , CHAP , EAP By Remote Peer - allows a definition of a remote username and password |
The static routes feature allows the definition and management of static routes. Routes can be created for IPv4 and IPv6 and are assigned to specific network interfaces. The following options exist.
Setting | Description |
---|---|
Connection | Allows the selection of the network connection to which the route will be associated with |
Type | Allows the definition of the IP type. Options are IPv4 IPv6 |
Destination IP | Allows the definition of the destination IP or network |
Destination BitMask | Allows the definition of the associated bitmask in the form of xxx.xxx.xxx.xxx or xx Example: 255.255.255.0 24 |
Gateway IP | Allows the definition of the gateway address |
Metric | Allows the definition of the routing metric value. Normal routes have a default value of 100 |
The hostname feature allows the configuration and management of manual hostname definitions, which is equivalent to entries in the host's file.
The following options exist.
Setting | Description |
---|---|
IP Address | allows the definition of the target hosts IP address. IPv4 and IPv6 formats are supported |
Hostname | allows the definition of the hostname of the target |
Alias | allows the definition of additional hostname aliases |
The DHCP function allows the configuration and management of a DHCP server for target devices. The DHCP server is by default not configured and not active. After a DHCP scope is defined, the system will start serving IP addresses to all target devices which are connected to the interface which matches the general DHCP scope.
The configuration of the DHCP server is a two-step process. In the first, the general DHCP scope and configuration is configured and created. In the 2nd step can IP address ranges (Network Range
) be defined which will be used to server IP addresses as well as IP address reservations (Hosts
) for specific hosts.
The following options exist.
Setting | Description |
---|---|
SubNet | IP address subnet network which will be used. This has to match the configuration of a configured interface. |
Netmask | The network mask for the defined subnet in the format xxx.xxx.xxx.xxx |
Domain | allows defining the domain name for the scope |
Domain Name Servers (DNS) | allows the definition of DNS servers for the scope |
Router IP | allows the definition of a default gateway for the scope |
Network Range - IP Address Start | allows the definition of the first IP address which will be severed |
Network Range - IP Address End | allows the definition of the last IP address which will be served |
Hosts - Hostname | allows the definition of a hostname for IP address reservation |
Hosts - HW Address | allows the definition of a MAC address to which an IP address reservation applies |
Hosts - IP Address | allows the definition of an IP address which will be assigned to specific host matching the defined MAC address |
The Nodegrid Server Router appliance enables users to configure the built-in network switch. Allowing for advanced network configuration for each network enable card and port. Currently supported functions include the enabling and disabling of individual ports and creation of tagged (access) and untagged (trunk) ports.
Each card which provides network connectivity, Backplane 0/1 and SFP0/1 are directly connected to the switch. The interfaces Backplane0/1 and SFP0/1 are active by default and can be used to provide or consume ZTP, PXE and DHCP requests by default. All other network interfaces are disabled by default.
All ports belong to VLAN1 and provide by direct communication between all enabled interfaces, except Backplane1 and SFP1 which belong to VLAN2.
The switch interfaces provide an overview of all switch ports, their current status and allow enabling, disable, show the current VLAN associations (Tagged and Untagged) and to configure Port VLAN IDs.
The Port VLAN ID will be assigned to all incoming untagged packets. The Port VLAN ID will then be used to forward the packets to other ports which match that VLAN ID.
The switch port interface will clearly identify the VLAN interfaces to which a port belongs. On most common scenarios a port is either an untagged port which is the equivalent to an access port or a tagged port which is the equivalent to a trunk port.
The VLAN options allow administrators to create, delete and manage VLAN's and assign ports to them as needed. By default, VLAN 1 and VLAN 2 exist. All ports belong by default to VLAN 1 except BACKPLANE1 and SFP1 which belong by default to VLAN2.
To assign a port to a specific VLAN as an untagged or access port can be done by enabling the port and by then changing the PORT VLAN ID to the desired VLAN. By doing this the port will automatically be assigned to VLAN and untagged port.
Note: the VLAN needs to exist before the port can be assigned to it
Tagged ports allow incoming packets to carry already VLAN tags. Tagged ports will accept any packet which belongs to an assigned VLAN. They are mostly used to create a trunk connection between multiple switches. To assign a port as a tagged port a minimum of 1 VLAN needs to to be added to a port as tagged VLAN. This can be done through the VLAN configuration. The Port VLAN ID for a tagged port should match one of the assigned VLANs or should be blank. In this case, no untagged traffic will be accepted by the port.
Note: the VLAN needs to exist before the port can be assigned to it
The backplane settings control the switch interfaces which are exposed to the Nodegrid platform directly. For the Nodegrid to communicate with any of the existing switch ports or VLANs at least one of the backplane interfaces has to be part of the specific VLAN. The backplane settings display again the current VLAN associations and allow to set the Port VLAN ID's for the backplane interfaces.
The Nodegrid solution supports multiple VPN options, which allow the system to act as VPN servers or Clients in a variety of different scenarios. The system currently supports SSL VPN Client and Server options as well as IPSec configuration options for a host to host, site to site and others.
Nodegrid supports a wide variety of SSL configuration option and the system can act as either an SSL Client or SSL Server depending on the customer configuration and security needs.
The SSL VPN client configuration option is mostly used for failover scenarios, whereby a main secure connection fails over to a less secure connection type. The VPN tunnel is then used to secure the traffic between the sides. When the Nodegrid is configured as an SSL VPN client, the configuration gets bound to a network interface (optional) and the VPN tunnel will automatically be established as soon as the bounded interface is starting. Multiple Client configurations can be added supporting different connection and interface details.
Note: Depending on the configuration multiple files are required, which have to be present before the configuration can be completed. All files need to be placed in /etc/openvpn/CA
The following options exist for the Client configuration.
Setting | Description |
---|---|
Name | connection name |
Network Connection | allows selecting the network interface to which the tunnel will be bound. |
Gateway IP Address | IP address or FQDN of the SSL VPN server |
Gateway TCP Port | TCP port which will be used for the connection, the default value is 1194 |
Connection Protocol | supported connection protocols are UTP TCP |
Tunnel MTU | MTU size for the tunnel interface |
HMAC/Message Digest Alg | allows selecting the HMAC connection algorithm from a list |
Cipher Alg | allows selecting the connection cipher algorithm from a list |
Use LZO data compress Algorithm | Can be enabled to support data compression |
Authentication Method | allows to define the user authentication method, options are TLS Static Key Password Password plus TLS |
TLS - CA Certificate | CA Certificate used by the SSL Server |
TLS - Client Certificate | The certificate which is recognized by the SSL Server |
TLS - Client Private Key | Client Certificates Private key |
Static Key - Secret | The secret to be used |
Static Key - Local Endpoint (Local IP) | Local IP address for the VPN connection |
Static Key - Remote Endpoint (Remote IP) | The remote IP address for the VPN connection |
Password - Username | Connection Username |
Password - Password | Connection Password |
Password - CA Certificate | CA Certificate file used by the SSL Server |
Password plus TLS - Username | Connection Username |
Password plus TLS - Password | Connection Password |
Password plus TLS - CA Certificate | CA Certificate file used by the SSL Server |
Password plus TLS - Client Certificate | Client Certificate which is recognized by the SSL Server |
Password plus TLS - Client Private Key | Client Certificates Private key |
The Nodegrid can be configured to act as an SSL VPN server. By default, the server is disabled. After the server is configured and started provides the SSL Server Status page an overview of the general server status and connected clients.
Note: Depending on the configuration multiple files are required, which have to be present before the configuration can be completed. All files need to be placed in /etc/openvpn/CA
The following server configuration options exist
Setting | Description |
---|---|
Status | Default value is Disabled this setting needs to be set to Enabled to start the server after it is fully configured |
Listen IP address | This setting allows to the definition of a listening IP address if defined the server will only respond to client requests coming in on this interface. |
Listen Port number | this setting defines the listening port for incoming connections. The default value is 1194 |
Protocol | this value defines the protocol to be used options available are UDP TCP |
Tunnel MTU | allows defining the MTU used for the tunnel. The default value is 1500 |
Number of Concurrent Tunnels | allows defining the total amount of concurrent SSL client sessions. The default value is 256 |
IP Address | This section allows the definition of the IP address settings for the tunnel options available are Network Point to Point Point To Point IPv6 |
IP Address - Network - IPv4 Tunnel(NetAddr Netmask) | Allows the definition of an IPv4 network address and network mask which will be used for the tunnel |
IP Address - Network - IPv6 Tunnel(NetAddr/Bitmask): | Allows the definition of an IPv4 network address and network mask which will be used for the tunnel |
IP Address - Point-to-Point - Local Endpoint (Local IP) | Allows the definition of a local IPv4 IP address for a Point to Point connection |
IP Address - Point-to-Point - Remote Endpoint (Remote IP) | Allows the definition of a remote IPv4 IP address for a Point to Point connection |
IP Address - Point-to-Point IPv6 - Local Endpoint (Local IP) | Allows the definition of a local IPv6 IP address for a Point to Point connection |
IP Address - Point-to-Point IPv6 - Remote Endpoint (Remote IP) | Allows the definition of a remote IPv6 IP address for a Point to Point connection |
Authentication Method | This allows selecting the desired authentication method, available options are TLS Static Key Password Password plus TLS |
TLS - CA Certificate | allows selecting the CA certificate to be used |
TLS - Server Certificate | allows selecting the server certificate to be used |
TLS - Server Key | allows selecting the private key belonging to the server certificate |
TLS - Diffie Hellman | allows selecting the Diffie Hellman key |
Static Key - Secret | allows selecting the secret to be used |
Static Key - Diffie Hellman | allows selecting the Diffie Hellman key |
Password - CA Certificate | allows selecting the CA certificate to be used |
Password - Server Certificate | allows selecting the server certificate to be used |
Password - Server Key | allows selecting the private key belonging to the server certificate |
Password - Diffie Hellman | allows selecting the Diffie Hellman key |
Password plus TLS - CA Certificate | allows selecting the CA certificate to be used |
Password plus TLS- Server Certificate | allows selecting the server certificate to be used |
Password plus TLS- Server Key | allows selecting the private key belonging to the server certificate |
Password plus TLS- Diffie Hellman | allows selecting the Diffie Hellman key |
HMAC/Message Digest | allows selecting the HMAC connection algorithm from a list |
Cipher | allows selecting the connection cipher algorithm from a list |
Min TLS version | The expected connection TLS minimum version. Supported values are None TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 |
Use LZO data compress Algorithm | When enabled all tunnel traffic with be compressed |
Redirect Gateway (Force all client generated traffic through the tunnel) | When enabled all traffic emanating from a client will be forced through the tunnel. |
The Nodegrid solution supports the configuration of IPSec tunnels. The system supports a variety of configuration options for a host to host, host to site, site to site and road warrior configurations.
Note: As the Nodegrid node will be directly be exposed to the Internet. Is it strongly recommended securing the appliance. Built-in features can be used for this like:
- Configuring Firewall
- Enabling Fail-2-Ban
- Changing all default passwords with strong passwords
- Disabling services which are not required.
Multiple Authentication methods are available together with IPSec and the Nodegrid solution. Some of these are very easy to implement, like Pre-Shared keys and RSA keys but offer limited flexibility in larger setups while certificates required more initial configuration and setup but offer the flexibility and consistency to easily manage and maintain larger setups.
Pre-shared Keys is a simple and the least secure method to secure an IPSec connection. Pre-shared keys are a combination of characters which represent a secret. Both nodes need to share the same secret. Nodegrid supports pre-shared keys with a minimum length of 32 characters. The maximum length is much higher but due to compatibility reasons with other vendors, we will use a length of 64 bit for the examples below. In general, the longer the pre-shared is the more secure it is.
RSA Keys or Raw RSA keys are commonly used for static configurations between single or a few hosts. The nodes manually configured to have each other’s RSA keys as part of the configuration.
X.509 Certificate authentications are typically used for larger deployments with a small to many nodes. The RSA keys of the individual nodes are signed by a central Certificate Authority (CA). The Certificate Authority is used to maintain the trust relationship between the nodes including revocation of trust for specific nodes. Nodegrid solutions support for this purpose public and private CA’s. Further to this can the Nodegrid Solution be used to host and manage its own Certificate Authority for the IPSec communication.
IPSec supports many connection scenarios, starting from communication just between 2 nodes to communication of one node to multiple nodes, communication limited just to the nodes involved or expanding beyond the directly involved nodes to the networks access able behind the nodes. Due to the multitude of communication options, examples are provided for some of the most common scenarios.
Host to Host communication means that 2 nodes have a VPN tunnel open which connects them directly. The communication which is exchanged through the tunnel is limited to direct communication between them. None of the packages will be routed or forwarded. This is essentially a point-to-point communication between 2 nodes.
In a Host to Site communication scenario one node establishes a VPN tunnel to a 2nd node. Communication is limited on one site to the specific node and on the other side to all devices in a range of subnet which is accessible by the 2nd node.
In a Site to Site communication, the tunnel is as before established between 2 nodes, communication is allowed to specify the subnet on both sides, allowing for communication between devices on either side of the connection.
Multi-Site communication scenarios can be created by either creating individual VPN connections between hosts or by specific multi-site configurations. The later greatly improve scalability and manageability of the connection setup.
Host to multi-site communication allows multiple nodes to connect to the same node. A typical scenario for this would be that remote offices have a VPN connection to the main office. In this specific scenario would the communication be limited to the one node and devices on specified subnets in the remote locations.
This scenario is probably the most common form for enterprise VPN setups. It is similar to the Host to multi-site option but communication is allowed to the specific subnet on either side, whereby the West node would have access to all specified subnet on any of the sites but the remote sites have only access to subnet exposed by the West node.
Host to Host | Host to Site | Site to Site | Host to Multi-Site | Site to Multi-Site | |
---|---|---|---|---|---|
Pre-shared Keys | possible | possible | possible | possible | possible |
RSA Key | Recommended | Recommended | Recommended | possible | possible |
X.509 Certificates | Recommended | Recommended | Recommended | Recommended | Recommended |
This section outlines the general configuration steps which can be used to configure the desired connection.
Prepare the Nodegrid. See: How to Prepare a Nodegrid Node for IPSec
Ensure that one of the authentication methods is prepared
Note: For Production environments, it is recommended to use RSA Keys or Certificate Authentication. Pre-Shared Keys are easy to set up and are a good starting point for test environments.
Create an IPSec configuration file. Configuration Examples can be found here:
Pre-Shared Keys
RSA Keys
Certificates
Distribute and exchange configuration files and Keys as required to all nodes
Test the connection
For more detailed instruction on how t use IPSec with the Nodegrid solution, visit our Knowledge Base.
The Nodegrid platform has support for the Virtual Router Redundancy Protocol (VRRP) embedded. This protocol allows the Nodegrid to become part of a virtual router interface, which allows for redundancy of a router, this is mostly used to provide automatic failover support for default gateways. By default, is the protocol not configured and the service is not running. To enable the support needs the service be configured. This can be done by an administrator using the shell.
Note: VRRP can only be used with network interfaces which are directly exposed to the Nodegrid OS. Individual switch ports on a Nodegrid Service Router card for example can not be used.
The VRRP support is implemented through the keepalived services. The official documentation for the service can be found here.
The configuration files for the service are located in /etc/keepalived/
at a minimum the keepalived.conf
needs. to have a valid configuration. The service can then be started using the following command.
/etc/init.d/keepalived start
To automatically start keepalived on the next system start run the following command
update-rc.d -s keepalived defaults 90
Authentication is the process of validating who you are or who you claim to be, which is usually done using credentials. Credentials take most often the form of a username and password.
Authorization is the essential security part, that complements authentication. Once you are authenticated using your credentials, authorization determines what you have access to, e.g. certain directories, power or serial devices, etc.
Nodegrid has a built-in admin user account named 'admin' with full access and rights to set all configurable aspects of the unit, network, security, authentication, authorization, devices to be managed, including other users. This special user account, 'admin' cannot be deleted and it has the default password 'admin'.
Note: For security reasons, administrators are strongly advised to change the default password during the first login by using the Change Password option on the pull-down menu under your username in the top right corner of the WebUI.
The Nodegrid platform fully the supports Authentication of local users and groups as well as external users and groups. External authentication of users and groups can be done through LDAP/AD, Tacacs+, Radius and Kerberos.
All users have access to all enabled managed devices by default. Fine Grain Authorization can be enabled by selecting the option Device access enforced via user group authorization
under Services
.
Based on the groups they are assigned to, these users have limited access to Nodegrid Web portal management attributes. Privileges of users can be modified by setting profile and access rights in an authorization group. A user who belongs to the group Admin will have the same administrative privileges as the admin user. Each user must have a specific user account on Nodegrid or on an external authentication server. A user can be assigned to one or more authorization groups.
Go to Security :: Authentication :: Servers
and add some authentication server to associate any server's user to a group.
Go to Security :: Authorization
and click on Add
button to add a valid group. Remember to add some group that already has users associated with it. Set the following field and save to add a group:
group_name_in_auth_server
New local users can be added, deleted, changed and locked under Local Accounts
in Security
. Administrators can force passwords to be changed upon next login and set expiration dates for the user accounts. Regardless of activation options, users can change their passwords at any time. This feature lists all users and their respective information.
The Management of Local users can be archived under Security :: Local Accounts
. The following options are available.
Add
- New users can be addedEdit
- Existing user settings can be changedDelete
- Existing users can be removedLock
- Existing users can be locked, this will prevent users from login in, without removing the accountUnlock
- Existing locked users accounts can be unlocked Add Local Users
Navigate to Security :: Local Accounts
, all local users are displayed
Click on Add
to display the Local User Information screen
Enter a new user name and password
Hash Format Password
checkbox, see Hash Format Password belowOptionally,
To add the user to an available user group, choose the group name from the box on the left and then click Add
. To remove a user group from the box, select it and click Remove
Click Save
.
If you are an admin and prefer to not use a plain password, using instead a hash format password, you can do so using this feature. This may be of special interest in using scripts, to avoids scripts containing or displaying actual passwords of the users.
It should be noticed, however, that this requires the hash password to be generated separately beforehand, using a hash password generator of your preference. Examples of popular hash generators in Linux are OpenSSL, chpasswd, mkpasswd, using MD5, SHA256, SHA512, etc..
The Nodegrid can also be used for this purpose, its own OpenSSL implementation. Example using Nodegrid's OpenSSL version
xxxxxxxxxx
root@nodegrid:~# openssl passwd -1 -salt mysall
Password:
$1$mysall$YBFr9On0wjde5be32mC1g1
All local user accounts are subject to password rules. These can be adjusted under Security :: Password Rules
, the administrator can set values for password complexity as well as password expiration, as a set of minimum days, maximum days and warning days.
The following settings can be adjusted.
Setting | Value | Description |
---|---|---|
Check Password Complexity | True False | Enables or Disables, Password complexity rules. The default value is disabled |
Password Complexity - Minimum Number of Digits | Number | The minimum amount of digits which need to be included in the password. Default value: 0 |
Password Complexity - Minimum Number of Upper Case Characters | Number | The minimum amount of upper cases which need to be included in the password. Default value: 0 |
Password Complexity - Minimum Number of Special Characters | Number | The minimum amount of special characters which need to be included in the password. Default value: 0 |
Password Complexity - Minimum Size | Number | The minimum amount of characters included in the password. Default value: 8 |
Password Complexity - Number of Passwords to Store in History | Number | Amount of password stored in the password history. Preventing the reuse of passwords for this amount. Default value: 1 |
Password Expiration - Min Days | Number | Amount of days the password has to be valid for before it can be changed. Default value: 0 |
Password Expiration - Max Days | Number | The maximum amount of days a password can be valid for before it has to be changed. Default value: 99999 |
Password Expiration - Warning Days | Number | Amount of days, users will be notified before their password expires. Default value: 7 |
Nodegrid uses user groups to combine multiple local and remote users into a single local group, which is then used to assign system-wide administrative roles/permissions like user permission and administrative permissions. Further, are groups used to grant access permissions to specific target devices. User Groups which are authenticated against external authentication provider are mapped to local groups, this will assign the remote groups the permissions of the assigned local group.
Should a user be a member of multiple groups then the combined access rights will take effect.
Administrators can add and delete groups, as well as change their permissions. When you log in to the Nodegrid for the first time, you will see two groups in the default configuration, Admin and Users, which can not be deleted.
The Nodegrid platform contains two default groups with default permissions. The admin
grants the admin user full system and target access. user
group grants all members full access to all targets if Fine Grain Authorization is disabled (default). In case Fine Grain Authorization is enabled then the user
group members have no access to any target device by default.
Administrators can create, edit and delete groups under Security :: Authorization
Security :: Authorization
to display all groupsAdd
to enter the new group name and then Save
At this point, the group has been created to change its properties and permissions click on the group name.
Security :: Authorization
to display all groupsMembers
. This shows a list of members already in the group.Add
to show a list of local users that can be added in the left box. Add
to move the selected user to this group, in the right box. Remove
, to remove a selected user in this group and place it back to the local user's box.Security :: Authorization
to display all groupsProfile
A user group can be assigned multiple additional system permissions. All groups have by default the user
permission, granting them access to the Access
table, which will allow them to connect to target devices based on the specific target permissions.
The following system permissions can be assigned.
Note: Multiple permissions can be assigned to the same group.
Permission | Description |
---|---|
Track System Information | Grants access to tracking information. See section Tracking |
Terminate Sessions | Grants the permission to terminal user and device sessions |
Software Upgrade and Reboot System | Grants Permission to perform system upgrades and reboots |
Configure System | Grants administrative rights to change the system configuration |
Configure User Account | Grants permissions to change the Authorization setting. |
Apply & Save Settings | Grants permissions to save settings |
Shell Access | Grants access to the system shell |
The following settings can be configured
Setting | Value | Description |
---|---|---|
Permissions | Track System Information Terminate Sessions Software Upgrade and Reboot System Configure System Configure User Account Apply & Save Settings Shell Access | System Permissions |
Restrict Configure System Permission to Read Only | True False | The granted system settings are visible but cannot be changed |
Menu-driven access to devices | True False | The members of the group will be presented with a target menu when ssh connection directly to the Nodegrid is established. |
Custom Session Timeout | True False | Enable a custom session time |
Timeout [seconds] | Number | Session timeout in seconds |
Startup application | CLI Shell | Allows an administrator to set the default start application when a user of this group connects via ssh to the Nodegrid unit. Default: CLI |
Email Events to | Email Address | list of the email address to which events will be sent |
External groups need to be assigned to a local group. This will ensure that the remote group gets the correct permissions assigned. To assign an external group, follow the below steps
Note: This step is required for LDAP, AD, and Kerberos groups. Radius and Tacacs authentication provider offer other methods to link external groups/users to local groups.
Security :: Authorization
to display all groupsRemote Groups
Save
In case Fine Grain Authorization is enabled the permissions to access specific devices need to be assigned to groups. This is done by adding specific devices to a group and to set the appropriate access rights to the target. Multiple devices can be added at the same time and the access permissions can be set together.
Note: access permissions to control power outlets are granted through the
Outlets
permissions and not throughDevices
Access permissions can be added, deleted and edited for each group as necessary
Security :: Authorization
to display all groupsDevices
Add
Save
The following access permissions can be assigned
Permission | Value | Description |
---|---|---|
Session | Read-Write Read-Only No-Access | Permission to access serial or ssh sessions (Console) |
Power | Power Control Power Status No Access | Power Control permissions through IPMI |
Door | Door Control Door Status No Access | Door Control permissions |
MKS | True False | Access to MKS sessions |
Reset Device | True False | Permission to reset a device session |
KVM | True False | Access to KVM sessions |
SP Console | True False | Access to IPMI console sessions (Serial over Lan) |
Virtual Media | True False | Access to establish a Virtual Media session to an IPMI device |
Access Log Audit | True False | Access to read the access log of an IPMI device |
Access Log Clear | True False | Permission to clear the access log of an IPMI device |
Event Log Audit | True False | Permission to read the device-specific event log |
Event Log Clear | True False | Permission to clear the device-specific Event Log |
Monitoring | True False | Permission to access monitoring features |
Sensors Data | True False | Permission to read sensor data |
Custom Commands | True False | Permission to execute custom commands |
Access permissions for power outlets from Rack PDUs are controlled individually as the power to turn on or off a device can have severe consequences for the running of a data center or remote location. The assignment of permissions is analogous to device's access permissions.
Go to Security :: Authorization
to display all groups
Click on the name of the group you want to add members to
Click on Outlets
Click on Add
To move managed devices from the available device list on the left to the list of authorized devices on the right, double-click on the name or select the device and then click Add.
Devices can be removed from the box on the right by double-clicking on the device or by clicking on the delete button after selecting the device to be removed
Select desired device permissions
Click Save
Nodegrid provides an easy and simple way to enable external authentication on the platform. It can be set up to authenticate users with:
In order to allow external users access to the Nodegrid platform the following steps need to be performed independently of the specific authentication provider
Authentication providers can be added, deleted, modified in the Security :: Authentication
section. The section will display all currently configured authentication providers and allows the creation, deletion, modification, and order of the authentication providers.
The order of the authentication providers determent which one will be used first to authenticate the user. Should the authentication then fail the user access might be rejected or the next authentication provider might be tried. The authentication provider setting Fallback if denied access
control this. If the feature is enabled then the next provider will be used. If disabled the user access will be granted or denied based on the result.
Note: Should a provider not be available to authenticate users at any given time then the provider will be skipped and the next provider will be used.
All users accessing the Nodegrid need to be a member of a group. If a user can not be identified as being a group member then a default group will be used. By default, this is the user
group. The group which will be used can be adjusted using the Default Group
option.
The following section outlines how the different external authentication providers are added and configured.
The LDAP protocol is an open standard and there is a large variety of implementations, all similar but bearing slight variations. LDAP examples shown are based on OpenLDAP implementation.
Microsoft’s Active Directory is one of the largest and widely used implementations of LDAP, it allows the implementation of very complex authentication provider structure reflecting the internal organization of companies.
Provide the following information to set up an LDAP or Active Directory authentication server. Notice that this page allows enabling features such as Fallback if denied access
, Authorize users authenticated with ssh public key
and Search Nested Groups (AD only)
.
Field | Values | Description |
---|---|---|
Status | True False | Default value is Enabled. This means the provider will be used to authenticate users |
Fallback if denied access | Enabled or Disabled | Default is Disabled. It is recommended to Enable this feature in case the provider is not available. |
Remote Server | FQDN or IP of LDAP server or domain | Nodegrid supports resolution of Active Directory Servers through DNS requests. This means that either specific Active Directory Servers can be specified or a valid Active Directory Domain. In case of the later, the system will contact the closest Server based on the DNS results. |
Base | Base DN | This field can contain the Root DN or a sublevel DN. This DN marks the highest point which will be used to search for users or groups |
Authorize users authenticated with ssh public key | Enabled or Disabled | Disabled by Default |
Secure | On, Off or Start_TLS | Default is off, all traffic between the Nodegrid and the LDAP server will be sent unencrypted. On is recommended. (This feature needs to be supported by the Server) |
Global Catalog Server | True False | When enabled that the provider will use an Active Directory Global Catalog Server |
Database Username | Search User Name | Full Qualified username, which can be used to search through the directory. Only required if the LDAP server requires authentication for browsing of the directory |
Database Password and Confirm Password | Password for the search user | Only required if the LDAP server requires authentication for browsing of the directory |
Login Attribute | Field identifies the username | attribute field which contains the username. For Active Directory this is sAMAccountName by default. |
Group Attribute | Field identifies the group names | Attribute filed which contains the group identifier. For Active Directory this is memberOf by default |
Search Filter | Search Filter following the LDAP implementation | |
Search Nested Groups (AD only) | Enabled or Disabled | Disabled by Default |
Example configuration for OpenLDAP server
Field | Value |
---|---|
Status | True |
Fallback if denied access | True |
Remote Server | 192.168.1.1 |
Base | dc=zpe,dc=net |
Secure | Off |
Global Catalog Server | False |
Database Username | cn=admin,dc=zpe,dc=net |
Login Attribute | cn |
Group Attribute | memberUID |
Example configuration for Active Directory server
Field | Value |
---|---|
Status | True |
Fallback if denied access | True |
Remote Server | 192.168.1.1 |
Base | dc=zpesystems,dc=com |
Secure | Start TLS |
Global Catalog Server | True |
Database Username | cn=Administrator,cn=Users,dc=zpesystems,dc=com |
Login Attribute | sAMAccountName |
Group Attribute | memberOf |
More information on how to setup LDAP and Active Directory can be found under How to Configure Active Directory or LDAP Authentication Provider
Terminal Access Controller Access-Control System Plus (TACACS+) is a protocol developed by Cisco and released as an open standard beginning in 1993. Although derived from TACACS, TACACS+ is a separate protocol that handles authentication, authorization, and accounting (AAA) services. TACACS+ and other flexible AAA protocols have largely replaced their predecessors.
Notice that this page allows to set options such as Fallback if denied access
, Authorize users authenticated with ssh public key
, and Enable User-Level attribute of Shell and raccess services association to local authorization group
.
Field | Values | Description |
---|---|---|
Status | Enabled Disabled | Default value is Enabled. This means the provider will be used to authenticate users |
Fallback if denied access | Enabled or Disabled | Default is Disabled. It is recommended to Enable this feature in case the provider is not available. |
Remote Server | IP address | |
Accounting Server | IP address | |
Authorize users authenticated with ssh public key | Enabled or Disabled | Disabled by Default |
TACACS+ Port | TCP Port | Default port 49 |
Service | ppp shell raccess | Authentication service used by TACACS. The default value is raccess |
Secret/Confirm Secret | Secret | |
Timeout | Number | Communication timeout in seconds. Default value: 2 |
Retries | Number | Amount of retries before connection fails |
TACACS+ Version | V0 V1 V0_V1 V1_V0 | TACACS version to be used. The default value is V1 |
Enable User-Level attribute of Shell and raccess services association to local authorization group | True False | |
User Level 1 - 10 | Nodegrid group name |
RADIUS is a client/server protocol that runs in the application layer and can use either TCP or UDP as transport. Operating on port 1812, it provides centralized Authentication, Authorization, and Accounting (AAA) management for users.
The Nodegrid Platform allows multiple methods to assign Radius users to Nodegrid groups. Following options exist:
Framed-Filter-ID
be used to assign a user to a Nodegrid group
Example: Framed-Filter-ID = “group_name=<ng-groupname>[,<ng-groupname1>];”
Framed-Filter-ID
, Nodegrid supports Vendor-Specific Attributes (VSA) as well, which can be used for authorization purposes. The following 2 properties need to be defined on the Radius server
-- VENDOR ZPE 42518
-- ATTRIBUTE ZPE-User-Groups 1 stringEach user to be authorized by the Nodegrid Platform needs the ZPE-User-Groups attribute assigned. The value is a comma-separated list of Nodegrid Group names.
Configuration Example for FreeRadius server.
xxxxxxxxxx
VENDOR ZPE 42518
BEGIN-VENDOR ZPE
ATTRIBUTE ZPE-User-Groups 1 string
END-VENDOR ZPE
xxxxxxxxxx
$INCLUDE dictionary.zpe
$INCLUDE dictionary.jradius
NOTE: If both attributes are defined, "ZPE-User-Groups" will take precedence.
xxxxxxxxxx
rad-edmond Cleartext-Password := "*****"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-Filter-Id = "group_name=filter-grp1, filter-grp2;",
ZPE-User-Groups = "vsa-grp1, vsa-grp2",
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP
Field | Values | Description |
---|---|---|
Status | True False | The default value is Enabled. This means the provider will be used to authenticate users |
Fallback if denied access | Enabled or Disabled | Default is Disabled. It is recommended to Enable this feature in case the provider is not available. |
Remote Server | IP address | |
Accounting Server | IP Address | |
Secret / Confirm Secret | Secret | |
Timeout | Number | Communication timeout in seconds. The default value: 2 |
Retries | Number | Amount of retries before connection fails |
Enable ServiceType attribute association to local authorization group | True False | Allows the assignment of Radius Service Types to Nodegrid local groups |
Service Type Login | Nodegrid group name | |
Service Type Framed | Nodegrid group name | |
Service Type Callback Login | Nodegrid group name | |
Service Type Callback Framed | Nodegrid group name | |
Service Type Outbound | Nodegrid group name | |
Service Type Administrative | Nodegrid group name |
Kerberos is a computer network authentication protocol that uses tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Designed primarily as a client–server model, it provides mutual authentication. Both the user and the server verify each other's identity. It builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography. It uses UDP port 88 by default.
Field | Values | Comment |
---|---|---|
Status | True False | Default Value is Enabled. This means the provider will be used to authenticate users |
Fallback if denied access | Enabled or Disabled | Default is Disabled. It is recommended to Enable this feature in case the provider is not available. |
Remote Server | IP address | |
Realm Domain Name | Kerberos realm name | |
Domain Name | domain name |
This section covers 2-factor authentication configuration required in Nodegrid as well as RSA Security Console.
Login as admin in the Nodegrid Web Interface
Click on the 'Security' icon, then 'Authentication' tab
Click on '2-Factor' tab and then the 'Add' button
Fill in all fields following the example below (see Notes below)
Name: This name will identify your SecurID system, e.g. SecurID
Rest URL: URL to access the SecurID Authentication API. It should follow the format https://
Enable Replicas: Rest Service URL to failover to the server. There can be up to 15 replicas. One per line. e.g. rsa-am-replica2.zpesystems.com:4444, 192.168.2.229:5555
Client Key: Available through RSA Security Console. Copy/Paste the Access Key from SecurID Security Console. The Access Key is available at RSA SecurID Authentication API (under System Settings)
Client ID: Retrieve the Server Node name from the Authentication Manager Contact List.
Enable Cloud Authentication Service: If enabled, two fields will appear. These two fields are required for the service to work properly.
If RSA server is through Cloud Authentication a. Go to RSA SecurID Access, and click on the lock icon next to URL
b. Click on the Certificate
. This popup will appear. Click on the first/top certificate, and drag it to your desktop to copy it. The copied certificate will be available in your workstation and can be directly uploaded to Nodegrid. Nodegrid will convert it automatically to the expected certificate format.
The downloaded certificate file (RootCA.cer) will be available in your workstation and can be directly uploaded to Nodegrid. Nodegrid will convert it automatically to the expected certificate format.
RSA SecurID 2-factor authentication can be added to any of the supported authentication methods in Nodegrid: Local, LDAP/AD, Radius, Tacacs or Kerberos.
Nodegrid will authenticate the users following the authentication servers’ order as configured. Once a method succeeds, i.e. the user is authenticated, Nodegrid will start the 2-factor authentication if such method has such configuration.
The user will then receive a request straight from RSA SecurID to provide the token code and PIN as it was set in the RSA Security Console for such user. This process applies to users logging in via Web Browser, SSH, Telnet or Console port.
Note that for Local authentication method it is possible to enforce or skip the 2-factor authentication. This allows local Nodegrid administrators to login without having to configure the counterpart users in the RSA Security Console.
Once 2-factor authentication is enabled, the user will need to provide credentials as well as pass code in order to be granted access. This means the users allowed to login must be configured also in RSA Security Console.
To configure a user in Nodegrid’s local accounts:
The exact same users must be configured in RSA SecurID and have a token assigned.
To login in Nodegrid, first, provide the user’s credentials. Whenever 2-factor authentication is required, the login process will prompt for the information as directly requested by SecurID.
The Nodegrid platform allows users to use ssh keys for authorization. The feature is primarily designed to allow automation systems to provide secure access to the unit without the need to provide a password, hence it is designed to work with direct Shell access and each user which wants to use ssh keys needs to have a local home directory. This feature is available for all local, LDAP, AD and Tacacs+ users.
Note: Radius users can not use ssh keys for authentication.
To setup ssh key authorization for a user, the following steps need to be followed.
Security :: Authorization
Profile
option.Startup application
value to Shell, all users which are part of this group will get by default shell access and not CLI access on connection via SSHSecurity :: Local Accounts
ssh-copy-id
Optional Steps
If the user needs by default CLI access and not Shell access, then the user can be at this point be removed from the newly created Group.
If the user should be authorized by an external authentication provider like LDAP, AD or TACACS+, then the Local user account can be locked.
Security :: Local Accounts
Lock
The user can then still use the sskhey for authentication but his permissions will be enforced based on his group permissions using the external authentication provider.Nodegrid acts as a Firewall when configured to do so by an administrator. There are 6 built-in default chains, 3 for IPv4 and 3 for IPv6. These accept Output, Input and Forward packets. Additional User chains can be created and deleted if required. For each chain, the default policy can be set. The default policy is set to Accept
packages.
Default chains cannot be deleted.
Rules can be created for each chain, by clicking on the chain name. This will list all existing rules belonging to the chain. Rules can be created, deleted and modified. The following settings exist for rules. For more details review the iptables documentation.
Setting | Values | Description |
---|---|---|
Target | ACCEPT DROP REJECT LOG RETURN | |
Source IP/Mask | IP address and mask | |
Reverse match for source IP/mask | TRUE FALSE | |
Destination IP/Mask | IP address and mask | |
Reverse match for destination IP/mask | TRUE FALSE | |
Input Interface | Any Available interfaces | one value of the list can be selected |
Reverse match for input interface | TRUE FALSE | |
Output Interface | Any Available interfaces | one value of the list can be selected |
Reverse match for output interface | TRUE FALSE | |
Enable State Match | NEW ESTABLISHED RELATED INVALID | one or multiple States can be selected |
Reverse state match | TRUE FALSE | |
Fragments | All packets and fragments Unfragmented packets and 1st packets 2nd and further packets | one value of the list can be selected |
Reject With | Network Unreachable Host Unreachable Port Unreachable Protocol Unreachable Network Prohibited Host Prohibited Administratively Prohibited TCP Reset | |
Protocol | Numeric TCP UDP ICMP | |
Protocol - Numeric - Protocol Number | Protocol Number | |
Protocol - TCP - Source Port | Port Number | |
Protocol - TCP - Destination Port | Port Number | |
Protocol - TCP - TCP Flag SYN | Any Set Unset | |
Protocol - TCP - TCP Flag ACK | Any Set Unset | |
Protocol - TCP - TCP Flag FIN | Any Set Unset | |
Protocol - TCP - TCP Flag RST | Any Set Unset | |
Protocol - TCP - TCP Flag URG | Any Set Unset | |
Protocol - TCP - TCP Flag PSH | Any Set Unset | |
Protocol - TCP - Reverse match for TCP flags | TRUE FALSE | |
Protocol - UDP - Source Port | Port Number | |
Protocol - UDP - Destination Port | Port Number | |
Protocol - ICMP - ICMP Type | Any Echo Reply Destination Unreachable Network Unreachable Host Unreachable Protocol Unreachable Port Unreachable Fragmentation Needed Source Route Failed Network Unknown Host Unknown Network Prohibited TOS Network Unreachable TOS Host Unreachable Communication Prohibited Host Precedence Violation Precedence Cutoff Source Quench Redirect Network Redirect Host Redirect TOS Network Redirect TOS Host Redirect Echo Request Router Advertisement Router Solicitation Time Exceeded TTL Zero During Transit TTL Zero During Reassembly Parameter Problem Bad IP Header Required Option Missing Timestamp Request Timestamp Reply Address Mask Request Address Mask Reply | |
Protocol - ICMP - Reverse match for ICMP type | TRUE FALSE | |
Reverse match for protocol | TRUE FALSE | |
Reverse match for source port | TRUE FALSE | |
Reverse match for destination port | TRUE FALSE | |
Log Level | Debug Info Notice Warning Error Critical Alert Emergency | |
Log Prefix | Log Prefix String | |
Log TCP Sequence Numbers | TRUE FALSE | |
Log Options From The TCP Packet Header | TRUE FALSE | |
Log Options From The IP Packet Header | TRUE FALSE |
Nodegrid acts as a Firewall when configured to do so by an administrator. The NAT section allows defining rules for the NAT table and can be used to define Network Address Translation rules (NAT). There are 8 built-in default chains, 4 for IPv4 and 4 for IPv6. These accept Pre-routing, Output, Input and Post-routing packets. Default chains cannot be deleted.
Rules can be created for each chain by clicking on the chain name. This will list all existing rules belonging to the chain. Rules can be created, deleted and modified. The following settings exist for rules. For more details review the iptables documentation.
Setting | Values | Description |
---|---|---|
Target | ACCEPT DROP REJECT LOG RETURN | |
Source IP/Mask | IP address and mask | |
Reverse match for source IP/mask | TRUE FALSE | |
Destination IP/Mask | IP address and mask | |
Reverse match for destination IP/mask | TRUE FALSE | |
Input Interface | Any Available interfaces | one value of the list can be selected |
Reverse match for input interface | TRUE FALSE | |
Output Interface | Any Available interfaces | one value of the list can be selected |
Reverse match for output interface | TRUE FALSE | |
Enable State Match | NEW ESTABLISHED RELATED INVALID | one or multiple States can be selected |
Reverse state match | TRUE FALSE | |
Fragments | All packets and fragments Unfragmented packets and 1st packets 2nd and further packets | one value of the list can be selected |
Reject With | Network Unreachable Host Unreachable Port Unreachable Protocol Unreachable Network Prohibited Host Prohibited Administratively Prohibited TCP Reset | |
Protocol | Numeric TCP UDP ICMP | |
Protocol - Numeric - Protocol Number | Protocol Number | |
Protocol - TCP - Source Port | Port Number | |
Protocol - TCP - Destination Port | Port Number | |
Protocol - TCP - TCP Flag SYN | Any Set Unset | |
Protocol - TCP - TCP Flag ACK | Any Set Unset | |
Protocol - TCP - TCP Flag FIN | Any Set Unset | |
Protocol - TCP - TCP Flag RST | Any Set Unset | |
Protocol - TCP - TCP Flag URG | Any Set Unset | |
Protocol - TCP - TCP Flag PSH | Any Set Unset | |
Protocol - TCP - Reverse match for TCP flags | TRUE FALSE | |
Protocol - UDP - Source Port | Port Number | |
Protocol - UDP - Destination Port | Port Number | |
Protocol - ICMP - ICMP Type | Any Echo Reply Destination Unreachable Network Unreachable Host Unreachable Protocol Unreachable Port Unreachable Fragmentation Needed Source Route Failed Network Unknown Host Unknown Network Prohibited TOS Network Unreachable TOS Host Unreachable Communication Prohibited Host Precedence Violation Precedence Cutoff Source Quench Redirect Network Redirect Host Redirect TOS Network Redirect TOS Host Redirect Echo Request Router Advertisement Router Solicitation Time Exceeded TTL Zero During Transit TTL Zero During Reassembly Parameter Problem Bad IP Header Required Option Missing Timestamp Request Timestamp Reply Address Mask Request Address Mask Reply | |
Protocol - ICMP - Reverse match for ICMP type | TRUE FALSE | |
Reverse match for protocol | TRUE FALSE | |
Reverse match for source port | TRUE FALSE | |
Reverse match for destination port | TRUE FALSE | |
Log Level | Debug Info Notice Warning Error Critical Alert Emergency | |
Log Prefix | Log Prefix String | |
Log TCP Sequence Numbers | TRUE FALSE | |
Log Options From The TCP Packet Header | TRUE FALSE | |
Log Options From The IP Packet Header | TRUE FALSE |
The Services page allows defining the Active Services
running on the system as well as general service settings for ZPE Cloud
, Managed Devices
, Intrusion Prevention
, SSH
settings to the systems itself, Web Service
settings and Cryptographic Protocols
for the Web Service.
This allows configuring the security level of the system. For instance, can unsecured protocols like Telnet or HTTP be disabled, or the SSH version which is allowed to access the system.
ZPE Cloud is a cloud based management platform for Nodegrid products. No need for shipping pre-configured devices to the branch. ZPE Cloud makes the initial deployment, configuration and ongoing management simple and provides with a 360 visibility of the entire deployment along with rich analytics that are easy to understand and operate.
ZPE Cloud coupled with Nodegrid devices allow for shipping the IT devices without having to stage or pre-configure them. Configure the IT devices only when they are at the branch in safeguard. Deploy consistent automated provisioning via the ZPE Cloud from the safety of your NOC.
ZPE Cloud brings together all Nodegrid products on a cloud platform. Use “Reset” button available on all Nodegrid products to reconnect back your Nodegrid to the ZPE Cloud.
The ZPE Cloud
section allows configuring the cloud services on the unit. The following settings are available:
Setting | Value | Description |
---|---|---|
Enable ZPE Cloud | TRUE FALSE | Enabled by Default for the Nodegrid SR family (NSR, GSR, BSR & LSR) Note: Nodegrid Serial Console default value is disabled. |
Enable File Protection | TRUE FALSE | Disabled by Default. When enabled, any file transfer will require an authentication hash based on this password to validate the integrity and origin of the file. |
Enable File Encryption | TRUE FALSE | Disabled by Default. When enabled, file must be encrypted via ZIP by the owner using the password defined under file protection. |
⚠️ For Nodegrid units shipped prior to Nodegrid v4.1, the following command must be executed by root
in order to enroll the unit to the ZPE Cloud.
The script can be called with 3 combinations of arguments as shown below:
xxxxxxxxxx
root@ZPECloudNSR2:~# zpe_cloud_enroll -h
Usage: zpe_cloud_enroll [options]
ZPE Cloud Enrollment
Options:
-v, --version Displays version information.
-h, --help Displays this help.
-c <customer-code> ZPE Cloud customer code to enroll device.
-k <enrollment-key> ZPE Cloud customer enrollment key.
-r Read customer enrollment key from barcode.
If no arguments are provided, the device will request that the customer code
and the enrollment key
to be entered:
xxxxxxxxxx
root@ZPECloudNSR2:~# zpe_cloud_enroll
Enter your customer code: 2
Customer Code: "2"
Enter your enrollment key: example_key
For this case, customer code (-c) and enrollment key (-k) are provided as the script arguments:
xxxxxxxxxx
zpe_cloud_enroll -c 2 -k example_key
Once the ZPE Cloud is enabled on the unit, access www.zpecloud.com to manage all enrolled devices. The cloud management portal requires a Company registration and an admin user account.
The Active Services
page allows controlling which Services should be enabled in the system and which network ports they should be using.
The following settings are available:
Setting | Value | Description |
---|---|---|
Enable detection of USB devices | TRUE FALSE | Enabled by Default |
Enable RPC | TRUE FALSE | Required for NFS share access |
Enable gRPC | TRUE FALSE | Support for gRPC protocol. Disabled by Default |
Enable FTP Service | TRUE FALSE | |
Enable SNMP Service | TRUE FALSE | Enabled by Default |
Enable Telnet Service to Nodegrid | TRUE FALSE | |
Telnet TCP Port | Port number | Default value: 23 |
Enable Telnet Service to Managed Devices | TRUE FALSE | |
Enable ICMP echo reply | TRUE FALSE | Enabled by Default |
Enable USB over IP | TRUE FALSE | |
Enable Virtualization Services | TRUE FALSE | Needs to be Enabled in order to run NFV's or Docker apps. Both features require licenses |
Cluster TCP Port | Port Number | Default value: 9966 |
Enable Automatic Cluster Enrollment | TRUE FALSE | |
Search Engine TCP Port | Port Number | Default Value: 9300 |
Enable Search Engine High Level Cipher Suite | TRUE FALSE | |
Enable VM Serial access | TRUE FALSE | Enabled by Default |
VM Serial Port | Port Number | Default Value: 9977 |
vMotion timeout [seconds] | Number in seconds | Default Value: 300 |
Enable Zero Touch Provisioning | TRUE FALSE | Enabled by Default |
Enable PXE (Preboot eXecution Environment) | TRUE FALSE | Enabled by Default |
The Managed Devices
section allows controlling of general aspects and services controlling managed devices. The following settings are available.
Setting | Value | Description |
---|---|---|
Device access enforced via user group authorization | TRUE FALSE | When this feature is enabled, users will only have access to devices listed under the authorization groups that the user belongs. If this feature is not enabled, all enrolled devices in the Nodegrid will be available to the user and the user will be able to access them without restriction. |
Enable Autodiscovery | TRUE FALSE | This feature allows the Auto Discovery of managed devices on the network. |
DHCP lease controlled by autodiscovery rules | TRUE FALSE | If this feature is enabled then the DHCP server will only server leases to devices which have been discovered through the Auto Discovery process. This feature is only available when Enable AutoDiscovery is enabled. |
The Intrusion Prevention
section allows the configuration of mechanisms which can prevent unauthorized access to a system, like Fail 2 Ban
and Rescue Mode
. The following settings are available.
Setting | Value | Description |
---|---|---|
Block host with multiple authentications fails | TRUE FALSE | |
Period Host will stay blocked (min) | Number in min | Amount of time the system will not be reachable on the network. Default value:10 |
Timeframe to monitor authentication fails (min) | Number in min | Amount of time during which failed authentication attempts are counted and before the counter gets reset. Default value:10 |
Number of authentication fails to block host | Number | Amount of failed authentication attempts during Number of authentication fails to block host before the host will be blocked. Default value:5 |
Rescue Mode requires authentication | TRUE FALSE | After this feature is enabled, the Rescue Mode will require authentication through a local user account, like root. |
Password protected boot * | TRUE FALSE | After this feature is enabled, editing BIOS and Grub will require authentication based on password defined here. |
Password Protected Boot is a patent-pending feature that allows Nodegrid OS to communicate with BIOS in order to enable the BIOS password to prevent unauthorized changes on it. The same password will also protect Grub from unauthorized changes.
The SSH
section allows configuration of the SSH service controlling access to the Nodegrid system. The following settings are available.
Explicit specification of SSHv1 is eliminated. We only support SSHv2 now.
Setting | Value | Description |
---|---|---|
SSH allow root access | TRUE FALSE | Allows root access through SSH, Enabled by default. |
SSH TCP Port | Port Number | Default value: 22 |
SSH Ciphers | allowed list of ciphers | Default value: blank, which allows all ciphers which are supported by Nodegrid |
SSH MACs | allowed list of MAC addresses | Default value: blank, which allows all systems to access the Nodegrid via ssh |
SSH KexAlgorithms | an allowed list of key exchange algorithms | Default value: blank |
The Web Service
section allows the configuration of the web server. The following settings are available.
Setting | Value | Description |
---|---|---|
Enable HTTP access | TRUE FALSE | Default value: Enabled |
HTTP Port | Port Number | Default value: 80 |
Enable HTTPS access | TRUE FALSE | Default value: Enabled |
HTTPS Port | Port Number | Default value: 443 |
Redirect HTTP to HTTPS | TRUE FALSE | Default value: Enabled |
The Cryptographic Protocols
allow configuration of ciphers which are supported to access the web server. The following settings are available.
Setting | Value | Description |
---|---|---|
TLSv1.3 | TRUE FALSE | Default value: Enabled |
TLSv1.2 | TRUE FALSE | Default value: Enabled |
TLSv1.1 | TRUE FALSE | Default value: Enabled |
TLSv1 | TRUE FALSE | Default value: Disabled |
Cipher Suite Level | High Medium Low Custom | Default value: Medium |
Cluster is a Nodegrid feature that establishes a secure and resilient connection among other Nodegrid platforms so that when Clustering is enabled, multiple Nodegrid systems can easily manage and access all managed devices from other nodes. Nodegrid makes cluster access management even easier with cluster asset search. By logging into any Nodegrid node users can search the entire Nodegrid-managed enterprise network and cluster with a single interface. This allows for vertical and horizontal scalability.
There are two types of clustering topologies:
The Peers
page lists all Nodegrid units that are enrolled in the cluster.
The table shows the name of each Nodegrid, their IP Addresses, type, and status of communication with other peers.
Peers can be removed by selecting entries and then clicking on the Remove
button.
If the Nodegrid is the coordinator, it cannot be removed from the table.
In this section, the Cluster feature and the additional services Peer Management
and License Pool
can be enabled and configured.
Note: The Cluster feature requires a software license for each node in the cluster.
The Cluster feature can be enabled by checking the Enable Cluster
checkbox. Each Cluster requires to have one Coordinator
which coordinates and controls the enrollment of peer systems.
The first unit the cluster needs to be set as Type
Coordinator. All other units can then be set to type Peer. The role of the Coordinator
can later be changed to another system by selecting the Type of Coordinator on a peer. The change will then automatically propagated through the system.
If the Nodegrid is the coordinator, make sure the Allow Enrollment
checkbox is checked, and provide a Cluster Name
and Pre-Shared Key
so that peers can be enrolled to the Cluster. Select also Cluster Mode
as Star or Mesh, to configure the type of clustering desired.
Please note that the Cluster Name
and the Pre-Shared Key
will be used in the Peer’s settings.
If the Nodegrid is the Peer, then enter the Coordinator’s Cluster Name
, Coordinators's Address
, and the Pre-Shared Key
.
Check the Enable Clustering
checkbox for allowing other Nodegrid systems to manage, access, and search all managed devices from other nodes.
Note: In MESH, the Coordinator is only required for the enrollment of the peers. Once all Nodegrid systems were enrolled in the Cluster, the Coordinator can be set as Peers to prevent the enrollment of other units.
The Automatic Enrollment
features allow administrators to automatically add new Nodegrid systems which become available to an existing cluster. The feature is enabled by default for Peers
to be detected. The setting Pre-Shared Key
need to be the same on the Coordinator as well as on the Peers. It is set by default to nodegrid-key. The value Interval [seconds]
only applies to coordinators and regulates how often invitations are sent to potential peers. This is based on the defined network list.
After the Coordinator
is enabled and configured, the admin user can add a range of IPs where other Nodegrid systems are on the network. To add network ranges for the discovery process add them to the Automatic Enrollment Range
page under Cluster Settings.
Note: It is recommended to only add IP's to the Automatic Enrollment Range which are potentially Nodegrid units, as the system will send continually invitations to all IP's until a Nodegrid unit was found on a specific IP and it was added to the Cluster.
This way, the Coordinator will communicate with any Nodegrid system on those ranges and add them to the Cluster, thus eliminating the need to go to each of the Nodegrid nodes and set them as peers.
The License Pool
feature allows for central management of all software licenses within a cluster. For this at least one unit needs (in STAR, it should be the coordinator) to be set up as a License Pool Server
, all other units are set up as License Pool Clients
, which is the default setting.
License Pool Clients will automatically request required licenses from the License Pool Server
. Licenses Pool Server will check the availability of licenses and assign the requested licenses if they are available. The Client will renew the licenses dependent on the servers Renew Time [days]
. In case a client becomes unavailable for an extended period of time and exceed the servers Lease Time [days]
, then the licenses will become invalid on the client and return to the pool. The Lease Time [days]
option accepts values from 7-30 days.
The currently leased licenses can be viewed on the License Pool Server in the System :: Licenses
section.
Note: Each Nodegrid unit is shipped with 5 additional test target licenses. The test license will be licensed automatically when a target license is added to the system. This applies as well if a target license is applied through the license pool server. This means the first time a system request target licenses it will request 5 additional licenses to cover the currently used test licenses.
The Peer Management
feature enables a function to centrally upgrade the firmware of Nodegrid units in the cluster. To enable the feature select Enable Peer Management
.
The cluster Management
page allows then to start the software upgrade process for remote Nodegrid units from a central location. The firmware which will be applied to the units needs to be hosted on a central location which is available through a URL.
Note: The URL should include the remote server’s IP or hostname, file path, and the ISO file. For example:
ftp://192.168.2.200/nodegrid/Nodegrid_Platform_v3.1.0_20160127.iso
The page lists all Nodegrid systems in the Cluster. Select desired nodes that have the Management Status as Idle. If the status shows disabled, it means that the Nodegrid has Peer Management
feature disabled. Once the selection is done, click on the Software Upgrade button. Select Remote Server
and enter URL
, Username
, and Password
.
The option Format partitions before upgrade
will format the Nodegrid units hard drive before performing the firmware upgrade.
If downgrading the software, you have the option to Restore configuration saved on version upgrade
or Apply factory default configuration
.
The auditing feature allows events which have been created to be sent to four different destinations: Email, File, SNMP Trap, and Syslog. It also allows data logging and events logging to be stored locally, remotely via NFS or sent to a syslog server.
The Data logging feature allows capturing the data stream going to and coming from target devices as well as from the Nodegrid system. General settings for the data logging feature are available under Auditing :: Settings
. The following settings are available.
Setting | Values | Description |
---|---|---|
Enable File Destination | TRUE FALSE | When the feature is enabled all Data Logs are stored to the defined File location under Auditing Destinations . Default Value: Enabled |
Enable Syslog Destination | TRUE FALSE | When the feature is enabled all Data Logs are sent to the defined Syslog location under Auditing Destinations .Default Value: Disabled |
Add Timestamp on every line logged | TRUE FALSE | When this feature is enabled, a timestamp will be added to each data log line |
Timestamp Format | UTC Local Time | Defines the timestamp timezone, which will be used. Default value: UTC |
The Nodegrid system automatically creates events based on its and device settings. All events get stored to the local file system by default. This behavior can be adjusted under Auditing :: Events
. The administrator can configure to which destination events get logged and which event categories get logged.
The system supports 4 event categories which can be individually controlled:
Note: Under
Tracking :: Event List
are all events listed and the category they belong to.
Each of these event categories can be configured to send the events to any of the 4 event destinations or to none. Event Destinations are:
Data logs are written by default to files which are maintained locally. The file destination and archive settings can be set under Auditing :: Destinations :: File
Note: NFS requires RPC service to be enabled in Security :: Services
The following options are available.
Setting | Values | Description |
---|---|---|
Destination | local NFS | |
NFS - NFS Server | IP address of NFS Server | |
NFS - NFS Path | Path to the NFS root directory | Each unit should have its own root directory. |
File Size [Kbytes] | File size in Kbytes | File size at which the file will be rotated. Valid values are between 0 (disabled) and 2048 Kb. Default value: 1024. |
Number of Archives | Number | Number of archive files which should be kept before they will be discarded. Default value: 10 max value: 99 |
(NFS) Archive by Time [HH:MM] | Time in format HH:MM | Time at which the file archive will be rotated. Default value: blank |
The Syslog destination can be used to store data logs and event notifications. The system supports a local Syslog destination or a remote IPv4 and IPv6 destination.
The following option is available.
Setting | Values | Description |
---|---|---|
System Console | TRUE FALSE | Syslog events will be displayed on the Nodegrid system console port sessions. By default, this option is enabled |
Admin Session | TRUE FALSE | Syslog events will be displayed and any admin session which is open to the Nodegrid system. By default this option is disabled. |
IPv4 Remote Server | IP address | One or multiple IP addresses can be provided. Addresses need to be separated by a comma. |
IPv4 Address or Hostname | TRUE FALSE | By default is disabled |
IPv6 Remote Server | IP address | One or multiple IP addresses can be provided. Addresses need to be separated by a comma. |
IPv6 Address or Hostname | TRUE FALSE | By default is disabled |
Event Facility | Log Local 0 Log Local 1 Log Local 2 Log Local 3 Log Local 4 Log Local 5 | Defines the Syslog logging facility for Events |
Data Logging Facility | Log Local 0 Log Local 1 Log Local 2 Log Local 3 Log Local 4 Log Local 5 | Defines the Syslog logging facility for data logs |
Any triggered event can be sent via an SNMP trap to an existing NMS system. The Nodegrid system supports SNMP v2 and 3 for traps. The MIB files for the Nodegrid system are available together with the firmware files.
The MIB files are located as follows:
xxxxxxxxxx
root@nodegrid:~# ls -l /usr/local/mibs/
total 104
-rw-r--r-- 1 root root 36940 Nov 20 2017 NodeGrid-MIB.asn
-rw-r--r-- 1 root root 61403 Nov 20 2017 NodeGrid-TRAP-MIB.asn
-rw-r--r-- 1 root root 2732 Nov 20 2017 ZPESystems.smi
Note: SNMP3 INFORM messages are currently not supported.
The following options are available.
Setting | Value | Description |
---|---|---|
SNMP Engine ID | none | Displays the systems Engine ID |
Server | IPv4 or IPv6 IP address | |
Transport Protocol | UDP-IPv4 TCP-IPv4 UDP-IPv6 TCP-IPv6 | protocol used to send the traps. Default is UDP-IPv4. |
Port | TCP port | default value is 161 |
Trap Version | Version 2c Version 3 | SNMP version to be used |
Version 2c - Community | community name | |
Version 3 - User Name | user name | |
Version 3 -Security Level | noAuthNoPriv authNoPriv authPriv | |
Version 3 -Authentication Algorithm | MD5 SHA | |
Version 3 -Authentication Password | Password | |
Version 3 -Privacy Algorithm | DES AES | |
Version 3 -Privacy Passphrase | Passphrase |
Events can be sent via Email to an email address. The following options are available.
Setting | Value | Description |
---|---|---|
Server | SMTP server address | |
Port | TCP port to be used | Default port is 25 |
Username | Username | |
Password | Password | |
Confirm Password | Password | |
Destination Email | email address | target email address to which the events will be sent to |
Start TLS | TRUE FALSE | Should TLS be used for the communication |
The Monitoring feature allows Nodegrid to monitor and collect sensor data from Managed Devices which are connected to a Nodegrid sensor or support SNMP or IPMI as a protocol.
The collected data are defined and controlled through Monitoring Templates
which will be assigned to a monitored device during its configuration.
There are a number of preexisting monitoring templates, which typically fulfill the user's requirements. Should the need arise then these templates can be customized.
All templates are text files located in sub directories of the/etc/collectd.templates
directory according to the protocol used to collect the monitoring data, either SNMP or IPMI.
/etc/collectd.templates/snmp
/etc/collectd.templates/ipmi
Any new file in these directories will automatically appear in the user interface.
To create a new SNMP template, login as root to the shell. Create a copy of one existing template as a starting point for the new template.
Each SNMP template file has two types of subsections:
Data
Host
The template file should only include data points which are of interest, all other data points can be removed from the file.
The following table explains the settings and the possible values for a data entry
Setting | Value | Description |
---|---|---|
Data | Internal name of the Data point as it will be collected by the Nodegrid system. The Name should be unique. | the name should not have any spaces. Example Data "pdu_in_cur" Data "pdu_in_vol" |
Type | temperature fanspeed humidity counter percent timeleft voltage current power apparent_power power_factor frequency | data type |
Table | true false | reflects if the OID is part of a table or not |
Instance | true false | If Table is true: A SNMP OID prefix that will be walked to retrieve a list of names that will be associated with the corresponding values. For example, in a PDU this could be the outlet name. If Table is false: The name [of the instance] that will be associated with the value, as a string. |
InstancePrefix | String | Optional. A string to the prepend to the Instance, enclosed in double quotes. |
Values | true false | If Table is true: The SNMP OID prefix that will be walked to retrieve a list of values. If Table is false: The SNMP OID used to retrieve a single value. |
Scale | Decimal value | Optional. A decimal value to be multiplied to the value retrieved before persisting it. |
Example
xxxxxxxxxx
<Data "pdu_in_cur">
Type "current"
Table true
Instance ".1.3.6.1.4.1.476.1.42.3.8.40.20.1.20"
Values ".1.3.6.1.4.1.476.1.42.3.8.40.20.1.130"
Scale 0.01
</Data>
The host entry in an SNMP template does only require an adjustment in the Collect
setting. The values list should contain a list of all data entries which should be collected. All listed data entries require a corresponding data entry definition.
The ‘discover’ template for IPMI will automatically discover all the sensors available on an IPMI device.
The template will have only one subsection, Host, and the options of interest are:
Setting | Value | Description |
---|---|---|
AuthType | none md2 md5 straight | The authentication type for the IPMI protocol. The default is to negotiate the strongest one. |
Privilege | callback user operator admin | The privilege level for the IPMI protocol. The default is admin . |
Sensor | Name of the Sensor to be collected | Selects sensors to collect or to ignore, depending on IgnoreSelected. May be defined multiple times, each one selecting one sensor. |
IgnoreSelected | true false | If true, will not collect that for the sensors selected by Sensor. If false will only collect the sensors selected by Sensor. |
Scale | “ | Optional. A decimal value to be multiplied to the value retrieved before persisting it. |
Monitoring is enabled on a per-device basis. The settings are part of the Managed Device settings. To enable Monitoring are the following steps required.
Managed Device
section.Management
sectionNodegrid provides the dashboard tool to visually see Event Details, Managed Device details and monitoring data from the system and the Managed Devices. It gives the flexibility to create several dashboards for different purposes and monitor managed devices data points such as Power Consumption, Voltage (V), Current (A), Temperature, Fan speed, and many more. It provides options to show data from a different period of times such as the last 15 minutes, the last hour, the last day, this week, this month, the last 5 years.
The Dashboard guide will provide a starting point on how to create simple and useful Dashboards which can be expanded if needed and allow users to create the relevant dashboards.
Note: The Dashboard feature is only available through the WebUI
This section is not required, but it will describe how it can be verified that the collected data are stored and to learn more about the data being collected. The raw data points which are collected can be viewed by performing the steps below.
Click on Dashboard
Click on Discover
Select the desired Index Pattern
logstash-*
contains monitored data*_date_*
contains event notificationsBy default, all data are displayed which were collected in the defined time frame.
Search
field to search for a specific device or data pointVerify that data points where collected and inspect the available fields.
Note: As collected data is buffered before being stored, it can take a couple of collection cycles before the data can be visualized.
The following fields can be used in search expressions.
Data Point fields (logstash-*
Index )
Field | Values | Description |
---|---|---|
host | Device Name | The name of the device being monitored. |
plugin | snmp ipmi nominal aggregation | Name of the collection plugin |
plugin_instance | sum average | The instance of the plugin collecting the data, if the plugin requires it. Present in the aggregation plugin |
collectd_type | temperature fanspeed humidity counter percent timeleft voltage current power apparent_power power_factor frequency | Type of measurement |
type_instance | Data Point Name | The name of the element associated with the measurement |
Device fields (logstash-*
Index )
Field | Values | Description |
---|---|---|
name | Device Name | The name of the device being monitored. |
mode | enabled ondemand disabled | operational mode of the device |
type | device type | Device type as assigned to the device under Managed Devices |
family | ilo drac ipmi_1.5 ilmi_2.0 cimc_ucs device_console pdu | device family |
addr_location | Address | |
coordinates | Coordinates | |
ip | IP address | |
mac | MAC address | The MAC address of the device, if known. |
alias | IP address alias | |
groups | list of groups | The authorization groups which have granted access to the device |
licensed | yes no | device license state |
status | connected disconnected in-use unknown | The current status of the device |
nodegrid | Nodegrid hostname | The hostname of the Nodegrid that controls the device |
custom fields | Any custom field configured for the device |
Event fields (*_date_*
Index )
Field | Value | Description |
---|---|---|
event_id | Number | Event ID number |
event_msg | Text | Event Message |
host | Nodegrid hostname | hostname of the Nodegrid where the Event occurred. |
message | Text | Full message text |
Visualizations allow the gathered data to be displayed on a Dashboard. The Visualization includes a wide variety of different options to display and aggregate data. The following sections cover a small subset of the options available and aim to be a starting point in the creation process of custom visualizations.
Line Charts allow the visualization of data points along the line graph. It is one of the most common graphs used.
The following process outlines the general steps to create a line chart.
Click on Visualize
Select a Visualization Style to be used. In this example, a Line Chart
will be created
Select a search source
by clicking on From a new search.
Select logstash-* as index pattern
Select the data points you want to visualize by entering a search expression such as host:”<device name>”
in the search field.
The search expression can be extended to be more selective.
Click on the Arrow
to the left of Y-Axis to expand it.
Select Average for Aggregation
and value for Field.
Click on X-Axis.
Select Date Histogram as Aggregation
. Leave Field
and Interval
as default. If you just want your visualization to be a single-line graph, skip the next sub-steps, as the next steps will split the data point set into a multi-line graph.
Click on Add sub-buckets
to add multiple data points.
Click on Split Lines
.
Select Filters as Sub Aggregation
.
Enter a search expression to select the element you want to visualize.
Optionally, associate a label by clicking on the settings icon
provide a label
Click on Add Filter
to add another element to the visualization
Click on the green arrow to refresh the graph based on the configuration provided.
The graph will reflect the configuration provided.
Click on the Save
icon to save the visualization.
Provide a Title for the visualization and click on Save
.
The area chart, which is useful for stacking measurements for different although related entities, such as the outlets of a PDU.
Note: Review the
Line Chart
section before continuing with theArea Chart
Click on Visualize
Select a Visualization Style to be used. In this example, a Area Chart
will be created
Configure the visualization options to have Chart Mode
as stacked.
This is the appearance of such a visualization
All search expressions are used to select, or limit, the data points that will be used to compose the visualization. They can be used as a filter for the whole visualization, as sub-aggregation filters, or as a filter for the whole dashboard.
These search expressions are not restricted to the data points’ fields, but they can also refer to fields associated with the device in Nodegrid, such as type, IP address, authorization groups, custom fields, and more
For example, to collect the current provided by each outlet in a selection of Rack PDUs, one with the custom field “rack:abc” and another with “rack:xyz”.
To show the total sum of the current provided by outlets of each Rack PDU the following settings can be used.
Aggregation
as Sum
buckets
interval to match the collecting period
Sub-Aggregation
filters are set to custom fields
The resulting visualization would look like this
Filters can be added to display the values of only one Rack PDU by using the IP address
Additional filters can be used as needed, all from the same visualization.
Note: When using area charts too careful to not account for the same measurement twice, by mixing power consumers and power producers, or a Rack PDU’s input and output power.
Dashboards are a collection of one or more visualizations. They can be changed or new Dashboards can be created. The following steps outline how a new Dashboard can be created.
Click on Dashboard.
Click on the new dashboard icon.
Click on the add visualization icon.
This will show the previously saved visualizations. Click on the visualization you want to add to the dashboard.
Repeat the previous steps until all the desired visualizations are added.
Resize and reposition the graphs as needed.
If applicable, filters can be added to the dashboard.
Click on the save icon.
Provide the dashboard name and then click on save.
From this point on can be opened and viewed, following the below steps.
Click on Dashboard.
Click on the folder icon.
Click on the dashboard name. It is possible to search for a dashboard by entering a search expression in the dashboard filter.
The selected dashboard will show up.
The display time frame can be adjusted by clicking on the clock icon.
Selecting a new time frame.
It is possible to automatically refresh the Dashboard by clicking on the auto-refresh icon and select the refresh frequency
The Nodegrid platform allows running additional applications on it. This is mostly used to expand software capabilities like running specific applications close to the end devices. The most common use cases are in the areas of monitoring and SD-WAN. While all Nodegrid units support this feature, is the Services Router Family specifically designed to run applications and provides a wide variety of connectivity options.
Note: The applications feature requires additional licenses to be installed. The Virtualization service is by default disabled and needs to be enabled under
Services
Docker is an open platform for building, shipping and running distributed applications. The Nodegrid platform allows administrators to run Docker applications. The platform allows pulling of Docker applications from Docker Hub, starting and stopping of the Docker Containers.
Note: "Enable Virtualization Services" must be enabled in Security :: Services in order to run NFV's or Docker apps. Both features require licenses (System :: License).
Note: The management of Docker Applications is currently only available through the WebUI. The WebUI provides a basic interface to manage Docker Containers. For more advanced features can administrators use the docker command line tools.
The Applications :: Images
section allows administrators to download and to delete specific Docker containers images. They can be directly downloaded from Docker Hub. For this, the Nodegrid requires direct network access to Docker Hub.
New Images can be download following the below steps.
Navigate to Applications :: Images
Click on Add
Provide the image which should be downloaded, specific versions can be downloaded by using the :
sign
Click on Save
, the image will now be downloaded
The Applications :: Containers
section allows administrators to add a container based on an existing image to the Nodegrid system. The container can be started, stopped and deleted if required.
For additional detail see the official Docker create documentation.
Note: After the container was created it will not be started automatically.
To add a container follow the following steps.
Navigate to Applications :: Containers
Click on Add
Provide the following information
Setting | Value | Description |
---|---|---|
Image name | name of a Docker Image | List of valid image names can be found under Applications :: Images |
Command | Command | Optional, command which will be run within the container |
Hostname | hostname | Hostname which will be assigned to the container |
Domain | domain name | Domain name which will be assigned to the container |
Container Name | Name | Name of the Docker container |
CPUs | NUMBER | Amount of CPU's which will be assigned to the container |
Memory(MB) | NUMBER | Amount of RAM assigned to the container |
Arguments | Arguments | Optional, Options which will be used when the container is created |
Application Links allow administrators to create simple web links to running containers and other applications.
Applications :: Links
Add
Name
for the linkURL
fieldSelect Icon
Note: Depending on the Application might it be advantages to create a target device for the created Application.
The Nodegrid platform allows administrators to run additional NFV's or other Virtual Machines. A large variety of configuration options is available through the command line interface.
Please contact Technical Support for more information.
Our Technical Support staff are standing by to provide assistance in case you have any operational or installation issues regarding your licensed Nodegrid product. In order to be assisted in the fastest way possible, follow the steps below:
To submit an online ticket request for support follow the following steps:
Submit a request
link in the top right corner of the page.I'm not a robot
checkbox.Submit
You will receive an Email from ZPE Systems confirming that your request has been received and will be reviewed by our support staff. The Email will as well contain your ticket number. Please take note if the ticket number and refer to it at later times as needed.
To automatically receive information about important security patch announcements, future firmware updates, and other technical information, sign up to The Loop here:
In order to redirect the VMware virtual machine vSPC data to Nodegrid Platform, the virtual machine serial port needs to be configured as described below:
To modify the outgoing port range, connect to the ESXi command line and execute the following commands:
Edit the port section:
Save the changes and then restart the firewall service:
For further information on VMware firewall, please refer to VMware Knowledge Base.
DC power is connected to DC-powered equipment using three wires: Return (RTN), Ground (⏚) and 48 VDC.
Warning It is critical that the power source supports the DC power requirements of your Nodegrid. Make sure that your power source is the correct type and that your DC power cables are in good condition before proceeding. Failure to do so could result in personal injury or damage to the equipment.
Warning Wiring to power from a DC supply may be confusing, especially in telecom racks, where the supply's positive wire (usually of red color) goes to the ground, and the hot wire (usually of black color) carries the -48VDC. In case of any doubt, consult a certified electric technician before proceeding with connections. Failure to do the right connections could result in personal injury or damage to the equipment.
Figure: Dual DC Power Connection Terminal Block
Number | Description |
---|---|
1 | Power Switch |
2 | RTN (Return) |
3 | Ground (⏚) |
4 | 48 VDC |
Figure: DC association - terminal power source and switch
Figure: NSR Single DC + PoE Power Connection Terminal Block
To power a Nodegrid unit with DC power:
AC diagram for the NSR models with PoE+ support
Figure: NSR Single AC + PoE Power Input and Switch
The tables below display serial port pinout information.
Cisco-like Pinout
Pin | Signal Name | Input/Output |
---|---|---|
1 | CTS | IN |
2 | DCD | IN |
3 | RxD | IN |
4 | GND | N/A |
5 | GND | N/A |
6 | TxD | OUT |
7 | DTR | OUT |
8 | RTS | OUT |
Legacy Pinout
Pin | Signal Name | Input/Output |
---|---|---|
1 | RTS | OUT |
2 | DTR | OUT |
3 | TxD | OUT |
4 | GND | N/A |
5 | CTS | IN |
6 | RxD | IN |
7 | DCD | IN |
8 | Unused | N/A |
Please refer to the links below for product safety information.
Please refer to the links below for product installation information.
Please refer to the links below for RoHS information.
In normal operation, user data resulting from keystrokes, managed devices output, and device monitoring data passing through our product may be stored in nonvolatile device memory when data logging or monitoring is enabled in the configuration settings.
The Nodegrid devices contain the following memory devices:
There are two ways to remove user data from the nonvolatile memory of Nodegrid unit:
Erase the nonvolatile memory of Nodegrid using the following procedure:
Access Nodegrid unit with one of the following options:
xxxxxxxxxx
****************************************************************************
*Nodegrid Manager <version> *
*Nodegrid Manager <version> - Factory Default Settings *
*Nodegrid Manager <version> - Rescue Mode <-- *
*Nodegrid Manager <version> - Network boot *
*Nodegrid Manager <version> (verbose) *
* *
* *
* *
* *
* *
* *
* *
* *
****************************************************************************
xxxxxxxxxx
` Use the * and * keys to select which entry is highlighted.
Press enter to boot the selected OS, `e' to edit the commands
before booting or `c' for a command-line.`
Apply factory settings completed.
INIT: Switching [ ... ] reboot: System halted
Erase the nonvolatile memory of Nodegrid unit using the following procedure:
Access Nodegrid unit with one of the following options:
xxxxxxxxxx
GNU GRUB version 2.00
+--------------------------------------------------------------------------+
|Nodegrid Platform - Chain boot |
|Nodegrid Platform - Rescue Mode |
|Nodegrid Platform - Secure Erase <-- |
| |
| |
| |
| |
| |
| |
| |
| |
+--------------------------------------------------------------------------+
xxxxxxxxxx
`Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, `e' to edit the commands
before booting or `c' for a command-line.`
Nodegrid Boot live - Secure Erase
This action will completely erase the system. Using this procedure will destroy ALL data on the SSD and render it unrecoverable even by data recovery services. After executing this step, system software will no longer exist and must be reinstalled via network.
Type 'erase' to secure erase the SSD or 'cancel' to reboot:
Note: Secure Erase requires the unit to be power cycled (powered off and powered on) prior to executing the erase command. Otherwise, the following message will show and the system will halt to allow the user to perform a power cycle as required:
Operation not supported. Unit must be power cycled prior to erase command.
Wait for system halt and power cycle the unit.
[ 4.614365] reboot: System halted
Secure erase cannot be canceled once confirmed.
Type 'yes' to confirm secure erase:
Secure erase of SDD will start now…
security_password="PasSWorD"
/dev/sda:
Issuing SECURITY_SET_PASS command, password="PasSWorD", user=user, mode=high
security_password="PasSWorD"
/dev/sda:
Issuing SECURITY_ERASE command, password="PasSWorD", user=user
Secure erase completed. System halting…
[ 29.083186] reboot: System halted
Access here for a copy of the Letter of Volatility
ZPE Systems, the ZPE Systems logo, Nodegrid, and Nodegrid Manager are registered Trademarks of ZPE Systems, Inc. or its affiliates in the U.S. and other countries.
All other marks are the property of their respective owners.
© 2013-2019 ZPE Systems, Inc.
Contact us
Sales: [email protected]
Support: [email protected]
ZPE Systems, Inc.
46757 Fremont Blvd.
Fremont, CA 94538
USA