Felix configuration

A Felix configuration resource (FelixConfiguration) represents Felix configuration options for the cluster.

See Configuring Felix for more details.

Sample YAML

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  ipv6Support: false
  ipipMTU: 1400
  chainInsertMode: Append

Felix configuration definition

Metadata

• Calico automatically creates a resource named default containing the global default configuration settings for Felix. You can use calicoctl to view and edit these settings
• The resources with the name node.<nodename> contain the node-specific overrides, and will be applied to the node <nodename>. When deleting a node the FelixConfiguration resource associated with the node will also be deleted.

Spec

genericXDPEnabled and xdpRefreshInterval are only relevant when bpfEnabled is false and xdpEnabled is true; in other words when XDP is being used to accelerate denial-of-service prevention policies in the iptables dataplane.

When bpfEnabled is true the “xdp” settings all have no effect; in BPF mode the implementation of policy is always accelerated, using the best available BPF technology.

Health Timeout Overrides

Felix has internal liveness and readiness watchdog timers that monitor its various loops. If a loop fails to “check in” within the allotted timeout then Felix will report non-Ready or non-Live on its health port (which is monitored by Kubelet in a Kubernetes system). If Felix reports non-Live, this can result in the Pod being restarted.

In Kubernetes, if you see the calico-node Pod readiness or liveness checks fail intermittently, check the calico-node Pod log for a log from Felix that gives the overall health status (the list of components will depend on which features are enabled):

+---------------------------+---------+----------------+-----------------+--------+
|         COMPONENT         | TIMEOUT |    LIVENESS    |    READINESS    | DETAIL |
+---------------------------+---------+----------------+-----------------+--------+
| CalculationGraph          | 30s     | reporting live | reporting ready |        |
| FelixStartup              | 0s      | reporting live | reporting ready |        |
| InternalDataplaneMainLoop | 1m30s   | reporting live | reporting ready |        |
+---------------------------+---------+----------------+-----------------+--------+

If some health timeouts show as “timed out” it may help to apply an override using the healthTimeoutOverrides field:

...
spec:
  healthTimeoutOverrides:
  - name: InternalDataplaneMainLoop
    timeout: "5m"
  - name: CalculationGraph
    timeout: "1m30s"
  ...

A timeout value of 0 disables the timeout.

ProtoPort

Keep in mind that in the following example, net: "" and net: "0.0.0.0/0" are processed as the same in the policy enforcement.

  ...
spec:
  failsafeInboundHostPorts:
  - net: "192.168.1.1/32"
    port: 22
    protocol: tcp
  - net: ""
    port: 67
    protocol: udp
failsafeOutboundHostPorts:
  - net: "0.0.0.0/0"
    port: 67
    protocol: udp
  ...

RouteTableRange

The RouteTableRange option is now deprecated in favor of RouteTableRanges.

RouteTableRanges

RouteTableRanges is a list of RouteTableRange objects:

Each item in the RouteTableRanges list designates a range of routing tables available to Calico. By default, Calico will use a single range of 1-250. If a range spans Linux’s reserved table range (253-255) then those tables are automatically excluded from the list. It’s possible that other table ranges may also be reserved by third-party systems unknown to Calico. In that case, multiple ranges can be defined to target tables below and above the sensitive ranges:

 target tables 65-99, and 256-1000, skipping 100-255
calicoctl patch felixconfig default --type=merge -p '{"spec":{"routeTableRanges": [{"Min": 65, "Max": 99}, {"Min": 256, "Max": 1000}] }}

Note, for performance reasons, the maximum total number of routing tables that Felix will accept is 65535 (or 2*16).

Specifying both the RouteTableRange and RouteTableRanges arguments is not supported and will result in an error from the api.

AWS IAM Role/Policy for source-destination-check configuration

Setting awsSrcDstCheck to Disable will automatically disable source-destination-check on EC2 instances in a cluster, provided necessary IAM roles and policies are set. One of the policies assigned to IAM role of cluster nodes must contain a statement similar to the following:

{
    "Effect": "Allow",
        "Action": [
            "ec2:DescribeInstances",
            "ec2:ModifyNetworkInterfaceAttribute"
        ],
    "Resource": "*"
}

If there are no policies attached to node roles containing the above statement, attach a new policy. For example, if a node role is test-cluster-nodeinstance-role, click on the IAM role in AWS console. In the Permission policies list, add a new inline policy with the above statement to the new policy JSON definition. For detailed information, see AWS documentation.

For an EKS cluster, the necessary IAM role and policy is available by default. No further actions are needed.

Supported operations