-
Notifications
You must be signed in to change notification settings - Fork 231
Configuration
This page provides information about how to configure Gatekeeper using configuration files (static configuration) and at runtime (dynamic configuration).
The network and individual blocks are configured using the configuration files in the lua directory:
- Network
- Control Plane Services (CPS)
- Dynamic Configuration
- GT-GK Unit (GGU)
- Gatekeeper (GK)
- Grantor (GT)
- Link Layer Support (LLS)
- Solicitor (SOL)
Since Gatekeeper is a DPDK application, it can be given EAL parameters from the command line to configure various device, debugging, and memory options.
There are two EAL parameters that may be especially useful when running Gatekeeper:
--log-level <val>
The global log level is the baseline log level for all logs in Gatekeeper (see Network for more information). The global log level defined in the command line is only used for the early Gatekeeper setup, and is overwritten by the global log level defined in lua/net.lua.
--log-level gatekeeper:<val>
The Gatekeeper log level is used for all logs that are not directly related to the individual blocks (see Network for more information). The Gatekeeper log level defined in the command line is only used for the early Gatekeeper setup, and is overwritten by the Gatekeeper log level defined in lua/net.lua.
In addition to the EAL configuration, Gatekeeper can be configured via application parameters:
--lua-base-dir <val>
The base directory for Gatekeeper Lua files. The default base directory is ./lua.
--gatekeeper-config-file <val>
The Lua configuration file to initialize Gatekeeper. The default lua file is gatekeeper_config.lua.
--log-file-name-format <val>
The name format of log files. The default name format is gatekeeper_%Y_%m_%d_%H_%M.log.
--log-base-dir <val>
The base directory for Gatekeeper log files. The default base directory is ..
--log-file-mode <val>
The file permissions in octal value for Gatekeeper log files. The default mode is S_IRUSR | S_IWUSR, which corresponds to -rw-------.
At runtime, Gatekeeper can be dynamically configured using the Dynamic Configuration. This allows the user to add, delete, and show routes, neighbors, policies, etc.
Gatekeeper uses a packet queuing system that classifies IP (both IPv4 and IPv6) packets between Gatekeeper and Grantor servers according to whether they are request packets, granted packets, or legacy/unclassified packets. See Packet Priority Queuing for an overview of this queuing scheme.
Routers along the path from Gatekeeper servers to Grantor servers can adhere to Gatekeeper's packet queuing scheme by using the Traffic Control (tc(8)) mechanism in Linux. Such routers should configure interfaces that transmit Gatekeeper traffic by assigning queue disciplines for granted traffic and for request traffic. Request channel traffic should also be bandwidth limited (e.g. to 5% of the egress bandwidth) consistent with the configuration of the Solicitor block(s) of the Gatekeeper server.
Granted traffic should utilize RED queues with ECN, and request traffic should utilize the tc-skbprio(8) queuing discipline. This queue discipline maintains priority queues for each request priority (3-63), but also enforces a global limit over the number of packets among all priorities.
Below is an example configuration to enable a Linux router to adhere to Gatekeeper's queuing scheme:
tc qdisc add dev eth0 handle 1:0 root htb default 4 tc class add dev eth0 parent 1:0 classid 1:1 htb rate 10gbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 0.5gbit prio 1 tc class add dev eth0 parent 1:1 classid 1:3 htb rate 9.5gbit prio 2 tc class add dev eth0 parent 1:1 classid 1:4 htb rate 8bit ceil 10gbit prio 3 tc qdisc add dev eth0 parent 1:2 skbprio tc qdisc add dev eth0 parent 1:3 handle 30: sfq limit 3000 flows 512 divisor 1024 redflowlimit 1992296 min 83012 max 249037 probability 0.01 ecn headdrop tc filter add dev eth0 parent 1:0 prio 1 matchall action skbedit inheritdsfield action goto chain 10 tc filter add dev eth0 parent 1:0 prio 2 chain 10 basic match 'meta(priority gt 2)' and 'meta(priority lt 64)' flowid 1:2 tc filter add dev eth0 parent 1:0 prio 3 chain 10 basic match 'meta(priority eq 1)' or 'meta(priority eq 2)' flowid 1:3 tc filter add dev eth0 parent 1:3 handle 0x1 flow hash keys dst
The above rules create three queuing classes for a 10 Gbps link: for (1) request, (2) granted, and (3) operational traffic. The request channel is given 5% of the egress link bandwidth, the granted channel is given 95% of the egress link bandwidth, and the operational channel is given any residual amount of bandwidth available, up to the capacity of the link.
The request channel is assigned an skbprio (tc-skbprio(8)) queuing discipline.
The granted channel is assigned a stochastic fair queuing discipline (tc-sfq(8)), which performs round robin queuing over flows so that a single flow can not drown out other flows. On enqueueing, each packet is assigned to a hash bucket, based on the packet's hash value. The hash function for deciding the bucket is configured to be the destination IP field, according to the tc filter rule above. The granted channel also utilizes the random-early-detection (RED) algorithm, parameterized by:
- redflowlimit: the limit on the queue size of SFQ flows in bytes
- min: the average queue size at which marking becomes a possibility
- max: the average queue size at which the marking probability is maximal
- probability: the maximum probability for marking
- ecn: mark packets using the ECN field to indicate congestion instead of dropping when possible
- headdrop: when drops are required, drop packets from the head of the queue instead of the tail
It is also possible to specify the bandwidth of the request or granted channel as a percentage of the device's bandwidth. For example:
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 5% prio 1
Note that if the speed of the device changes, the bandwidth of the channel will not automatically be updated.