Switch QoS: Queuing on the 2950 platforms

今天在教QoS進行Lab設定時發現了一件事，那就是Cat.2950 Switch的AutoQoS產生的config竟然跟課本內容不相同(上次教學時還沒有發現這個問題)，因此上網找了一份資料供各位參考，原來是新版IOS修改了預設的template，因此會產生跟課本不一樣的結果，以下是我在網路上找到的一篇參考資料，內容寫得很詳實，可以讓各位更加了解wrr-queue的使用方式：


Dennis Hartmann

Switch QoS: Queuing on the 2950 platforms

By Dennis Hartmann on Thu, 06/11/09 - 4:53pm.http://www.networkworld.com/community/node/42627

The QoS SRND does a very good job of explaining the queuing configuration of the most popular switch platforms. I will discuss these switch platforms in this blog and the references section of this documents will include the direct links to the switch related queuing configuration section.

The 2950 EI (enhanced image) switch supports QoS, while the 2950 SI (standard image) does not. If the 2950 switch includes Gigabit Ethernet uplinks, the switch is an EI switch and supports QoS. The 2950 EI image does not include QoS support. QoS support is integrated in the hardware (ASIC) of the switch. An IOS upgrade will not bring QoS support to this switch. The 2950 supports a 1P3Q1T output only queuing architecture in which QoS processing is turned on by default. The 2950 is the only switch I know of that has QoS turned on by default. The 2950 has a 4 transmit (output) queue architecture with no WRED support. The queue architecture is represented as 4Q1T (4 queues, one threshold to drop traffic). The 1T nomenclature is very confusing because there are 6500 series line card that represent 1T as one threshold which congestion avoidance (WRED) will use to determine when the queue will drop lower priority traffic. The 4Q1T architecture of the 2950 switch can be converted to a 1P3Q1T architecture by turning on the priority queue (PQ). The priority queue on the 2950 is turned on differently based on the version of native IOS on the router.

Older versions of auto QoS performed the following configuration on the 2950 switch:

wrr-queue bandwidth 20 1 80 0
no wrr-queue cos-map
wrr-queue cos-map 1 0 1 2 4
wrr-queue cos-map 3 3 6 7
wrr-queue cos-map 4 5

The wrr-queue bandwidth command can be confusing because it looks like a long string of numbers. Each number relates to the amount of resources the weighted round robin (WRR) scheduler will associate with each queue. The bandwidth is carved up as follows during congestion:

Queue 1 - 20%
Queue 2 – 1%
Queue 3 – 80%
Queue 4 – 0 turns on the priority queue.

The numbers that appear in this command are not percentages. 20 represents the numerator in a fraction, while the denominator is the sum of all values used for all queues. If the sum of all the queues equal 100, each variable will represent a percentage. The priority (expedite) queue is a strict priority scheduler. The priority queue will be serviced until it is empty. The default CoS to queue mappings covered in an earlier blog is turned off with the no wrr-queue cos-map command. Each wrr-queue cos-map command relates one or more markings to a queue. The first number used in the string of numbers is the queue number, while each subsequent number represents the CoS value. Notice that no traffic was mapped to queue 2 in early versions of auto QoS.

Cisco IOS 12.1(20)EA2 generates a different auto qos policy that aligns to the current QoS SRND recommendations.

wrr-queue bandwidth 10 20 70 1
no wrr-queue cos-map
wrr-queue cos-map 1 0 1
wrr-queue cos-map 2 2 4
wrr-queue cos-map 3 3 6 7
wrr-queue cos-map 4 5

Notice that the newer version of autoqos use queue 2 and the nomenclature to turn queue 4 into a priority queue has changed. The value of 1 makes the configuration of the 2950 consistent with the other Cisco switch platforms.

In the next blog, I will explain the various recommended Cisco markings and continue the switch congestion management (queuing) conversation.

REFERENCES
2950 and 2955 QoS Configuration Guide - 12.1(20)EA2
http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/relea...

2950 and 2955 QoS Configuration Guide - 12.1(20)EA2
http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/relea...

Comments

Post a Comment

Popular posts from this blog

L2TPv3 Enables Layer 2 Services for IP Networks

