Learning IOS and JUNOS

Juniper CLI learning is a little challenge for junior network engineers or Cisco IOS engineers, because the JUNOS modular and hierarchical structure design. Some features may need several command line which were configured under different hierarchical levels, then combined all of them together in another hierarchical level. Such kind of CLI design especially not easy to learn when apply CoS on juniper device.(I believe many Cisco IOS engineers don't want to switch to JUNOS because of this...) As above figure is my understanding about the related JUNOS command which is using in our production network.

Customer Edge QoS Design Considerations In addition to the full-mesh implication of MPLS VPNs, these considerations should be kept in mind when considering MPLS VPN CE QoS design: Layer 2 access (link-specific) QoS design Service-provider service-level agreements (SLA) Enterprise-to-service provider mapping models http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/VPNQoS.pdf

Call-Signaling Traffic The following are key QoS requirements and recommendations for Call-Signaling traffic: • Call-Signaling  traffic should be marked as  DSCP CS3  per the QoS Baseline (during migration, it may also be marked the legacy value of DSCP AF31). • 150 bps  (plus Layer 2 overhead) per phone of  guaranteed bandwidth  is required for voice control traffic; more may be required, depending on the call signaling protocol(s) in use. Call-Signaling traffic was originally marked by Cisco IP Telephony equipment to DSCP AF31. However, the Assured Forwarding classes, as defined in RFC 2597, were intended for flows that could be subject to markdown and - subsequently - the aggressive dropping of marked-down values. Marking down and aggressively dropping Call-Signaling could result in noticeable delay-to-dial-tone (DDT) and lengthy call setup times, both of which generally translate to poor user experiences. The QoS Baseline changed the ma...

Frame Relay Dual-FIFO On the low-end router non-distributed platforms (Cisco 7200 and lower), Frame Relay employs a dual-FIFO queuing technique that automatically is invoked at the interface level when FRF.12 is configured. FRF.12 depends on Frame Relay traffic shaping (FRTS) or class-based FRTS being enabled. In a Frame Relay environment, the Tx-ring does not directly provide back pressure to the Layer 3 queuing algorithm. Instead, when the Tx-ring is full, it provides back pressure to the shaper (FRTS or CB-FRTS), which, in turn, signals the Layer 3 queuing system (LLQ) to engage. Because the FRTS mechanism does not take into account Frame Relay headers and cyclic redundancy checks (CRCs) in its calculations, it generally is recommended that you shape to 95 percent of CIR on Frame Relay circuits up to T1/E1 speeds. This, in turn, engages the LLQ algorithm slightly earlier and improves performance for real-time traffic. Traffic from each PQ for each DLCI is funneled into the hi...

在Cisco QoS 2.3課程中的ECN(Explicit Congestion Notification)的章節中第一次談到了ECN-Echo(ECE)，透過ECE(注意，這個欄位不在ToS中，而是在TCP header中的flag之一)可以通知對方放慢傳送的速度。當另一方收到ECE時，會減少它的congestion windows來放慢傳輸速率。然後在第一個封包中設置TCP header flag(CWR, Congestion Window Reduced)，用來通知原先發送ECE的那一方已經減少windows size並且放慢了傳輸速率． TCP 中的 ECN 支援 當路由器將 IP 封包的 ECN 欄位設定為 11 時，接收端 (而不是傳送端) 就會接到路徑中擁塞的通知。ECN 使用 TCP 標頭向傳送端指出網路正遇到擁塞狀況，同時向接收端指出傳送端已經從接收端接到擁塞指標，並且降低傳輸速率。 TCP 中的 ECN 支援使用 TCP 標頭中的兩個未使用位元 (先前定義為保留)。為 ECN 支援定義的兩個新旗標如下所示： • ECE  ECN-Echo (ECE) 旗標是用來指出，在 TCP 三方信號交換程序期間，TCP 對等體具備 ECN 功能，並指出 ECN 欄位在 IP 標頭中設定為 11 的連線上接到 TCP 區段。如需有關 TCP 三方信號交換程序的資訊，請參閱 RFC 793。 • CWR  Congestion Window Reduced (CWR) 旗標是由傳送主機設定，指出已接到設定 ECE 旗標的 TCP 區段。擁塞視窗是由 TCP 維護的內部變數，可管理傳送視窗的大小。 [圖 2] 顯示 TCP 標頭中 ECE 和 CWR 旗標相對於其它旗標的位置。如需有關 TCP 標頭中其它旗標的資訊，請參閱 RFC 793。 圖 2：TCP 標頭中的 ECE 和 CWR 旗標 觀看完整大小的影像 當兩個具備 ECN 功能的 TCP 對等體建立 TCP 連線時，它們交換 Synchronize (SYN)、SYN-Acknowledgement (SYN-ACK) 和 ACK 區段。SYN 區段已經針對具備 ECN 功能的 TCP 對等體同時設定 ECE 和 CWR 旗標；但是 SYN-ACK 區段則是設定...

While most of the previous research has focused on providing Quality of Service (QoS) on a per session basis, there is a growing need to also support hierarchical link-sharing, or QoS guarantees for traffic aggregate (such as those belonging to the same organization, service provider, or application family). Supporting QoS for both single sessions and traffic aggregates is difficult as it requires the network to meet multiple QoS requirements at different granularities simultaneously. This problem is exacerbated by the fact that there are no formal models that specify all the requirements. We have developed an idealized model that is the first to simultaneously capture the requirements of the three important services in an integrated services computer network: guaranteed real-time, adaptive best-effort, and hierarchical link-sharing services. We then designed two hierarchical scheduling algorithms, Hierarchical Packet Fair Queueing (H-PFQ) and Hierarchical Fair Service Curve (H-FSC)....

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

在舊版的QoS 2.2中只有提到WRR(Weighted Round Robin)，但是在實務中，SRR已經漸漸在愈來愈多的Switch平台中使用，其中WRR與SRR最大的差別就是在於它們同時使用權重但是Scheduling的方式不同。 以下圖而言(暫不考慮Strict Priority Queue)，如果是用WRR的話，Queue 3的權重為4，所以每一輪都可以同時送出4個封包；Queue 2的權重為2，所以每一輪都可以同時送出2個封包；Queue 1的權重為1，所以每一次都可以同時送出1個封包。 如果是用SRR(Shared or Shaped Round Robin)的話，Queue 3的權重為4，Queue 2的權重為2，Queue 1的權重為1。因此Q3,Q2,Q1各出1個封包，接著Q3,Q2各出1個封包，再接著Q3出2個封包，這樣子才算是一輪。 所以SRR的好處在於每一個Queue很平均地送出封包前後穿插進入FIFO Queue(Hardware Queue)，而不是像WRR那樣一次出清每個Queue權重所佔比例數量的封包，這樣子下來的結果會讓不同Queue中的封包排程更加smooth，不會互相排擠。 SRR is a scheduling service for specifying the rate at which packets are dequeued. With SRR there are two modes, Shaped and Shared (default). Shaped mode is only available on the egress queues. Shaped egress queues reserve a set of port bandwidth and then send evenly spaced packets as per the reservation. Shared egress queues are also guaranteed a configured share of bandwidth, but do not reserve the bandwidth. That is, in Shared mode, if a higher priority queue is empty, instead...

在QoS 2.2 P.7-43中有一段敘述，告訴我們在Traffic Shaping中Bc, Be的預設值建議由Cisco IOS自動計算它們的最佳數值(與Policing不同，Police預設是Bc=1500 bytes或CIR/32，由這兩個數值中挑選最大值當Bc)，所以經過一些實驗及資料的查詢，終於整理出以下規則供各位參考： 指令如下： shape {average peak} CIR [Bc] [Be] (1) If line rate Bc=8000 bits , Be=Bc=8000 bits (2) If line rate > 320kbps, Tc=25ms , Bc=CIR*Tc, Be=Bc=CIR*Tc

在QoS 2.2 Vol.2 P.7-72的slide中出現了一段"Bc to minCIR / 100"的內容，我翻遍了整本教材也完全沒有提到這個公式的由來，所以我特地去翻了一下Cisco官網的內容，後來在以下網址中找到一段相關的敘述，原來是Cisco IOS在PVC上為了因應Voice的特性因此選定Tc = 10ms，避免過大的延遲。 Configuring Frame Relay Traffic Shaping on 7200 Routers and Lower Platforms Configurable Parameters frame relay cir The average rate you want to send traffic out on a given PVC in bps. This is generally higher than the guaranteed rate but less than the access rate (AR). It equals the guaranteed rate only if: The service provider does not allow you to send above guaranteed rate. The physical line rate on the interface is same as the guaranteed rate. There are Voice (voice over IP [VOIP] or voice over Frame Relay [VOFR]) packets on this PVC, therefore you cannot afford dropped packets for quality or service. The value of the CIR is 56000 bps is by default. frame relay mincir The actual guaranteed rate obtained from service provider in bps. This value should be the minimum rate you should dr...

• Autonomous switching With this type of switching, an incoming packet matches an entry in the autonomous-switching cache located on the interface processor. Autonomous switching provides faster packet switching by allowing the ciscoBus controller to switch packets independently without having to interrupt the system processor. It is available only on Cisco 7000 series routers and in AGS+ systems with high-speed network controller cards. • SSE switching.  With this type of switching, an incoming packet matches an entry in the silicon-switching cache located in the silicon switching engine (SSE) of the Silicon Switch Processor (SSP) module. This module is available only on Cisco 7000 series routers. Silicon switching provides very fast, dedicated packet switching by allowing the SSE to switch packets independently without having to interrupt the system processor. 

Citrix Systems, Inc.  為實現全球接入架構解決方案提供優秀的 軟體 與服務，並在該領域內居全球領導地位，其解決方案能夠讓客戶在任何時間、任何地點、在任何設備上，通過任何形式的 網路 連接，高效獲取各種應用、 信息 及通訊。 Citrix 技術使得數位辦公室無處不在，令工作輕鬆易行。通過與世界一流的業界夥伴的攜手合作， Citrix 解決方案為企業級用戶實現應用發佈、遠端存取、移動辦公以及業務一致性等卓越功能，説明客戶利用現有的資訊資源，擴展至任意節點，為員工、業務夥伴、客戶與供應商分別設計個性化應用訪問服務，極大提升企業的IT投資回報和生產效率。 Citrix 以代號 CTXS 於 Nasdaq Stock MarketSM 上市，並獲列入標準普爾 500 指數。 2001 財年公司總收益為 5.92 億美元。 Citrix 總部設於美國佛羅里達州 Fort Lauderdale 。有關該公司其他資料，請流覽其網站 http://www.citrix.com 。  1999 年 Citrix 公司獲得《福布斯 ASAP 》雜誌評選的 “ 全美最具活力的軟體公司 ” 稱號 在《財富》 “ 發展最快的 100 家公司 ” 概要中排名第 27 位 2001 年 Citrix MetaFrame 被評為歐洲財富 500 強企業首選的十大軟體之一，並在 Gartner Midsize Enterprise Summit 中獲 “ 卓越科技大獎 ” 2001 年 Citrix NFuse 獲得由 Open Systems Advisors 頒發的 CrossRoad A 類大獎中 “ 最佳企業網站入門產品 ” 連續 4 年名列 Deloitte&Touche 的 “Fast 500” ，成為美國 500 家發展最快的科技公司之一 迄今全球已有近十五萬家用戶採用了 Citrix 解決方案，享受到 ICA 技術的用戶端更超過五千萬，其中包括世界財富 500 強中 99% 以上的集團，以及歐洲財經時代 500 強中 75% 以上的公司， Citrix 憑藉其卓越的技術方案和業務成就，贏得了業界與用戶的廣泛讚譽。 Citrix ICA 英文全名為 Independent Computing Architecture ，翻譯為獨立計算結構。 ...

很多人在學習QoS LLQ & CBWFQ的時候，遇到了頻寬保留分配問題都會有一些不太確定的感覺，因為Cisco在課程中並沒有非常詳細的說明不同的指令參數之間的搭配，會得到什麼樣的後果，所以我把這個問題在這邊提出來(這要感謝課堂上的同學問我這個問題，也順便釐清了這個不確定因素)。 假設我們現在在P1R1上有一路Serial頻寬為512k，現在我們要進行頻寬分配，分配的條件如下： Class TEST1使用LLQ(10%) Class TEST2使用CBWFQ剩下可用頻寬的(30%) Class TEST3使用CBWFQ剩下可用頻寬的(20%) 這個問題看似簡單，但是如果從來沒有認真去注意到的話就可以會有不同的解讀，到底TEST3可以使用多少的保留頻寬? 正確答案是： Class TEST1 LLQ使用頻寬上限=512k * 10%=51.2k Class TEST2 CBWFQ保留頻寬 = [(512k * 75%預設最大可分配的頻寬) - 51.2k] * 30% Class TEST3 CBWFQ保留頻寬 = [(512k * 75%預設最大可分配的頻寬) - 51.2k] * 20% 也就是說最後所有使用bandwidth percent remaining指令的總和不得超過100% 還有一點很重要的是，在這邊所謂的remaining並非指interface上現在實際流量的剩餘頻寬，Cisco QoS的指令在MQC中沒有這麼厲害可以隨時去監控現行使用流量來進行等比例的動態保留(maybe in the future) 為了證明真的是這個樣子，我進行了以下的實驗： P1R1(config)#policy-map TEST P1R1(config-pmap)#class TEST1 P1R1(config-pmap-c)#priority percent 10 P1R1(config-pmap-c)#class TEST2 P1R1(config-pmap-c)#bandwidth remaining percent 30 P1R1(config-pmap-c)#class TEST3 P1R1(config-pmap-c)#bandwidth remaining percent 80 Sum total of class bandwidths excee...

The  qos pre-classify  mechanism allows Cisco routers to make a copy of the inner IP header and to run a QoS classification before encryption based on fields in the inner IP header. Without this feature, the classification engine sees only a single encrypted and tunneled flow since all packets that traverse across the same tunnel have the same tunnel header and receive the same treatment in the event of congestion. If your classification policy matches with the ToS byte, you do not need to use the  qos pre-classify  command since the ToS value is copied to the outer header by default. You can create a simple QoS policy which sorts traffic into classes based on IP precedence. However, to differentiate traffic within a class and to separate it into multiple flow-based queues, the  qos pre-classify  command is required. Note:  ToS byte copying is done by the tunneling mechanism and not by the  qos pre-classify  command. The  qos pre-classify  command can be applied at various points in yo...

Serialization Delay = frame size (bits) / link bandwidth (bits per second [bps]) 在QoS中我們可以利用LLQ(Low Latency Queueing)來提供VoIP封包低延遲(delay)及減少抖動(jitter)發生的情況。雖然VoIP封包總是傳送到software queue的前端，serialization delay(Layer 2 Frame encoded into Layer 1 Bits)的問題仍無可避免。一個大型封包可能正在hardware queue中使用FIFO。當VoIP封包被傳送至software queue的前端，在hardware transmit queue中的大型封包進行serialization時會導致VoIP封包必須等待一段較長的時間之後才能被傳送出去。 這時我們就可以使用fragment將大型封包切割成許多的小型封包，同時搭配interleaving的方式，將VoIP封包穿插在這些被切割之後的小型封包之間，藉此減少抖動(jitter)情況的發生。 當你在某鏈結上要設置適合的fragment size(切割尺寸)時，比較常見的目標是使得最大serialization delay維持在10~15ms之間。 假設實體連接埠線路速度為512Kpbs，所需要的serialization delay不應該超過10ms(記住，fragment size是根據實體連接埠線路速度而計算出來的!)，fragment size(切割尺寸)必須設定為： 512000(bps)/8*0.01(sec)=640 bytes 我們可以使用下列指令來進行設置： Router(config-if)# ppp multilink fragment 640 or Router(config-map-class)# frame-relay fragment 640 如果在Cisco IOS CLI上如果今天要使用的是fragment delay數值(milliseconds)，那就必須再乘上所使用的interface頻寬(假設MLPPP virtual-template上的頻寬為384Kbps)。 因此，我們使用virtual-template interface上的頻寬(384Kp...

在還沒有發明LLQ(Low Latency Queue)之前，我們要在interface上調整Voice RTP的保留頻寬，只能使用 Router(config-if)# ip rtp priority starting-rtp-port-number port-number-range bandwidth 設定完成之後，我們可以使用以下的指令來檢查我們的配置： Router# show queue interface-type interface-number 以下是Cisco官網上的說明： Feature Overview The IP RTP Priority feature provides a strict priority queueing scheme for delay-sensitive data such as voice. Voice traffic can be identified by its Real-Time Transport Protocol (RTP) port numbers and classified into a priority queue configured by the ip rtp priority command. The result is that voice is serviced as strict priority in preference to other nonvoice traffic. The IP RTP Priority feature extends and improves on the functionality offered by the ip rtp reserve command by allowing you to specify a range of User Datagram Protocol (UDP)/RTP ports whose traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the p...

假設我們要針對某個interface上的voice traffic使用LLQ設定保留頻寬，最大保留頻寬為512K，每一路語音保留頻寬為64K(per flow bandwidth reservation無法使用MQC來達成，勢必要使用RSVP的方式)，我們可以這樣設定： Router(config)# ip rsvp pq-profile ? Max Flow Rate (bytes/second) voice-like Voice-like flows <cr> Router(config)# ip rsvp pq-profile voice-like Router(config)# int s0/0 Router(config-if)# ip rsvp bandwidth ? Reservable Bandwidth(KBPS) <cr> Router(config-if)# ip rsvp bandwidth 512 ? Largest Reservable Flow(KBPS) <cr> Router(config-if)# ip rsvp bandwidth 512 64 <cr>

在Frame Relay網路中設定FRTS(Frame Relay Traffic Shaping)幾乎可以說是R/S, S/P共通的重點項目之一，比較特別的是要設定map-class。在面對這樣的題目最難的不是設定command，而是要了解題意內容的暗示(cisco不會主動告知你用何種方式，只會告知不可用特定方式來限制你的方向)。 (1)假設題目內容是要求你在frame-relay interface上設定限速10Mbps，但是如果有超過20個以上的封包被放進佇列中等待傳遞時，該路由器會改變限速上限為8Mbps。請參考以下設定： Router(config)#map-class frame-relay FRTS Router(config-map-class)#frame-relay cir 10000000 Router(config-map-class)#frame-relay mincir 8000000 Router(config-map-class)#frame-relay adaptive-shaping interface-congestion 20 ! Router(config)#interface serial0/0 Router(config-if)#frame-relay class FRTS Router(config-if)#frame-relay traffic-shaping (2)如果在相同的條件下，但是題目不允許你使用frame-relay traffic-shaping的指令怎麼辦呢? 這就是CCIE Lab最喜歡的考試方向，所以請務必在作Lab練習時一定要針對相同的題目給予不同的假設條件，然後自己問自己除了你所知道的解法之後還有沒有其他的解法? 另外一種方式那就是使用MQC的指令來設定Shaping(假設Tc=50ms)： Router(config)#policy-map FRTS Router(config-pmap)#class class-default Router(config-pmap-c)#shape average 10000000 500000 1000000 Router(config-pmap-c)#shape adaptive 8000000 ! Router(c...

MPLS DiffServ Short Pipe Model Egress PE !!! Egress interace: ! class-map TOS match ip precedence 2 4 ! policy-map TOS_OUT_QOS class TOS bandwidth percent 40 random-detect precedence-based ! interface ethernet 0/0 service-policy output TOS_OUT_QOS

MPLS DiffServ Pipe Model For the Pipe and Short Pipe DiffServ Model, however, the ingress PE can change the EXP bits according to the policy of the service provider. Egress PE !!! Ingress interface: ! class-map MPLS_EXP match mpls experimental topmost 2 4 ! policy-map EXP_IN_QOS_GROUP class MPLS_EXP set qos-group mpls experimental topmost ! interface ethernet 0/0 service-policy input EXP_IN_QOS_GROUP ! ! ! !!! Egress interface: ! class-map QOS_GROUP match qos-group 2 match qos-group 4 ! policy-map QOS_GROUP_OUT_QOS class QOS_GROUP bandwidth percent 40 random-detect ! interface ethernet 1/0 service-policy output QOS_GROUP_OUT_QOS