Option to filter links between devices via tags

[bortok]

Even if two interconnected devices should be present in the exported topology, it is sometimes necessary to limit the list of connections between them to a certain subset. For example, in a multi-tenant setup, some links maybe dedicated for one customer, and other links to another. To filter a list of connections tags could be used.

Requestor: @frederic-loui

[bortok]

List of interfaces is extracted for each device individually: https://github.com/netreplica/nrx/blob/main/nrx/nrx.py#L191, and then each interface is checked for type (ethernet) and if it is connected. A check could be added for a supplied tag, to limit the export.

Although interfaces can be tagged in netbox, this approach has a drawback – both sides of the link would have to be tagged.

Potential CLI UI options:

1. Use separate list of tags for interfaces. This option is less elegant, but more flexible to allow use of different tags for devices and interfaces. Adding filtering for another entity like cables would require another parameter like --cable-tags:

   # when only interfaces carry tenant information, not devices (quite likely scenario)
   ./nrx.py --tags dc1 --interface-tags customer1
   # export WAN topology with links from a particular provider only
   ./nrx.py --tags wan --interface-tags provider1

2. Use a common list of tags, and enable filtering of interfaces. This option is more elegant and extendable to other entities like cables without adding more parameters, but does not allow use of different tags between devices and interfaces:

   ./nrx.py --tags customer1 --filter devices,interfaces

Option 1 seems to be better suited for common use cases outlined above, while the second option would be problematic to apply to those.

[frederic-loui]

Hi ! 1 seems to be more flexible. I have a question though while entering data into nbx.rare.nmaas.eu. While having to parse tag at interface and cable layer, would not it be preferable to use circuit tag in order to deal with tenancy export ? In that case we would have topology for core network but we would also have an other type for customer/tenant topology export ? As usual, we can have a quick VC if needed, as this use case applies to to what we would like to achieve. Depending on your choice we will follow your decision :-)