Adding Devices
Adding Devices#
To add, as an example, a Cisco router, add the following to your devices.yaml, with the relevant details changed for your device:
All Device Parameters#
| Parameter | Type | Description |
|---|---|---|
* name | String | Device's user-facing name. |
* address | String | Device management hostname or IP address. |
* network | String | Network Configuration |
* port | Integer | TCP port used to connect to the device. 22 by default. |
* nos | String | Network Operating System. Must be a supported platform. |
structured_output | Boolean | Disabled output parsing to structured data. |
driver | String | Override the device driver. Must be 'scrapli' or 'netmiko'. |
*credential | Device Credential Configuration | |
*vrfs | Device VRF Configuration | |
proxy | SSH Proxy Configuration | |
ssl | SSL Configuration for devices using hyperglass-agent. |
network#
A network is only used for grouping. For example, if your network contains more than one ASN, you might want to group each device separately. Currently, you must define a network on each device.
| Parameter | Type | Description |
|---|---|---|
* name | String | The network's name. This name is only used by hyperglass internally. |
* display_name | String | The network's use-facing name. |
proxy#
Any device that uses SSH (see platforms for breakdown) can be accessed through an intermediary SSH "proxy". The process is nearly identical to using local SSH tunneling, e.g. ssh -L local_port:remote_device:remote_port [email protected]_server -p proxy_port.
| Parameter | Type | Default | Description |
|---|---|---|---|
* name | String | Proxy hostname. | |
* address | String | Proxy management hostname or IP address. | |
* credential | Proxy Credential Configuration | ||
nos | String | 'linux_ssh' | Proxy's network operating system. Must be a supported platform. |
port | Integer | 22 | TCP port user to connect to the proxy. |
important
Currently, only linux_ssh has been tested and validated for use as an SSH proxy.
credential#
While all devices require a credential mapping, the credential values themselves may be used in different ways depending on the device NOS. For SSH devices, the credential is used as a typical SSH username and password.
For HTTP devices (i.e. devices using hyperglass-agent), the username is ignored and the password is used as a secret for JSON Web Token encoding/decoding.
| Parameter | Type | Description |
|---|---|---|
* username | String | Username |
password | String | Password Passwords will never be logged |
key | Path | Path to SSH Private Key |
To use SSH key authentication, simply specify the path to the SSH private key with key:. If the key is encrypted, set the private key's password to the with the password: field, and hyperglass will use it to decrypt the SSH key.
ssl#
HTTP devices may optionally use SSL for the connection between hyperglass and the device. This is disabled by default, which means devices will use unencrypted HTTP by default.
If SSL is enabled, the public key of the device must be provided in the form of an accessible absolute file path. With SSL enabled and a valid certificate specified, every connection to the device will use HTTPS in addition to payload encoding with JSON Web Tokens.
| Parameter | Type | Description |
|---|---|---|
enable | Boolean | Enable or disable the use of SSL. If enabled, a certificate file must be specified (hyperglass does not support connecting to a device over an unverified SSL session). |
* cert | String | Absolute path to agent's public RSA key. |
vrfs#
The VRFs section is a list of available VRFs for a given device. Each VRF may be configured with the following fields:
| Parameter | Type | Description |
|---|---|---|
* name | String | The VRF's name, as known by the device. hyperglass sends this field to the device for queries, so it needs to match the device's configuration. If this is the default/global routing table on the device, this value isn't sent to the device. |
display_name | String | The VRF's user-facing name. This field's value is visible in the UI. If this is not specified, hyperglass will try to create a "pretty" display name based on the name field. |
default | Boolean | Indicate that this VRF is the device's default/global routing table (more specifically, that it does not require specifying the VRF name when running commands).If this is set to true, the ipv4_default/ipv6_default command sets. If set to false, the ipv4_vpn/ipv6_vpn command sets will be used. |
info | Per-VRF Contextual Help Configuration | |
ipv4 | VRF's IPv4 Configuration | |
ipv6 | VRF's IPv6 Configuration |
ipv4#
May be set to null to disable IPv4 for this VRF, on the parent device.
| Parameter | Type | Description |
|---|---|---|
* source_address | String | Device's source IPv4 address for directed queries (ping, traceroute). |
force_cidr | Boolean | true |
access_list | IPv4 Access List Configuration |
ipv6#
May be set to null to disable IPv6 for this VRF, on the parent device.
| Parameter | Type | Default | Description |
|---|---|---|---|
* source_address | String | Device's source IPv6 address for directed queries (ping, traceroute). This address must be surrounded by quotes. Ex. "0000:0000:0000::" | |
force_cidr | Boolean | true | Convert IP host queries to actual advertised containing prefix length |
access_list | IPv6 Access List Configuration |
note
The force_cidr option will ensure that a BGP Route query for an IP host (/32 IPv4, /128 IPv6) is converted to its containing prefix. For example, a query for 1.1.1.1 would be converted to a query for 1.1.1.0/24. This is because not all platforms support a BGP lookup for a host (this is primary a problem with IPv6, but the option applies to both address families).
When force_cidris set to true, hyperglass will perform a lookup via the bgp.tools whois API to get the advertised prefix for an IP host.
access_list#
The access_list block can be thought of like a prefix-list from Cisco IOS. It is a list of rules, where the first matching rule is the action executed.
| Parameter | Type | Default | Description |
|---|---|---|---|
* network | String | This rule's IPv4 or IPv6 base prefix | |
action | String | 'permit' | This rule's action. Must be permit or deny |
ge | Integer | 0 | To match this rule, the target prefix must be greater than or equal to ge |
le | Integer | 32 | 128 | To match this rule, the target prefix must be less than or equal to le |
info#
Each VRF may enable, disable, or customize the contextual help menu for each enabled query type. The following parameters may be defined under any query type:
| Parameter | Type | Default | Description |
|---|---|---|---|
enable | Boolean | true | Enable or disable the help menu for this command. |
file | String | Path to a plain text or markdown file containing customized help information for this command. | |
params | Object | Any arbitrary key/value pairs where the value will replace any occurrences of the key when wrapped in braces (e.g. {key}) |
For example:
Telnet#
Telnet support is provided via the underlying device connection handling framework, Netmiko. To connect to a device via serial, add the suffix _telnet to the device's nos value and set the port value to 23.
For example:
Full Example#
Below is a full example with nearly every available knob turned:
YAML Anchors & Aliases#
If you have a lot of devices with shared configuration parameters, you may want to look into YAML Anchors and Aliases. If you've never used them before, they can be pretty weird looking at first read. Atlassian has a pretty decent guide.
Here's an example of using this to share two sets of credentials among multiple devices:
important
Nothing other than the routers key is read by hyperglass. In the above example, my_credentials is just an arbitrary list of mappings, is completely optional, and can be named whatever you want.
For a more complex example, here's an example of how to use YAML aliases & anchors to share a common VRF configuration among multiple devices, while overriding key variables such as the source_address key: