Questions tagged «lag»

1
某些机器上的SSH在局域网中“滞后”,混合发行版
几个月来,我的局域网内的SSH连接出现了一个奇怪的问题。仅当我使用Windows 10设备连接到(准系统)Linux计算机时,才会发生这种情况。 当我连接到SSH服务器时,就像我的输入每秒仅发送一次。如果我按住某个键,它一秒钟不会打印任何内容,在那一秒钟之后,我会看到这段时间内所做的每一次击键。 这是在工作服务器上的外观: 这是问题所在的外观: 我测试过/发现的事情 更改/ etc / sshd中的“ UseDNS”设置无法解决该问题 它在Debian(OpenSSH_7.4p1 Debian-10 + deb9u6,OpenSSL 1.0.2r 2019年2月26日)和Ash在Alpine Linux(OpenSSH_7.9p1,OpenSSL 1.1.1b 2019年2月26日)上使用bash(和zsh)发生 在Alpine Linux OpenSSH_7.7p1,LibreSSL 2.7.4上不会发生这种情况 并非每台机器都发生这种情况,只有一部分机器会发生(不取决于发行版) resolv.conf是正确的 使用和不使用ClientAliveInterval都会发生错误(已在客户端和服务器上测试) 对设备执行ping操作总是非常快(少于1毫秒),因此只有SSH 当我从Windows 10上的Linux子系统以及Putty和MobaXterm ssh SSH时,它也会滞后 从Linux而不是Windows连接时没有问题 有人能提供任何线索或尝试的方法吗?谢谢
9 linux  ssh  windows-10  putty  lag 

4
跨多个交换机的链路绑定?
我已经阅读了一些有关将ifsslave与nics绑定的信息。我无法理解的是,是否需要特殊配置才能将绑定拆分到两个交换机之间。例如,如果我有几台服务器,每个服务器各有两个nic,还有两个单独的交换机,我是否只需配置绑定并将每个nic分别插入1号交换机,将另一个nic插入2号交换机?还是还有更多呢? 如果绑定是活动备份,那么单台计算机上的nic故障会否意味着服务器可能会断开连接,因为其余的计算机都在使用主nic,而在使用辅助nic?还是也用一根电缆链接交换机?

1
第2层环路避免:串联三个开关
我知道这似乎是一个家庭作业问题,但这实际上是一个较大的项目(和网络)的一部分,需要将其分解为多个部分,这样我才能清楚自己在做什么。我从未使用过[R / M] STP,并且之前仅设置了静态LAG,所以我不确定在这里我需要什么。 我通过VLAN标记在同一广播域内拥有三台交换机,这些交换机通过一个LAG组互连,每个LAG组由2个铜质千兆以太网组成。 假设这些交换机支持LAG / LACP / * STP / 802.1q VLAN标记;为了进行比较,尝试在此处最小化供应商专有扩展,但是如果有供应商“重新标记”开放标准,或者值得一提,请随时这样做。 目标是: 通过B和C为交换机A提供冗余上行链路 在两个上行链路上均具有负载平衡/增加的带宽(如果可能的话,即4 x GbE LAG组或2 x 2 GbE LAG组“主动/被动”(如果有意义)) 我不确定的是: 我认为这种循环的工作方式是:来自机器B1(在交换机B上)的ARP请求寻找1.2.3.4,该请求属于机器A1(在交换机A上),它将从A到B和A到达交换机A。 -C上行链路。交换机A(我假设)首先通过直接的B-to-A LAG上行链路接收广播,但将从两个上行链路LAG端口发送回响应(即,LAG A-to-B是端口1/2和LAG A到C是端口23/24),极大地混淆了交换机B。我对这个循环的解释方式正确吗? 如果我断言#1确实是一个循环,那么我需要* STP。根据我的阅读,STP既旧又缓慢。RSTP更快(可能是除了最大的网络以外的所有节点上的争论点?似乎就是Intarweb所说的)。然后是MSTP,这让我感到困惑:似乎允许多个VLAN的多个STP组,但是假设我只处理一个VLAN(2),这是否必要?如果我添加了第二个VLAN来承载所有3台交换机怎么办? 我非常确定M-LAG(我想这就是它的名字)将允许跨交换机的LAG,但是我不清楚这是否是一个LAG,其中包括组成交换机A的A-的4个以太网连接到B(2)和A到C(2)上行链路? 我在某个地方的一个论坛上读过(不记得在哪里),LACP将消除对* STP的需求,因为它是“动态的”,并且会“知道”哪个上行链路根据负载平衡算法转发广播/单播流量,但是后来有人不这么认为。 归根结底,鉴于LAG / LACP / * STP的首字母缩略词汤和我的拓扑,在这里我应该做什么?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.