|Anonymous | Login
|2024-02-24 07:46 EST
|Main | My View | View Issues | Change Log | Roadmap
|View Issue Details
|Fixed in Version
|0001451: get rid of the uplinks=... concept
|After doing 7264ede and a1b4cc8 I wrote:
# FIXME I just refactored that method but I think we should simply get rid
# of the uplinks=... concept. If you've configured access-control on an
# uplink then it's your problem. Anyway we don't do anything on RADIUS based
# requests. I guess this was there at first because of misconfigured up/down
# traps causing concerns.
Plus we haven't implemented dynamic support on most vendor other vendors and maintaining a list manually is just painful.
We'll discuss it and then decide whether we should do it or not.
|No tags attached.
|fixed in git revision
|fixed in mtn revision
I'd like to ping this instead of opening a new bug request on it. We're having a problem with this now. Basically, the SNMP module for Cisco has "Cisco IP Phone" hardcoded as an identifier for a VoIP phone, but we don't use Cisco VoIP phones. I can easily make the change myself to support our phones, but then I run into maintenance issues with future upgrades.
Removing the uplinks concept entirely sounds viable, except that then there's no "gut check" when a trap comes in to catch any traps sourced from actual uplinks. I'm not sure when, if ever, such a trap would be sent, but having a check to prevent problems may be better than breaking the network.
I can think of two possible solutions. One, have a configurable option where the user can list the CDP/LLDP values of the IP phones they use. Another would be to reverse the check and have users list the CDP/LLDP values of switches they use. Either would solve this problem, I think, and would then put the onus of making the list on the user. Some simple help documentation on how to get the list from the switch should be sufficient.
|it has been fixed, so now we fetch the bit to detect if it's an ip phone in CDP flag.
|long-term => general
|Note Added: 0003343
|Note Added: 0003354
|new => resolved
|open => fixed
|Copyright © 2000 - 2012 MantisBT Group