Management traffic is any service that makes direct contact to another asset, either to retrieve or interface with the configuration and status of hardware components (conductor to router), the core operating system (NTP), features of user interfaces to the OS (DNS), or the business application, sometimes taking subsequent action to maintain or change configurations. All actions ultimately provide underlying support to the service being delivered by the managed resource to its users. Access is typically controlled via a set of privileges and will usually allow either modification and/or viewing of sensitive system configurations. Management traffic includes three categories: management, monitoring, and data backups and restores.
Networking equipment's management traffic typically traverses a separate physical interface for the purposes of network isolation and policing.
Depending on the nature and size of a deployment, the hardware platform may not have the required number of physical interfaces to separate management traffic. In these cases, the forwarding WAN interface can be leveraged for management traffic.
When using a separate non-forwarding interface for management traffic, packet forwarding is managed by Linux's routing table. Leveraging 128T's native routing capabilities for management traffic provides additional security, segmentation and advanced routing policy.
When provisioning management traffic to traverse forwarding interfaces, those interfaces will continue to be available for management related functions (e.g., ssh) even when the 128T is not running, yet will still be protected by firewall rules that match the respective policy. This is particularly important during maintenance operations when the 128T software is taken offline for an upgrade.
Once a forwarding interface is provisioned for management traffic, any existing OS configuration for that interface such as ifcfg and firewall rules will be overwritten to match the 128T configuration.
One of the strengths of the 128T data model is to dynamically apply policy only as needed. As it relates to management traffic, service policy will only be created for those management applications provisioned. The list of applications natively supported are:
- Conductor traffic. This works in tandem with conductor services
- Web server access
- DNS traffic for FQDN resolution
- Software Updates
When enabled, a default route will be configured in Linux's routing table to send all traffic to the interface
kni254, which is the pathway into the 128T packet forwarding engine. Thus, standard 128T forwarding rules apply: any traffic originated by the host operating system that does not match a configured service will be dropped. Services and corresponding service routes are automatically created for the applications listed above.
Because a default route is added in Linux, all traffic not captured by a static route, will be sent to the 128T. This means that the traffic will either be dropped, or match an existing service and route.
For each of the management services configured, the 128T will automatically generate corresponding
service-route configurations for forwarding the respective traffic. The generated configuration objects will all start with the prefix
Each of the service and service-routes share one important attribute: they are created with the
generated flag set to
true. If you want to make any modifications to the generated services, you must first set
false, or else your configuration changes will be stripped upon the next time the configuration is committed. For more information on configuration work-flows involving the
generated flag, refer to the 128T software documentation.
management interfaces cannot be used on device-interface types of
DNS servers can be configured within
authority > router > dns-config > address in one of two ways:
automatic- if the management interface is configured for DHCP, then the DNS server(s) learned through the DHCP lease are used
static- up to two DNS server addresses can be configured
These addresses are assumed to be reachable via the configured management interface(s).
If static DNS servers are configured and a network-interface is configured to obtain its address via DHCP, the DNS servers learned through the lease are ordered after any statically defined entries.
dns-config > address is required, however setting
dns-config > address to
automatic is only allowed when a management interface is enabled for DHCP.
When provisioning multiple management interfaces, a management vector is used to provide preference amongst the interfaces.
When the 128T service is not running, a default route is created for the interface configured as management with the lowest metric (if multiple management interfaces are configured).
For example, the following 128T configuration:
Will produce the corresponding configuration within Linux:
Management interfaces can be configured for redundancy between nodes of a HA pair by provisioning
authority > router > node > device-interface > shared-phys-address. If the interface is redundant and management, a
authority > router > node > device-interface > network-interface > address > utility-ip-address is required on the network-interface. This address is assigned to the Linux interface when 128T is not running with the original MAC address, not the virtual
shared-phys-address from 128T configuration. The
utility-ip-address must be unique per node across the router.
router > node > device-interface > network-interface > source-nat must be set to
true when using management over forwarding since all management traffic will originate from
router > node > device-interface > network-interface > default-route must also be set to
true to ensure that Linux uses the network interface as its preferred route for traffic originating from the host OS.
For any other service not defined by the default management services list, the user can configure a service to best suit their needs. It is necessary to configure the internal tenant within the
access-policy of the service to allow traffic originating from the Linux host.