Tìm hiểu các giao thức phát hiện và sửa lỗi trong mạng chuyển mạch nhãn đa giao thức

2.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 kiểm tra. Stack FEC có thể giữ một hoặc nhiều hơn các nhãn mà nơi nhận được dùng để 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 2.9 chỉ ra định dạng của một echo MPLS yêu cầu:

Hình 2.9: Đị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, mà ta có thể nhìn thấy trên bảng 2.2.

Bảng 2.2: 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).

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

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

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.

Ta có thể thấy các giá trị có thể của mã trở lại trong bảng 2.3. RSC quy cho (refer) đế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à...

Bảng 2.3: 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 2.4 liệt kê các TLV khác nhau có thể được mang bởi các gói echo MPLS.

Bảng 2.4: Các TLV

2.3.4.2. Điều hành Ping LSP.

Yêu cầu echo MPLS cho một Ping MPLS giữ các thông tin sau đây:

- Tiêu đề Echo MPLS

- Target FEC Stack TLV

- A PAD TLV (optional)

Đáp trả echo giữ các thông tin sau đây:

- Tiêu đề Echo MPLS

- Một Error Code TLV (optional)

- A PAD TLV (optional)

- Target FEC Stack TLV từ yêu cầu echo (optional)

Yêu cầu echo MPLS cho một Ping MPLS bị ép buộc vào trong FEC tại nơi gửi.

LSR không thực hiện việc này qua một quá trình tìm kiếm địa chỉ IP đơn giản trong bảng CEF. Địa chỉ IP đích là từ khoảng địa chỉ 127.0.0.0/8 (anyway), vì vậy (this is not even possible). Đích đến của gói được chuyển phát từ địa chỉ IP mà câu lệnh người dùng hoặc một thiết bị phần mềm cung cấp. Điều này xem xét nơi stack nhãn được đẩy lên gói. Gói được chuyển ra ngòai của LSR theo thông tin này. Tại một mức tối thiểu, TTL của đỉnh nhãn được đăt tới 255. khi nơi nhận nhận yêu cầu echo MPLS, nó phải thực hiện các tác vụ sau đây:

- Kiểm tra các lỗi định dạng trên yêu cầu echo.

- Chú ý giao diện mà gói nhận được.

- Chú ý stack nhãn của gói như lối vào của LSR.

