Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config/mt: Add vlan-pair MT selector #9729

Closed
wants to merge 2 commits into from
Closed

Conversation

jlucovsky
Copy link
Contributor

Continuation of #9401

Add a new MT selector type to support use cases where a VLAN pair should be used to determine the MT tenant.

Packets with one VLAN id will never match as vlan-pair requires at least QinQ

Tenants are selected by:

  • The outer VLAN equals vlan-id or vlan-id is 0 (wildcard)
  • The inner VLAN equals vlan-id-inner or vlan-id-inner is 0 (wildcard)

Link to redmine ticket: 6237

Describe changes:

  • Add and document a new MT selector -- vlan-pair -- for use cases where a VLAN pair should determines the tenant.

Updates

  • Reworked to support a pair of VLAN (outer, inner) determines the tenant.

Provide values to any of the below to override the defaults.

To use a pull request use a branch name like pr/N where N is the
pull request number.

Alternatively, SV_BRANCH may also be a link to an
OISF/suricata-verify pull-request.

SV_REPO=
SV_BRANCH=pr/1354
SU_REPO=
SU_BRANCH=
LIBHTP_REPO=
LIBHTP_BRANCH=

Issue: 6237

The VLAN pair selector uses a pair of values to select a tenant.
- vlan-id
- vlan-id-inner

Each of these can accept a wild-card value (0).

The tenant is selected by
- vlan-id matches the outer vlan or is 0
- vlan-id-inner matches the inner vlan or is 0
Copy link
Member

@victorjulien victorjulien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Partial review about the user interface

::

register-tenant-handler <tenant id> vlan <vlan id>
register-tenant-handler <tenant id> vlan-pair <vlan id>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it confusing that we speak of pair but have a singular value

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also think it would be best to not mix these with the simple vlan examples, but have it separately

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch. Actually, it's register-tenant-handler <tenant id> vlan-pair <vlan id> <vlan inner id>

I'll separate the examples so it's clearer.

yaml: tenant-3.yaml

mappings:
- vlan-id: 1000
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering if it would be better to have a new vlan-id-pair name here, with a value of an array? Or something like "qinq": [ 1000, 1 ]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How long til we'll need qinqinqinqinqinqinq? I like the qinq name here where the value is an array. Limited to 2 for now perhaps, but could grow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like both ideas and I suggest vlan-id-tuple: [1000, 1] along with changing the selector name from vlan-pair to vlan-tuple

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if the selector value, and the name of the field for that select could be the same, however we don't have that for vlan and vlan-id now. If vlan-tuple it could be nice to have:

selector: vlan-tuple
mappings:
- vlan-tuple: [..]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that suggestion @jasonish -- will do.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 16373

@jlucovsky
Copy link
Contributor Author

Continued in #9737

@jlucovsky jlucovsky closed this Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants