Learning IOS and JUNOS

資料來源: 中关村网友社区 http://www.newzgc.com/bbs/ 有時候彈出應用程式:........- 應用程式錯誤: "0x......." 指令引用的 "0x........" 記憶體。該記憶體不能為 "written"或read 也可以在運行中輸入CMD 在用命令:for %1 in (%windir%\system32\*.dll) do regsvr32.exe /s %1註冊下所有的dll.也許可以幫你解決問題.Windows XP的“體重”比起其它系統，已經成為一個不折不扣的“大胖子”。各優化“瘦身”技巧早已佈滿各大IT報刊雜誌，望著Windows XP的“Windows”成百上千的DLL（動態連結程式庫）檔，為使系統更清爽，我們可以通過regsvr32.exe程式重新註冊修復和反註冊遮罩系統功能，以減少系統資源。很多朋友都用過Windows系統下提供的regsvr32.exe這個命令。不要瞧不起這個小命令。有時候它可能幫你解決大問題。 一、輕鬆修復IE流覽器 很多經常上網的朋友都有過這樣的經歷：IE不能打開任何新的視窗，。用滑鼠點擊超聯接也沒有任何的反應。這是一般情況下需要重新開機機器或者重新安裝IE就能解決問題。其實根本沒這麼 麻煩，使用regsvr32.exe命令就可以輕鬆搞定。在開始---運行裡輸入“regsvr32.exe actxprxy.dll”回車 確定；再次輸入運行Regsvr32.exe shdocvw.dll”回車。重新開機電腦後IE被輕鬆修復。上網一切正常如初。 二、解決windows無法線上升級的問題 windows漏洞很多。每隔一段時間都需要使用windows update來升級自己的系統。可這個程式總是出現無法使用的情況。這個時候使用regsvr32.exe有可以幫助我們解決這個問題。開始---運行--輸入regsvr32.exe wupdinfo.dll回車。這是系統重新註冊了UPDATE的元件。重新開機機器後有可以升級你的系統。 三、卸載 WIN XP中的雞肋功能 XP系統中有的服務不僅佔用系統資源嚴重，而且功能要強不強，要弱不弱。根本不如一些專業的軟體來的方便。比如它的圖片予覽功能和ZIP壓縮功能。這個時候我們就可以使用regsvr32.e

◎Weighted Round Robin(WRR) 佇列調度將每個interface分為多個輸出佇列，佇列之間輪流調度，保證每個佇列都得到一定的服務時間，WRR可為每個佇列配置一個加權值(依次為W3、W2、W1、W0)，加權值表示獲取資源的比重。 如一個FE interface，配置它的WRR佇列調度算法的加權值為50、30、10、10(依次對應W3、W2、W1、W0)，這樣可以保證最低優先等級佇列至少獲得10Mbits/sec頻寬，避免了採用PQ調度時低優先等級佇列中的封包可能長時間得不到服務的缺點。WRR佇列還有一個優點是，雖然多個佇列的調度是輪番進行的，但是對每個佇列不是固定地分配服務時間片段 - 如果某個佇列為空，那麼馬上換到下一個佇列調度，這樣頻寬資源可以得到充份的利用。 (借錢不還) ◎Deficit Round Robin(DRR) Deficit Round Robin 機制與 WRR 相似，但可適合不同封包長度的應用，並解決了一些WRR頻寬分配不準確的問題(byte count and MTU ratio過大或過小)。DRR 也是和 WRR 一樣去掃瞄每一個有封包的佇列，只不過每次服務固定的 byte count，如果有剩下的byte count，則會被紀錄起來，等待下次再輪到這個佇列時還可使用。 (有借有還) ◎Modified Deficit Round Robin(MDRR) 當我們使用MDRR當成佇列策略時，非空的佇列會以輪流的方式(round-robin fashion)被一個接著一個被服務(發送出去)。每當一個佇列被服務時，一個固定數量的資料從佇列中被送出離開。這個演算法接著再去服務下一個佇列。當某佇列被服務時，MDRR會將被送出佇列的資料位元超出所設定數值的數量記錄下來。下一次，當該佇列被再度服務時，較少的資料會被送出佇列用以補償之前服務超過的資料數量。最後，每個佇列被送出的平均資料數量將會趨近於所設定的數值。附帶一說，MDRR中擁有一個可以被優先服務的優先佇列(Priority Queue)。 在每個MDRR的佇列中定義了兩個變數： Quantum value – 這是每一輪被服務的平均位元數量。 Deficit counter – 這是用來紀錄每一輪中各佇列被傳送出去的位元數量。初始值等於Quantum value。 只要Def

◎Behavior Aggreagate(BA) DiffServ把基於相同PHB轉發的同一群組封包稱為行為聚集(Behavior Aggregate, BA)。每一種DSCP數值可辨識一種BA。 ◎(Per-Hop-Behavior, PHB) DiffServ將重點放在資料流匯集以及適用於整個網路服務等級的"逐跳行為(PHB)"上。我們可以根據預先確定的規則對資料流進行分類，進而將多種應用資料流匯集成有限的幾種資料流等級。核心路由器在調度轉發IP封包時以資料流匯集為服務對象，根據IP封包表頭不同的DSCP提供不同的轉發服務QoS，這種對不同類型的數據封包進行轉發的方式，稱為"逐跳行為"(Per-Hop-Behavior, PHB)，實際上是一種相對優先等級機制。

