我知道这应该是一个“专业”论坛，但我希望有人能提供帮助，因为我的 ISP 并没有采取太多措施来尝试解决问题。
我的 ISP 为我提供了 DSL 调制解调器/路由器组合 - ADB / Pirelli P.DG A2100N，我拥有 4096 / 767 kbps 的连接。我将其纯粹用作调制解调器和路由器，并关闭了无线 AP 功能。我将其运行到 Ubiquiti Networks Toughswitch 并使用 Ubiquiti UAP 作为无线接入点 - 虽然我已经直接连接到路由器进行测试，没有连接任何其他设备，但仍然看到相同的问题。
我遇到过这样的问题：如果有人这样做，延迟会突然从 google.com 的 8 毫秒飙升到 250 毫秒以上任何事物在互联网上。如果我运行速度测试或类似的东西，我可以看到超过 3000ms 的延迟。下载某些内容时，即使速度被限制到，也会每隔几秒钟随机下降到 0kbps。
无法进行在线游戏，因为我注意到连接突然出现延迟，并且视频流或 VoIP 也会中断 - 这根本不一致。
我设法找到了调制解调器的密码，我认为设置没有问题 - 但我查看了日志并发现了以下内容：
Jun 6 17:10:30 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:30 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:31 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:40 user warn kernel: __ratelimit: 63 callbacks suppressed
Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:10:40 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:22 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:23 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:24 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:25 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:25 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:25 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:29 user warn kernel: __ratelimit: 15 callbacks suppressed
Jun 6 17:11:29 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:29 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:30 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:11:30 user warn kernel: nf_conntrack: table full, dropping packet.
Jun 6 17:55:26 user warn kernel: bcmxtmcfg: OAM loopback response not received on VCC 1.1.3
Jun 6 17:55:27 user warn kernel: bcmxtmcfg: OAM loopback response not received on VCC 1.1.4
那么，据我了解，似乎路由器正在丢弃数据包？
如果是这种情况，配置中有什么我可以更改的吗？或者我应该购买新的路由器、新的调制解调器，还是两者都买？
答案1
conntrack full = TCP 连接跟踪表已满
这是用于跟踪任何本地主机与远程主机通信时同时进行的 TCP 连接的表，以便返回到正确的本地主机（即：natting 表）
如果路由器配置的数字较低，则可能会发生这种情况。
普通嫌犯：
- 比特流
- DOS（当您启用 DMZ/端口转发时有人试图连接您）
- 感染病毒/僵尸机器人
从您显示的系统日志来看，路由器似乎正在运行 Linux 版本。您可能能够或可能无法在路由器中配置更高的数字，但首先我会查看连接的来源并限制这些连接（例如：假设您的另一半和孩子同时在进行 torrenting...）