Tweet
Được phát hành bởi Công Ty TNHH Tư Vấn và Dịch Vụ Chuyên Việt
BÁO CỦA DÂN CÔNG NGHỆ - KỸ SƯ - QUẢN TRỊ MẠNG 8/2021
Tôi làm việc trong cả lĩnh vực kinh doanh và CNTT, tôi có thể cam đoan rằng, cho dù bạn chọn ngành nghề nào miễn bạn đang làm...
SỬ DỤNG MPLS PING VÀ TRACEROUTE NHƯ THẾ NÀO?
Hiện nay giao thức Multi-protocol Label Switching (MPLS) ngày càng trở nên phổ biến và thường được sử dụng trong các nhà cung cấp dịch vụ lưu trữ và private MPLS clouds thì sử dụng cho các tập đoàn lớn, do vậy chúng ta cần một số công cụ để khắc phục sự cố và duy trì hệ thống mạng này.
“Đối với các nhà cung cấp, việc ping hay traceroute như thông thường là chưa đủ”
Trên thực tế, trong vùng không gian các nhà cung cấp, họ không muốn những core router (P routers) được hiển thị khi khách hành tiến hành traceroute (cả cho vấn đề bảo mật và để giảm sự nhầm lẫn vì hầu hết các nhà cung cấp sử dụng địa chỉ Ip Private cho nội bộ ). Hiện nay các nhà cung cấp dịch vụ tắt tính năng truyền TTL (TTL propa-gation), việc tắt truyền TTL router biên của MPLS cloud sẽ KHÔNG sao chép IP TTL vào MPLS head-er. Điều này làm cho quá trình tra-ceroute của khách hàng sẽ không “thấy” các router trung gian trong Label Swith Path (LSP ) trong cloud của nhà cung cấp.
Ngoài ra, việc ping hay tra-ceroute tiêu chuẩn sẽ không thực sự cho nhà cung cấp biết liệu tuyến đường LSP có hoạt động đúng hay không. Bởi vì cả hai đều sử dụng địa chỉ IP làm target, hãy giả sử quá trình ping hoặc tracer-oute thành công là nhờ vào MPLS và LSP, nhưng nếu như có một sự cố đối với LSP và tất cả các nhãn được bật lên, khi đó sẽ có khả năng core router sẽ định tuyến các gói một cách bình thường (sử dụng bảng routing table) mà không dùng MPLS. Vì thế mặc dù ta biết ping hoặc tracerout thành công nhưng ta không biêt sự thành công đó như thế nào. Do vậy nhà cung cấp cần một số công cụ cần thiết để hỗ trợ MPLS: MPLS Ping và MPLS Tra-ceroute!
MPLS Ping và Traceroute
Việc sử dụng MPLS LSP Ping/ Traceroute trong VCCV (Virtual Circuit Connectivity Verification) cho LDP (Label Distribution Pro-tolol) và LSP Ping rất phù hợp để xác định sự cố LSP ( có thể hiểu là giao thức phân phối nhãn trong MPLS ) bởi một số lí do sau:
Việc sử dụng các gói tin MPLS echo request và reply để kiểm kết nối trong LSPs. Có 2 phương pháp mà downstreamer router (router ở hướng server đi về customer) có thể nhận packet:
Mặc định thì những tính năng này đã có sẵn trê n các router triển khai MPLS. Router nguồn sẽ xác định nhãn cần thiết để có thể đến router đích.
Các tính năng này có thể được truy cập của MPLS router bằng cách sử dụng câu lệnh ping mpls ipv4 hoặc traceroute mpls ipv4. Ở ví dụ dưới đây sẽ cho thấy (lưu ý tar-get ở đây là một route, không phải là một địa chỉ host)Việc xem và đối chiếu trong bảng định tuyến (RIB – routing table), bảng label (LIB – Label Information Table ), bảng thông tin chuyển tiếp nhãn (LFIB - Label Forwarding Information Table) thực sự tốt, do vậy sử dụng các công cụ trên là một cách để kiểm tra LSP có thực sự truyền lưu lượng đến mục tiêu đã cho. Đối với Layer 3 VPN, bạn có thể có được tất cả label bạn cần và các route đều ổn định, nhưng lại không xác định được lưu lượng traffic. Sử dụng MPLS Ping và MPLS Traceroute có thể giúp xác định đường đi đó có thực sự tốt không, nếu không thì vấn đề nằm ở đâu.
R1#ping mpls ipv4 4.4.4.0/24
Sending 5, 100-byte MPLS Echos to 4.4.4.0/24,timeout is 2 seconds, send interval is 0 msec: Codes: ‘!’ - success, ‘Q’ - request not sent, ‘.’ - timeout,
‘L’ - labeled output interface, ‘B’ - unlabeled output interface, ‘D’ - DS Map mismatch, ‘F’ - no FEC mapping, ‘f’ - FEC mismatch,
‘M’ - malformed request, ‘m’ - unsupported tlvs, ‘N’ - no label entry, ‘P’ - no rx intf label prot, ‘p’ - premature termination of LSP,
‘R’ - transit router, ‘I’ - unknown upstream index,
‘l’ - Label switched with FEC change, ‘d’ - see DDMAP for return code, ‘X’ - unknown return code, ‘x’ - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 740/816/868 ms Total Time Elapsed 4160 ms
R1#traceroute mpls ipv4 4.4.4.0/24
Tracing MPLS Label Switched Path to 4.4.4.0/24, timeout is 2 seconds Codes: ‘!’ - success, ‘Q’ - request not sent, ‘.’ - timeout,
‘L’ - labeled output interface, ‘B’ - unlabeled output interface, ‘D’ - DS Map mismatch, ‘F’ - no FEC mapping, ‘f’ - FEC mismatch,
‘M’ - malformed request, ‘m’ - unsupported tlvs, ‘N’ - no label entry, ‘P’ - no rx intf label prot, ‘p’ - premature termination of LSP,
‘R’ - transit router, ‘I’ - unknown upstream index,
‘l’ - Label switched with FEC change, ‘d’ - see DDMAP for return code, ‘X’ - unknown return code, ‘x’ - return code 0
Type escape sequence to abort.
0 10.0.12.1 MRU 1500 [Labels: 16 Exp: 0]
L 1 10.0.12.2 MRU 1500 [Labels: 16 Exp: 0] 348 ms
L 2 10.0.13.3 MRU 1504 [Labels: implicit-null Exp: 0] 360 ms ! 3 10.0.14.4 384 ms
BÁO CỦA DÂN CÔNG NGHỆ - KỸ SƯ - QUẢN TRỊ MẠNG 8/2021
Tôi làm việc trong cả lĩnh vực kinh doanh và CNTT, tôi có thể cam đoan rằng, cho dù bạn chọn ngành nghề nào miễn bạn đang làm...
SỬ DỤNG MPLS PING VÀ TRACEROUTE NHƯ THẾ NÀO?
Hiện nay giao thức Multi-protocol Label Switching (MPLS) ngày càng trở nên phổ biến và thường được sử dụng trong các nhà cung cấp dịch vụ lưu trữ và private MPLS clouds thì sử dụng cho các tập đoàn lớn, do vậy chúng ta cần một số công cụ để khắc phục sự cố và duy trì hệ thống mạng này.
“Đối với các nhà cung cấp, việc ping hay traceroute như thông thường là chưa đủ”
Trên thực tế, trong vùng không gian các nhà cung cấp, họ không muốn những core router (P routers) được hiển thị khi khách hành tiến hành traceroute (cả cho vấn đề bảo mật và để giảm sự nhầm lẫn vì hầu hết các nhà cung cấp sử dụng địa chỉ Ip Private cho nội bộ ). Hiện nay các nhà cung cấp dịch vụ tắt tính năng truyền TTL (TTL propa-gation), việc tắt truyền TTL router biên của MPLS cloud sẽ KHÔNG sao chép IP TTL vào MPLS head-er. Điều này làm cho quá trình tra-ceroute của khách hàng sẽ không “thấy” các router trung gian trong Label Swith Path (LSP ) trong cloud của nhà cung cấp.
Ngoài ra, việc ping hay tra-ceroute tiêu chuẩn sẽ không thực sự cho nhà cung cấp biết liệu tuyến đường LSP có hoạt động đúng hay không. Bởi vì cả hai đều sử dụng địa chỉ IP làm target, hãy giả sử quá trình ping hoặc tracer-oute thành công là nhờ vào MPLS và LSP, nhưng nếu như có một sự cố đối với LSP và tất cả các nhãn được bật lên, khi đó sẽ có khả năng core router sẽ định tuyến các gói một cách bình thường (sử dụng bảng routing table) mà không dùng MPLS. Vì thế mặc dù ta biết ping hoặc tracerout thành công nhưng ta không biêt sự thành công đó như thế nào. Do vậy nhà cung cấp cần một số công cụ cần thiết để hỗ trợ MPLS: MPLS Ping và MPLS Tra-ceroute!
MPLS Ping và Traceroute
Việc sử dụng MPLS LSP Ping/ Traceroute trong VCCV (Virtual Circuit Connectivity Verification) cho LDP (Label Distribution Pro-tolol) và LSP Ping rất phù hợp để xác định sự cố LSP ( có thể hiểu là giao thức phân phối nhãn trong MPLS ) bởi một số lí do sau:
- Gói tin MPLS echo request không thể chuyển tiếp thông qua IP, bởi vì IP TTL được đặt thành 1và địa chỉ IP đích được đặt thành 127/8 (127.x.y.z/8 đây là địa chỉ loopback )
- FEC (Forwarding Equiv-alence Class) không được lưu trong vùng địa chỉ IP đích (như trường hợp của ICMP)
Việc sử dụng các gói tin MPLS echo request và reply để kiểm kết nối trong LSPs. Có 2 phương pháp mà downstreamer router (router ở hướng server đi về customer) có thể nhận packet:
- Cisco đã triển khai MPLS echo request và reply trước đây trên cơ sở Internet Engineering Task Force (IETF) Internet Draft “Detecting MPLS Data Plane Fail-ures”
- Dựa theo IETF RFC 4379 “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Fail-ures.”
Mặc định thì những tính năng này đã có sẵn trê n các router triển khai MPLS. Router nguồn sẽ xác định nhãn cần thiết để có thể đến router đích.
Các tính năng này có thể được truy cập của MPLS router bằng cách sử dụng câu lệnh ping mpls ipv4 hoặc traceroute mpls ipv4. Ở ví dụ dưới đây sẽ cho thấy (lưu ý tar-get ở đây là một route, không phải là một địa chỉ host)Việc xem và đối chiếu trong bảng định tuyến (RIB – routing table), bảng label (LIB – Label Information Table ), bảng thông tin chuyển tiếp nhãn (LFIB - Label Forwarding Information Table) thực sự tốt, do vậy sử dụng các công cụ trên là một cách để kiểm tra LSP có thực sự truyền lưu lượng đến mục tiêu đã cho. Đối với Layer 3 VPN, bạn có thể có được tất cả label bạn cần và các route đều ổn định, nhưng lại không xác định được lưu lượng traffic. Sử dụng MPLS Ping và MPLS Traceroute có thể giúp xác định đường đi đó có thực sự tốt không, nếu không thì vấn đề nằm ở đâu.
R1#ping mpls ipv4 4.4.4.0/24
Sending 5, 100-byte MPLS Echos to 4.4.4.0/24,timeout is 2 seconds, send interval is 0 msec: Codes: ‘!’ - success, ‘Q’ - request not sent, ‘.’ - timeout,
‘L’ - labeled output interface, ‘B’ - unlabeled output interface, ‘D’ - DS Map mismatch, ‘F’ - no FEC mapping, ‘f’ - FEC mismatch,
‘M’ - malformed request, ‘m’ - unsupported tlvs, ‘N’ - no label entry, ‘P’ - no rx intf label prot, ‘p’ - premature termination of LSP,
‘R’ - transit router, ‘I’ - unknown upstream index,
‘l’ - Label switched with FEC change, ‘d’ - see DDMAP for return code, ‘X’ - unknown return code, ‘x’ - return code 0
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 740/816/868 ms Total Time Elapsed 4160 ms
R1#traceroute mpls ipv4 4.4.4.0/24
Tracing MPLS Label Switched Path to 4.4.4.0/24, timeout is 2 seconds Codes: ‘!’ - success, ‘Q’ - request not sent, ‘.’ - timeout,
‘L’ - labeled output interface, ‘B’ - unlabeled output interface, ‘D’ - DS Map mismatch, ‘F’ - no FEC mapping, ‘f’ - FEC mismatch,
‘M’ - malformed request, ‘m’ - unsupported tlvs, ‘N’ - no label entry, ‘P’ - no rx intf label prot, ‘p’ - premature termination of LSP,
‘R’ - transit router, ‘I’ - unknown upstream index,
‘l’ - Label switched with FEC change, ‘d’ - see DDMAP for return code, ‘X’ - unknown return code, ‘x’ - return code 0
Type escape sequence to abort.
0 10.0.12.1 MRU 1500 [Labels: 16 Exp: 0]
L 1 10.0.12.2 MRU 1500 [Labels: 16 Exp: 0] 348 ms
L 2 10.0.13.3 MRU 1504 [Labels: implicit-null Exp: 0] 360 ms ! 3 10.0.14.4 384 ms