- Kiểm tra (whether) stack nhãn trên gói là cùng như một (check whether the label stack on the packet is the same as the one in the Target FEC Stack TLV

- Kiểm tra LSR egress LSR quả thực cho FEC này.

- Kiểm tra (whether) giao thức phân bố FEC được chỉ định với giao diện đến.

- Gửi một đáp trả echo , trừ khi Reply Mode là 1.

Nếu Reply Mode là Reply thông qua một gói UDP Ipv4/Ipv6 với cảnh báo router, tùy chọn cảnh báo router phải được xuất hiện. Điều này có nghiã là nếu đáp trả echo được đóng nhãn, gói có nhãn cảnh báo router như là đỉnh của nhãn. Địa chỉ IP đích của gói đáp trả echo là địa chỉ IP nguồn của gói yêu cầu echo. TTL IP được đặt tới 255, và các cổng UDP là 3503.

2.3.4.3. Ping MPLS trong IOS Cisco

Trong IOS Cisco, bạn có thể gửi một Ping LSP MPLS với lệnh “Ping mpls”, Có thể thấy rằng có 3 tùy chọn tồn tại: Ipv4, traffic – eng, và pseudowire. Tùy chọn pseudowire là cho thẩm tra kết nối mạch ảo (Virtual Circuit Connection Verification – VCCV), sẽ được giải thích sau. Tùy chọn Ipv4 là cho việc gửi đi một yêu cầu echo cho một LSP mà được giới hạn với một tiền tố Ipv4 (that is bound to an Ipv4 prefix). FEC được lựa chọn bởi việc chỉ rõ tiền tố Ipv4 (mạng và mặt nạ mạng). Cũng như vậy, tương ứng với stack nhãn cho tiền tố Ipv4 này là đặt trên yêu cầu echo. Địa chỉ IP đích của yêu cầu là mặc định bởi 127.0.0.1. Vì vậy, router sử dụng địa chỉ FEC mục tiêu (Target FEC Address) bạn gõ trong vào hình dáng mà stach nhãn đặt lên trên gói và trên LSP nào mà để chuyển gói đi; nó không được sử dụng như là địa chỉ IP đích thật sự trong tiêu đề IP.

2.3.5 Dấu vết tuyến LSP MPLS

Mục tiêu của traceroute là để kiểm tra tuyến, nhưng trái lại mục tiêu của ping là để kiểm tra kết nối. Mục tiêu của traceroute LSP MPLS là kiểm tra tuyến của LSP và sác minh mặt phẳng điều khiển và mặt phẳng dữ liệu trên mọi LDR dọc theo tuyến của LSP.

Một traceroute LSP MPLS không là gì nhiều hơn một yêu cầu echo MPLS. Sự khác nhau với Ping LSP MPLS là traceroute LSP MPLS gửi một vài gói yêu cầu echo MPLS với sự giảm dần TTL MPLS. Đầu tiên sự điều tra traceroute LSP MPLS có TTL MPLS là 1 và cho mọi điều tra sau đó, TTL giảm đi 1. Một TLV bổ sung là bao gồm với yêu cầu echo cho traceroute LSP MPLS là TLV ánh xạ Downtream. Nếu một LSR nhận yêu cầu echo MPLS với TTL 1, nó đáp trả tới nó (? It replies to it). Nếu LSR không là egress LSR cho FEC và mọi kiểm tra đều tốt, các đáp trả LSR như là một trong các router downstream. Bởi vậy, nó đáp trả với một mã trở lại của 8 và thông tin TLV downstream thích hợp (MTU, Address Type, Downstream IP Address, Downstream Interface Address, Multipath Information, Downstream Label, và Protocol) lấp đầy trong đó. Nếu LSR là egress LSR cho FEC, nó không cần lấp đầy thông tin ánh xạ Downstream nhưng sẽ đáp trả với một mã trở lại của 3.

Yêu cầu echo MPLS cho một Traceroute MPLS giữ các thông tin sau:

- Tiêu đề echo MPLS

- Target FEC Stack TLV

- Downstream Mapping TLV

- A PAD TLV (optional)

Đáp trả echo sẽ giữ các thông tin sau:

- Tiêu đề echo MPLS

- An Error Code TLV (optional)

- A PAD TLV (optional)

- Downstream Mapping TLV

Nơi gửi của các gói Traceroute LSP MPLS copy TLV ánh xạ Downstream (Downstream Mapping TLV) nhận được vào trong yêu cầu echo tiếp theo để gửi đi. Như vậy, tại mỗi hop, các nhãn được hi vọng đã báo cáo bởi LSR một hop upstream được kiểm tra với nhãn trên gói nhận được trên LSR downstream.

2.3.6 VCCV

VCCV được chỉ định để kiểm tra và xác minh mặt phẳng dữ liệu của pseudowires. VCCV đòi hỏi các thủ tục để tạo nên một kênh điều khiển giữa các router PE mà cung cấp dịch vụ AtoM. Lớp mạng có thể thực tế là MPLS, L2TPv3, hoặc là IP. Bởi vì sách này bao phủ chỉ MPLS, nó chỉ (deals) sau đó với MPLS như là lớp mạng khi nhìn vào VCCV. Nếu MPLS là lớp mạng, VCCV sử dụng lại Ping LSP MPLS để thẩm tra kết nối của các pseudowire. VCCV tạo ra một kênh điều khiển giữa các router PE nhờ đó các gói VCCV được gửi đi qua như các gói IP. Bạn có thể sử dụng 3 lọai kênh điều khiển sau:

- VCCV Inband

- VCCV Out – of – band

- TTL expiry VCCV

Phương thức đầu tiên sử dụng VCCV Inband. Các gói trên VCCV Inband mang một từ điều khiển. Dữ liệu AtoM có thể mang một từ điều khiển giữa stack nhãn và tải trọng MPLS. Nibble đầu tiên của từ điều khiển này là (then) 0000. Để cho các gói trên kênh điều khiển, tuy nhiên, nibble đầu tiên của từ điều khiển là 0001. Từ điều khiển sau đó đóng vai trò như đối tượng nhận dạng tải trọng (hoặc giao thức trường ID). Đối tượng giao thức là 0x21 cho các gói Ipv4 hoặc 0x57 cho các gói Ipv6. Tuy nhiên, sự có mặt của từ điều khiển là không bị áp đặt, vì vậy tùy chọn này là không phải luôn luôn khả dĩ (sẵn dùng – possible).

Phương thức thứ 2 sử dụng VCCV Out – of – band. VCCV out – of – band không dựa trên xự xuất hiện của từ điều khiển nhưng xa hơn trên sự xuất hiện một cách ngay lập tức của nhãn cảnh báo router trên nhãn VC. Vấn đề với sự gần đến này là những sự bổ sung đó sác định quyết định load balancing dựa trên một nhãn tại một vài độ sâu trong stack nhãn có thể sửa đổi quyết định này bởi vì sự xuất hiện của nhãn với giá trị bằng 1. Nếu lưu lượng dữ liệu AtoM và lưu lượng OAM AtoM – lưu lượng VCCV – lấy một tuyến khác, sự kiểm tra là không thật sự có hiệu lực.

Phương pháp thứ 3 và phương pháp cuối cùng sử dụng sự hết hạn của TTL (TTL expiry). Về bản chất, giá trị TTL của nhãn VC được đặt đến 1 vì vậy TTL của gói được gán nhãn hết hạn tại egress PE router, và LSR sẽ kiểm tra gói bởi vì chuyển tiếp xa hơn. Tuy nhiên, TTL của nhãn VC có thể được viết đề lên khi nhãn đường hầm được gỡ ra. Bởi vậy, phương pháp thứ 3 là không thích hợp. Phương pháp thứ nhất

là số một mà IOS Cisco sử dụng.

Chú ý: IOS Cisco không ghi đè lên giá trị TTL của 1 trong nhãn VC khi nhãn đường hầm được lấy ra tại LSR hop áp chót.

VCCV sử dụng tiêu đề gói Ping LSP MPLS và các TLV. Target FEC Stack TLV được sử dụngl nó chỉ ra một Pseudowire. FEC 128 Pseudowire (new) được sử dụng cho VCCV trong IOS Cisco.

Khả năng để hỗ trợ một kênh điều khiển và kiểu của kênh này là báo hiệu giữa (tín hiệu – signaled) các router PE. Điều này được thực hiện bởi một thông số VCCV TLV (VCCV parameter TLV) trong một TLV giao điện VC FEC cho LDP. LDP là giao thức báo hiệu giữa các router PE cho AtoM. VCCV parameter TLV giữ một kiểu kênh điều khiển (CC) và một kiểu sác minh điều khiển (control verification – CV). CC chỉ ra một vài lọai sau đây:

- Một từ điều khiển với nibble đầu tiên là 0001 và một đối tượng nhận dạng tải trọng.

- Nhãn cảnh báo router MPLS.

- Một nhãn VC với TTl được đặt lên 1. Kiểu CV chỉ ra một số điều sau đây:

- Ping ICMP

- Ping LSP

- Bảo vệ chuyển tiếp gói hai hướng (bidirectional Forwarding Detection)

- VCCV sử dụng Ping ICMP khi giao thức mạng là IP hoặc L2TPv3.VCCV sử dụng Ping LSP khi giao thức mạng là MPLS, như nó là cho AtoM. Cuối cùng,VCCV có thể sử dụng hai hướng giữa hai nền (platform) – để sác minh phiên giữa hai router PE. BFD có thể được sử dụng cho một vài của ba giao thức mạng (any of the three network protocols).

IOS Cisco sử dụng phương thức đầu tiên khi gửi đi các gói VCCV AtoM, gói đầu tiên (the one with) với từ điều khiển với nibble đầu tiên là 0001 và một đơn vị nhận dạng tải trọng.

2.3.7 IP Service Level Agreement

Cisco IP Service Level Agreement (IPSLA) là một công cụ đo đạc hiểu suất mạng mà được nhúng trong IOS Cisco. IP SLA cho phép người điều hành mạng định lượng hiệu suất mạng một cách thông thạo và có thể nhìn thấy được nếu các SLA