我有一个不幸的（也没有正确的计划）的事件，让我的一个远程Hyper-V主机分配了一个APIPA地址，因此我无法用任何方式连接它。 有趣的是，我可以将RDP发送到在主机顶端运行的虚拟机。 我也可以将RDP连接到Hyper-V DR主机，该主机继续使用APIPA地址与主Hyper-V主机进行复制。 我能够在networking选项卡上看到它正在使用资源pipe理器使用APIPA地址。 主机不能使用内部IP或主机名进行ping命令，当然也不能使用APIPA（不知道是否可以ping通）。 两台Hyper-V主机都运行Windows 2012 R2 Standard，位于主机主机上方的VM是Windows 2011 SBS。 由于我没有机会访问服务器（它位于另一个大陆），有什么办法可以访问吗？
我希望我的监控盒（Zenoss）在我的上游networking出现故障时通知我，而不会造成实际的链路丢失。 我们的CoLo交换机出现了一些问题，但是直到我们的用户通知我们，我才知道。 我希望有一个LTE无线热点故障转移到所以我可以发送有关停机/任何其他内部问题的Zenoss通知，而不必完全依赖DC的连接，但是希望尽可能避免使用LTE数据。 我正在使用Debian 7 预先感谢您的帮助！
当有人连接到我的networking，并尝试浏览，我想redirect到一个欢迎页面。 我知道有一些商业解决scheme的热点在那里，我正在寻找只是redirect。 理想情况下，我可以从命令行设置这个networking规则，而不是通过networkingpipe理员的GUI。 你能指导我做一些重要的工作或教程吗？ 编辑：networking是像在酒店的无线局域网。 理想的是寻找一个独立于路由器的解决scheme，但是对Netgear Aircard的build议就足够了。
我和一些朋友是我们当地大学的networkingpipe理员。 我们的职责包括pipe理build立在运行最新Debian的台式机上的小型NAS。 用户群（大约300人）差异很大，范围从像我们这样的networkingpipe理员级别的人到只能勉强打开笔记本电脑的人。 目前我们通过两种方式实现共享： web界面通过apache2，只读 桑巴共享，读写 我们从来没有真正关心过一个linux用户，在他的本地机器上安装共享之后，意外地抹去了整个NAS，因为linux不是那么常见，因为我们信任linux用户。 最近这个蒸汽臭虫出现了，我们非常担心，特别是因为我们中的一个在他的拱形桌面上使用蒸汽。 蒸汽将（希望）尽快解决，而问题依然存在。 我怀疑这样的错误可能是相当普遍的，如果不是，我认为find一个更好，更安全的方法来共享文件夹是一个好主意。 做备份不是一个select，因为我们是在严格的预算，不授予对samba用户的写入权限也不好，因为文件被移动，重命名和删除，我们不这样做的生活，也不无论如何有时间这样做。 TL，DR：我们希望find一种方法来共享一个debian文件系统，授予用户读写权限，但以某种方式防止意外删除文件，如“rm -rf /”。 用户群使用windows，* nix和mac os，所以一些os特定的解决scheme将不会有好处。 我们目前使用samba，但是我们对不同的解决scheme是开放的。
我在端口9292上运行一些东西（= Faye服务器）： david@theta:~$ lsof -ni tcp:9292 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ruby 2406 david 13u IPv4 1579461398 0t0 TCP 127.0.0.1:9292 (LISTEN) david@theta:~$ telnet localhost 9292 Trying 127.0.0.1… Connected to localhost. Escape character is '^]'. 问题是从别处我无法达到它： david@eclipse:~$ telnet 188.226.243.223 9292 Trying 188.226.243.223… telnet: connect to address 188.226.243.223: Connection refused 港口80工作： david@eclipse:~$ telnet […]
为了安全起见，我检查了服务器故障指南，我认为这个问题属于第三方平台pipe理或networkingpipe理。 我敢肯定，我不是唯一的系统pipe理员这个问题！ 在我们的networking上，我们有大约15台大型复合机/复印机。 我想以编程方式拉他们的帐户跟踪数据（每用户代码打印计数），我正在打墙。 SNMP仅提供汇总数据（机器的总打印计数） 没有SSH访问 只有一个Web界面可用（我知道） Web界面提供了一个csv文件作为下载与帐户跟踪数据，这是相当不错的。 但是，我很想自动化首先获取该CSV的步骤。 有没有办法抓住这些数据？ 我认识到答案可能涉及通过某种types的脚本从Web界面中获取数据。
我感兴趣的是确定本地区的实际工厂和networking容量，这恰好是波士顿，但可能在任何地方。 例如，我知道在波士顿有一种叫做波士顿纤维环的东西，在华盛顿街上有一座build筑物，那里有一个巨大的终点站。 我想知道这个城市的主要networking是什么，他们有什么带宽/服务水平，他们连接到哪个build筑物，以及哪个提供商运营它们（COMCAST，Verizon，RCN，DSCI，XO都在这个领域，例如）。 我要问的原因是让供应商做出select，找出谁来做大带宽交易。 换句话说，我不想去COMCAST，后来发现Verizon的容量是COMCAST对我的build筑物的10倍，甚至更糟糕的是，我们发现COMCAST租用Verizon的带宽服务于我，我可以去了Verizon，完全避开了一个中间人。 我不想这样做的方式是去乞求6个不同的供应商看到他们“提供”，基本上是在黑暗中谈判。 在开始和他们谈话之前，我想先了解他们的实体工厂，以便知道他们所持有的卡片。 我怎样才能find？ 请注意，像COMCAST / Verizon这样的“零售”提供商在许多情况下并不是实际的光纤拥有者。 实际的纤维是由许多不同的公司拥有的。 例如，在波士顿有一个由Last Mile Solutions运营的光纤环，连接到几个市中心的build筑物。 如果你能够直接访问这个环，你可以以比COMCAST更低的成本获得更高的带宽。 COMCAST只是把你最后一公里的纤维转卖给你。 其中一个想法是，我知道DigSafe拥有城市中所有地下线路的地图，但这显然是做出networking估算的一个非常粗糙的方法。 另一个select是，我可以通过IP地图来确定工厂的电子设备，并且找出城市中的每一台宽带路由器。 显然，这会给我一个关于谁在哪里有什么带宽的非常细致的图像，但是我可以说的是，编程，时间和成本这么做会很重要，如果信息可以是这样的，我想避免这样做其他地方更容易获得。
我有一个项目，要求我发送stream量的服务器上的特定端口的服务器有7个以太网端口。 我已经创build了IP规则来将数据从某个主机发送到某个端口。 我可以通过“ip rule show”高兴地查看我的规则 但是，当我创build一个路由来说“使用此网关的主机”我没有看到与Netstat的主机特定路线。 ip route add 172.16.2.65 via 172.16.1.1 dev eth3 table eth3 当我做netstat -rn的时候，我希望为这个主机指定一个特定的路由。 它是否正确？ 我没有看到这个主机特定的路线。 Netstat -rn是正确的命令。 有什么想法吗。 谢谢。 [18:29:20] shock:/home/debug # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 […]
我有一个Centos 5.11服务器，每10分钟一个脚本 脚本就是这个 #!/bin/sh FNAME=/var/www/html/cached/conntrack_count COUNT=`cat /proc/net/ip_conntrack | /usr/bin/wc -l` echo $COUNT > $FNAME 我已经运行了这个脚本几年没有问题（输出文件通过http定期读取，由一个仙人掌服务器，然后绘制在图表上）。 上周我跑了一个完整的yum更新，以减轻GHOST漏洞。 但是现在看起来当这个脚本运行时，它会导致本地套接字的并发问题（特别是当cat运行时memcached（locahost-> localhost）的连接经常超时）。 我想知道有没有人可以解释为什么现在是一个问题，以前不是？ 难道现在Linux正在对其被访问的文件进行某种locking，这可能会阻止build立新的连接？ 这似乎不太可能，但我没有其他解释
我一直在debuggingESX vmware主机通过使用TCP / IP的虚拟交换机与虚拟linux机器进行通信的情况。 拥塞事件发生后，当虚拟机正在等待来自vmware主机的更多数据时，vmware主机正在等待来自虚拟机的确认。 大的接收卸载（LRO）打开，问题似乎是vmware驱动程序没有给它内置的子部分的大小（它可以通过sk_buff结构的gso_size字段）给内核。 使用通用接收卸载（GRO）而不是LRO使问题消失。 所以，我在这里有两个可能的解决scheme， 1）修复vmware驱动程序，以便设置传递给内核的sk_buff的gso_size字段，或2）closuresLRO（使用ethtool -K），然后使用GRO。 在网上search有关LRO和GRO的信息，我只find没有硬数据或明确参考的片段和意见。 我想知道使用LRO vs GRO有什么优缺点。 从我在networking上的search到目前为止，我相信：*）LRO和GRO都可以减lessack的数量，这应该减lessnetworkingstream量，但也可能会降低拥塞窗口（cwnd）在慢启动或拥塞地方回避。 *）LRO和GRO都应该减less中断次数和内核堆栈遍历的次数。 由于使用新的API（NAPI），GRO是否比LRO减less中断？ *）LRO有时会把太多的数据包放在一起（具有不同头的特定数据包，打破了某些应用程序）。 *）LRO只做IPV-4，而GRO可以做IPV-6。