-
Notifications
You must be signed in to change notification settings - Fork 229
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.
There are four application parameters that may be especially useful when running Gatekeeper:
--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. Gatekeeper servers mark packets with such a classification by writing to the differentiated services ("DiffServ" or "DS") field in IP packets. The type to value mapping is:
- Legacy/unclassified packets: DS field value of 0
- Granted packet, or granted packet in flow whose capability is about to expire: DS field value of 1 or 2, respectively
- Request packet: DS field value of 3-63, where a larger value is a higher priority
Note that Gatekeeper does not explicitly pass operational, control plane packets (ARP, ND, BGP, etc.) through the Gatekeeper to Grantor channel, and therefore any such packets do not fall under the above queuing scheme either because they are below the IP layer (ARP) or would be given a DS field value of 0 by legacy software (ND, BGP). This is represented by the Operational RED Queue in the above figure. Any such packets are transmitted using either a small amount of reserved bandwidth, or as best-effort utilizing whatever residual bandwidth is left after processing granted and request packets.
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.
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