Skip to content

Configuration

Jump to bottom
Cody Doucette edited this page Mar 13, 2020 · 12 revisions

This page provides information about how to configure Gatekeeper using configuration files (static configuration) and at runtime (dynamic configuration).

Table of Contents

Configuring Gatekeeper

Static Configuration

The network and individual blocks are configured using the configuration files in the lua directory:

Command Line Parameters

EAL Configuration

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:

Global Log Level

--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.

Gatekeeper Log Level

--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.

Application Configuration

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:

Gatekeeper Lua Files

--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.

Gatekeeper Log Files

--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-------.

Dynamic Configuration

At runtime, Gatekeeper can be dynamically configured using the Dynamic Configuration. This allows the user to add, delete, and show routes, neighbors, policies, etc.

Configuring Routers

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
A diagram showing how Gatekeeper queues outgoing packets is below.

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.

Example Router Queuing Configuration 

 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
Clone this wiki locally