Mirror port traffic with TAP-as-a-Service

Monitor network traffic by using TAP-as-a-Service port mirroring for security and compliance, performance analysis, troubleshooting, auditing, and lawful surveillance on traffic to and from ports.

TAPaaS uses the TAP mirror service, which uses OVN port mirroring capabilities. The mechanism intercepts packets and duplicates them without altering the original packet headers, ensuring that IP addresses and port information remain intact for the monitoring tool.

TAPaaS captures traffic at the VM instance TAP port. The mirrored traffic is identical to what the instance receives and sends. Traffic blocked by a security group or firewall rule is not included in the mirror.

You can use the GRE or ERSPAN protocols to tunnel TAP traffic from the source port to the destination port.

Activate TAP-as-a-Service for port mirroring
Copy link

Enable TAP-as-a-Service in the Networking service.

Before you begin
Copy link

  • You have the oc command line tool installed on your workstation.
  • You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges.
  • A deployed OpenStackControlPlane resource in the openstack namespace.

Procedure
Copy link

  1. Locate your existing networking service plugins: 
    echo service_plugins=$(oc exec "$(oc get pods -l service=neutron -o name | head -n 1)" -c neutron-api -- crudini --get /etc/neutron/neutron.conf.d/01-neutron.conf DEFAULT service_plugins)

    You should see output similar to:

    service_plugins=qos,ovn-router,trunk,segments,port_forwarding,log
  2. Save the output from the previous step.
  3. If you do not have an OpenStackControlPlane CR YAML file (such as openstack_control_plane.yaml), create one as shown in the following example: 
    $ oc get openstackcontrolplanes.core.openstack.org controlplane -o yaml > openstack_control_plane.yaml
  4. Edit your OpenStack control plane CR file on your workstation.
  5. If the CR file has a service_plugins parameter key,value pair under spec.neutron.template.customServiceConfig, replace the value with the list that you saved in a previous step. If not, add the parameter. The result looks like the following example: 
    service_plugins = qos,ovn-router,trunk,segments,port_forwarding,log,taas,tapmirror
  6. Ensure that the [service_providers] section exists and that it includes the parameter key,value pair TAAS:TAAS:neutron_taas.services.taas.service_drivers.ovn.taas_ovn.TaasOvnDriver:default. See the following example.
    Warning

    The service_plugins list is additive. As shown in the previous steps, you must include existing plugins, such as ovn-router and trunk, to avoid disabling essential networking features.

     
    spec:
  neutron:
    ...
    template:
      ...
      customServiceConfig: |
        [DEFAULT]
        vlan_transparent = true
        agent_down_time = 600
        router_distributed = true
        router_scheduler_driver = neutron.scheduler.l3_agent_scheduler.ChanceScheduler
        allow_automatic_l3agent_failover = true
        debug = true
        default_availability_zones = zone-1,zone-2
        service_plugins = qos,ovn-router,trunk,segments,port_forwarding,log,taas,tapmirror
        [service_providers]
        service_provider = TAAS:TAAS:neutron_taas.services.taas.service_drivers.ovn.taas_ovn.TaasOvnDriver:default
...
  7. Apply the updated configuration: 
    $ oc apply -f openstack_control_plane.yaml

Results
Copy link

  • Verify that the neutron pods reconciled without an error. Include the -w option if you want to observe the process. 
    $ oc get pods -l service=neutron -w -n openstack

    In the following example, the neutron pods were successfully reconciled:

    $ oc get pods -l service=neutron
NAME                        READY   STATUS    RESTARTS   AGE
neutron-d44b4c69-bvckl      2/2     Running   0          74s
neutron-d44b4c69-dqmhd      2/2     Running   0          110s
neutron-d44b4c69-n22wc      2/2     Running   0          2m29s

Mirror traffic to a remote IP (example)
Copy link

Mirror port traffic to a remote IP address by using ERSPAN or GRE tunneling. For example, use openstack tap mirror to mirror traffic inbound to a port on VM1.

