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

Support for Juniper SRX Clusters #1614

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

Originally created by @domel138 on GitHub (Mar 9, 2018).

Issue type

[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.5
  • NetBox version: 2.3.1

Description

Im wondering if you were considering adding support for Juniper SRX Firewall Clusters. Basically they relay on reth (redundant Ethernet interfaces) - ideally i would see this implemented in similar way that Virtual Chassis is (single control-plane) but there is couple of caveat's like reth interfaces, management ip etc.
I would like to have for this functinality to have:

  • in-band management via reth interface sharing same ip-address across two nodes
  • out-of-band management via fxp0 with separate ip-addresses (it is possible now i believe)
  • sharing any ip-address across reth interface with virtual mac-address

Basically i think it should be simillar to Virtual Chassis with different roles - instead of master/members it should say node0/node1 with respective roles

Use case would be to add SRX clusters into Netbox - have no idea on what changes on postgres end this will require but maybe someone will help with it

Originally created by @domel138 on GitHub (Mar 9, 2018). ### Issue type [x] Feature request <!-- An enhancement of existing functionality --> [ ] Bug report <!-- Unexpected or erroneous behavior --> [ ] Documentation <!-- A modification to the documentation --> ### Environment * Python version: 3.5.5 * NetBox version: 2.3.1 ### Description Im wondering if you were considering adding support for Juniper SRX Firewall Clusters. Basically they relay on reth (redundant Ethernet interfaces) - ideally i would see this implemented in similar way that Virtual Chassis is (single control-plane) but there is couple of caveat's like reth interfaces, management ip etc. I would like to have for this functinality to have: - in-band management via reth interface sharing same ip-address across two nodes - out-of-band management via fxp0 with separate ip-addresses (it is possible now i believe) - sharing any ip-address across reth interface with virtual mac-address Basically i think it should be simillar to Virtual Chassis with different roles - instead of master/members it should say node0/node1 with respective roles Use case would be to add SRX clusters into Netbox - have no idea on what changes on postgres end this will require but maybe someone will help with it
adam closed this issue 2025-12-29 16:33:29 +01:00
adam commented 2025-12-29 16:33:30 +01:00
Author
Owner
Copy Link

@PeepOks commented on GitHub (Mar 9, 2018):

In some way it's similar to https://github.com/digitalocean/netbox/issues/1950

@PeepOks commented on GitHub (Mar 9, 2018): In some way it's similar to https://github.com/digitalocean/netbox/issues/1950
adam commented 2025-12-29 16:33:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 9, 2018):

Any representation of SRX clusters will need to be done within the virtual chassis model. We can look at tweaking it somewhat if needed, but we definitely won't be adding any new models to support this.

@jeremystretch commented on GitHub (Mar 9, 2018): Any representation of SRX clusters will need to be done within the virtual chassis model. We can look at tweaking it somewhat if needed, but we definitely won't be adding any new models to support this.
adam commented 2025-12-29 16:33:30 +01:00
Author
Owner
Copy Link

@domel138 commented on GitHub (Mar 9, 2018):

Hi Jeremy,

Sorry im completely new at github society - however i can take a look at VC
implementation and propose some enhancements to support SRX platform - is
it a good way to comment it via github request or shall i create new thread
for this?

Pozdrawiam, Dominik Siecinski.

2018-03-09 20:47 GMT+01:00 Jeremy Stretch notifications@github.com:

Any representation of SRX clusters will need to be done within the virtual
chassis model. We can look at tweaking it somewhat if needed, but we
definitely won't be adding any new models to support this.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/digitalocean/netbox/issues/1959#issuecomment-371925999,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQT88jRNaAG-Nis6UUQsllEgoqMBiGPrks5tctxagaJpZM4SjjG_
.

@domel138 commented on GitHub (Mar 9, 2018): Hi Jeremy, Sorry im completely new at github society - however i can take a look at VC implementation and propose some enhancements to support SRX platform - is it a good way to comment it via github request or shall i create new thread for this? Pozdrawiam, Dominik Siecinski. 2018-03-09 20:47 GMT+01:00 Jeremy Stretch <notifications@github.com>: > Any representation of SRX clusters will need to be done within the virtual > chassis model. We can look at tweaking it somewhat if needed, but we > definitely won't be adding any new models to support this. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/digitalocean/netbox/issues/1959#issuecomment-371925999>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AQT88jRNaAG-Nis6UUQsllEgoqMBiGPrks5tctxagaJpZM4SjjG_> > . >
adam commented 2025-12-29 16:33:30 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 12, 2018):

