New and Changed Information

The following table provides an overview of the significant changes to this guide up to this current release. The table does not provide an exhaustive list of all changes that are made to the guide or of the new features up to this release.

Table 1. New Features and Changed Behavior

Cisco APIC Release Version

Feature

Description

5.1(3)

OpFlex Drop Log

This guide became available.

About OpFlex Drop Log

The OpFlex Drop Log feature logs any packet that gets dropped in the datapath. It is useful to know what policy dropped a packet while debugging flow drops. Overall policy logging can be useful to understand the policies in a datapath without looking at the configuration.

Currently tools such as ovs-appctl ofproto/trace that are provided by Open vSwitch (which allow tracing of a specific packet through the datapath) are being used to debug drops. The Drop log feature makes it easy to monitor drops at scale.

Policy logging is already available on ACI as an action in addition to permit and deny while specifying filters.

This feature extends the functionality to the compute, while adding policy-miss logging.

Benefits of OpFlex Drop Log

The OpFlex Drop Log provides several benefits:

  • Allows logging of all dropped packets in the datapath due to policy miss.

  • In Kubernetes, events are published to the corresponding pods, and from there any issue in traffic for which datapath is dropping can be noticed easily.

  • If not on Kubernetes, then OpFlex logs will have all the packet drops logged and the IP addresses can be used to map the VMs involved in traffic.

  • Support IPv4 (not option processing), IPv6, TCP, UDP, and Geneve with custom TLVs.

OpFlex Drop Log Limitations and Restrictions

Be aware of the following issues when configuring OpFlex Drop Log:

  • Permit Logging is not supported.

  • Drop action for policy is not available as a CRD in Kubernetes.

  • Events are not supported on OpenStack, but OpFlex logs should be available.

Prerequisites for Configuring OpFlex Drop Log

You must complete the following tasks before you configure OpFlex Drop Log:

  • You must have basic working knowledge about Cisco ACI CNI deployment or OpenStack ACI plug-in.

  • Socket operations requires a minimum version of 1.58 for boost::asio.

OpFlex Drop Log Configuration Workflow

This section describes a high-level overview of the tasks you perform to configure OpFlex Drop Log:

  1. You can either configure the OpFlex Drop Log natively or on Kubernetes.

    For more information see Configuring the OpFlex Drop Log Natively or Configuring the OpFlex Drop Log on Kubernetes.

  2. For OpenStack, configuring the OpFlex Drop Log natively workflow, would have been performed if using the Cisco installer with the exception of dynamically enabling drop log. This can be done by editing the a.droplogcfg file to have the following contents {"drop-log-enable": true}, instead of false.

  3. Verify the configuration.

    For more information, see Verifying the OpFlex Drop Log on Non-Kubernetes Environment or Verifying the OpFlex Drop Log on Kubernetes.

Configuring the OpFlex Drop Log on Kubernetes

This section describes how to configure the OpFlex Drop Log on Kubernetes.

Procedure

Step 1

In the acc-provision input file the configuration is automatically done by enabling the flag:

Example:

drop_log_config:
   enable: true
Step 2

In the context of opflex-agent running in Kubernetes, execute the acc-provision input file:

Example:

$ acc-provision -i input_file -f <flavor> > aci-containers.yaml

Verifying the OpFlex Drop Log on Kubernetes

This section describes how to verify the OpFlex Drop Log on Kubernetes.

Procedure

Check that the following knob is set in the /usr/local/etc/aci-containers/host-agent.conf file.

Example:

"enable-drop-log": true

This knob drives all the configuration mentioned previously for OpFlex.

In addition to the logs getting printed under opflex-agent, the event will be logged to the pod in question. If both source and destination pods are present on the same node, only the source pod will have the event. Repeated events to the same pod are rate limited to one every 2 minutes and dropped before publishing if the event could not be published within 10 minutes of the event timestamp.

Example of an event under a pod: