Các Codepoint Của Kiểu Lỗi Trong Các Gói Oam Fdi./bdi

Giả định tên của 3 LSP trong hình 2.5 là A, B, C. Ta có trong LSP A giữa LSR4 và LSR5 được chêm nhãn mức độ 1 (stack depth of one). LSP B từ LSR2 qua LSR3 và qua LSP A đến LSR6 chêm nhãn mức 2, và cuối cùng LSP C từ LSR1 qua LSP B qua LSR7 đến LSR8 chêm nhãn mức 3.

Xem xét một lỗi được phát hiện giữa LSR2 và LSR3. Điều này sẽ có các hệ quả (tầm quan trọng - consequences) cho cả LSP B và LSP C. Cả LSR6 và LSR8 sẽ phát hiện ra rằng một lỗi đã xuất hiện khi lỗi thực sự là tại LSP B. Để ngăn cản các báo động cho LSP C tại LSR8, LSR6 thông báo cho router này bằng cách gửi các gói FDI theo cùng một đường như là LSP C sẽ sử dụng trước khi lỗi xuất hiện. Nó không chỉ cần thiết (to inform the downstream egress LSRs, LSR6 have to inform LSR2), các ingress LSR của LSP B, nơi mà trong sự quay về của nó sẽ cung cấp tin tức cho LSR1 về lỗi tốt như việc sử dụng các gói BDI. Cách mà các gói BDI được gửi đi, ví dụ như tìm kiếm một tuyến về thay đổi, sẽ được thảo luận ở dưới.

2.3.2 Defect type codepoint

Mã của kiểu lỗi (Defect type code) được mã hóa trong 2 octets. Octet đầu tiên chỉ ra lớp và octet thứ 2 chỉ ra bản chất của lỗi (nature of the defect). Để có thể phát hiện được các lỗi này chúng ta cần một thiết bị trạng thái sãn sàng trên LSP (LSP availability state machine – ASM) trên cả các ingress LSR và egress LSR của LSP. Tại ingress LSR (do we have the LSP Trail Far – End Defect State and for the egress LSR the LSP Trail Sink Near-End Defect State).

Bảng 2.1: Các codepoint của kiểu lỗi trong các gói OAM FDI./BDI

Defect Type (DT)

DT code (Hex)	Description
dServer	01 01	Any server layer defect arising below the MPLS layer network
dLOCV	02 01	Simple Loss of Connectivity Verification.
dTTSI_Mismatch	02 02	Trail Termination Source Identifier Mismatch defect.
dTTSI_Mismerge	02 03	Trail Termination Source Identifier Mismerge defect.
dExcess	02 04	Increased rate of CV OAM packets with the expected TTSI above the nominal rate of one per second.
dUnknown	02 FF	Unknown defect detected in the MPLS layer.
None	00 00	Reserved
None	FF FF	Reserved

Có thể bạn quan tâm!

Xem toàn bộ 81 trang tài liệu này.

Trong bảng 2.1 có 4 lỗi trên mặt phẳng người dùng MPLS: dLOCV, TTSI_Mismatch, dTTSI_Mismerge and dExcess. Khi một trong số các lỗi này xuất hiện, thì ASM đi vào trong LSP Trail Sink Near-End Defect State nơi mà trong sự quay trở lại của nó, khi các gói BDI đi đến được ingress LSR, nó sẽ làm cho ingress LSR đi vào Trail Far-End Defect State. 2 kiểu lỗi khác phân phối (deals) với các lỗi từ bên ngoài của lớp MPLS và không nhận biết được các lỗi. Mội hành động mà được cầu khẩn sử dụng khi quá trình đi vào LSP Trail Sink Near-End Defect State bị ngừng lại khi LSP Sink Near- End Defect State được thoát ra .

Mô tả ý nghiã của một số loại lỗi:

- dServer : một vài lỗi xuất hiện ở lớp server bên dưới mạng của lớp MPLS là một lỗi dServer. Chức năng này chỉ ra rằng chỉ có một lỗi trên các lớp bên dưới MPLS, nhưng không có thông tin gì về loại của lỗi được tìm thấy. Lỗi này không được phát ra bởi các kĩ thuật OAM MPLS, nó là đầu ra cho OAM MPLS từ lớp server.