Image
White Paper -------------------------------------------------------------------------------- Layer 2 Tunneling Protocol Version 3 Enables Layer 2 Services for IP Networks The competitive environment for service providers has changed considerably since the Internet became a global force in the 1990s. Enterprises are no longer signing up for new IP-based services for the novelty or out of fear of being left behind by the competition. The challenge for service providers today is to grow their businesses by expanding their customer base and service revenue in a more cautious spending environment. Most enterprises are taking a more conservative approach to network investments. New IP-based services give enterprises an opportunity to improve their productivity and competitiveness while lowering their existing network expenses. Service providers that offer these services and savings can grow their customer base and service revenue. This white paper focuses on one such opportunity—offering tra
Read More »

TCP/IP 明確擁塞通知 (ECN)

Image
當路由器擁塞的程度已經達到填滿傳入封包緩衝區而開始捨棄封包時，會影響網路而縮減頻寬，對資料損失敏感或具時效性的傳輸量流動會進而受到衝擊，而且可能在擁塞之後產生連結閒置時間。TCP/IP 明確擁塞通知 (ECN) 讓路由器能夠通知「傳輸控制通訊協定」(TCP) 對等體，由於網路擁塞，緩衝區已滿。TCP 對等體會以減緩資料傳輸來回應，協助防止封包損失。 明確擁塞通知(Explicit Congestion Notification) TCP/IP 的 ECN 支援同時使用 IP 及 TCP 標頭中的未使用位元。 • 在 (IP) 網際網路層上，轉送封包時，傳送主機必須能夠表示有能力執行 ECN，而路由器則必須能夠指出所遇到的擁塞狀況。 • 在 (TCP) 傳輸層，TCP 對等體必須彼此表明有能力執行 ECN。接收端對等體必須能夠通知傳送端對等體，已經從遇到擁塞狀況的路由器接到封包；傳送端對等體必須能夠通知接收端對等體，已經從接收端對等體接到擁塞指標，並且已經降低傳輸速率。 IP 中的 ECN 支援 IP 標頭中的 8 位元 [Type of Service (TOS)] 欄位最先定義於 RFC 791 中，指出封包由路由器進行非預設傳送的傳送優先順序、延遲、輸送量、可靠性，以及成本等特性。TOS 欄位在 RFC 2474 中重新定義，以包含 6 位元區別服務代碼點 (Differentiated Services Code Point, DSCP) 及兩個未使用的位元。DSCP 值表示的傳送優先順序會對應於先前在內部網路的路由器中設定的佇列。IP 中的 ECN 支援使用 RFC 2474 所定義 TOS 欄位的兩個未使用位元。[圖 1] 顯示 ECN 中 TOS 欄位的新定義。 圖 1：ECN 中 TOS 欄位的新定義 RFC 2474 所定義 TOS 欄位中的兩個未使用位元在 RFC 3168 中定義為 ECN 欄位，欄位的值如下： • 00 傳送主機不支援 ECN。 • 01 或 10 傳送主機支援 ECN。 • 11 路由器已遇到擁塞狀況。 具備 ECN 功能的主機傳送其封包時，會將 ECN 欄位設定為 01 或 10。對於具備 ECN 功能的主機所傳送的封包，如果路徑中的路由器具備 ECN 功能，但是正遇到擁塞狀況，則 ECN 欄位會設定為 11。一旦 ECN
Read More »

Q-in-Q(Dot1Q Tunnel) Sample Configuration

透過IEEE 802.1q in IEEE 802.1q(Q-in-Q)的方式，我們可以讓VLAN的數量增加超過4096(4096*4096)，也可以讓客戶自行設定Trunk穿過Service Provider所提供的Ethernet Solution(如：FTTx)。 假設現在的網路架構為： SW1 F0/1 <- SP VLAN 10 -> SW2 F0/1 兩端的設備都是連接到VLAN 10，因此在兩端的Switch啟用Dot1q Tunnel建立Trunk SW1(config)#vlan dot1q tag native !預設,Native VLAN不會加上tag,如果在Q-in-Q中要針對native vlan加tag，必須使用上述指令 SW1(config)#int f0/1 SW1(config-if)#switchport mode dot1q-tunnel SW1(config-if)#switchport access vlan 10 SW1(config)#system mtu 1508 !一般Switch預設system mtu 1500，為了支援多層tag，必須加大MTU，設定完成必須reload switch SW2(config)#vlan dot1q tag native !預設,Native VLAN不會加上tag,如果在Q-in-Q中要針對native vlan加tag，必須使用上述指令 SW2(config)#int f0/1 SW2(config-if)#switchport mode dot1q-tunnel SW2(config-if)#switchport access vlan 10 SW2(config)#system mtu 1508 !一般Switch預設system mtu 1500，為了支援多層tag，必須加大MTU，設定完成必須reload switch
Read More »