Before you begin
Copy link

  • TAPaaS is configured and enabled.
  • You have the oc command line tool installed on your workstation.
  • You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges.
  • The IDs of the target (monitoring) and source (monitored) neutron ports.

Procedure
Copy link

  1. Access the client pod: 
    $ oc rsh openstackclient
  2. Retrieve the port ID of the VM you want to mirror. For example, for a vm called vm1. 
    $ openstack port list --server vm1 -c ID

    The output resembles the following example.

    +--------------------------------------+
| ID                                   |
+--------------------------------------+
| a7dc39fd-b299-464b-bb29-94ba4cd3dffa |
+--------------------------------------+
  3. Create the TAP mirror using the VM port ID as the port to be mirrored. The following example creates a mirror named my_mirror1 for BOTH ingress and egress traffic. The mirrored traffic is encapsulated using the erspanv1 header with a tag of 102 to mirror traffic to the remote IP address 1.2.3.4.
    Note

    You can also specify ingress only with IN keyword or egress with the OUT keyword. For example, --directions OUT=103 would represent egress only traffic which will be tagged with a tag 103.

    Example:

    $ openstack tap mirror create \
  --name my_mirror1 \
  --directions BOTH=102 \
  --remote-ip 1.2.3.4 \
  --mirror-type erspanv1 \
  --port a7dc39fd-b299-464b-bb29-94ba4cd3dffa

Results
Copy link

  1. Use ssh to log in to the Compute node that hosts the source instance.
  2. Use the tcpdump tool to view the traffic. The following example can be used to capture GRE or ERSPANv1 mirror types, because both use GRE.

    Example:

    $ tcpdump -i br-ex proto gre

Mirror traffic to a VM in OpenStack (example)
Copy link

Mirror traffic between virtual machines across different networks to inspect and analyze network packets.

Before you begin
Copy link

  • TAPaaS is configured and enabled.
  • You have the oc command line tool installed on your workstation.
  • You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges.
  • A deployed OpenStackControlPlane resource in the openstack namespace.
  • The IDs of the target (monitoring) and source (monitored) neutron ports.
  • The source and target instances are running.

About this task
Copy link

You can specify ERSPAN or GRE tunneling. This example uses GRE.

Note

You must create a separate TAP mirror for each mirrored port.

Procedure
Copy link

  1. Access the client pod: 
    $ oc rsh openstackclient
  2. Retrieve the source port ID. 
    $ openstack port list --server vm1 -c ID

    The output resembles the following example.

    +--------------------------------------+
| ID                                   |
+--------------------------------------+
| a7dc39fd-b299-464b-bb29-94ba4cd3dffa |
+--------------------------------------+
  3. Create a destination VM in OpenStack and ensure that the destination VM IP is reachable from the mirrored VM network. In addition, ensure that the destination VM allows GRE traffic.

    Here is an example of security group rule which allows ingress GRE (protocol number 47) traffic:

    $ openstack security group rule create --ingress --protocol 47 <security group of the destination VM>
  4. Create the TAP mirror using source VM port id (step 1) and point the mirror to the IP of the destination VM.

    For example, in this case the destination VM IP is 192.168.122.192. The following example creates a mirror named my_mirror_2 for egress (OUT) traffic. The mirrored traffic is encapsulated using the gre header with a tag of 103 to mirror traffic to the remote IP address 192.168.122.192 (the destination VM)

    $ openstack tap mirror create \
  --name my_mirror_2 \
  --directions OUT=103 \
  --remote-ip 192.168.122.192 \
  --mirror-type gre \
  --port a7dc39fd-b299-464b-bb29-94ba4cd3dffa

Results
Copy link

  1. Log in to the destination instance.
  2. Run the tcpdump tool on the destination instance to confirm receipt of mirrored packets. In this example, the tcpdump would show a more verbose output. 
    $ tcpdump -envi eth0 proto 47