The System category has 9 subnavigation options available – API Key, Powercode Settings, SNMP, DNS, NTP, Update Firmware, Backup/Restore Config, Factory Default and Reboot.
The API key page displays the current PI key needed to integrate the BMU with your Powercode management system. If the key is compromised or you wish to change it, you can click Generate New API Key to generate a new one.
This page allows you to configure a number of different options directly related to Powercode. The redirect IP option determines where the BMU will redirect unauthorized users to – this is typically the IP of your management server. The management IP should be set to the IP of your management server – if this is set incorrectly, the management server may not be able to send commands to the BMU.
The default behavior option can be set to one of three settings – Allow, Deny or Slave.
In Allow mode, the BMU will allow unknown users to pass through if they meet the following criteria:
- The IP address of the user is not within a defined address range
- The IP address of the user is unknown within Powercode
The purpose of this mode is to allow BMUs to be installed in a ring or chain configuration. Each BMU would be set to Allow mode. They would then control their known users (address ranges configured in Powercode) and would allow through other users configured on other BMUs.
In Deny mode, the BMU will deny all unknown users.
In Slave mode, the BMU will perform no redirection or rate limiting. The sole purpose of this mode is so the BMU can provide DHCP and network monitoring in the network, typically when it is a slave of a Procera PRE BMU.
Maximum Download/Maximum Upload
These settings are directly related to bursting. While total traffic on an interface is below this number, customers will be allowed to burst. Once traffic exceeds this number, bursting will no longer be allowed. This is typically set to the speed of your upstream.
This setting determines whether or not the DHCP server has the authoritative flag set. The purpose of this is that a DHCP client can request its last known IP address. If the client remains connected to a network for which this IP is valid, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request if the IP is not valid, making the client ask for a new IP address immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address.
Generally, if the BMU is the only DHCP server on the network, it is best to set this to authoritative. If it is not and it may hear requests destined for other DHCP servers, it is best to set it to not authoritative.
By default, SNMP access to the BMU is disabled. You can enable it here as well as setting the read community, location and contact information. Currently, the BMU only supports reads, no writes. The BMU implements the standard Ethernet and Linux MIBs – there is currently no custom MIB available.
Here you can configure the DNS servers the BMU should use to resolve hostnames. This is defaulted to Google public DNS (188.8.131.52/184.108.40.206).
You can set the timezone you wish to use and an NTP server here. This defaults to pool.ntp.org. After changing the timezone, you may wish to reboot the BMU to reset the times in your logfiles as you may end up with out of entry log timestamps otherwise.
You can save a binary configuration file here or restore an older configuration file. Configuration files are also stored in Powercode automatically when any change is made to the BMU configuration. You can only restore backups that match your current BMU firmware version – e.g. a 3.3.10 backup can only be restored if you are running version 3.3.10 on your BMU.
This page allows you to reset the BMU to factory default.
Use this to reboot the BMU.