14 octets 2 octets
4.3.3Tuỳ chọn cảnh báo router và nhãn cảnh báo router.
4.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 4.7 để thấy định nghiã kiểu của một tùy chọn IP.
Hình 4.7 : định nghiã kiểu tùy chọn IP
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.
4.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 iệ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.
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.
Để 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 4.9 đư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.
4.3.4.1. Các chi tiết giao thức Ping LSP.
Ping LSP tương tự như Ping IP trong đó nó cũng sử dụng một echo yêu cầu và echo đáp trả. Ping LSP MPLS có định dạng gói khác hoàn toàn và có nhiều thông tin giải quyết vấn đề hơn các gói trở lại. Một echo yêu cầu MPLS được gửi đi bởi nơi gửi và kiểm tra một FEC riêng biệt. Echo yêu cầu giữ stack FEC chỉ thị, cái mà FEC đang được
xắc minh. Nơi nhận sau đó sẽ xắc minh rằng stack FEC trên echo yêu cầu là chính xác cho FEC. Cũng theo cách này, thông tin mặt phẳng dữ liệu cho FEC được xác minh với thông tin mặt phẳng điều khiển.
Một echo yêu cầu MPLS là một gói UDP với một cổng đích của 3503 và một cổng nguồn được chọn bởi nơi gửi. Nó có một tùy chọn cảnh báo router. Để ngăn cản gói từ một vài chuyển mạch xa hơn như là một gói IP nêu LSP bị gãy nhưng tuyến IP vẫn tốt, TTL IP của gói được đặt lên 1 và địa chỉ IP đích của gói là từ khoảng 127.0.0.0/8. Khoảng địa chỉ 127.0.0.0/8 là cho địa chỉ IP cục bộ cho host; bởi vậy, các gói mà có một địa chỉ IP đích từ khoảng này sẽ không bao giờ thấy trên wires mạng. Một LSR không bao giờ chuyển tiếp toàn bộ gói IP nếu LSP bị gãy, và không một cái nào làm egress LSR của LSP. Egress LSR gửi gói đến module phần mềm UDP đang chạy trên router nge ngóng UDP ở cổng 3503. Địa chỉ IP nguồn là một sự lựa chọn hợp lý địa chỉ IP của nơi gửi. Hình 4.10 chỉ ra định dạng của một echo MPLS yêu cầu:
Hình 4.10 : Định dạng gói echo MPLS
Chỉ có một phiên bản duy nhất. Trường Global Flags hiện hành chỉ có một bít được định nghiã. LSB là cờ V (Validate FEC stack). Nếu cờ V được đặt, nơi gửi muốn nơi nhận phê chuẩn (validate) stack FEC. Message Type là 1 cho một echo MPLS yêu cầu
hoặc là 2 cho một echo MPLS đáp trả. Mode Reply chỉ ra có bao nhiêu echo MPLS đáp trả sẽ được trở lại. Có 4 khả năng tồn tại, nha ta có thể nhìn thấy trên bảng 4.1 .
Bảng 4.1 : mode reply
Mode Reply 1 được sử dụng chỉ nếu các đáp trả echo không cần quay trởi lại. Nó có thể được ai đó định lượng đích bằng ý nghiã của một thiết bị phần mềm để thấy được nếu các yêu cầu echo MPLS tạo ra nó, vì vậy sự trở lại của các đáp trả echo là không cần thiết. Đáp trả mode 2 là mode đáp trả không thay đổi (regular reply mode).
Reply Mode 3 là tương tự như Reply Mode 2, nhưng các gói echo đáp trả được trở lại với tùy chọn cảnh báo router. Như đã giải thích trong các phần trước, bạn có thể sử dụng điều này để chắc chắn rằng gói có sự đồng ý cao nhất một cách chắc chắn để trở lại, trong trường hợp của vấn đề chuyển tiếp dọc theo tuyến trở lại. Reply Mode 4 là một mode đáp trả nằm ngòai band. Chú ý rằng Ping LSP MPLS kiểm tra một LSP. Bởi vì các LSP là theo một phương duy nhất, chỉ các yêu cầu echo là kiểm tra LSP MPLS. Các gói echo đáp trả không kiểm tra một cái gì nữa; chúng được yêu cầu đơn giản để lấy thông tin trở lại nơi gửi. Cũng như vậy, mạng không cần trở lại các gói đáp trả echo dọc theo cùng một tuyến trong hướng ngược lại. Mạng có thể gửi trở lại chúng như các gói IP.
Một handle hoặc sos chỉ định ai gửi chúng. Sequence Number nhận dang các yêu cầu echo đến sau và các đáp trả echo được gửi bởi cùng một LSR. Timestamp được đưa ra (compose) của 2 trường: một trong vài giây và một trong khoảng vài micro giây. Timestamp Sent chỉ định thời gian của ngày mà nơi gửi gửi các yêu cầu echo, và Timestamp Received chỉ ra thời gian của ngày mà nơi nhận nhận được yêu cầu echo. Để Timestamp là có hiệu lực sử dụng, bạn cần đồng bộ hóa đồng hồ của nơi gửi và nơi nhận. Các trường cuối cùng vận chuyển các TLV. (adsbygoogle = window.adsbygoogle || []).push({});
đến các mã con (subcode) trở lại. Mã con trở lại chỉ ra độ sâu của nhãn cho trở lại thích hợp. Độ sâu của nhãn là 1 cho đáy của nhãn và là 2 cho nhãn ở trên và…and so on.
Bảng 4.2 : các mã trở lại
Nơi gửi luôn luôn đặt mã trở lại là 0. Nơi nhận có thể đặt mã trở lại như là phản hồi đến nơi gửi của yêu cầu echo. Nếu nơi nhận quả thực là egress LSR thích hợp cho FEC dưới sự kiểm tra, nó sẽ trở lại gói đáp trả echo với một mã trở lại của 3. Đó là mã trở lại bạn sẽ nhìn thấy nếu Ping MPLS làm việc tốt. Một bộ nhận sẽ biết nếu nó là egress LSR thích hợp (proper) bằng cách so sánh thông tin trong stack FEC của yêu cầu echo với thông tin thực tế trên LSR. Code trở lại 8 có nghiã là gói có một stack nhãn chỉ ra rằng một sụ điều hành lấy nhãn ra hay tráo đổi nhãn được thực hiện và nó là tốt cho chuyển tiếp đi một gói đã được đóng nhãn. Một mã trở lại của 9 chỉ ra một sự điều hành nhãn, nhưng đó là các gói đã được đóng nhãn không được chuyển mạch ra ngòai. Một mã trỏ lại của 4 có nghiã là nhãn trong stack là không biết LSR (a return code of 4 means that the label in the stack is unknown to the LSR). Một mã trở lại của 5 có nghiã là đối tượng ánh xạ downstream được cung cấp bởi LSR upstream không phải là cái mà LSR downstream mong đợi.
Chú ý rằng Ping LSP MPLS được chỉ rõ trong RFC 4379, “phát hiện lỗi mặt phẳng dữ liệu của chuyển mạch nhãn đa giao thức” (detecting Multi-Protocol Label Switched
Data Plane Failures). Các giá trị mã trở lại của 6 và 7 có một ý nghiã khác trong các phiên bản trước đó của phác thảo được được đề xuất bởi RFC. Mã trở lại 6 có nghiã “router đáp trả là một trong các router downstream, và ánh xạ của nó cho FEC này trên giao diện nhận là do nhãn mang lại”. Mã trở lại 7 có nghiã “router đáp trả là một trong các router downstream nhưng ánh xạ của nó cho FEC này không được mang lại bởi nhãn.”
Cuối cùng, gói echo MPLS có các TLV. Bảng 4.3 liệt kê các TLV khác nhau có