Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IM] Add option to set behaviour of reseller aggregate graphs #914

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

listerr
Copy link
Contributor

@listerr listerr commented Feb 21, 2025

This update adds a new config option GRAPHER_BACKEND_MRTG_RESELLER_AGGREGATE Which has the following options:

  • include= Always include reseller uplink ports in member aggregate graphs (default)

    • Set this if resellers always have separate physical peering/uplink ports.
  • exclude = Always exclude reseller uplink ports from member aggregate graphs.

  • ppp = Only include peering/reseller uplink ports having a crossconnect.

    • All other other port types are included except 'fanout'.

    • Set this if you have patch panel records, and resellers:

      • Can have only reseller uplink ports (no peering ports), or;
      • Have their own peering VLAN via the same physical interface as the reseller uplink port, or;
      • Have their own peering VLAN via a subinterface of reseller uplink port.
      • Other 'software' interfaces or VLAN translation is used for reseller peering ports., and you want to avoid double-counting.

    In this case, for resellers, reseller|peering ports which do not have an associated patch panel port are not added to the member aggregate graphs. This solves the problem where reseller ports are double counted on the aggregate graphs for the member.

This only affects the individual aggregate graphs for resellers. Reseller/Fanout ports are always excluded from overall aggregate graphs. (as before).

In addition to the above, I have:

  • ensured all relevant template output is escaped to avoid XSS attached with <?= $t->ee( $data ) ?> or equivalent.
  • ensured appropriate checks against user privilege / resources accessed
  • API calls (particular for add/edit/delete/toggle) are not implemented with GET and use CSRF tokens to avoid CSRF attacks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant