starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Firewall / Router - Cluster / Virtual Contexts #5545

New Issue
Closed
opened 2025-12-29 19:29:16 +01:00 by adam · 3 comments
adam commented 2025-12-29 19:29:16 +01:00
Owner
Copy Link

Originally created by @patrickpreuss on GitHub (Oct 21, 2021).

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

Originally created by @patrickpreuss on GitHub (Oct 21, 2021). ### 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_
adam added the type: feature label 2025-12-29 19:29:16 +01:00
adam closed this issue 2025-12-29 19:29:16 +01:00
adam commented 2025-12-29 19:29:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 21, 2021):

  1. FHRP - VRRP Addresses

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

  1. 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.

@jeremystretch commented on GitHub (Oct 21, 2021): > 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](https://github.com/netbox-community/netbox/discussions/new) to collect input from others as you flesh out your plan.
adam commented 2025-12-29 19:29:17 +01:00
Author
Owner
Copy Link

@patrickpreuss commented on GitHub (Oct 21, 2021):

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.

@patrickpreuss commented on GitHub (Oct 21, 2021): 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.
adam commented 2025-12-29 19:29:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 21, 2021):

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!

@jeremystretch commented on GitHub (Oct 21, 2021): 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!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5545
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?