Add OSPF interfaces to session

[alehaa]

Plugin version

v0.3.1

NetBox version

v4.3.4

Feature type

Change to existing functionality

Proposed functionality

Currently, a single OSPF interface can be modeled. I propose changing this to sessions between two devices, just like NetBox cables have two terminations.

Use case

Modeling two separate interfaces can lead to inconsistencies between endpoints, such as when the area, passphrase, or other parameters are changed for only one of the two interfaces. Additionally, if a device is removed from NetBox, the missing relationship to the other side doesn’t automatically tear down the OSPF adjacency. Introducing a proper relationship between both sides ensures consistency and automatically maintains clean data.

Database changes

I propose implementing these changes:

• Renaming OSPFInterface model to OSPFSession
• Renaming the interface field to a_interface
• Renaming the instance field to a_instance
• Adding new fields b_interface and b_instance (being optional for the moment to not break current data)

External dependencies

None

Mockup

[alehaa]

Revisiting the RFC of OSPFv2, it appears that sessions can involve more than two peers. Consequently, I propose modifying my feature request to introduce a dedicated OSPFSession model for managing the area, authentication, and passphrase fields. The OSPFInterface can then establish a link to this session using a ForeignKey, ensuring consistent data management. For added convenience, we can incorporate properties within OSPFInterface that retrieve the session properties (such as the password).

It could look as follows:

# Usable by other protocols as well
class RoutingSessionMixin(models.Model):
    authentication = models.CharField(
        max_length=50,
        choices=choices.AuthenticationChoices,
        blank=True,
        null=True,
    )
    passphrase = models.CharField(
        max_length=200,
        blank=True,
        null=True,
    )

    class Meta:
        abstract = True


class OSPFSession(PrimaryModel, RoutingSessionMixin):
    area = models.ForeignKey(
        to='netbox_routing.OSPFArea',
        on_delete=models.PROTECT,
        related_name='sessions',
    )

    prerequisite_models = ('netbox_routing.OSPFArea',)


class OSPFInterface(PrimaryModel):
    session = models.ForeignKey(
        to='netbox_routing.OSPFSession',
        related_name='interfaces',
        on_delete=models.PROTECT,
    )

[DanSheps]

Not going to go forward with this, in it's current state.

The interface model will not change, as it is similar to the actual implementation where ospf is enabled per interface.

As a counterpoint to your "Doesn't automatically tear down", this mimics real life where if you remove a device, you need to remove the OSPF session on the peer device.

While OSPF neighbor ships are not currently modelled and could be something that could be added, I don't know if this is the place to do it.

I think OSPF sessions could exist in the OSPF configuration, authentication should still be defined per interface (however I would be open to adding a separate authentication model to allow linking authentication information to specific interfaces to reduce repeatition

[alehaa]

As a counterpoint to your "Doesn't automatically tear down", this mimics real life where if you remove a device, you need to remove the OSPF session on the peer device.

Fair point. It’s like the IP doesn't automatically get removed on the other end, and the patch panel cable doesn't unplug itself.

As I understand it, all OSPF neighbors must share the same area, authentication, and timers. Would you be open to a model that groups these fields, or just authentication?

[DanSheps]

As I understand it, all OSPF neighbors must share the same area, authentication, and timers. Would you be open to a model that groups these fields, or just authentication?

I think some form of authentication "template" might be valid. I would probably say that it would make sense for it to only be a template (so changing the password on the template would not impact the actual password set; If you are doing wholesale changes, bulk update should be sufficient for that).

I don't think a session model is the best, but a neighbor model is potentially a good thing.

[mrhyks]

As I understand it, all OSPF neighbors must share the same area, authentication, and timers. Would you be open to a model that groups these fields, or just authentication?

I think some form of authentication "template" might be valid. I would probably say that it would make sense for it to only be a template (so changing the password on the template would not impact the actual password set; If you are doing wholesale changes, bulk update should be sufficient for that).

I don't think a session model is the best, but a neighbor model is potentially a good thing.

Something like this?

But I would change displayed neighbor name from just "port" to "Device:port" if possible.

[mrhyks]

Like this