PBR có thêm bất kỳ độ trễ nào khi thực hiện SNAT giả sử PBR hoàn toàn được thực hiện trong phần cứng không?
Sup720 hỗ trợ PBR trong CTNH , độ trễ bổ sung (nếu có) là không đáng kể vì PBR không thêm hàng đợi giao diện. Tôi nghĩ PBR sẽ khiến mọi thứ trở nên khó khăn hơn mức cần thiết (và tôi vẫn không chắc liệu nó có hoạt động hay không ... các chi tiết cụ thể của tùy chọn đó không hoàn toàn rõ ràng)
Nói ngắn gọn về XFF và SNAT đã đề cập trước đó, PBR có phải là lựa chọn duy nhất ở đây không và cách tốt nhất để giữ PBR được cấu hình chặt chẽ là gì?
PBR không phải là lựa chọn duy nhất. Tùy chọn đề xuất của bạn là một chút không rõ ràng, nhưng PBR thường sôi sục không có gì khác hơn là một cách dễ dàng hơn để thực hiện định tuyến tĩnh.
Thông thường, đây là cấu trúc liên kết tốt nhất cho các dịch vụ cân bằng tải yêu cầu truy vấn SQL ...
- Đặt VIP của bạn trên mạng con phía trước ... 172.16.1.0/24 trong sơ đồ
- Đặt nhóm máy chủ của bạn trong mạng con phía sau ... 172.16.2.0/24 trong sơ đồ
- Đặt các truy vấn SQL của bạn trên một giao diện khác ... 172.16.3.0/24 trong sơ đồ. Thêm giao diện thứ hai cho tất cả các máy chủ yêu cầu truy vấn SQL. Thực hiện tất cả các truy vấn SQL của bạn đến địa chỉ trên mạng con này. Cấu trúc liên kết này hoạt động cho cả Unix và Windows, vì bạn chỉ dựa vào ARP hoặc tuyến máy chủ (tùy theo sở thích của bạn) cho kết nối SQL.
Biểu đồ:
Cấu trúc liên kết này có lợi ích bổ sung:
- Nó phân tách các giao diện SQL khỏi lưu lượng truy cập web, vì các truy vấn SQL rất phức tạp và có thể làm tắc nghẽn lưu lượng truy cập web.
- Nó cung cấp các MTU khác nhau cho các dịch vụ cân bằng tải của bạn (thường cần duy trì ở mức 1500 hoặc thấp hơn, nếu chúng truyền qua internet) và các dịch vụ SQL của bạn (ưu tiên các khung jumbo).
Bất kỳ cấu trúc liên kết cân bằng tải một vũ trang là một lựa chọn ít mong muốn hơn vì bạn kết thúc việc cắt giảm thông lượng tối đa của mình xuống một nửa vì cấu trúc liên kết một vũ trang.
EDIT cho câu hỏi về chuyển đổi CTNH vs SW trên Sup720
Đây là một chủ đề sâu sắc, nhưng tôi sẽ đưa ra phiên bản tóm tắt ... Sup720 áp dụng ACL theo từng hướng (xâm nhập / đi ra) và ACL phải phù hợp với TCAM dựa trên bất kỳ thuật toán hợp nhất nào mà nền tảng đã chọn. Trình quản lý tính năng của Sup720 (tức là fm) chịu trách nhiệm trung gian các tính năng vào TCAM và báo cáo xem bạn có phụ thuộc punt (có nghĩa là chuyển đổi SW) hay không, liệu kết hợp giao thức và hướng được chuyển đổi trong CTNH. Để cô lập liệu
- Đầu tiên, xác định tất cả các giao diện Lớp 3 đi vào và đi ra mà lưu lượng PBR có thể chuyển
- Tiếp theo, kiểm tra đầu ra của
show fm fie int <L3_intf_name> | i ^Interf|Result|Flow|Config(bạn phải xem cả hai hướng vào và ra cho tất cả các giao diện trong Bước 1 ). Lưu lượng truy cập của bạn sẽ được chuyển đổi nếu các giá trị trong CAPS khớp với các giá trị bạn thấy bên dưới ... lưu ý rằng đầu ra của lệnh tôi đang sử dụng rất giống với những gì bạn thấy trong show fm fie summary...
Tx.Core01#sh fm fie int Vl220 | i ^Interf|Result|Flow|Config
Interface Vl220:
Flowmask conflict status for protocol IP : FIE_FLOWMASK_STATUS_SUCCESS <--- in HW
Flowmask conflict status for protocol OTHER : FIE_FLOWMASK_STATUS_SUCCESS <--- in HW
Flowmask conflict status for protocol IPV6 : FIE_FLOWMASK_STATUS_SUCCESS <--- in HW
Interface Vl220 [Ingress]:
FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT <--- in HW
Features Configured : V4_DEF - Protocol : IP
FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT <--- in HW
Features Configured : OTH_DEF - Protocol : OTHER
FIE Result for protocol IPV6 : FIE_SUCCESS_NO_CONFLICT <--- in HW
Features Configured : V6_DEF - Protocol : IPV6
Interface Vl220 [Egress]:
No Features Configured
No IP Guardian Feature Configured
No IPv6 Guardian Feature Configured
No QoS Feature Configured
Tx.Core01#
Giao diện ở trên không hiển thị đầu ra đi ra, nhưng điều đó không liên quan ... đầu ra tương tự như hướng Ingress. Ricky Micky đã viết lên một lời giải thích nổi bật về 'giao diện sh fm fie' nếu bạn muốn biết thêm chi tiết về động lực của các ngân hàng TCAM / kết quả hợp nhất.