主页 / user-152073

Andrew B's questions

Martin Hope
Andrew B
Asked: 2016-02-12 12:00:05 +0800 CST
  • 44

引用 RFC 以支持意见（包括 Serverfault Q&A）是非常常见的，但普通 IT 员工对于哪些 RFC 定义标准以及哪些是纯粹提供信息的理解非常差。这应该不足为奇：所有经验水平的系统管理员通常会避免对 RFC 视而不见，除非他们别无选择。

在像我们这样的网站上，非常重要的是，我们不会在我们赞成的答案中延续常见的误解。从搜索引擎中游来的随机用户会假设没有争议评论的赞成票是审查的充分指标。最近，我偶然发现了 2011 年的一个答案，这表明这在某些情况下肯定不会被抓住，因为我们支持并且可能需要做出一些努力来告知我们的社区和整个互联网。

因此，事不宜迟，如何区分可作为互联网标准引用的 RFC 和纯粹提供信息的 RFC？

rfc
Martin Hope
Andrew B
Asked: 2016-01-11 08:28:00 +0800 CST
  • 4

这是关于 ISC BIND 名称服务器软件中速率限制的规范问题。

最近我听说了 BIND 的速率限制功能。特别是 DNS RRL 似乎变得越来越普遍。

我有点困惑。一些文档似乎说这些功能不应该与递归 DNS 服务器一起使用，但其他文档非常具体地解决了递归 DNS 基础设施。谁是对的？

domain-name-system
Martin Hope
Andrew B
Asked: 2015-06-02 09:14:35 +0800 CST
  • 3

我为一家在 AD 域上使用拆分 DNS 配置的公司工作。我知道这不太理想，但我无法推动这一领域的变革。我拥有不涉及 Active Directory 的权威 DNS（内部和外部），而另一个团队拥有域控制器。

背景：

  • 我们有一个名为的拆分域example.com，它存在于所有域控制器上。
  • DC 被配置为对它们不具有权威性的所有域使用转发器。
  • 该 ( ) 的子域使用记录sub.example.com委派给 DMZ 中的公共 IP 地址。NS我需要使用 DMZ 之外的内部 IP 地址来消除这些 IP 地址。
  • 可以从转发器访问新 IP 地址，但不能从域控制器访问。

要直观地表示这一点：

    example.com. (DCs are authoritative)
sub.example.com. (subdomain not managed by the DCs)

我希望将sub.example.com. NS记录转换为条件转发器，将流量发送到标准转发器，但我们的域管理员告诉我，Windows DNS 不允许转发器进入正向查找区域。

这是一个不受支持的配置，这是真的吗？其他 DNS 产品对位于权威区域下的转发器没有问题，因此我想确保在使用不同的策略之前使用正确的信息，例如绕过转发器的每个 DC 的防火墙漏洞. （啊）

我已经查看了在 Windows 2k3 中将子域的转发请求转发到另一台 DNS 服务器以及推荐NS委派的已接受答案，该答案没有回答这个问题。

domain-name-system
Martin Hope
Andrew B
Asked: 2015-05-22 09:57:52 +0800 CST
  • 12

（免责声明：我不是 Windows DNS 管理员。不过，我确实有相当多的 DNS 经验，但这没有任何意义。我正在与负责这些设备的管理员密切合作，并且可以将测试执行为需要。）

我们遇到了一个问题，我们无法在 Windows Server 2012 下添加指向 BIND 名称服务器的条件转发器。添加服务器的 IP 地址会导致验证错误：An unknown error occurred while validating the server.