RSVP supports the following messages: 1. Path message(PATH): An RSVP path message is sent by each sender along the unicast or multicast routes provided by the routing protocol. A path message is used to store the path state in each node. The path state is used to route reservation-request messages in the reverse direction. 2. Reservation-request message(RESV): A reservation-request message is sent by each receiver host toward the senders. This message follows in reverse the routes that the data packets use, all the way to the sender hosts. A reservation-request message must be delivered to the sender hosts so that the hosts can set up appropriate traffic-control parameters for the first hop. RSVP does not send any positive acknowledge messages. "Each Reservation is Unidirectional" 3. Error and confirmation messages: Reservation-request acknowledgment messages are sent as the result of the appearance of a reservation-confirmation object in a reservation-request messa

參考資料：http://www.iii.org.tw/ncl/document/Qos_web.htm IntServ架構 在IntServ網路中，使用者必須透過RSVP通訊協定來宣告封包流 (packet flow，即一串具有相同來源與目的地之IP位址與port numbers的封包) 的特性 (透過PATH訊息之Tspec參數)以及作頻寬保留 (透過RESV訊息之Rspec參數)。路徑上的所有路由器都必須處理這些RSVP訊息，包括了記錄PATH訊息的路徑、參數，以及依據RESV訊息之參數和路由器資源與link頻寬使用的狀況對使用者要求之頻寬或服務執行允入控制 (admission control)。除了RSVP協定訊息之外，路由器還必須對每一封包執行Multi-Field (MF) calssification以辨識封包流，並對每一封包流執行policing與scheduling。換言之，在IntServ的架構裡，無論是core或edge路由器都必須要能夠辨識、記錄、並且管控每一封包流的狀態。如此一來，隨著網路的逐漸擴張，封包流大量增加，無論是在儲存設備或是處理速度方面對於路由器而言都是一大挑戰，這就是IntServ一直為人所詬病的scalability問題。 IntServ架構提供了定量 (quantitative) 與定性 (qualitative) 兩類服務品質保障 (當然，還有best-effort)，它們分別是Guaranteed 以及Controlled Load。 Guaranteed Service 提供嚴格的封包延遲與流失量保證，而 Controlled Load Service 則提供比較級的服務品質 – “Best-effort over uncongested network”，而無定量的保證。 DiffServ架構 DiffServ架構的精神在於它設法簡化core routers的複雜度，盡量將複雜的允入控制交由Bandwidth Broker負責、封包辨識工作交由edge routers負責，並且不提供per-flow QoS，而以比較粗略的per-class QoS取代。 在DiffServ架構中，一個DiffServ Domain可以是一ISP或一企業網路，DiffServ Domain與其使用者之

參考資料： BDCOM QoS技术 依照我們常見的Queueing(佇列)技術，我們來一一介紹並且比較它們之間的差異性： 1. FIFO(Fist-In/Fist-Out Queue) 它不對Packet進行分類，當封包進入interface的速度大於interface的傳送速度時，FIFO按照封包到達interface的先後順序讓封包進入佇列，同時，在佇列的出口讓封包按照進入佇列的順序離開佇列。 2. PQ(Priority Queue) 將所有的Packet依據預先配置分成最多四類(High/Medium/Normal/Low)，按照FIFO的方式分別進入四個優先等級不同的佇列。在封包離開佇列時，高優先等級的的佇列相對於較低優先等級的佇列具有絕對的優先權，等到高優先等級的佇列封包傳送完畢之後，較低優先等級的佇列才可以傳送封包出去，而且較低優先等級的封包在發生擁塞時會被較高優先等級的封包搶佔資源。因此採用這種佇列機制可以保證在網路發生擁塞的情況下，重要服務(設定成高優先等級)的數據傳輸可以得到絕對的優先傳送。但是如果較高優先等級的封包傳送速度總是大於interface的速度時，會使得較低優先等級的封包始終得不到發送的機會。 PQ是一種沒有量化的QoS/DiffServ服務，只定義了預先規定的高優先等級封包擁有優先轉發的權利，甚至有可能會導致較低優先等級的封包永遠沒有機會傳送出去。 3. CQ(Custom Queue) 根據設置將所有封包分成最多16類(Queue 1~16)，然後按照FIFO的方式分別進入1個系統佇列(System Queue, Queue 0)和16個用戶佇列(Custom Queue, Queue 1~16)。在封包離開佇列的調度上，系統佇列具有絕對的優先權，系統總是先處理完該佇列後再處理用戶佇列(CQ)；16個用戶佇列佔用出口頻寬的比例可以調整，CQ按照定義的比例使得各個佇列之間在佔用的interface頻寬上滿足管理者預先設置的比例關係。當擁塞發生時，CQ可以根據比例保持不同服務獲得相對應的頻寬使用，進而保證重要服務能夠獲得較多的頻寬，又不至於使得非重要服務無法得到頻寬(避免類似使用PQ時可能發生的問題)。 CQ是為了避免PQ在擁塞時，所有較低優先等級的流量資料都無法傳送的問題而發展出來的。 4. WFQ(Weighted Fair Qu