基于snmp的網絡自適應與自發現（建議開發運維自動化平臺和基礎架構支撐的朋友看）

網絡自適應與自發現的動機

• 避免手動初始配置和更新網絡設備發現
• 網絡基礎設施數據填充數據組織過程資產
• 通過定期數據更新保持最新狀態
• 保持對要支持的網絡設備的精確描述
• 高效的網絡運營和規劃
• 資產庫存管理（CMDB）
• 準確清點所有硬件和軟件資產組織
• 網絡管理系統的核心準確定位
• 網絡拓撲的自動生成和邏輯關系的清楚展現

輸出的目標
安全風險與故障的及時有效的準確定位和排除
“要知道我們有什么，在哪里以及如何使用”

設備發現

• 通過IP地址發現網絡設備
• 掃描IP地址范圍（ping，snmp）
• 發現網絡設備，拓撲和IP地址空間
• 從核心交換機開始，通過網絡拓撲結構逐跳使用路由表中的下一跳
• 掃描每個接口上的子網絡并查找連接的設備
• 使用CDP或LLDP
• L3網絡拓撲
• 發現IP地址空間 - 每個接口上的子網
• 通過MAC地址發現網絡設備 - 每個LAN / VLAN
• 檢查每個設備接口上的ARP表
• 配對IP和MAC地址
• 在局域網上查找交換機
• 查詢交換機轉發表
• 了解網絡中的DHCP池
• L2網絡拓撲（ forwarding tables, ，STP）
  檢測設備的類型
• 路由器，交換機，UPS，主機（Linux，Windows ...）
• 檢測設備供應商
• 檢測設備型號
• 檢測設備資源（屬性）
• 系統名稱，型號，序列號
• 檢測設備組件及其資源
• 接口
• 物理實體 - 模塊，卡，CPU，內存...
• 邏輯實體 - 存儲分區，虛擬內存，路由表，連接用戶，BGP對等體，QoS策略等。
• 軟件組件 - 已安裝的軟件，運行過程...
  ok，各位看官提綱已經列出來，大家繼續往下走分享具體實現邏輯，不然肯定有大牛說都是大而虛，不切實際，那我們下面就將具體信息落實：

using SNMP - CLI
snmpwalk command
snmpwalk -v 2c -c 1qaz@WSX 100.100.32.10

Standard MIBs
System (.1.3.6.1.2.1.1)
Name, description, uptime

Response bindings:
1: sysObjectID.0 (object identifier) enterprises.9.1.516
2: sysUpTimeInstance (timeticks) 42 days 23h:23m:48s.31th (371302831)
3: sysContact.0 (octet string) (zero-length)
4: sysName.0 (octet string) WS-C3750v2-48TS [57.53.2D.43.33.37.35.30.76.32.2D.34.38.54.53 (hex)]
5: sysLocation.0 (octet string) (zero-length)
6: sysServices.0 (integer) 6
7: sysORLastChange.0 (timeticks) 0 days 00h:00m:00s.00th (0)
8: sysORID.1 (object identifier) enterprises.9.7.129
9: sysORID.2 (object identifier) enterprises.9.7.115
10: sysORID.3 (object identifier) enterprises.9.7.265
Interfaces (IF-MIB)
IfTable (.1.3.6.1.2.1.2.2), IfXTable (.1.3.6.1.2.1.31.1)

IP (IP-MIB)
ipAddrTable (.1.3.6.1.2.1.4.20) – used IP addresses

ipRouteTable (.1.3.6.1.2.1.4.21) – Routing table