转发器失败。 :(

查看 BIND 服务器上的查询日志，我们发现了一些相当有趣的东西：Windows DNS 服务器正在查询. IN SOA，即根名称服务器的 SOA 记录。example.com. IN SOA根本没有查询。它尝试查询 root 权限，并且在收到 的响应时不会继续REFUSED。

client 192.168.203.20#59067 (.): query: . IN SOA - (192.168.208.201)
client 192.168.203.20#50553 (.): query: . IN SOA - (192.168.208.201)
client 192.168.203.20#55468 (.): query: . IN SOA - (192.168.208.201)

疯狂。为了幽默，我们在实验室重现了这个问题。我下载了根区域的副本并配置了一个.区域（注释掉我的根提示），你瞧，这个错误不再发生。

我真的不明白这个。我正在提供一个无需提供答案的权威名称服务器，. SOA而且就目前情况而言，我将不得不将此区域添加到我们所有的生产服务器中，以便与 Windows 2012 很好地配合。根据我的经验，一个转发器应该只关心目标名称服务器是否对相关区域具有权威性。

为什么会这样？

如果我们尝试忽略错误（仍然单击确定），我们会得到以下错误对话框：

更多转发器失败。 :(

查询日志仍然显示上游服务器只要求. IN SOA. 永远不会尝试查看服务器是否对example.com..

domain-name-system
Martin Hope
Andrew B
Asked: 2015-02-20 02:08:50 +0800 CST
  • 11

这是关于 DNS 服务器管理的规范问题。

我有一百个左右的域。所有这些域都需要进行相同的配置，但必须为每个域配置一个新的区域和/或区域文件似乎是一种巨大的浪费时间。必须有更好的方法来自动化它！

我想我正在做某事......如果我创建一个名为 的区域.，或者在我的 DNS 软件中使用其他一些功能来在请求记录时始终返回特定 IP A，这似乎让我非常接近我想要的结果结果。我的服务器对请求做出权威响应，而且管理起来更容易！

在名称服务器验证软件开始检查这些域之前，这一直很好。我发现我可以通过添加记录来消除大部分错误，但是我的软件不允许我在同一个区域文件中NS放置多个记录。SOA

如何解决这个多SOA记录问题？

domain-name-system
Martin Hope
Andrew B
Asked: 2014-12-06 14:35:44 +0800 CST
  • 6

我已阅读并理解您能否帮助我进行容量规划？，但我不确定我是否了解在 DNS 服务器方案中我的下一步是什么。我认为我的 CPU 负载很高，或者我可能开始放弃查询，但我想在对服务器采取行动之前更好地了解服务器的负载。这对我来说尤其令人担忧，因为众所周知，将您的基础架构扩展到 DDoS 负载正在输掉战斗。

为了了解我的环境，我应该分析什么？

domain-name-system
Martin Hope
Andrew B
Asked: 2014-10-10 08:40:32 +0800 CST
  • 29

这是关于保护公共 DNS 解析器的规范问题

开放式 DNS 服务器看起来非常简洁和方便，因为它们提供了我们可以在整个公司内一致使用的 IP 地址，无论它们位于何处。Google 和 OpenDNS 提供了此功能，但我不确定我是否希望这些公司能够访问我们的 DNS 查询。

我想设置这样的东西供我们公司使用，但我听到很多关于这是危险的做法（特别是在放大攻击方面），我想确保我们做对了。在构建这种类型的环境时，我需要记住哪些事项？

domain-name-system
Martin Hope
Andrew B
Asked: 2014-07-20 02:53:34 +0800 CST
  • 152

这是关于区域顶点（或根）的 CNAME的规范问题

CNAME域顶端的记录是一种禁忌做法，这是相对普遍的知识。

例子： example.com. IN CNAME ithurts.example.net.

在最好的情况下，名称服务器软件可能会拒绝加载配置，在最坏的情况下，它可能会接受此配置并使 example.com 的配置无效。

最近，我有一家网络托管公司向业务部门传递指令，我们需要将我们域的顶点 CNAME 到新记录。知道这在提供给 BIND 时将是一个自杀配置，我建议他们我们将无法遵守，这通常是愚蠢的建议。这家虚拟主机公司的立场是，标准定义的 RFC 并没有完全禁止它，并且他们的软件支持它。如果我们不能 CNAME 顶点，他们的建议是根本没有顶点记录，并且他们不会提供重定向网络服务器。...什么？

我们大多数人都知道RFC1912坚持这一点A CNAME record is not allowed to coexist with any other data.，但让我们在这里对自己诚实，RFC 只是信息性的。我所知道的最接近禁止这种做法的措辞来自RFC1034：

如果 CNAME RR 出现在节点上，则不应出现其他数据；这可确保规范名称及其别名的数据不能不同。

不幸的是，我在这个行业已经足够长的时间知道“不应该”与“不能”是不一样的，这对大多数软件设计师来说已经足够了。知道任何缺少与灌篮的简洁链接都会浪费我的时间，我最终让公司逃脱了责骂，因为推荐的配置可能会在没有适当披露的情况下破坏常用软件。

这将我们带到问答环节。这一次，我希望我们能够真正了解顶级 CNAME 的疯狂，而不是像我们通常在有人就该主题发帖时那样回避这个问题。RFC1912是不受限制的，我没有想到的任何其他适用于此处的信息 RFC 也是如此。让我们关闭这个婴儿。

domain-name-system
Martin Hope
Andrew B
Asked: 2014-07-16 15:54:40 +0800 CST
  • 27

围绕反向 DNS 的要求令人困惑！人们经常谈论如果没有反向 DNS，一切都会中断，这听起来很可怕。即使在应用程序不需要反向 DNS 的情况下，也经常引用 RFC 来支持强制 PTR 记录创建。

其中一些 RFC 包括：

RFC1912：常见的 DNS 操作和配置错误

每个 Internet 可访问的主机都应该有一个名称。... 确保您的 PTR 和 A 记录匹配。对于每个 IP 地址，in-addr.arpa 域中应该有一个匹配的 PTR 记录。如果主机是多宿主的（多个 IP 地址），请确保所有 IP 地址都有相应的 PTR 记录（不仅仅是第一个）。没有匹配的 PTR 和 A 记录可能会导致 Internet 服务丢失，类似于根本没有在 DNS 中注册。

RFC1033：域管理员操作指南

添加主机。

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

尽管如此，有些人仍然坚持说，管理 DNS 管理的标准不需要创建PTR 记录。实际要求是什么？

domain-name-system
Martin Hope
Andrew B
Asked: 2014-06-14 16:44:30 +0800 CST
  • 5

我的团队有一个指向 Active Directory 提供的 DNS 的服务器，以确保它能够访问该域管理的任何主机。不幸的是，我的团队也需要dig +trace经常运行，我们偶尔会得到奇怪的结果。我是 DNS 管理员，但不是域管理员，但负责这些服务器的团队也不确定这里发生了什么。

问题似乎在操作系统升级之间转移，但很难说这是操作系统版本的特征还是升级过程中更改的其他设置。

  • 当上游服务器是 Windows Server 2003 时，第一步（来自第一个条目的dig +trace请求）偶尔会返回 0 字节响应。. IN NS/etc/resolv.conf
  • 当上游服务器升级到 Windows Server 2012 时，零字节响应问题消失了，但取而代之的是我们偶尔会获取 DNS 服务器上配置的转发器列表的问题。

第二个问题的例子：

$ dig +trace -x 1.2.3.4      

; <<>> DiG 9.8.2 <<>> +trace -x 1.2.3.4
;; global options: +cmd
.                       3600    IN      NS      dns2.ad.example.com.
.                       3600    IN      NS      dns1.ad.example.com.
;; Received 102 bytes from 192.0.2.11#53(192.0.2.11) in 22 ms

1.in-addr.arpa.         84981   IN      NS      ns1.apnic.net.
1.in-addr.arpa.         84981   IN      NS      tinnie.arin.net.
1.in-addr.arpa.         84981   IN      NS      sec1.authdns.ripe.net.
1.in-addr.arpa.         84981   IN      NS      ns2.lacnic.net.
1.in-addr.arpa.         84981   IN      NS      ns3.apnic.net.
1.in-addr.arpa.         84981   IN      NS      apnic1.dnsnode.net.
1.in-addr.arpa.         84981   IN      NS      ns4.apnic.net.
;; Received 507 bytes from 192.0.2.228#53(192.0.2.228) in 45 ms

1.in-addr.arpa.         172800  IN      SOA     ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net.
4827 7200 1800 604800 172800
;; Received 127 bytes from 202.12.28.131#53(202.12.28.131) in 167 ms

在大多数情况下，这不是问题，但dig +trace如果我们在 AD 具有内部视图的域内进行跟踪，则会导致走错路。

为什么会dig +trace失去理智？为什么我们似乎是唯一抱怨的人？

domain-name-system
Martin Hope
Andrew B
Asked: 2014-04-11 15:34:24 +0800 CST
  • 32
$ORIGIN example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

NS 记录在域顶点下的作用是众所周知的。它们的存在是为了将子域的权限委托给另一个名称服务器。上述示例包括 和 的 NSsub1记录sub2。这些允许名称服务器分发它不认为自己具有权威性的域部分的引用。

NS 记录在域顶点的目的，ns1在ns2这种情况下，整个互联网似乎不太了解。我的理解（可能不是整体的）如下：

  1. 缓存 DNS 服务器不使用它们来确定域的权威服务器。这由在注册商级别定义的名称服务器粘合处理。注册商从不使用此信息来生成粘合记录。
  2. 它们不用于将整个域的权限委托给其他名称服务器。尝试使用 ISC BIND 等软件这样做根本不会导致“预期的”引用行为，因为名称服务器将继续认为自己对该区域具有权威性。
  3. 名称服务器不使用它们来确定它是否应该返回权威响应（AA标志集）；该行为由软件被告知是该区域的主机还是从机来定义。大多数域名服务器软件很乐意为与上游粘合记录所包含的信息不一致的顶级 NS 记录提供服务，这反过来会导致知名的 DNS 验证网站为域生成警告。

既然如此，我们还剩下什么？如果这些信息似乎没有被整个 Internet 上的 DNS 服务器缓存所消耗，我们为什么要定义这些信息？

domain-name-system ns-record glue-record
Martin Hope
Andrew B
Asked: 2013-11-08 17:50:40 +0800 CST
  • 9

服务器：Poweredge r620
操作系统：RHEL 6.4
内核：2.6.32-358.18.1.el6.x86_64

我在生产环境中遇到应用程序警报。关键的 CPU 饥饿进程正在缺乏资源并导致处理积压。最近部署的集群中的所有第 12 代戴尔服务器 (r620s) 上都出现了该问题。据我所知，发生这种情况的实例正与峰值 CPU 利用率相匹配，并伴随着大量的“功率限制通知”垃圾邮件dmesg。这些事件之一的摘录：

Nov  7 10:15:15 someserver [.crit] CPU12: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU0: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU6: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU14: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU18: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU2: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU4: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU16: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU0: Package power limit notification (total events = 11)
Nov  7 10:15:15 someserver [.crit] CPU6: Package power limit notification (total events = 13)
Nov  7 10:15:15 someserver [.crit] CPU14: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU18: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU20: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU8: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU2: Package power limit notification (total events = 12)
Nov  7 10:15:15 someserver [.crit] CPU10: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU22: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU4: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU16: Package power limit notification (total events = 13)
Nov  7 10:15:15 someserver [.crit] CPU20: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU8: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU10: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU22: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU15: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU3: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU1: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU5: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU17: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU13: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU15: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU3: Package power limit notification (total events = 374)
Nov  7 10:15:15 someserver [.crit] CPU1: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU5: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU7: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU19: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU17: Package power limit notification (total events = 377)
Nov  7 10:15:15 someserver [.crit] CPU9: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU21: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU23: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU11: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU13: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU7: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU19: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU9: Package power limit notification (total events = 374)
Nov  7 10:15:15 someserver [.crit] CPU21: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU23: Package power limit notification (total events = 374)

一点 Google Fu 透露，这通常与 CPU 过热或电压调节启动有关。但我不认为这是正在发生的事情。集群中所有服务器的温度传感器运行良好，iDRAC 中禁用了功率上限策略，并且我的系统配置文件在所有这些服务器上设置为“性能”：

# omreport chassis biossetup | grep -A10 'System Profile'
System Profile Settings
------------------------------------------
System Profile                                    : Performance
CPU Power Management                              : Maximum Performance
Memory Frequency                                  : Maximum Performance
Turbo Boost                                       : Enabled
C1E                                               : Disabled
C States                                          : Disabled
Monitor/Mwait                                     : Enabled
Memory Patrol Scrub                               : Standard
Memory Refresh Rate                               : 1x
Memory Operating Voltage                          : Auto
Collaborative CPU Performance Control             : Disabled

我在网上能找到的一切都让我在这里转圈。到底是怎么回事？

linux
Martin Hope
Andrew B
Asked: 2013-05-21 11:58:00 +0800 CST
  • 1

BIND 9.4.1 为私有地址空间实现了自动清空反向区域，以防止反向 DNS 泄漏。这为管理员省去了必须定义这些空区域的麻烦，并减少了将反向 DNS 查找泄漏到IANA 黑洞服务器的“开箱即用”配置的数量。

来自自动空白反向区域的合成回复的默认格式是什么？文档中未完整描述该格式。（只是几个选项的默认值）

domain-name-system
Martin Hope
Andrew B
Asked: 2013-03-29 21:10:39 +0800 CST
  • 4

This question is similar,但没有详细说明为什么NS无法获得记录这一令人困惑的情况。

我们的缓存 DNS 环境之一（RHEL 5.8、BIND 9.3.6-20.P1.el5_8.4）已停止返回区域的任何有用数据。通常这类问题最终会成为陈旧NS或胶水记录，但在这种特殊情况下，我似乎甚至无法让缓存报告NS该区域的记录。

  • dig @mycache somedomain NS回报SERVFAIL。根本没有缓存的名称服务器记录。
  • dig +trace显示了一个健康的委托路径，最终名称服务器返回响应。对最终名称服务器手动运行dig查询返回有效NS记录，相应的A记录存在并与胶水一致，等等。

是什么赋予了？为什么NS我从DNS缓存中获取不到任何记录，连一条坏记录都没有？

domain-name-system
Martin Hope
Andrew B
Asked: 2013-02-27 23:51:16 +0800 CST
  • 32

当 DNS 缓存的准确性受到质疑时，dig +trace这往往是确定面向 Internet 的 DNS 记录的权威答案的推荐方法。这似乎在与 配对时特别有用+additional，它也显示胶水记录。

有时似乎在这一点上存在一些分歧——有人说它依赖于本地解析器来查找中间名称服务器的 IP 地址，但命令输出没有提供任何迹象表明这发生在根目录的初始列表之外名称服务器。+trace如果 的目的是从根服务器开始并向下追踪，那么假设情况并非如此似乎是合乎逻辑的。（至少如果你有正确的根名称服务器列表）

是否dig +trace真的将本地解析器用于根名称服务器之后的任何内容？

domain-name-system
Martin Hope
Andrew B
Asked: 2013-01-08 14:05:58 +0800 CST
  • 11

背景：

我继承了一个大容量缓存名称服务器环境（Redhat Enterprise Linux 5.8，IBM System x3550），它具有不一致的环形缓冲区设置：eth0 为 1020，eth1 为 255。eth0 连接到其本地数据中心的交换机 1，eth1 连接到同一数据中心的交换机 2。集群中的每台服务器都在 eth0 或 eth1 是活动接口之间交替，并且每个集群都位于不同的区域。环形缓冲区显然需要保持一致。

这是事情变得更棘手的地方：我在研究为什么许多名称服务器频繁记录“错误发送响应：未设置”错误时发现了上述问题，ISC 知识库表明这与出站拥塞有关。具有较高环形缓冲区设置 (1020) 的服务器在 ifconfig 上丢弃的数据包较少（正如人们所期望的那样），但倾向于以很高的频率记录上述错误，在我的最高负载组之一中每天约 20k 次。我们将其称为“第 1 组”。具有较低环形缓冲区 (255) 设置的服务器每天丢弃明显更多的入站数据包（再次，预期），但 BIND 错误的实例要少得多，在同一负载组中通常为 0-150。

这里也不是什么大谜团。缓存 DNS 是一种递归服务：如果某些内容没有被缓存，服务器必须代表那个问题进行多次查询，直到它最终返回一个答案。这是一个（一入）->（多出）查询关系。修复 RX 环形缓冲区应该使这个数字全面等于一个新值，从那里调整内核在 proc (wmem_max/wmem_default) 中的出站网络队列可能是个好主意。

我喜欢能够衡量配置更改对性能问题的影响，所以我在开始进行生产更改之前编写了一份报告来收集一些数据。这是第 1 组中前两台服务器的输出示例：

group1-01
    RX: 7166.27/sec av.
    TX: 7432.57/sec av.
    RXDROP: 7.43/sec av.
    unset_err: 27633
group1-02
    RX: 7137.37/sec av.
    TX: 7398.50/sec av.
    RXDROP: 9.94/sec av.
    unset_err: 107

这些是公式。请注意，这是一个本地脚本，不依赖于必须在每个服务器上维护的 shell 脚本。

    RXPACK=$(ssh $server "sar -n DEV -f /var/log/sa/sa$(date --date=yesterday '+%d') | grep \"Average: .*\$(awk '{if (\$2 == "00000000") { print \$1 }}' /proc/net/route)\" | awk '{print \$3}'" 2>/dev/null)
    TXPACK=$(ssh $server "sar -n DEV -f /var/log/sa/sa$(date --date=yesterday '+%d') | grep \"Average: .*\$(awk '{if (\$2 == "00000000") { print \$1 }}' /proc/net/route)\" | awk '{print \$4}'" 2>/dev/null)
    RXDROP=$(ssh $server "sar -n EDEV -f /var/log/sa/sa$(date --date=yesterday '+%d') | grep \"Average: .*\$(awk '{if (\$2 == "00000000") { print \$1 }}' /proc/net/route)\" | awk '{print \$6}'" 2>/dev/null)
    TXDROP=$(ssh $server "sudo grep 'error sending response: unset' /var/log/dns_named.1" 2>/dev/null | wc -l)

一旦我开始在我的所有缓存 DNS 环境中运行此报告，我注意到另一个数据包负载几乎相同的组（我们称之为第 2 组）完全没有问题：

group2-01
    RX: 7066.44/sec av.
    TX: 7345.95/sec av.
    RXDROP: 0.00/sec av.
    unset_err: 0
group2-02
    RX: 7019.18/sec av.
    TX: 7312.47/sec av.
    RXDROP: 0.00/sec av.
    unset_err: 0

问题：

为什么 group2 在不需要进一步调整 RX 环形缓冲区或net.core.wmem_default/的情况下以这种方式运行net.core.wmem_max？无论如何我都需要规范化环形缓冲区，但我想在开始使用 /proc 中的 wmem 值之前了解这里发生了什么。

我唯一能想到的是应用程序清空队列的速度更快，但网络堆栈调整不是我有大量实践经验的东西，我想征求第二意见。（我的眼睛盯着一些 ethtool 计数器名称，我不会否认）

我已经排除了以下可能性。证明在分隔符之后。

  • 环形缓冲区布局是相同的。（group1和group2的第一台服务器配置相同，group1和group2的第二台服务器配置相同）
  • 默认网关布局是相同的。
  • 网卡是一样的。(博通 BCM5708)
  • ethtool 报告的固件版本是相同的。(bc 4.0.3 ipms 1.6.0)
  • sysctl -a两个组的第一台服务器和两个组的第二台服务器之间的输出匹配。（不包括内核和 fs 部分）
  • Group 1 和 Group 2 的服务器总数相同。(10)

出于保密原因，我无法显示原始的 named.conf 或我用来排除信息的 grep 过滤器。您必须相信我的话，以下配置参数在所有四台服务器之间都是恒定的：

    notify no;
    allow-transfer { none; };
    allow-recursion { any; };
    allow-query { any; };
    allow-query-cache { any; };
    recursive-clients 100000;
    max-cache-size 2G;
    max-ncache-ttl 900;

下面是大量的系统信息。“hosthash”只是为了证明循环的每次迭代实际上都是在不透露实际主机名的情况下访问不同的服务器。

主机哈希：

group1-1: dc78abcb154b74c87feecb3f35222263d40c028c
group1-2: 9fe491d58fd1e7d4e21e5bf10c164e4cf66e884b
group2-1: fc76bb3ee1ff580c6aba0d685713bb4145bd5fe3
group2-2: b7550c65d37622a131b1e47f066773defbb4d817

for server in $group1_1 $group1_2 $group2_1 $group2_2
do
    echo ____________________
    ssh $server "echo -en hosthash: \$(echo \$HOSTNAME | sha1sum)\\\n\\\n &&
         SARFILE=/var/log/sa/sa\$(date --date=yesterday '+%d') &&
         uname -srvmpio &&
         sudo /usr/sbin/dmidecode -s system-product-name
         dmesg | grep Broadcom &&
         head /proc/cpuinfo &&
         GWIF=\$(awk '{if (\$2 == 00000000) { print \$1 }}' /proc/net/route) &&
         sar -n DEV -f \$SARFILE | egrep '(IFACE|Average)' &&
         sar -n EDEV -f \$SARFILE | egrep '(IFACE|Average)' &&
         sudo /sbin/ethtool \$GWIF &&
         sudo /sbin/ethtool -i \$GWIF &&
         sudo /sbin/ethtool -g \$GWIF &&
         sudo /sbin/ethtool -c \$GWIF &&
         sudo /sbin/ethtool -S \$GWIF &&
         echo sysctl linecount: \$(sudo /sbin/sysctl -a | egrep -v '^(fs|kernel)' | wc -l) &&
         echo sysctl hash: \$(sudo /sbin/sysctl -a | egrep -v '^(fs|kernel)' | sha1sum)"
done

输出：

____________________
hosthash: dc78abcb154b74c87feecb3f35222263d40c028c -

Linux 2.6.18-308.16.1.el5 #1 SMP Tue Sep 18 07:21:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
IBM System x3550 -[7978AC1]-
bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.1.11 (July 20, 2011)
eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem c8000000, IRQ 90, node addr 001a649db00e
eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem ce000000, IRQ 177, node addr 001a649db010
cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.7 (July 20, 2011)
Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.0.3 (Aug 04, 2011)
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 23
model name  : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
stepping    : 6
cpu MHz     : 2493.750
cache size  : 6144 KB
physical id : 0
siblings    : 4
12:00:01 AM     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
Average:           lo   1269.15   1269.15 206600.39 206600.39      0.00      0.00      0.00
Average:         eth0   7166.27   7432.57 704051.80 2419779.42      0.00      0.00      0.94
Average:         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
12:00:01 AM     IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s
Average:           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth0      0.00      0.00      0.00      7.43      0.00      0.00      0.00      0.00      0.00
Average:         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
driver: bnx2
version: 2.1.11
firmware-version: bc 4.0.3 ipms 1.6.0
bus-info: 0000:04:00.0
Ring parameters for eth0:
Pre-set maximums:
RX:     2040
RX Mini:    0
RX Jumbo:   8160
TX:     255
Current hardware settings:
RX:     1020
RX Mini:    0
RX Jumbo:   0
TX:     255

Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 999936
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 18
rx-frames: 12
rx-usecs-irq: 18
rx-frames-irq: 2

tx-usecs: 80
tx-frames: 20
tx-usecs-irq: 18
tx-frames-irq: 2

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

NIC statistics:
     rx_bytes: 1505439501410
     rx_error_bytes: 0
     tx_bytes: 4672574845104
     tx_error_bytes: 0
     rx_ucast_packets: 15315548049
     rx_mcast_packets: 2035415
     rx_bcast_packets: 1101989
     tx_ucast_packets: 15505474251
     tx_mcast_packets: 40018
     tx_bcast_packets: 36019
     tx_mac_errors: 0
     tx_carrier_errors: 0
     rx_crc_errors: 0
     rx_align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     tx_deferred: 0
     tx_excess_collisions: 0
     tx_late_collisions: 0
     tx_total_collisions: 0
     rx_fragments: 0
     rx_jabbers: 0
     rx_undersize_packets: 0
     rx_oversize_packets: 0
     rx_64_byte_packets: 92309552
     rx_65_to_127_byte_packets: 1243637891
     rx_128_to_255_byte_packets: 790117566
     rx_256_to_511_byte_packets: 127197337
     rx_512_to_1023_byte_packets: 168929387
     rx_1024_to_1522_byte_packets: 11591832
     rx_1523_to_9022_byte_packets: 0
     tx_64_byte_packets: 60586118
     tx_65_to_127_byte_packets: 1976738758
     tx_128_to_255_byte_packets: 2830395753
     tx_256_to_511_byte_packets: 157607989
     tx_512_to_1023_byte_packets: 1483716940
     tx_1024_to_1522_byte_packets: 406821340
     tx_1523_to_9022_byte_packets: 0
     rx_xon_frames: 0
     rx_xoff_frames: 0
     tx_xon_frames: 116422
     tx_xoff_frames: 134780
     rx_mac_ctrl_frames: 0
     rx_filtered_packets: 0
     rx_ftq_discards: 0
     rx_discards: 0
     rx_fw_discards: 14015105
sysctl linecount: 504
sysctl hash: dd6aab90d0fd9ae90742c5f812a78734e2f2ff1c -
____________________
hosthash: 9fe491d58fd1e7d4e21e5bf10c164e4cf66e884b -

Linux 2.6.18-308.16.1.el5 #1 SMP Tue Sep 18 07:21:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
IBM System x3550 -[7978EHU]-
bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.1.11 (July 20, 2011)
eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem c8000000, IRQ 90, node addr 001a6479655c
eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem ce000000, IRQ 177, node addr 001a6479655e
cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.7 (July 20, 2011)
Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.0.3 (Aug 04, 2011)
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 23
model name  : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
stepping    : 6
cpu MHz     : 2493.746
cache size  : 6144 KB
physical id : 0
siblings    : 4
12:00:01 AM     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
Average:           lo   1261.04   1261.04 205548.08 205548.08      0.00      0.00      0.00
Average:         eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth1   7137.37   7398.50 702340.35 2409580.71      0.00      0.00      0.97
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
12:00:01 AM     IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s
Average:           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth1      0.00      0.00      0.00      9.94      0.00      0.00      0.00      0.00      0.00
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
driver: bnx2
version: 2.1.11
firmware-version: bc 4.0.3 ipms 1.6.0
bus-info: 0000:06:00.0
Ring parameters for eth1:
Pre-set maximums:
RX:     2040
RX Mini:    0
RX Jumbo:   8160
TX:     255
Current hardware settings:
RX:     255
RX Mini:    0
RX Jumbo:   0
TX:     255

Coalesce parameters for eth1:
Adaptive RX: off  TX: off
stats-block-usecs: 999936
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 18
rx-frames: 12
rx-usecs-irq: 18
rx-frames-irq: 2

tx-usecs: 80
tx-frames: 20
tx-usecs-irq: 18
tx-frames-irq: 2

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

NIC statistics:
     rx_bytes: 1501719289640
     rx_error_bytes: 0
     tx_bytes: 4654179094291
     tx_error_bytes: 0
     rx_ucast_packets: 15253610508
     rx_mcast_packets: 2108112
     rx_bcast_packets: 1136240
     tx_ucast_packets: 15438361249
     tx_mcast_packets: 40135
     tx_bcast_packets: 1721
     tx_mac_errors: 0
     tx_carrier_errors: 0
     rx_crc_errors: 0
     rx_align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     tx_deferred: 0
     tx_excess_collisions: 0
     tx_late_collisions: 0
     tx_total_collisions: 0
     rx_fragments: 0
     rx_jabbers: 0
     rx_undersize_packets: 0
     rx_oversize_packets: 0
     rx_64_byte_packets: 92376678
     rx_65_to_127_byte_packets: 1183040190
     rx_128_to_255_byte_packets: 788176623
     rx_256_to_511_byte_packets: 126838328
     rx_512_to_1023_byte_packets: 168170816
     rx_1024_to_1522_byte_packets: 13350337
     rx_1523_to_9022_byte_packets: 0
     tx_64_byte_packets: 60806588
     tx_65_to_127_byte_packets: 1955234150
     tx_128_to_255_byte_packets: 2806601346
     tx_256_to_511_byte_packets: 154015585
     tx_512_to_1023_byte_packets: 1466206531
     tx_1024_to_1522_byte_packets: 405928513
     tx_1523_to_9022_byte_packets: 0
     rx_xon_frames: 0
     rx_xoff_frames: 0
     tx_xon_frames: 150648
     tx_xoff_frames: 173552
     rx_mac_ctrl_frames: 0
     rx_filtered_packets: 1
     rx_ftq_discards: 0
     rx_discards: 0
     rx_fw_discards: 19605427
sysctl linecount: 504
sysctl hash: 4626e3788c72e091487afe1e3a7cfd32278ab07d -
____________________
hosthash: fc76bb3ee1ff580c6aba0d685713bb4145bd5fe3 -

Linux 2.6.18-308.16.1.el5 #1 SMP Tue Sep 18 07:21:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
IBM System x3550 -[7978AC1]-
bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.1.11 (July 20, 2011)
eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem c8000000, IRQ 90, node addr 001a649dc68a
eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem ce000000, IRQ 177, node addr 001a649dc68c
cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.7 (July 20, 2011)
Broadcom NetXtreme II iSCSI Driver bnx2i v2.7.0.3 (Aug 04, 2011)
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 23
model name  : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
stepping    : 6
cpu MHz     : 2493.750
cache size  : 6144 KB
physical id : 0
siblings    : 4
12:00:01 AM     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
Average:           lo   1891.67   1891.67 266593.77 266593.77      0.00      0.00      0.00
Average:         eth0   7066.44   7345.95 730519.41 2215508.99      0.00      0.00      4.37
Average:         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
12:00:01 AM     IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s
Average:           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
driver: bnx2
version: 2.1.11
firmware-version: bc 4.0.3 ipms 1.6.0
bus-info: 0000:04:00.0
Ring parameters for eth0:
Pre-set maximums:
RX:     2040
RX Mini:    0
RX Jumbo:   8160
TX:     255
Current hardware settings:
RX:     1020
RX Mini:    0
RX Jumbo:   0
TX:     255

Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 999936
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 18
rx-frames: 12
rx-usecs-irq: 18
rx-frames-irq: 2

tx-usecs: 80
tx-frames: 20
tx-usecs-irq: 18
tx-frames-irq: 2

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

NIC statistics:
     rx_bytes: 4640887074833
     rx_error_bytes: 0
     tx_bytes: 12640942400790
     tx_error_bytes: 0
     rx_ucast_packets: 46405845860
     rx_mcast_packets: 14487857
     rx_bcast_packets: 3476467
     tx_ucast_packets: 47159091638
     tx_mcast_packets: 118147
     tx_bcast_packets: 5504
     tx_mac_errors: 0
     tx_carrier_errors: 0
     rx_crc_errors: 0
     rx_align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     tx_deferred: 0
     tx_excess_collisions: 0
     tx_late_collisions: 0
     tx_total_collisions: 0
     rx_fragments: 0
     rx_jabbers: 0
     rx_undersize_packets: 0
     rx_oversize_packets: 0
     rx_64_byte_packets: 136463411
     rx_65_to_127_byte_packets: 4245502343
     rx_128_to_255_byte_packets: 2357984838
     rx_256_to_511_byte_packets: 355610202
     rx_512_to_1023_byte_packets: 608223572
     rx_1024_to_1522_byte_packets: 65320154
     rx_1523_to_9022_byte_packets: 0
     tx_64_byte_packets: 112166114
     tx_65_to_127_byte_packets: 3010346100
     tx_128_to_255_byte_packets: 4087240164
     tx_256_to_511_byte_packets: 1625596725
     tx_512_to_1023_byte_packets: 3037109096
     tx_1024_to_1522_byte_packets: 927187571
     tx_1523_to_9022_byte_packets: 0
     rx_xon_frames: 0
     rx_xoff_frames: 0
     tx_xon_frames: 79164
     tx_xoff_frames: 89685
     rx_mac_ctrl_frames: 0
     rx_filtered_packets: 1
     rx_ftq_discards: 0
     rx_discards: 0
     rx_fw_discards: 6857729
sysctl linecount: 504
sysctl hash: dd6aab90d0fd9ae90742c5f812a78734e2f2ff1c -
____________________
hosthash: b7550c65d37622a131b1e47f066773defbb4d817 -

Linux 2.6.18-308.16.1.el5 #1 SMP Tue Sep 18 07:21:07 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
IBM System x3550 -[7978EHU]-
bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.1.11 (July 20, 2011)
eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem c8000000, IRQ 90, node addr 00215e3f1ec4
eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem ce000000, IRQ 177, node addr 00215e3f1ec6
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 23
model name  : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
stepping    : 6
cpu MHz     : 2493.753
cache size  : 6144 KB
physical id : 1
siblings    : 4
12:00:01 AM     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
Average:           lo   1883.04   1883.04 263726.79 263726.79      0.00      0.00      0.00
Average:         eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth1   7019.18   7312.47 720911.92 2214861.10      0.00      0.00      1.02
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
12:00:01 AM     IFACE   rxerr/s   txerr/s    coll/s  rxdrop/s  txdrop/s  txcarr/s  rxfram/s  rxfifo/s  txfifo/s
Average:           lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
Average:         sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
driver: bnx2
version: 2.1.11
firmware-version: bc 4.0.3 ipms 1.6.0
bus-info: 0000:06:00.0
Ring parameters for eth1:
Pre-set maximums:
RX:     2040
RX Mini:    0
RX Jumbo:   8160
TX:     255
Current hardware settings:
RX:     255
RX Mini:    0
RX Jumbo:   0
TX:     255

Coalesce parameters for eth1:
Adaptive RX: off  TX: off
stats-block-usecs: 999936
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 18
rx-frames: 12
rx-usecs-irq: 18
rx-frames-irq: 2

tx-usecs: 80
tx-frames: 20
tx-usecs-irq: 18
tx-frames-irq: 2

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

NIC statistics:
     rx_bytes: 4621548539323
     rx_error_bytes: 0
     tx_bytes: 12598031299743
     tx_error_bytes: 0
     rx_ucast_packets: 46260356368
     rx_mcast_packets: 5352446
     rx_bcast_packets: 3474589
     tx_ucast_packets: 47008853953
     tx_mcast_packets: 118164
     tx_bcast_packets: 5471
     tx_mac_errors: 0
     tx_carrier_errors: 0
     rx_crc_errors: 0
     rx_align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     tx_deferred: 0
     tx_excess_collisions: 0
     tx_late_collisions: 0
     tx_total_collisions: 0
     rx_fragments: 0
     rx_jabbers: 0
     rx_undersize_packets: 0
     rx_oversize_packets: 0
     rx_64_byte_packets: 126851062
     rx_65_to_127_byte_packets: 4117708205
     rx_128_to_255_byte_packets: 2346047550
     rx_256_to_511_byte_packets: 356266112
     rx_512_to_1023_byte_packets: 604666332
     rx_1024_to_1522_byte_packets: 62938478
     rx_1523_to_9022_byte_packets: 0
     tx_64_byte_packets: 111216848
     tx_65_to_127_byte_packets: 2984505931
     tx_128_to_255_byte_packets: 4027485330
     tx_256_to_511_byte_packets: 1577669672
     tx_512_to_1023_byte_packets: 3015060448
     tx_1024_to_1522_byte_packets: 933575954
     tx_1523_to_9022_byte_packets: 0
     rx_xon_frames: 0
     rx_xoff_frames: 0
     tx_xon_frames: 129873
     tx_xoff_frames: 145090
     rx_mac_ctrl_frames: 0
     rx_filtered_packets: 1
     rx_ftq_discards: 0
     rx_discards: 0
     rx_fw_discards: 6752713
sysctl linecount: 504
sysctl hash: 4626e3788c72e091487afe1e3a7cfd32278ab07d -
linux