Skip to content

Functional Block: LLS

Qiaobin Fu edited this page Jun 1, 2019 · 12 revisions

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.

Table of Contents

Description

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.

Static Configuration

All static configuration variables can be configured in lua/lls.lua.

Variables to Change for Basic Operation

These variables are likely to change from deployment-to-deployment based on the operator's preferences.

Log Level

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.

Variables to Change for Performance Reasons

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 Maximum Entries (Exponential)

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 Cache Size

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

mailbox_burst_size

Maximum number of entries to receive in a burst every time the mailbox is checked.

Maximum Mailbox Submission Size

mailbox_max_pkt_sub

Maximum number of packets that the GK and GT blocks can submit to the LLS block at once.

Log Rate Limit Interval

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 Rate Limit Burst

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.

Interface Maximum Packet Burst (Front and Back)

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.

ICMP Rate Limiting (Front and Back)

  • 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 Echo replies LLS block issues per second to avoid a scenario where Gatekeeper servers are the source of an attack. We limit the rate of ICMP Echo reply 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 Echo reply 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 Echo reply messages for the back interface.

LLS block only issues ICMP Echo reply messages when it receives an ICMP Echo request message.

Variables Unlikely to Change

These variables likely only need to be changed under extreme circumstances or for deployment-specific reasons.

Number of Cache Records

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

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.

Dynamic Configuration

Dumping a Cache

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.

Clone this wiki locally