| 2023-04-06 11:56:40 |
Lajos Katona |
description |
ERSPAN (Encapsulated Remote Switch Port Analyzer) is a videly used tool to analyse traffic of switch ports. The whole concept first was used widely in Cisco switches.
ERSPAN protocol is used in 2 versions, version 1 (Type II), and version 2 (Type III) (Note: Type I was not widely used) ERSPAN version 2 adds an extra ERSPAN header over GRE, and a similar but more flexible extra ERSPAN header is used for version 3 (see [1]).
Since OVS 2.10 it is possible to use ERSPAN with OVS (see [2], and [3]) both ERSPAN v1 and v2.
Since OVN v22.12.0 it is possible to create mirrors with OVN (see [4], I can't find it in the release-notes or in any OVN docs, I suppose that is my lack of experience with OVN).
NOTE: OVN only supports ERSPAN v1, and with OVN it is also possible to create a clean GRE type mirror.
There's a few things to consider, I add here now only the question of how the API should look like.
The current TAAS API deals with 2 high level objects:
* The Tap Service identifies the destination of the mirroring, which is a Neutron port (see [5])
* The Tap Flow identifies the source of the mirroring, which is again a Neutron port (see [6]). There is a N:1 relationship between tap-flows and tap-services, so multiple tap-flows can be the source of one tap-service.
With ERSPAN this model is not that useful:
* one way forward can be to keep the current API with extra fields for both Tap Service and for Tap flow:
Tap Service: new field that mark the tap-service as ERSPAN destination port (in this case the port field should not be obligatory)
Tap Flow: new fields: erspan_dst_ip and erspan_idx.
* Another option is to encode this in the Tap Service and we could keep at least the Tap Flow unchanged. This would mean that for "legacy" mirroring with OVS or SRIOV the API behaves differently, or used differenltly.
* Yet another option is to introduce a new API for ERSPAN to make as simple as possible.
[1]: https://datatracker.ietf.org/doc/id/draft-foschiano-erspan-02.txt => Note this is a draft, and I think ERSPAN was not standardized.
[2]: https://docs.openvswitch.org/en/latest/faq/configuration/
[3]: http://www.openvswitch.org//support/dist-docs/ovs-fields.7.txt
[4]: https://github.com/ovn-org/ovn/commit/323f978cbf4599568fcca9edec8ed53c076d2664
[5]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-service
[6]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-flow
[7]: https://review.opendev.org/c/openstack/tap-as-a-service/+/693366 |
ERSPAN (Encapsulated Remote Switch Port Analyzer) is a videly used tool to analyse traffic of switch ports. The whole concept first was used widely in Cisco switches.
ERSPAN protocol is used in 2 versions, version 1 (Type II), and version 2 (Type III) (Note: Type I was not widely used) ERSPAN version 2 adds an extra ERSPAN header over GRE, and a similar but more flexible extra ERSPAN header is used for version 3 (see [1]).
Since OVS 2.10 it is possible to use ERSPAN with OVS (see [2], and [3]) both ERSPAN v1 and v2.
Since OVN v22.12.0 it is possible to create mirrors with OVN (see [4], I can't find it in the release-notes or in any OVN docs, I suppose that is my lack of experience with OVN).
NOTE: OVN only supports ERSPAN v1, and with OVN it is also possible to create a clean GRE type mirror.
There's a few things to consider, I add here now only the question of how the API should look like.
The current TAAS API deals with 2 high level objects:
* The Tap Service identifies the destination of the mirroring, which is a Neutron port (see [5])
* The Tap Flow identifies the source of the mirroring, which is again a Neutron port (see [6]). There is a N:1 relationship between tap-flows and tap-services, so multiple tap-flows can be the source of one tap-service.
With ERSPAN this model is not that useful:
* one way forward can be to keep the current API with extra fields for both Tap Service and for Tap flow:
Tap Service: new field that mark the tap-service as ERSPAN destination port (in this case the port field should not be obligatory)
Tap Flow: new fields: erspan_dst_ip and erspan_idx.
* Another option is to encode this in the Tap Service and we could keep at least the Tap Flow unchanged. This would mean that for "legacy" mirroring with OVS or SRIOV the API behaves differently, or used differenltly.
* Yet another option is to introduce a new API for ERSPAN to make as simple as possible.
[1]: https://datatracker.ietf.org/doc/id/draft-foschiano-erspan-02.txt => Note this is a draft, and I think ERSPAN was not standardized.
[2]: https://docs.openvswitch.org/en/latest/faq/configuration/
[3]: http://www.openvswitch.org//support/dist-docs/ovs-fields.7.txt
[4]: https://github.com/ovn-org/ovn/commit/323f978cbf4599568fcca9edec8ed53c076d2664
[5]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-service
[6]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-flow |
|