- dLOCV : sự mất mát đơn (Simple Loss) của lỗi sác minh kết nối xuất hiện khi không có các gói OAM CV được mong đợi với đối tượng xem xét TTSI được mong đợi (expected TTSI observed) trong một vài chu kĩ của 3 giây liên tiếp nhau (period of three consecutive seconds). Nếu nguyên nhân của dLOCV là tại lớp server và cũng có một tín hiệu FDI đến từ lớp server, sau đó codepoint DT cho dServer được sử dụng. Codepoint của dLOCV chỉ được sử dụng khi các lỗi kết nối đơn giản lớp MPLS xuất hiện trong các LSP của bản thân nó.

- dTTSI_Mismatch : lỗi Trail Termination Source Identifier Mismatch xuất hiện khi có một vài gói OAM được xem xét trong một vài chu kĩ của 3 giây liên tiếp (period of three consecutive seconds) với một TTSI không được mong đợi và không có gói OAM CV (observed 0 với một TTSI được mong chờ trong cũng một chu kì. Các lỗi này làm mất cấu hình kết nối. Điều kiện của lỗi này mang đến quyền được ưu tiên cả trên lỗi dLOCV và điều kiện dTTSI-Mismerge trong những trường hợp khi mà chúng cũng xuất hiện.

Điều này xuất hiện khi mà các LSP A và B trao đổi nhãn, nó thay thế cho quá trình của A1->A2 và B1->B2, chúgn ta chuyển A1->B2 và B1->A2. (Đó là thay vì A1-> A2 và B1->B2, chúng ta có A1->B2 và B1->A2). Trong trường hợp này chúng ta lấy một TTSI không được mong đợi tại sink point LSP và không có TTSI được

mong đợi tại sink point.

- dTTSI_Mismerge : lỗi Trail Termination Source Identifier Mismerge xuất hiện khi có một vài các gói OAM CV với một TTSI không được mong đợi và không có một gói OAM CV nào mà có một TTSI được mong đợi xem xét (an expected TTSI observed) trong một vài chu kì của 3 giây liên tiếp. Các lỗi này bao gồm cả lỗi nhánh (misbranching) và thay thế các lỗi không dự tính trước. Theo Neil Harrison từ British Telecom lỗi mất nhánh là sự thay thế không dự tính trước của một vệt đuôi (of a trail) và trường hợp nơi một vệt đuôi đơn (single trail) có thể không dự tính trước lỗi nhánh trở lại trên bản thân nó (ví dụ như bị vòng lặp – looping).

Các lỗi thay thế không dự tính trước xuất hiện khi nói LSP B (gets unintentionlly replicated, or let say duplicated, into say LSP A). trong cách này cả LSP A và B sẽ vận chuyển lưu lượng trên LSP B. Misbranching được hiểu như là LSP B bị mất tuyến và trộn vào trong LSP A và không bao giờ đến được sink point trên LSP B.

Neil Harrison nói rằng các lỗi mất trộn (mismerge) này xuất hiện trong 2 trường hợp:

+ Khi LSP B không bao giờ đi đến tại B2, nhưng đến một cách không dự tính trước tại A2. Điều này có thể được minh họa bởi A1+B1->A2, và 0->B2. Ở đây A2 sẽ lấy cả TTSI được mong đợi cho LSP A và một TTSI không được mong đợi cho LSP B tại sink point của LSP A. Trong các giới hạn của các lỗi, LSP A chỉ ra một lỗi mất trộn và ở đây LSP B chỉ ra một lỗi dLOCV từ B2 không bao giờ lấy một vài TTSI (never gets some TTSIs).

+ Khi LSP B vẫn đến tại B2, nhưng đến A2 một cách không dự tính trước được. Điều này có thể được hiểu như là A1+B1->A2, và B1->B2. Ở đây A2 sẽ lấy cả một TTSI được mong đợi cho LSP A và lấy một TTSI không được mong đợi cho LSP B tại sink point của LSP A. Điều này là tương tự như kịch bản được nêu ra ở trên, Trong các giới hạn của các lỗi, LSP A chỉ ra một lỗi mismerge nhưng LSP B không chỉ ra lỗi.

- dExcess : một lỗi dExcess xuất hiện khi có một sự tăng về tốc độ, 5 gói hoặc nhiều hơn của các gói OAM CV với TTSI được mong đợi bên trong một chu kì của 3 giây liên tiếp. Điều này có thể mang lại một ví dụ cho cho bản thân lỗi mismerging, một nguồn LSR có lỗi, tấn công từ chối dịch vụ (DoS attack).

- dUnknown: không nhận biết được lỗi phát hiện trong lớp MPLS. Điều này

được mong đợi để sử dụng cho các lỗi trên nút MPLS mà được phát hiện bên trong node (hầu như chắc chắn bởi người chủ) và tác động đến lưu lượng mặt phẳng người dùng. Chú ý rằng lỗi này không được phát hiện bởi các OAM MPLS, xa hơn nó là một đầu ra đến OAM MPLS.

2.3.3 Tuỳ chọn cảnh báo router và nhãn cảnh báo router.

2.3.3.1 Tùy chọn cảnh báo router

Các gói IP có thể có một tùy chọn cảnh báo router được thêm vào header IP. Tùy chọn này là một tùy chọn IP cho phép router có thể kiểm tra gói xa hơn khi quá trình chuyển tiếp gói, dù là gói không có địa chỉ trực tiếp đến router. Router không nên chỉ chuyển gói bằng cách kiểm duyệt qua IP, nhưng router sẽ kiểm tra kỹ hơn trước khi chuyển nó đi. Sự kiểm tra này không được định nghĩa, và phụ thuộc vào sự bổ sung phần mềm trong router. Tùy chọn cảnh báo router là một tùy chọn IP như là các tùy chọn Timestanp, Loose Source Route, và Strict Source Route. Mỗi tùy chọn IP được mã hóa như là một giá trị trường kiểu (Type Length Value – TLV). Nhìn vào hình 2.6 để thấy định nghiã kiểu của một tùy chọn IP.

Hình 2.6: Định nghĩa kiểu tùy chọn IP

Hình 2.7: Chỉ ra tùy chọn IP với các giá trị cho tùy chọn cảnh báo router IP.

Tùy chọn cảnh báo router làm việc chỉ khi gói là một gói IP. Nếu gói được đóng nhãn và như là toàn bộ được chuyển đi bởi LFIB trên LSR, LSR sẽ không biết rằng gói có trình diện tùy chọn cảnh báo router. Tất nhiên, bạn có thể lập trình cho LSR để thi hành kiểm tra gói sâu (deep packet inspection) và luôn luôn nhìn vào thông tin tiêu đề IP của các gói đã được đóng nhãn để chỉ ra dù không biết tùy chọn cảnh báo router được trình bày. Tuy nhiên, điều này có thể dẫn đầu tới một hiệu suất chuyển tiếp đông đặc ngiêm trọng (a serious forwarding performance impact) trên LSR, vì vậy nó không phải là giải pháp tốt nhất. Nó có thể không khả thi để thực hiện việc này trong các phương tiện phần cứng chuyển tiếp gói, hoặc nó có thể là quá đắt. Một giải pháp tốt hơn để sử dụng một nhãn MPLS đặc biệt như đỉnh nhãn trong stack nhãn của các gói mà các LSR cần để ngiên cứu. Nhãn đặc biệt này là một nhãn MPLS, được gọi là nhãn cảnh báo Router.

2.3.3.2 Nhãn cảnh báo router.

Nhãn cảnh báo router có một giá trị của 1 (has a value of 1), và nó có thể xuất hiện tại một nơi nào đó trong stack nhãn trừ tại vị trí bottom. Khi một LSR nhận một gói với nhãn l như là đỉnh nhãn, nó biết rằng nó phải thực thi xa hơn gói. Bởi vậy, LSR tháo gỡ nhãn l và thực thi gói. LSR sau đó nhìn vào đỉnh nhãn mới trong stack nhãn và thực hiện một quyết định chuyển tiếp gói bằng việc nhìn vào nhãn đó trong LFIB. Quyết định chuyển tiếp gói này làm cho LSR thực hiện một cuộc tráo đổi, lấy ra hoặc điều hành thêm vào trên stack nhãn và trởi lại giao diện ra và hop kế tiếp cho gói. Trước khi chuyển mạch gói ra ngòai khỏi LSR, LSR đặt nhãn l trở lại như là đỉnh nhãn trong stack nhãn và chuyển các gói đi. Vì vậy, có nhãn cảnh báo router như

là đỉnh nhãn không ảnh hưởng đến quyết định chuyển tiếp gói được tạo nên trên gói; nó chỉ ra một cách duy nhất rằng LSR phải kiểm tra gói. Trên các router chạy hệ điều hành của Cisco, các gói có nhãn cảnh báo router được chuyển đi trong phần mềm, điều đó có nghiã là các máy chuyển tiếp phần cứng là đi đường vòng (bypassed). Sự sử dụng của nhãn cảnh báo router cho các gói đã được đóng gói là tương tự như sự sử dụng của tùy chọn cảnh báo router cho các gói IP.

Bởi vì nhãn cảnh báo router bắt buộc (forces) LSR đối xử với một gói đã được đóng nhãn trong một cách khác hơn là khi gói đã được đóng nhãn không có nhãn cảnh báo router như là đỉnh nhãn khi chuyển tiếp gói tin, sự sử dụng của nó không có tác dụng trực tiếp cho OAM MPLS. Nhớ rằng một trong các yêu cầu là cho lưu lượng dữ liệu người dùng MPLS và lưu lượng OAM MPLS được chuyên đi trong cùng một đường. Điều này rõ ràng không là trường hợp cho lưu lượng của đỉnh nhãn là nhãn l đặc biệt. Vì vậy, nhãn cảnh báo router không đước sử dụng để gửi đi các gói OAM MPLS khi kiểm tra một LSP. Nó có thể, tuy nhiên, được sử dụng cho lưu lượng OAM trở lại. Bởi vì một LSP là không theo một hướng duy nhất (unidirectional), lưu lượng OAM MPLS kiểm tra LSP trong chỉ một hướng duy nhất. Điều này có nghiã là lưu lượng trở lại không kiểm tra cái gì cả; nó chỉ cần được quay trở về nguồn. Lưu lượng trở lại có thể được gửi đi với tùy chọn cảnh báo router vì vậy nó đi đường vòng (bypasses) qua các máy móc phần cứng chuyển tiếp và có một cơ hộ lớn hơn của việc trở lại đến nguồn (chance of getting back to the source). Nếu lưu lượng trở lại được đóng nhãn, nó cũng có nhãn cảnh báo router, vì vậy các máy phần cứng chuyển tiếp gói là đi theo đường vòng.

Các gói chuyển tiếp được đóng nhãn (Forwarding Labeled Packets), bạn đã nhìn thấy một nhãn đặc trưng MPLS được gọi là nhãn cảnh báo vận hành và bảo dưỡng (Operation and Maintenance Alert Label) mà có một giá trị của 14 (has a value of 14). Bạn chèn thêm nhãn cảnh báo OAM vào stack nhãn bên dưới nhãn của LSP dưới sự kiểm tra. Hệ điều hành của Cisco không sử dụng nhãn MPLS đặc biệt này ở bất cứ đâu cả. Có điều này là bởi vì sự giới thiệu của một nhãn đặc biệt trong stack nhãn có thể ảnh hưởng tới sự đối xử đối với gói khi nó đang được chuyển đi. Một ví dụ đó là trường hợp của các gói được đóng nhãn load balancing, nơi mà trao đổi trong stack nhãn có thể giới thiệu một cách đối xử chuyển tiếp khác.

Cũng giống như vậy, lưu lượng dữ liệu người dùng thực sự và lưu lượng OAM

có thể được chuyển tiếp đi trong cùng một tuyến, trả lại kiểm tra OAM trừ khi trong một vài trường hợp. Một ví dụ thứ hai là sự sử dụng của lấy nhãn ra ở Hop áp chót (penultimate) (PHP) trong một mạng MPLS trên IP rõ ràng. Trong trường hợp này, gói đến trên egress LSR với hòan tòan nhãn cảnh báo OAM trong stack nhãn nơi nếu không thì nó sẽ nhận không có một stack nhãn. Không cái nào của các kĩ thuật OAM đã thảo luận trong chương này và được sử dụng bởi Cisco IOS sử dụng nhãn cảnh báo OAM.

2.3.4 Ping LSP MPLS.

Ping LSP MPLS là tên gọi cho một yêu cầu echo MPLS và đáp trả echo MPLS. Ping là một công cụ giải quyết sự cố tốt đã được biết đến cho các mạng IP. Nó giống như sử dụng SONAR trên tàu ngầm. Ping sử dụng ICMP, được thiết kế để tăng lên (augument) giao thức IP bởi vì nó có thể báo hiệu các điều kiện lỗi (không đến được đích…) và gửi thông tin quảng bá (redirect, address mask…). Ping sử dụng ICMP để mang thông điệp yêu cầu và các gói đáp trả. Gói yêu cầu echo được gửi thẳng đến đích, nơi mà sẽ gửi lại đáp trả với một gói echo đáp trả. Nguồn nhận echo đáp trả chỉ ra rằng 2 host có thể nhìn thấy mỗi host còn lại trên mức mạng (lớp 3).

Bởi vì MPLS không thể làm việc mà không có Ip trên mức mạng, bạn có thể vẫn sử dụng Ping IP khi mạng đang chạy MPLS. Các gói Ping được gán nhãn và chuyển nhãn thông qua mạng. Tại sao lại phải tạo ra Ping LSP MPLS? Ping IP là không đủ hiệu lực cho việc thẩm tra sự chính xác của LSP MPLS. Mặc dù nó có thể thẩm tra một trong hai kết nối có hiện diện trên mức IP, nó không thẩm tra cả hai LSP đã bị gãy. Nếu bạn có một mạng MPLS trên nền IP rõ ràng (plain) và LDP bị gãy giữa hai LSR, Ping chỉ ra rằng không có vấn đề gì như là echo yêu cầu tạo nên cho chúng đến đích và echo trả lời làm nó trở lại nguồn. Giữa 2 LSR nơi mà phiên LDP bị gãy, các gói lúc này không còn được dán nhãn. Ping chỉ ra một cách giả dối rằng mọi thứ đều tốt, khi trong sự tin tưởng LSP là bị gãy.

Hình 2.8 : LSP bị gãy trong mạng AtoM

Để thấy rằng điều này có thể hướng dẫn để sử dụng việc xử lý sự cố, thử tưởng tượng rằng bạn đang chuyển một vài một lưu lượng vài phương tiện trên MPLS (AtoM) qua LSP này (imagine that you are switching Any Transport over MPLS (AtoM) traffic across that LSP), và 2 LSR với phiên LDP bị gãy (vỡ - broken) là các router P trong một mạng AtoM. Hình 2.8 đưa ra một mạng.

Nếu LSP bị gãy, lưu lượng AtoM trở nên không có nhãn giữa các LSR P2 và P3. Bởi vì 2 LSR đó không biết rằng làm thế nào để chuyển các frames này đi, khi chúng đã bì rớt. Một Ping từ PE router đến PE khác qua LSP sẽ thành công, nhưng lưu lượng AtoM sẽ bị lỗi. Để có một giao thức tương tự như giao thức Ping IP chỉ ra các vấn đề đặc trưng với các LSP MPLS, Ping LSP MPLS được phát minh.

Các LSP có thể làm vỡ (break) bởi một vài lí do, trong khi kết nối IP lưu lại trạng thái bình thường. Sau đây là một vài lý do một LSP có thể bị gãy:

- Phiên LDP bị down.

- MPLS không cho phép trên một LSR (hoặc một giao diện).

- LFIB có một entry không đúng cho LSP này (nhãn vào/ra sai hoặc sai thông tin đến trạm kế tiếp).

- Phần mềm và phần cứng LFIB có sự không thống nhất (discrepancy).

Trong những trường hợp như trên, các gói mất nhãn, các nhãn khác có là do chuyển mạch nhãn, nhưng không đúng cách. Đó là lý do tại sao bạn cần một kĩ thuật để kiểm tra đầu cuối LSP và mang đến một vài sự trợ giúp phản hồi khi LSP bị gãy. Khi bạn đang giải quyết vấn đề của LSP, ta cần biết nơi LSP bị gãy và lỗi đó là gì. Ping LSP MPLS phát hiện các vấn đề trong mặt phẳng chuyển tiếp, nhưng nó cũng kiểm tra mặt phẳng điều khiển ngược lại thông tin trong mặt phẳng dữ liệu.

Xem toàn bộ nội dung bài viết ᛨ