你好
希望与社区分享在提供商公司中实施的想法，以快速响应铜缆损坏。 关于双绞线和以太网。 当然，我不装作优雅的解决方案，但该服务显示出良好的效果。
对于那些懒得读书的人。 工作原理：监控半径范围内的会话下降，按开关分组，测试线路，头盔通知。
由于公司原因，我无法提供完整的项目代码，但对于有兴趣的人，我将删除破坏者下方的代码。 是的，每个提供商的实施方式会有所不同。 相反，目标是分享可以帮助某人的想法。
该公司的设备是99％D-link，因此该供应商列出了SNMP MIB。 其中一些是RFC，应该适合其他制造商。
关于这一切如何产生的一些历史。
这一切都始于2018年春季。技术支持组（TP）的负担增加了。 除了处理订户呼叫外，TP还可以在连接新订户以及离开以恢复和调试现有客户时协调安装程序。 必须稍微卸载TP并为安装程序提供一些工具。 决定组成一个使者可以接受订户的登录/合同的Messenger“机器人”，安装程序可以直接在字段中进行最少的调试。
我不想将所有功能嵌入一个应用程序中，因为 实际上，此类功能在处理呼叫时在同一CRM中的浏览器中也很有用，因此决定将与网络设备，计费，半径的交互机制置于单独的服务中，使其成为一个API并通过该API连接漫游器和CRM，仅此而已随便
现在再编写一些代码，然后继续讨论该帖子的本质。
因此，安装程序在以下字段中需要什么：
- 电缆测试当然
- 查看端口错误
- 查看端口状态
- 查看端口上是否有MAC地址。 （突然，订户将电缆插入LAN端口而不是WAN中）
- IPTV订阅
- 查看授权日志
- 余额状态
我们将通过SNMP和某些地方通过telnet与交换机交互。
我使用Bottle作为Web框架。
等等
我们添加了带有API密钥和装饰器的表格以进行验证，但我们不会将数据连续提供给所有人。
代号 apikeys = ['RANDOM_KEY1', 'RANDOM_KEY2'] api_error = '{"error":"apikey invalid"}' host_down_error = '{"error":"host down"}' def apikey_checker(fn): def wrapper(*args, **kwargs): if not check_apikey(): return api_error return fn(*args, **kwargs) return wrapper def check_apikey(): return 'apikey' in request.query and request.query['apikey'] in apikeys
好吧，实际上有几个与设备交互的功能。
代号 @route('/port_status/<ip>/<port>') @apikey_checker def get_port_status(ip=' ', port=' '): return snmp.port_status(ip, port) @route('/cable_test/<ip>/<port>') @apikey_checker def get_cable_test(ip, port): return snmp.cable_test(ip, port)
在snmp内部，我们有一个字典，用于解释端口对上返回的SNMP状态。
状态字典 pair_status = { '0': 'ok', '1': 'open', '2': 'short', '3': 'open-short', '4': 'crosstalk', '5': 'unknown', '6': 'count', '7': 'no-cable', '8': 'other' }
准备端口测量结果字典。 我们将复制它，以免每次都复制一个新的。
隐藏文字 pair_result = { 'pairs': { 1: { 'status': '-', 'length': '-' }, 2: { 'status': '-', 'length': '-' }, 3: { 'status': '-', 'length': '-' }, 4: { 'status': '-', 'length': '-' }, } }
功能介绍
电缆测试 def cable_test(ip, port): if not check_ip(ip):
函数将返回
结果 { "pairs": { "1": { "status": "other", "length": "0" }, "2": { "status": "open", "length": "4" }, "3": { "status": "open", "length": "4" }, "4": { "status": "other", "length": "0" } } }
后来，他添加了另一个类似的功能，专门用于脚本，它接收端口列表作为输入，而不是一个，并且在测试之前不检查端口的状态，这对于链接的大量减少是不必要的。
这就是机器人开始的样子
现在到帖子的本质。
在执行服务器
调试之前，使用了类似于
habr.com/post/188730中描述的技术。 在启用了SNMP阶梯的端口上循环。 当“飞机”掉落在港口时，有关此消息的信息落入了监控中。
首先，我拧紧了脚本，以便在跟踪链接断开时，调试服务器转到交换机，检查端口是否确实在说谎，而不仅仅是闪烁，并且端口上的线对打开或短路，然后向操作员发送消息。
但是，只有大约10％的交换机具有这种物理陷阱，事实证明这还不够。
后来想出了一个监视器半径。 这样就可以将监视范围的百分比提高到100％。 在这里，一切都已经与提供商基础设施有所不同。
我们会定期查看从某个特定的交换机切换到多少个客户端会话。 如果在交换机上启用了circuit_id，这很容易做到，其形式为
D4：CA：6D：0A：66：C9 ::
192.168.20.86 ::
20这里我们有用户的MAC，IP交换机，用户的端口号。 即 调试所需的一切。
我们通过IP交换机将完成的会话分组，如果此类会话的数量不止一个（我们将触发器设置为每分钟2个会话），那么脚本将与调试服务器联系并测试已删除会话的端口。 如果端口仍然处于闲置状态，并且电缆对断开或短路，并且至少两个端口的长度相同（+-2米），这恰好是交换机眼中电缆切断的样子，那么我们认为情况可疑，并向操作员发送消息。
当然，当屋子里的灯闪烁时会出现误报，或者恰好巧巧的是订户同时关闭电缆并且长度相同，但是正如他们所说的，这是最好的做法。 此外，您可以限制长度（仅响应短长度），同时下降的数量等。
这是可疑事件的真实报告。
以及处理此类消息的结果
在某些情况下，脚本会发送类似的消息，并且几秒钟后，交换机会脱机，因为 光学元件损坏，如果不是软件速度问题，那么这种情况将被误认为是房屋中的典型停电。
另一时间，管理公司开始在没有警告的情况下修理屋顶，VOKhR带着机枪飞向他们，锁匠突然受到压力。
因此，该脚本开始显示出良好的效果，并且经过4个月的工作，VOKhR，警察和提供者的员工本人成功完成了10多次破坏事件。 因此，我决定分享这种监视的概念。
现在，脚本可以监视大约15,000台交换机，而没有任何物理“陷阱”和SNMP陷阱。
在新的一年祝大家好运！