解析udt的库文件并推送给CMDB
##(此项目已经停止维护,被新版vservermap中的Restful接口代替)
本程序主要作用是把udt产生的allarpmacfile解读成 mac,ip,设备sn,接口 的四元组。通过API接口推送到cmdb的数据库中。
- 取udt文件夹中allarpmacfile的最后一行的id,然后创建多线程,grep 每一个arp信息行,然后进行该id的mac信息处理。 最终处理的结果是返回精确的 ip mac 接口 设备的SN号 四元组信息。
- 程序开始要对allarpmacfile 是否存在,api接口是否正常可用做一次判断。程序执行过程中,插入四元组动作要有日志记录。 api调用失败要有日志记录。
- 取值策略,只需独立id的第一行和最后一行,所以请确保udt结果中最后一行是直连服务器的交换机接口, 实现的方法是,udt中配置文件应该吧核心放在前边。 如果一个独立id对应的只有一行记录(说明没有二层信息),则返回‘unknow1’,并且记录在日志文件中体现为‘no interface info’。 若返回的大于一条记录,那么第一条记录毋庸置疑肯定是arp信息,直接处理字符串取出ip和mac备用,第二条记录需要过滤判断(发现Bridge.Agg 字符串,返回unknow2),没有被过滤掉的信息被认为是有效的二层mac-interface信息(ip-mac-device-if)
- 寻找物理交换机的sn号,过程为:通过第三部中判断得到的有效的mac信息行中的交换机ip和接口信息组合成ipif字符串,即 192.168.254.3-2 之类的字符串。 用这个字符串对 ini配置文件过滤, 一定会得到一个sn号。 这个sn号就确定了一个物理交换机。
- 配置文件的含义:第一个字段ipif ,即管理ip和slot号,作用是标示同一个管理ip下不同的交换机(IRF结构),如果是非IRF结构的交换机,这个字段填写ip-1即可,例如DB2交换机就不是irf结构。这个配置文件的作用主要是,可以让程序通过udt-allarpmac.html 中的二层信息找到这个二层交换机的SN号。
注意:unknow1 的意思只只有三层信息的条目;unknow2 的意思是 有二层条目但是是汇聚口,所以被过滤掉了。 sn error的意思是寻找sn号的时候有问题。 注意;10.2.8.1 如果有完整的id信息也会被写入数据库 注意:数据会有重复的原因是,一个ip的三层信息可能会出现在多台交换机上。 但是这并不影响结果,不管出现多少条三层信息,设备真实链接的交换机的端口总是固定的。 我这个层面无法去重复,所以在插入对方数据库的时候请自动加ID。 注意:当增加网络设备时,需要在配置文件中添加sn条目,否则会在日志中出现find sn error 错误。 注意:当日志中出现大量 find sn error,说明程序在便利allarpmac库文件的时候,出现有条目(ip+solt号)无法再ini文件中找到序列号。考虑是否出现了新增设备。
接口验证成功:
[root@localhost udt_pushto_API]# python udt_pushto_api.py Data={infoList:[{'switch_port': '31', 'switch_sn': '324', 'server_ip': '192.168.2.1', 'switch_port_mac': 'null', 'server_sn': 'null', 'server_network_mac': '00:22:19:ad:a6:e9'}]} {"result":"0","msg":"更新入库成功"}{"status":0,"message":"OK","data":{}}
bug1修复: udt程序已经出现了一个严重的阻碍, CLI方式需要两次才能获取到完整的arp信息, 这样对线上设备有侵入性,更糟糕的是mac信息无法通过这种方式获取完整的。也就是说肯定有mac信息被遗漏了。 也就是说,肯定会有一些设备有三层信息但是找不到二层信息。 这种CLI方式获取已经遇到了瓶颈, 本次bug修复仅仅是临时解决arp表的完整问题, 至少先保证ip表是全的。个别服务器找不到接口的bug不会在这里实现了。 下一步准备用go语言读取snmp的方式进行全盘完善。
python 2.7.5
yihongfei QQ:413999317 MAIL:[email protected]
CCIE 38649
为网络自动化运维尽绵薄之力