Deploying End-to-End QoS部署端對端 QoS

To facilitate true end-to-end QoS on an IP network, a QoS policy must be deployed in the campus network and the WAN. Each network segment has specific QoS policy requirements and associated best practices. When the enterprise uses a service provider network that provides Layer 3 transport, end-to-end QoS requires close coordination between the QoS policy of the enterprise and of the service provider. Designing and testing QoS policies is just one step in the overall QoS deployment methodology in the Enterprise environment.

要在 IP 網路上實現真正的端對端 QoS，必須在校園網路與 WAN 中都部署 QoS 政策。每個網路區段都有其特定的 QoS 政策需求及相關最佳實務。當企業使用提供第 3 層傳輸的服務供應商網路時，端對端 QoS 需要企業的 QoS 政策與服務供應商的 QoS 政策緊密協調。在企業環境整體 QoS 部署方法論中，設計與測試 QoS 政策只是其中一個步驟。

Deploying QoS in an enterprise is a multistep process that is repeated as the business requirements of the enterprise change.

在企業中部署 QoS 是一個多步驟的流程，且會隨著企業業務需求的改變而重複進行。

A successful QoS policy deployment requires a clear definition of the business objectives that the enterprise wants to achieve with the QoS implementation. Interview business stakeholders to identify their business-critical applications and to understand the service-level requirements of these applications as implemented in the enterprise. It is also crucial to have executive approval of the QoS policy to ensure that the QoS policy aligns with the overall strategy of the organization. Once a good understanding of the service-level requirements for the critical business applications is understood and executive approval of the proposed policy is in place, a detailed policy can be created and tested. Once tested, the policy can be rolled out across the entire enterprise network. The policy and performance of the business-critical applications should be constantly monitored to ensure that the QoS objectives are being met.

要成功部署 QoS 政策，需要清楚定義企業希望透過 QoS 實作達成的業務目標。應與業務利害關係人面談，找出他們業務關鍵的應用程式，並了解這些應用程式在企業中實作時的服務等級需求。取得高階主管對 QoS 政策的核准也非常重要，以確保 QoS 政策與組織整體策略一致。一旦充分了解關鍵業務應用程式的服務等級需求，並取得對所提議政策的高階核准後，就可以建立並測試詳細的政策。測試完成後，該政策就可以推行到整個企業網路。應持續監控業務關鍵應用程式的政策與效能，以確保達成 QoS 目標。

These phases need to be repeated as business conditions evolve.

隨著業務條件的演變，這些階段需要重複進行。

A QoS policy is only as strong as the weakest point in the network. If VoIP or video traffic experiences packet loss or jitter at any point in the network, the user experience will be noticeably impacted. In order to provide QoS guarantees, an end-to-end QoS deployment is required that covers traffic from endpoint to endpoint across the entire network path. The rapid rise of highly sensitive collaboration traffic has made it even more critical to ensure that QoS is not only deployed on the WAN, where congestion on low-speed links was the typical cause of poor application performance, but also in the high-speed campus environment.

QoS 政策的強度取決於網路中最薄弱的環節。若 VoIP 或視訊流量在網路的任何一點發生封包遺失或抖動，都會明顯影響使用者體驗。為了提供 QoS 保證，需要部署涵蓋整個網路路徑（從端點到端點）流量的端對端 QoS。隨著高敏感度協作流量迅速增加，確保 QoS 不只部署在 WAN（低速鏈路的壅塞過去是應用程式效能不佳的典型原因），也部署在高速校園環境中，就變得更加關鍵。

Although network administrators sometimes equate QoS only with queuing, the QoS toolset extends considerably beyond queuing tools. Classification, marking, and policing are all important QoS functions that are optimally performed within the campus network, particularly at the access layer ingress edge (the access edge).

雖然網路管理員有時只把 QoS 等同於佇列，但 QoS 工具集所涵蓋的範圍遠超過佇列工具。分類、標記與管制都是重要的 QoS 功能，最適合在校園網路中執行，特別是在存取層的入向邊緣（存取邊緣）。

Classifying and marking applications as close to their sources as technically and administratively possible enables end-to-end DiffServ PHBs. Sometimes endpoints can be trusted to set CoS or DSCP markings correctly, but this is not recommended because users can easily abuse provisioned QoS policies if they are permitted to mark their own traffic. For example, if DSCP EF received priority services throughout the enterprise, users could easily configure the NIC on a PC to mark all traffic to DSCP EF, thus hijacking network priority queues to service their nonreal-time traffic. Such abuse could easily ruin the service quality of real-time applications, such as VoIP, throughout the enterprise. For this reason, the phrase "as close as ... administratively feasible" is included in the design principle.

