Closed ekrichbaum closed 3 months ago
Thank you for your suggestions. I certainly need to improve the readme.
For dataflows, you used to be able to use the native Service object as source or destination (via a Object Alias), but I found it to be too limiting. A service represents a listening TCP, UDP or SCTP port. You can't represent other protocols (IPSEC? ICMP?), and you can't represent a source because it is (most often) not listening. E.g.: if you want to represent an application connecting to its database, the database listener can be easily represented by a service, but not the application, unless you misrepresent it somehow (I previously used TCP port 1 when I tried to do it with services).
Regarding object aliases, they are due to technical limitations of being a plugin (I'm not allowed to modify the native NetBox models, for good reasons) and the need to have ManyToMany relationships with GenericForeignKey (to be able to support IP Addresses, Prefixes and Ranges), which are simply not supported by Django as far as I know (hence the underlying hidden ObjectAliasTarget model). It's not possible to select directly a Device or Virtual Machine as these can have several interfaces and IP addresses, with different purposes, so you need to select to the corresponding IP (it could work with services too I suppose).
If there is a strong demand for them, I may add Service back as a possible type for object aliases, but then I would need to address what it means to have a service as a source, or how to handle a dataflow with a protocol or port different than the service.
To give you a better idea of how I use my plugin, here are three examples:
In the examples above, Services could be used as destination instead of IP Addresses for TCP, UDP or SCTP dataflows, but when it is ICMP or IPSEC, or when the destination is generic ranges/prefixes, then that does not work.
@Alef-Burzmali, would you be open for pull requests addressing suggested changes? I don't want to duplicate information in NetBox, so I prefer to work on a solution that is both flexible and allows using existing NetBox objects whenever possible.
Thanks for your interest. As I feel that could be a major decision regarding the structure and operation of the plugin, I'd like first to hear what you plan to implement in more details. Can you please open another issue and describe what you have in mind?
Came across your plugin in the netbox slack today. This has promise but I'd like to make some suggestions:
When you spend time on a plugin, there is obviously a desire to solve a problem. I look forward to seeing more details here.