-
Notifications
You must be signed in to change notification settings - Fork 231
Functional Block: LLS
The Link Layer Support (LLS) block has the responsibility of handling all link layer protocols and address resolution services. This includes resolving IP addresses to Ethernet addresses for all of the other functional blocks using ARP and ND.
Gatekeeper and Grantor servers need to map neighbor IPv4 and IPv6 addresses to their MAC addresses. Therefore, Gatekeeper and Grantor support the ARP and ND protocols.
The LLS component works in an autonomous fashion. Instead of resolving IP addresses to MAC addresses on the demand, the LLS component receives all the IP addresses that the other components are interested in, and keep those maps updated. The LLS component keeps each entry of its map updated independently of the lookup demand of the other components.
The components that query LLS do not wait for a resolution if the map is not current; they simply drop the packet at hand. This behavior is essential because Gatekeeper and Grantor work under tight time constraints, so waiting for a resolution on the demand would disrupt the pipeline of the packets.
The LLS component is also responsible for the functioning of the LACP protocol to allow link bandwidths to be aggregated.
The LLS block is allocated one lcore in Gatekeeper.
All static configuration variables can be configured in lua/lls.lua.
These variables are likely to change from deployment-to-deployment based on the operator's preferences.
log_level
The log level for the LLS block. Can be set to any one of the following values: RTE_LOG_EMERG, RTE_LOG_ALERT, RTE_LOG_CRIT, RTE_LOG_ERR, RTE_LOG_WARNING, RTE_LOG_NOTICE, RTE_LOG_INFO, RTE_LOG_DEBUG.
Since we typically use RTE_LOG_ERROR as the most severe log condition, we recommend not to set this value below RTE_LOG_ERROR.
Note: set to RTE_LOG_DEBUG to log every LLS entry when the cache is periodically scanned.
It is not crucial to change these variables, and they only need to be changed to fine tune the performance of Gatekeeper. Otherwise, the default values are likely fine.
mailbox_max_entries_exp
The log (base 2) of the maximum size of the LLS mailbox. For example, if the variable is set to 7, then room for 2^7 = 128 entries will be made in the mailbox.
Also used to determine how many entries will actually be available for use in the mailbox, which for efficiency reasons is one less than the maximum size of the mailbox (127 in the example above).
mailbox_mem_cache_size
Number of mailbox entries to keep in the cache for more efficient use of the mailbox. Set to 0 to disable the cache of the memory pool for the mailbox.
mailbox_burst_size
Maximum number of entries to receive in a burst every time the mailbox is checked.
mailbox_max_pkt_sub
Maximum number of packets that the GK and GT blocks can submit to the LLS block at once.
log_ratelimit_interval_ms
The interval at which logs are rate limited (in milliseconds). For a given interval, only log_ratelimit_burst log entries are permitted. The count of entries is reset for each new interval.
log_ratelimit_burst
The number of entries per interval allowed to be logged. When the number of log entries exceeds this limit in a given interval, the entries will be dropped.
front_max_pkt_burst & back_max_pkt_burst
Maximum number of packets received in each burst on the front and back interfaces, respectively.
The LLS block only receives bursts of packets directly from the interfaces when EtherType filters are available in hardware, since in that case ARP packets can be directly received. Otherwise, ARP packets are received through the LLS mailbox and these variables are not used. Note that ND packets are always received via the mailbox, since they can not be matched using EtherType or ntuple filters.
- front_icmp_msgs_per_sec & front_icmp_msgs_burst
- back_icmp_msgs_per_sec & back_icmp_msgs_burst
It is necessary to limit the number of ICMP messages that the LLS block passes to the KNI interfaces per second to avoid a scenario where Gatekeeper servers are the source of an attack. We limit the rate of ICMP messages using the token bucket algorithm, and the limit is set per network interface.
front_icmp_msgs_per_sec and front_icmp_msgs_burst represent the rate and burst size of the ICMP messages for the front interface, and back_icmp_msgs_per_sec and back_icmp_msgs_burst represent the rate and burst size of the ICMP messages for the back interface.
These variables likely only need to be changed under extreme circumstances or for deployment-specific reasons.
max_num_cache_records
The maximum number of entries that the address resolution caches (hash table) can hold. A reasonable value is 1024.
cache_scan_interval_sec
The interval at which the LLS caches are scanned to mark entries as stale and to remove stale entries. A reasonable value is 10 seconds.
The ARP and ND caches can be separately dumped to the console by calling either list_lls_arp() or list_lls_nd(). They accept as parameters an LLS configuration structure, a callback function that is invoked once for every entry in the cache, and a accumulator string.
For examples, see lua/examples/example_of_dynamic_config_request.lua.