检测非托管第 2 层交换机的网络映射算法？
我继承了一个分布在仓库/前台办公室的网络，其中包含大约 50 台台式电脑、各种服务器、网络打印机和路由器/交换机。
“智能”路由器位于服务器机房中。 随着公司的发展，我们增加了额外的空间，但并没有非常优雅地在天花板等处铺设各种长度的 CAT5。我在天花板上发现了各种集线器和交换机 - 没有一个以任何方式标记或记录。
当然，闪烁灯告诉我有人连接到了这些设备，我只是无法找出谁。
我可以运行传统的网络地图工具（有很多这样的东西），它向我展示了网络中基于 IP 的东西。 这很好，但我已经掌握了信息。 我需要知道的是网络拓扑 - 交换机（网桥）如何互连等。并且由于它们是现成的 linksys 非托管类型，因此它们不响应 SNMP，所以我不能使用它...
我可以用什么最好/最便宜的工具来分析和检测网络中不响应 SNMP 的集线器和交换机之类的东西？
如果没有您知道的工具，您会建议使用什么通用算法来找出这个问题？ 我的猜测是，我可以查看设备（交换机、台式机等）的 MAC 转发表并以这种方式构建一条链，但我不知道是否可以从非托管交换机获取该表（更不用说一个枢纽）。
（该专利有一些巧妙的想法，但我找不到用它构建的任何软件：http://www. freepatentsonline.com/6628623.html）
谢谢！
I've inherited a network spread out over a warehouse/front office consisting of approximately 50 desktop PCs, various servers, network printers, and routers/switches.
The "intelligent" routers live in the server room. As the company has grown, we've annexed additional space and not very elegantly run various lengths of CAT5 thru the ceilings etc. I've been finding various hubs and switches in the ceilings -- none of which is labeled or documented in any way.
Of course, das blinken-lights tell me that someone is connected to these devices, I just have no way of finding out who.
I can run traditional network map tools (there are tons of these things) and it shows me the IP-based things in the network. That's nice, but information I already have. What I need to know is the network topology -- how the switches (bridges) are interconnected etc.. And since they are off-the-shelf linksys unmanaged-types, they don't respond to SNMP so I can't use that...
What's the best/cheapest tool out there that I can use to analyze and detect things like hubs and switches in the network that don't respond to SNMP?
If there's no tool that you're aware of -- what generalized algorithm would you suggest to find this out? My guess would be that I could look at the MAC forward tables for the devices (switches, desktops, etc.) and build a chain that way, but I don't know if it's possible to get that from an unmanaged switch (let alone a hub).
(This patent has some neat ideas but I can't find any software built with it: http://www.freepatentsonline.com/6628623.html)
Thanks!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
您可以尝试 NetskateKoban，它将为您提供包含连接到托管交换机每个端口的终端数量的地图。 您可以通过供应商名称了解非托管设备的存在。
我们已经看到了类似的问题，网络管理员必须弄清楚存在多少交换机（托管/非托管）。 它会给你这些地方的位置。 尝试一下...一切顺利
You can try NetskateKoban, that will give you the map with the number of terminals connected to each port of the managed switch. You can know the presence of unmanged device from there by the vendor name.
We have seen a similar kind of problem, where a network admin had to figure out how many switches (managed/unmanaged) are present. It will give you the location of such places. Try it out... all the best
您可能无法明确检测非托管设备...但您有 MAC -> 交换机端口映射，在您的托管端口上，对吗？ 如果是这样，您应该能够推断存在具有多个连接客户端的非托管交换机/集线器 - 我不知道您如何找到只有一个的端口。
您的网络拓扑中可能没有任何意外环路（或者您的网络可能无法工作），因此您可以假设核心之外有一个树结构。
You probably can't explicitly detect unmanaged devices... but you have MAC -> switch port mappings, on your managed ones, right? If so, you should be able to infer the presence of unmanaged switches / hubs with more than one connected client -- I don't know how you'd find a port with only one.
You probably don't have any accidental loops in your network topology (or your network probably wouldn't work) so you can probably assume a tree structure outside your core.
您可以尝试从智能交换机中获取生成树协议信息； 即使非托管交换机也必须参与此协议（但这不适用于集线器）。
You could try to get spanning-tree protocol information out of the smart switches; even unmanaged switches have to participate in this protocol (this doesn't apply to hubs, though).
我不认为非托管交换机/集线器会有 arp 条目 - 在 mac 层透明是它们存在的原因。
而且我认为没有办法让他们的 MAC 转发表不把它们拆开并找到 JTAG 或其他端口来与它们通信，这不太可能可行。
我能想到的最好的主意是依次对每个内部 IP 进行 pingflood，然后在执行此操作时尝试对所有其他 IP 执行 ping 操作。 这会有所帮助，因为您只能从不与您进行 pingflooding 的设备共享链接（现已拥塞到遗忘状态）的机器上获得不错的响应。 基本上，您正在利用交换机上的背板比它们之间的互连快得多的事实来确定哪些连接是通过互连，哪些是通过背板。 这还可以让您观看闪烁的灯光并找出哪些端口用于连接哪些 IP。
遗憾的是，据我所知，没有任何软件可以为您执行此操作。
I don't think unmanaged switches/hubs will have arp entries - being transparent at the mac layer is their reason for existing.
And I don't think there's a way to get their MAC forwarding tables short of taking them apart and finding a JTAG or other port to talk to them with, which is unlikely to be feasible.
The best idea I can come up with is to pingflood each internal IP in turn, and then while that's going on, try and ping all the other IPs. This will help because you'll only get decent responses from machines that don't share a (now congested into oblivion) link with the one you're pingflooding. Basically you're using the fact that the backplane on the switches is much faster than the interconnects between them to map out which connections are via interconnects and which are via backplanes. This also lets you watch das blinkenlights and figure out which ports are used to connect to which IPs.
Sadly I know of no software that will do this for you.
我个人也遇到过同样的问题。 乐趣。 我通过在主数据柜中安装新的 Cisco Catalyst 交换机并将每个端口上的智能端口配置文件设置为“桌面”来部分解决了该问题。 这将端口限制为 1 个 MAC 地址。
首次在非托管设备上激活多个设备时，任何连接有非托管集线器/交换机的端口都将自动禁用。
当我找到非托管集线器/交换机时，我将它们替换为配置为将每个端口限制为 1 个 MAC 的托管交换机。
如果您的预算不允许这样做，另一种方法是直观地跟踪每条电线并手动验证是否存在非托管网络设备。
I've personally had the same issue. Fun. I partially solved the problem by installing new Cisco Catalyst Switches in the main data closet and setting the Smart Ports profile on each port to "Desktop". This limits the port to 1 MAC address.
Any port with an unmanaged hub/switch attached will be automatically disabled the first time more than one device is activated on the unmanaged device.
As I located unmanaged hubs/switches I replaced them with managed switches configured to limit each port to 1 MAC.
If your budget won't allow this, the alternative is to trace each wire visually and manually verify the presence of unmanaged networking equipment.
我一直在研究这个问题，我发现了这篇旧的研究论文 Using VPS Probing to发现第 2 层拓扑。 理论上，您可以使用可变数据包大小 (VPS) 探测，通过第 2 层交换机引入的延迟来发现它们。 我还没有机会在实践中尝试。
更新：我发现了论文的最新版本 Using Simple Per-HopCapacity Metrics to发现链路层网络拓扑
I've been looking into this and I found this old research paper Using VPS Probing to Discover Layer 2 Topology. The theory is that you can use Variable Packet Size (VPS) probing to discover layer 2 switches by the delay they introduce. I haven't had a chance to try it in practice yet.
Update: I found a later version of the paper called Using Simple Per-Hop Capacity Metrics to Discover Link Layer Network Topology
如果您还没有尝试过 HP Openview 试用版，除了使用 SNMP 之外，它还使用 ARP 表来确定您的拓扑。
If you haven't already, try HP Openview trial version, and apart of using SNMP, it also uses ARP tables to figure out your topology.
您可以在下个月发布的 AdventNet opmanager8.0 中期待这些功能
You can expect these features in release of AdventNet's opmanager8.0 next month
一个想法可能是使用 3com Network Director 试用版（或 The Dude）之类的程序。 用它来发现您的所有工作站以及任何具有 IP 地址的其他东西。
等待一段安静的时间，拔掉每个集线器/开关……然后你至少可以开始制作地图，其余的将在下面的电缆上爬行。 网络管理确实意味着变得肮脏。
An idea could be to use a program like 3com network director trial version (or The Dude). Use it to discover all of your workstations and anything else with an IP address.
Wait for a quiet time and unplug each hub/switch ... you'll then at least begin to be able to make a map, the rest will be crawling about following cables. Network administration does mean getting dirty.