My personal opinion on the virtual chassis setup right now, is it seems to work best for something like a switch stack, where there is 1 management and control plane (and a semi-shared data plane).

I think the current VC model fails for things like vPC, VSS, SRX clusters and ASA clusters, where there are sometimes independent interfaces on all devices but also can be shared interfaces (or HSRP/VRRP/GLBP/etc interfaces tied to both devices).

I am not sure the best way to correct this "problem" though, as a tweak the other way would not be suitable for stacked switches. Perhaps a VC model "type" that changes the behavior of the VC based on the type (for example, vPC/VSS would not show shared interfaces, might add things like vPC domain and such). This seems like a big job though and I honestly think it might be easier to try a parent/child device relationship where the parent is a psuedo device and the child is the individual devices. Not sure how that works out either though.

That said, with the virtual chassis, I do wish it was represented as a device itself, instead of the master device showing all interfaces, as this makes it difficult for quickly adding connections from another device to the master unit (slave units you can individually pick and set the interface from the interface list without seeing all interfaces).

Just my thoughts, I am sure I have more rattling around in there as well...

@DanSheps commented on GitHub (Mar 12, 2018): My personal opinion on the virtual chassis setup right now, is it seems to work best for something like a switch stack, where there is 1 management and control plane (and a semi-shared data plane). I think the current VC model fails for things like vPC, VSS, SRX clusters and ASA clusters, where there are sometimes independent interfaces on all devices but also can be shared interfaces (or HSRP/VRRP/GLBP/etc interfaces tied to both devices). I am not sure the best way to correct this "problem" though, as a tweak the other way would not be suitable for stacked switches. Perhaps a VC model "type" that changes the behavior of the VC based on the type (for example, vPC/VSS would not show shared interfaces, might add things like vPC domain and such). This seems like a big job though and I honestly think it might be easier to try a parent/child device relationship where the parent is a psuedo device and the child is the individual devices. Not sure how that works out either though. That said, with the virtual chassis, I do wish it was represented as a device itself, instead of the master device showing all interfaces, as this makes it difficult for quickly adding connections from another device to the master unit (slave units you can individually pick and set the interface from the interface list without seeing all interfaces). Just my thoughts, I am sure I have more rattling around in there as well...
adam commented 2025-12-29 16:33:30 +01:00
Author
Owner
Copy Link

@luqasz commented on GitHub (Jun 14, 2018):

That said, with the virtual chassis, I do wish it was represented as a device itself, instead of the master device showing all interfaces, as this makes it difficult for quickly adding connections from another device to the master unit (slave units you can individually pick and set the interface from the interface list without seeing all interfaces).

Same here. I have a stack of juniper EX4300 and I'd like to add interfaces to virtual chassis and not individual nodes.

@luqasz commented on GitHub (Jun 14, 2018): > That said, with the virtual chassis, I do wish it was represented as a device itself, instead of the master device showing all interfaces, as this makes it difficult for quickly adding connections from another device to the master unit (slave units you can individually pick and set the interface from the interface list without seeing all interfaces). Same here. I have a stack of juniper EX4300 and I'd like to add interfaces to virtual chassis and not individual nodes.
adam commented 2025-12-29 16:33:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 14, 2018):

That said, with the virtual chassis, I do wish it was represented as a device itself, instead of the master device showing all interfaces

This is the way NetBox represents a virtual chassis. If you need to model virtual chassis differently, NetBox may not be the right tool for you.

@jeremystretch commented on GitHub (Jun 14, 2018): > That said, with the virtual chassis, I do wish it was represented as a device itself, instead of the master device showing all interfaces This is the way NetBox represents a virtual chassis. If you need to model virtual chassis differently, NetBox may not be the right tool for you.
adam commented 2025-12-29 16:33:30 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 14, 2018):

Closing this out as no one has proposed a specific model for representing an SRX cluster or similar arrangement.

@jeremystretch commented on GitHub (Jun 14, 2018): Closing this out as no one has proposed a specific model for representing an SRX cluster or similar arrangement.
adam commented 2025-12-29 16:33:31 +01:00
Author
Owner
Copy Link

@luqasz commented on GitHub (Jun 14, 2018):

Closing this out as no one has proposed a specific model for representing an SRX cluster or similar arrangement.

What about assigning ips, interfaces etc to a virtual chassis ?

@luqasz commented on GitHub (Jun 14, 2018): > Closing this out as no one has proposed a specific model for representing an SRX cluster or similar arrangement. What about assigning ips, interfaces etc to a virtual chassis ?
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
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#1614
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?