部分帶有路由功能的交換機會在(.1.3.6.1.2.1.4.24體現路由信息例如cisco 3750

ICMP (IP-MIB)
icmpStatsTable (.1.3.6.1.2.1.5.29) – statistics of ICMP packets

目前這部分被廣泛應用在大數據分析、設備狀態監測、甚至在APM也有所使用

UDP (UDP-MIB)
udpTable (.1.3.6.1.2.1.7.5)
TCP 1.3.6.1.2.1.6

如何識別設備類型？
發現測試 - 檢索特定設備類型的唯一值
路由器
如何識別路由器？
路由表？主機也有一張路由表……
sysServices（.1.3.6.1.2.1.1.7）
返回值的位數確定設備所在的OSI/TCP的層數
例如：6（dec）= 0110（bin） - 第3層和第2層（L3交換機）
ipForwarding (.1.3.6.1.2.1.4.1) in IP-MIB
forwarding(1) – for routing capable devices
not-forwarding(2) – for all other devices

上述我舉例的方式已經很詳細，就不一一給大家截圖分析了，下面就直接給大家貼oid了：
BGP protocol (BPG4-MIB)
bgpPeerTable (.1.3.6.1.2.1.15.3)
OSPF protocol (OSPF-MIB)
ospfAreaTable (.1.3.6.1.2.1.14.2), ospfLsdbTabl (.1.3.6.1.2.1.14.4)
MPLS (MPLS-LSR-MIB, MPLS-×××-MIB)
mplsInSegmentTable (.1.3.6.1.3.96.1.3)
mplsOutSegmentTable (.1.3.6.1.3.96.1.6)
BRIDGE-MIB
Discovery test
dot1dBaseBridgeAddress (.1.3.6.1.2.1.17.1.1)
dot1dBasePortTable (.1.3.6.1.2.1.17.1.4)
pairing switching ports with interfaces (ifTable)
HOST-RESOURCES-MIB
Discovery test
hrSystem (.1.3.6.1.2.1.25.1)
these (.1.3.6.1.2.1.25.1.1), hrSystemDate (.1.3.6.1.2.1.25.1.2)
hrStorageTable (.1.3.6.1.2.1.25.2.3)
hrDeviceTable (.1.3.6.1.2.1.25.3.2)
hrProcessorTable (.1.3.6.1.2.1.25.3.3)
private.enterprises (.1.3.6.1.4.1) subtree
cisco (.1.3.6.1.4.1.9)
apc (.1.3.6.1.4.1.318)
microsoft (.1.3.6.1.4.1.311)
juniperMIB (.1.3.6.1.4.1.2636)
vmware (.1.3.6.1.4.1.6876)
…………
詳情見我之前分享的完整廠家分享，對與未知設備但凡支持SNMP需要在庫中不斷更新
OID sysObjectID (.1.3.6.1.2.1.1.2)
returns vendor specific OID which defines device model
Example:
sysObjectID = .1.3.6.1.4.1.9.1.283
CISCO-PRODUCTS-MIB (.1.3.6.1.4.1.9.1)
OID .1.3.6.1.4.1.9.1.283
Identifier
type: name: Cat6509
returns no date

上述是發現思科機框設備都會有不同的模塊和板塊

可以預期通過拓撲發現技術，可以不斷識別網絡地址空間，并不斷探索網絡的邊界；可以持續地對終端設備進行普查，這種審查發生在網絡核心，不需要安裝終端；同時，能夠不斷積累設備元數據和行為數據。
這些能力能夠發現未曾記錄在檔案的網絡，發現網絡中的無賴設備，甚至發現有威脅特征的設備，等等。而消除這些網絡安全風險所付出的代價又較小，這也是我青睞于拓撲技術在網絡安全中應用的重要原因

目前很多態勢感知類設備甚至是soc都需要借助SNMP去獲取一些設備狀態信息、日志信息、包括進程，甚至是應用狀態的監控，來掌握網絡實時狀態，隨著SDN的發展，某些廠家通過網絡虛擬化技術沒通過opefew技術，對虛擬化網絡設備及安全設備中的fewtable進行檢測，傳統的流量檢測還是用了netfew技術，但是根據調研目前大部分虛擬化設備還是支持SNMP的，無論哪種技術，無非都是完成對企業內部資源的可視化：“拓撲可視化”“流量可視化”“設備配置信息可視化”“資產可視化等等。。。。”

具體還在不斷的學習和實踐中，還希望有這方面研究的朋友一起探討。