在技術與管理上可行的前提下，盡可能靠近來源對應用程式進行分類與標記，可實現端對端的 DiffServ PHB。有時候可以信任端點正確設定 CoS 或 DSCP 標記，但並不建議這麼做，因為若允許使用者標記自己的流量，很容易濫用已部署的 QoS 政策。舉例來說，如果 DSCP EF 在整個企業中都能獲得優先服務，使用者可能會輕易在 PC 的網路卡上設定將所有流量都標記為 DSCP EF，藉此挾持網路優先佇列來服務他們的非即時流量。這種濫用很容易破壞整個企業中即時應用程式（例如 VoIP）的服務品質。因此，此設計原則中才會包含「在管理上盡可能靠近」這樣的措辭。

There is little sense in forwarding unwanted traffic only to police and drop it at a subsequent node, especially when the unwanted traffic is the result of attacks, such as when the attackers flood the victim with a high volume of packets or connections overwhelming the network. Such attacks can cause network outages by overwhelming network device processors with traffic.

把不需要的流量轉送到下一個節點才進行管制並丟棄，幾乎沒有意義，特別是當這些不需要的流量是攻擊所造成時，例如攻擊者以大量封包或連線灌爆受害者、使網路不堪負荷。這類攻擊可能會以大量流量壓垮網路裝置的處理器，進而造成網路中斷。

Always perform QoS in hardware rather than software when a choice exists. Cisco IOS routers perform QoS in software. This situation places additional demands on the CPU, depending on the complexity and functionality of the policy. Cisco Catalyst switches, on the other hand, perform QoS in dedicated hardware ASICs and therefore do not tax their main CPUs to administer QoS policies. You can therefore apply complex QoS policies at 1 Gigabit, 10 Gigabit, 25 Gigabit or 40 Gigabit Ethernet line speeds in these switches.

只要有選擇，就一律以硬體而非軟體執行 QoS。Cisco IOS 路由器是以軟體方式執行 QoS，視政策的複雜度與功能而定，這會對 CPU 造成額外負擔。相對地，Cisco Catalyst 交換器則是在專用的硬體 ASIC 中執行 QoS，因此不會佔用主 CPU 資源來管理 QoS 政策。因此，您可以在這些交換器上以 1 Gigabit、10 Gigabit、25 Gigabit 或 40 Gigabit 乙太網路線速套用複雜的 QoS 政策。

Most campus links are underutilized. Some studies have shown that 95 percent of campus access layer links are utilized at less than 5 percent of their capacity. This underutilization means that you can design campus networks to accommodate oversubscription between access, distribution, and core layers. Oversubscription allows for uplinks to be utilized more efficiently, and more importantly, it reduces the overall cost of building the campus network. Common campus oversubscription values are 20:1 for the access-to-distribution layers and 4:1 for the distribution-to-core layers.

大多數校園鏈路的使用率都偏低。有研究顯示，95% 的校園存取層鏈路使用率不到其容量的 5%。這種低使用率意味著您可以在設計校園網路時，讓存取層、分佈層與核心層之間採用超額訂閱（oversubscription）。超額訂閱可以讓上行鏈路獲得更有效率的運用，更重要的是能降低建置校園網路的整體成本。常見的校園超額訂閱比例為存取層到分佈層 20:1、分佈層到核心層 4:1。

It is quite rare, under normal operating conditions, for campus networks to suffer congestion. If congestion does occur, it is usually momentary and not sustained, as at a WAN edge. However, these short moments of congestion can lead to packet loss due to instantaneous buffer overload on these high-speed links.

在正常運作條件下，校園網路發生壅塞的情形相當罕見。如果真的發生壅塞，通常也只是短暫的，不像 WAN 邊緣那樣持續發生。不過，這些短暫的壅塞時刻仍可能因為這些高速鏈路上瞬間的緩衝區超載而造成封包遺失。

The only way to provide service guarantees is to enable queuing at any node that has the potential for congestion, regardless of how rarely this congestion may actually occur. The potential for congestion exists in campus uplinks because of oversubscription ratios and speed mismatches in campus downlinks (for example, Gigabit Ethernet to Fast Ethernet links).

提供服務保證的唯一方法，就是在任何可能發生壅塞的節點上啟用佇列，無論這種壅塞實際發生的機率有多低。由於校園上行鏈路存在超額訂閱比例，以及校園下行鏈路存在速度不匹配的情況（例如 Gigabit Ethernet 對 Fast Ethernet 鏈路），因此仍有發生壅塞的可能性。

Queuing helps to meet network requirements under normal operating conditions, but enabling QoS within the campus is even more critical under abnormal network conditions. During such conditions, network traffic may increase exponentially until links are fully utilized. Without QoS, the attack-generated traffic drowns out applications and causes denial of service through unavailability. Enabling QoS policies within the campus maintains network availability by protecting and servicing critical applications such as VoIP, video, and even best-effort traffic.

佇列有助於在正常運作條件下滿足網路需求，但在異常網路狀況下，於校園內啟用 QoS 更是格外重要。在這類狀況下，網路流量可能會呈指數增長，直到鏈路完全被佔滿為止。若沒有 QoS，攻擊產生的流量會淹沒應用程式，並因無法使用而造成阻斷服務。在校園內啟用 QoS 政策，可透過保護並服務關鍵應用程式（例如 VoIP、視訊，甚至盡力服務流量）來維持網路可用性。