Tại máy client, thực hiện lệnh traceroute đến 8.8.8.8 và 8.8.4.4
Hình 4. 4: Kết quả traceroute từ máy client đến 8.8.8.8 (khi chưa bật chế độ cân bằng tải)
Hình 4.5: Kết quả traceroute từ máy client đến 8.8.8.8 (sau khi bật chế độ cân bằng tải)
Hình 4.6: Kết quả traceroute từ máy client đến 8.8.8.8 (trước và sau khi bật chế độ cân bằng tải)
Đối với IP đích 8.8.8.8, bộ cân tải đã chọn gateway 2 làm đường tốt nhất (latency từ client đến 8.8.8.8 thông qua gateway 2 là 0.5 ms, trong khi thơng qua gateway 1 là 62 ms). Cịn đối với IP đích 8.8.4.4, thì gói tin ln đi hướng gateway 1 vì đây là hướng duy nhất có thể đến 8.8.4.4. Tóm lại, dựa vào hình trên cho thấy gói tin đã đi đúng hướng mong muốn.
4.3.2 Kịch bản 2: Test khả năng tự thay đổi hướng truyền dữ liệu khi Best QoS thay đổi hoặc băng thông sắp nghẽn QoS thay đổi hoặc băng thơng sắp nghẽn
Hình 4.7: Kịch bản 2 (Test khả năng tự thay đổi hướng truyền dữ liệu khi Best QoS thay đổi hoặc băng thông sắp nghẽn)
a) Ngữ cảnh
Các kết nối đều hoạt động tốt và còn trống băng thơng
Client thực hiện lệnh “ping 8.8.8.8” (tức gởi gói tin ICMP đến 8.8.8.8)
Bộ cân tải lái dữ liệu qua gateway 2 (vì hướng này QoS tốt nhất và cịn trống băng thông)
b) Sự kiện
Tại gateway 2 giới hạn băng thơng bằng cách chạy script đã cấu hình từ trước. Khi đó, từ bộ cân tải đi 8.8.8.8 thơng qua gateway 2 có tỉ lệ rớt gói rất cao (giả lập trường hợp best QoS bị thay đổi).
c) Phản ứng
Bộ cân tải tự động nhận biết sự thay đổi hướng có Best QoS đến 8.8.8.8, và sau đó lái gói tin đi 8.8.8.8 thơng qua gateway 1.
d) Kết quả kiểm tra phản ứng của kịch bản 2
Tại client thực hiện lệnh “traceroute 8.8.8.8” để xem chiều đi gói của gói tin
Hình 4.8: Kết quả tracert tại kịch bản 2
Dựa vào hình 4.8 cho thấy, lưu lượng đi 8.8.8.8 đã tự động được đổi qua hướng gateway 1 (trước đó là hướng gateway 2)