Table of Contents
Tap-as-a-Service¶
[gerrit filter: https://git.opendaylight.org/gerrit/#/q/topic:TaaS]
Tap-as-a-Service provides port mirroring for tenant virtual networks.
Problem description¶
Debugging a complex virtual network can be a difficult task for a cloud administrator. The administrator does not have any visibility into the network. In order to analyze the network behavior we need to mirror the traffic and do a packet inspection.
Use Cases¶
TaaS will provide visibility into the network, by monitoring the network traffic generated or received by the VM. Port mirroring involves sending a copy of packets entering or leaving one port to another designated port. TaaS can also provide data for network analytics and security applications.
Port mirroring happens from Tap Flow Port to Tap Service Port. TapFlow represents the port on a VM from which the traffic needs to be mirrored and TapService represents the port on a different VM to which the mirrored traffic is delivered. The first phase of the feature will support the following use cases.
- Use case 1: Local port mirroring where the Tap Service Port(TSP) and Tap Flow Port(TFP) are on the same switch. Both the TFP and TSP are untagged Neutron Ports.
- Use case 2: Local Port mirroring where TFP is untagged and TSP is tagged sub-port.
- Use case 3: Local Port mirroring where TSP and TFP are both transparent.
- Use case 4: Local Port mirroring where TFP is untagged and TSP is transparent.
- Use case 5: Local Port mirroring where TFP is tagged sub-port and TSP is transparent. Remote port mirroring where the Tap Service Port and Tap Flow Port are on different switches.
- Use case 6: Remote port mirroring where the Tap Service Port and Tap Flow Port are on different switches. Both the TSP and TFP are untagged Neutron Ports
- Use case 7: Remote Port mirroring where TFP is untagged and TSP is tagged sub-port.
- Use case 8: Remote Port mirroring where TSP and TFP are both transparent.
- Use case 9: Remote Port mirroring where TFP is untagged and TSP is transparent.
- Use case 10: Remote Port mirroring where TFP is tagged sub-port and TSP is transparent.
Proposed change¶
To realize tap services in OpenDaylight, a new tapservice module will be implemented. This module listens to neutron-tapaas configuration DS and fetches tap service and flow port data. This modules also listens to Interface State operational DS and retrieves the service and flow port related operational information. Based on the data, pipeline to realize the tap service is programmed. The tap service details are persisted so that if the VM that hosts the flow or service port migrates, the old flows can be detected and removed.
Pipeline changes¶
This features introduce the following pipeline:
- Two new tables will be added as a part of this feature.
- OUTBOUND_TAP_CLASSIFIER_TABLE = 170; INBOUND_TAP_CLASSIFIER_TABLE = 171;
Service priority for this feature is as follows :- * For traffic on tap flow port bound to outbound traffic (TaaS API with direction == OUT) , then TAP MUST be highest priority ingress service (w.r.t switch) for that lport INGRESS_TAP_SERVICE_INDEX = 1 * For a tap flow port bound to inbound traffic (TaaS API with direction == IN ) , then TAP MUST be lowest priority egress service (w.r.t to switch) for that port EGRESS_TAP_SERVICE_INDEX = 9
- A block of IDs from Id Manager will be allocated to get the tunnel Id corresponding to the Tap Service
- TAP_SERVICE_LOW_ID = 350000L TAP_SERVICE_HIGH_ID = 375000L;
Tap Flow Port Egress Traffic¶
Mirroring traffic egressing from Tap Flow port will be of highest priority. So the ingress traffic
(w.r.t switch) will match the INGRESS_TAP_SERVICE_INDEX
at the INGRESS_LPORT_DISPATCHER_TABLE
and go to the OUTBOUND_TAP_CLASSIFIER_TABLE
where the packet matching the Lport Tag
of the Flow Tap port will be
* copied and sent based on the Egress Actions for the Tap Service Port either
* to EGRESS_LPORT_DISPATCHER_TABLE
to the VM port if the Tap Service port is in the same switch as Tap Flow port or
* embed the label corresponding to Tap Service Id in the VNI field and sent onto the tunnel.
* original packet is ReSubmitted to the INGRESS_LPORT_DISPATCHER_TABLE
.
Tap Flow Port Ingress Traffic¶
Mirroring traffic ingressing into the Tap Flow Port will be of the lowest priority. So the egress traffic (w.r.t switch) will match the EGRESS_TAP_SERVICE_INDEX
at the
EGRESS_LPORT_DISPATCHER_TABLE
and go to Inbound_Tap_CLASSIFIER_TABLE
where the packet matching the Lport Tag
of the Flow Tap port will be
* copied and sent based on the Egress Actions for the Tap Service Port either
* to EGRESS_LPORT_DISPATCHER_TABLE
to the VM port if the Tap Service port is in the same switch as Tap Flow port or
* embed the label corresponding to Tap Service Id in the VNI field and sent onto the tunnel.
* ReSubmit the original packet to EGRESS_LPORT_DISPATCHER_TABLE
Tap Service Port Ingress Traffic¶
If the Tap Service port and Tap Flow port are on different switches then,
the copied packet will egress from the tunnel and will match on the tunnel id corresponding to the
Tap Service Id in the INTERNAL_TUNNEL_TABLE
and go to EGRESS_LPORT_DISPATCHER_TABLE
and from there it will be output onto the VM of the Service Tap port.
TABLE | MATCH | ACTION |
---|---|---|
LPORT_DISPATCHER_TABLE | metadata=service priority && lport-tag | goto OUTBOUND_TAP_CLASSIFIER _TABLE |
|
|
|
|
Reg6==service Priority && lport-tag |
|
|
Action 1: Output on the VM Service Port if same switch ONTO Tunnel port, if different Action 2: ReSubmit to EGRESS_LPORT _DISPATCHER_TABLE | |
INTERNAL_TUNNEL_TABLE | tunnel_id=tap service id | go to EGRESS_LPORT_DISPATCHER TABLE |
Tap Service with VLAN Tags¶
TFP TYPE | TSP TYPE | Packet entering TSP | Pipeline | ||
---|---|---|
UnTagged | UnTagged | UnTagged | Normal | ||
|
||
Transparent | Transparent | Tag retained | Normal | ||
UnTagged | Transparent | UnTagged | Normal | ||
|
Yang changes¶
New YANG model will be defined in a new module called “tapservice”. This yang is to support the tap service realization in opendaylight.
:caption: tapservice.yang grouping tap-port-attributes { description "Attributes for the service and flow port"; leaf dpid { type uint64; } leaf port-number { type uint32; } leaf if-index { type int32; } } container tap-services-lookup { description "Container to store the list of tap services configured from openstack along with its service and flow port attributes. This is used to program the openflow rules on the switches corresponding to tap service and flow ports"; list tap-services { key "tap-service-id"; leaf tap-service-id { type yang:uuid; description "UUID of the Tap Service Instance"; } leaf port-id { type yang:uuid; description "Destination port for traffic"; } uses tap-port-attributes; list tap-flows { key "tap-flow-id"; description "List of tap flows associated with the tap Service"; leaf tap-flow-id { type yang:uuid; description "Tap flow Instance"; } uses neutron-taas:tap-flow-attributes; uses tap-port-attributes; } } }
Configuration impact¶
There is no change to any existing configuration.
Clustering considerations¶
Clustering support is already taken care in the infrastructure. There is no new requirement for this feature.
Security considerations¶
Tap Service Port should be configured with the Openstack “port_security_enabled” set to “false” to enable tap traffic to ingress it.
Scale and Performance Impact¶
The performance impact of mirroring on the switches needs to be tested and documented
Targeted Release¶
Fluorine.
Alternatives¶
None.
Usage¶
Features to Install¶
This feature can be used by installing odl-netvirt-openstack. This feature doesn’t add any new karaf feature.
Workflow¶
Following are the steps to be followed for mirroring a Neutron port.
- Create a Tap Service Neutron port with “port_security_enabled” set to “false”.
- Launch a VM for receiving mirrored data. Associate the Neutron port in step 1 while creating the VM.
- Create a Tap Service instance using the TaaS CLI “neutron tap-service-create” and associate with the port created in Step 1. This can also be configured via REST APIs.
- Create a Tap Flow Port using Neutron Client command for TaaS, “neutron tap-flow-create” and associate with the Tap Service instance create in Step 3 and the target Neutron port whose traffic needs to be mirrored. Mirroring can be done for both incoming and/or outgoing traffic from the target Neutron port.
REST API¶
Tap Service and Flow port can also be created using the following REST API.
Create TapService¶
URL: /POST /v2.0/taas/tap_services
Sample JSON data
{
"tap_service": {
"description": "Test_Tap",
"name": "Test",
"port_id": "c9beb5a1-21f5-4225-9eaf-02ddccdd50a9",
"tenant_id": "97e1586d580745d7b311406697aaf097"
}
}
Create TapFlow¶
URL: POST /v2.0/taas/tap_flows
Sample JSON data
{
"tap_flow": {
"description": "Test_flow1",
"direction": "BOTH",
"name": "flow1",
"source_port": "775a58bb-e2c6-4529-a918-2f019169b5b1",
"tap_service_id": "69bd12b2-0e13-45ec-9045-b674fd9f0468",
"tenant_id": "97e1586d580745d7b311406697aaf097"
}
}
Delete TapService¶
URL: DELETE /v2.0/taas/tap_services/{tap_service_uuid}
Delete TapFlow¶
URL: DELETE /v2.0/taas/tap_flows/{tap_flow_uuid}
Implementation¶
Assignee(s)¶
- Primary assignee:
- <Hema Gopalakrishnan> (hema.gopalkrishnan@ericsson.com)
Work Items¶
- Add a new bundle
- Define a new Yang
- Add listener to neutron-tapaas configuration DS and do the processing.
- Add listener to Interface State Operational DS.
- Support Tap Service add for each of the use case.
- Support Tap Service delete scenario.
- Support VM migration
- Add UTs.
- Add ITs.
- Add CSIT.
- Add Documentation
Dependencies¶
Taap driver in networking-odl needs to be implemented.
Testing¶
Unit Tests¶
Relevant Unit Test cases will be added.
CSIT¶
Following test cases will be added to Netvirt CSIT.
- Configure Tap Service and Flow ports in the same switch and verify the traffic from the flow ports are mirrored to the tap service port.
- Configure Tap Service and Flow ports in different switches and verify that traffic flows through tunnel to reach the tap service port.
- Configure the Tap Service and flow ports with VLAN tags as untagged, tagged and transparent and verify each use case.
- Configure the Tap Flow port with different mirroring direction and verify the appropriate behavior.
Documentation Impact¶
This will require changes to User Guide and Developer Guide.
User Guide needs to be updated with information on how to configure Tap Services.
References¶
- [1] Netvirt Florine Release Plan -
- https://docs.google.com/spreadsheets/d/1bDygyIwNOGFEEFDTQJN2LqoTyfmaxwtka-AlwkPcvzE/edit#gid=1799274276
[2] Pipeline Changes - https://git.opendaylight.org/gerrit/#/c/71782/
[3] Netvirt Trello Card
[4] Openstack API Reference - https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst