过去的好时光
曾几何时，IP网络很简单。我们共享了以太网连接和串行连接。他们每个人都有自己的故障排除方法，但它们是基本的。我们运行了IP（以及其他一堆协议，但我们不会涉足这些协议），并遵循了四级TCP/IP模型（RFC 1122）找出我们网络中的问题。我们从自下而上工作，大部分时间都达到了快速分辨率。
事情永远不会保持简单
Maybe it never was that uncomplicated and it is just a wistful memory.RFC 1925：十二个网络真相说这总是比我们想象的要复杂。尽管如此，当我们添加了不同的运输方式时，事情变得更加复杂。
我们从TCP/IP模型慢慢移动以引用OSI模型（ISO/IEC 7498-1：1994）为了更具体地分解内容，尤其是在Internet层。解决问题仍然从最低到顶部上升，但通过更详细的步骤。
The Growing Popularity of Encapsulated Protocols
最终发生的有趣发展之一是将IP网络本身作为通用运输的想法。我们没有开发新的物理网络，而是开始使用封装协议来抽象事物，并在我们现有的网络上运行它们。我们不关心基础运输，但这会移动复杂性而不是消除它。在RFC 1925也。
当我们谈论封装协议时，我们通常在谈论通过基本网络运行覆盖网络。我们大多数人都熟悉格雷，，，，L2TPV3，，，，vxlanorMpls对于这种应用程序，但它不止于此。混合语音和数据网络带来了我们H.323/RTPandSIP / RTP。融合的数据和存储网络已添加FCIPandiscsi到我们的清单。
这些后一个协议可以视为服务，与在我们的网络上运行的任何其他应用程序没有什么不同。一件事使它们与众不同：它们每个人都独立存在于其他物理层上，然后再迁移到IP网络。
当我们诊断出任何或全部的问题时，我们必须查看两个或多个分层模型才能有效。
Layers Within Layers
当许多模型在游戏中时，隔离问题可能很棘手。在进行努力之前，我们必须隔离哪种模型最有可能成为罪魁祸首。在大多数情况下，我们将从外部工作，因为整个封装模型都骑在基本网络层的顶部。如果我们知道我们正在处理特定于有效载荷的问题，那么我们可能会从内部开始并努力出路。无论哪种方式，从底部开始工作的旧逻辑仍然存在。
电线中的耳语
从第一天开始，我们就会从物理层进行故障排除。封装不会改变这一点，但确实给了我们另一个要考虑的维度。我们的故障排除是从最外层的协议模型开始的，还是从最内向开始并开始工作？这将在很大程度上取决于问题的范围。与往常一样，这些模型可以帮助我们提出参考点，但是该过程本身将根据情况有所不同。
我们都听说人们说OSI模型不再重要。在某些方面，这可能是正确的。对于故障排除，它仍然可以作为模型。我们只需要立即递归应用。
阅读我的其他博客
审核安全网络流量的矛盾要求
