Firewall / Router - Cluster / Virtual Contexts

[patrickpreuss]

NetBox version

v3.0.7

Feature type

New functionality

Proposed functionality

Can we support FHRP and Firewall Clusters / Virtual Systems as a Model?

1) FHRP - VRRP Addresses It would be good that those addresses can be assigned to a Fist Hop Group object and this can be used with from a device. the group should als have information about active standby "state" of the members

2) Support Firewall Custers and Virtual Systems, like CheckPoint ClusterXL and VSX or Fortinet VDOMs.

Use case

it would be possible to document the logical / phisical design. Interfaces and IP Addresses could be asigned to the propper logic.

Database changes

No response

External dependencies

No response

[jeremystretch]

1. FHRP - VRRP Addresses

This is being addressed for v3.1 in #6235.

2. Support Firewall Custers and Virtual Systems, like CheckPoint ClusterXL and VSX or Fortinet VDOMs.

Do you have a specific, detailed implementation to propose? If not, please take some time to consider exactly what you'd like to propose before proceeding with a feature request. You may find it useful to start a discussion to collect input from others as you flesh out your plan.

[patrickpreuss]

Hi Jeremy

thanks for 1).

For two yes a discusision might be a good starting point.

We have following setup(s) in the field.

1) Foritgate / Checkpoint Clusters (Two Nodes)

• dedicated interface for per node mgmt
• cluster root VDOM / VSX for mgmt purposes
• several traffic VDOM / VSXs per customer / function Most of the ip addresses are residing within the VDOM / VSX and are just floating.

Where VSX and VDOMs are some special kind of VM.
They have in common to have their own routing table and policy.

Major diffence is that VSX can leak routes in between VSX(s) on a box, like VRFs on ciscos. and Foritgates can have a VRFs inside each VDOM.

Major benefit would be to have the cluster modeld properly would be for change planning and provisoning. Like move a VSX/VDOM to a diffent cluster or migrate between vendors.

[jeremystretch]

Ok, we'll close out this FR for now and I'll leave it to you to open a new discussion. One note: I'd strongly encourage you to drop the vendor-specific nomenclature when working toward a general-purpose model. We won't accept any vendor-proprietary extensions into NetBox core, so you'll want to be sure whatever you propose has a use case outside of one particular vendor.

Good luck!