VOQ與CX Switch QoS與針對特定來源目的IP做頻寬限制

今天在思考一個案例，長期觀察，發現所有User會用的Edge Port都有TX Drop發生，IoT設備就沒有，兩者是不同的VLAN。

而所有介面都沒有RX Drop，也不是廣播風暴造成的。

由於到Server的骨幹全部都是10G以上，因此不對稱頻寬的網路，是有可能讓TX Drop發生在Edge Port上。

不過Uplink是雙線10G，也會出現TX Drop，穩定緩緩持續增加。

初步判斷是正常現象，本文更進一步研究如何處理。

Virtual Output Queue（VOQ）

封包經過查找之後，決定要從某一或是某些介面出去時，會將封包「直接」放入這些出口介面的VOQ，單個介面有八個VOQ，八個VOQ中可以作為緩衝，也對應著傳送的優先程度。

真正的出口佇列只有一個，VOQ透過Scheduler安排不同優先度封包進入，並等出口佇列送出。

可以想像，VOQ是入口佇列與出口佇列中間的過度。

VOQ的TX Drop

在預設之下，預設流量皆為Local Priority 1，來到Queue 1。

然而VOQ的緩存大小有限，並且隨著Switch機型往更高階提升，如Data Center的緩存更高，甚至有防掉包的機制。

因此在不替換設備前提之下，基本上VOQ的大小是無法調整，就要朝另外一個方法著手。

由於Q1的流量最大，但是VOQ的大小卻沒有相對應更高，因此若套用QoS，就能讓更重要的流量走Q3之類的。

藉此空出Q1，避免Q1短時大流量而丟包。

特定流量QoS

假設要往168.95.1.1的流量要優先一點，可以使用以下設定。

先建Class與Policy。

class ip test 
match ip any 168.95.1.1
exit

policy test
class ip test action local-priority 3
exit

然後將Policy放入指定介面或是全局套用。

==== 特定介面 ====
CX10000-LAB(config)# 
int 1/1/4
no apply policy test in
exit

==== 全局使用 ====
CX10000-LAB(config)# apply policy test in

QoS實測

使用特定電腦 Ping 168.95.1.1

由於VOQ的關係，命中Policy後，會直接在對應出口介面的佇列，local-priority 3預設對應Q3。

出口介面為1/1/48，使用「show int 1/1/48 queue」查看計數是否增加。

可以看到int 1/1/48的Q3增加。

特定來源目的IP做頻寬限制 – OpenSpeedtest

Client IP為 10.0.0.101，並接至int 1/1/1。
Server IP為 10.0.2.1，並接至int 1/1/4。

以下速率限制為100,000 kbps 即 100Mps。

class ip BW_LIMIT_ACL
  10 match any 10.0.0.101/32 10.0.2.1/32
  20 match any 10.0.2.1/32 10.0.0.101/32 
exit

policy BW_LIMIT_ACL
 10 class ip BW_LIMIT_ACL action cir kbps 100000 cbs 100000 exceed drop
exit

int 1/1/1
apply policy BW_LIMIT_ACL in
exit

int 1/1/4
apply policy BW_LIMIT_ACL in
exit

實測結果

非對稱頻寬丟包的幾個辦法

經過上述QoS實測，一針對特定流量給與更高優先的佇列，二針對特定來源目的做頻寬限制。

Flow Control是需要流量路徑沿路啟用，在跨防火牆的環境中，部署比較不方便。

透過特定流量對應更高佇列，可舒緩短時大量造成的背景佇列緩存壓力。

二可以透過QoS進行頻寬限制，超過頻寬造成Filter增加，而不是TX Drop。

三可以針對Edge Port設定頻寬限制，避免短時大量造成硬體與佇列無法處理，稍微降低一點，使用者不會察覺到，也可以讓Server早點踩煞車。

# 只有Engress方向才會有頻寬限制
int 1/1/1
qos shape 90 percent burst 128
exit