Là cựu thành viên nhóm nòng cốt của dự án LVS, tôi sẽ khuyên bạn không nên sử dụng công nghệ này để cân bằng nhiều kết nối internet; thực tế tôi gần như có thể đảm bảo với bạn rằng nó sẽ không hoạt động như mong đợi.
Bây giờ, việc xử lý các liên kết nhà cung cấp không thành công thường được gọi là phát hiện cổng chết (DGD) và đôi khi được gọi là phát hiện không thể truy cập hàng xóm (NUD). Theo RFC816 và RFC1122, có nhiều cách để thực hiện DGD, tuy nhiên tôi chỉ thấy khoảng 3 trong số đó (từ một bài đăng cũ của tôi đến danh sách gửi thư của LVS):
- Thông tin lớp liên kết phát hiện và báo cáo lỗi máy chủ đáng tin cậy (ví dụ: ARPANET Destination Dead message) nên được sử dụng làm lời khuyên tiêu cực.
- Thông điệp chuyển hướng ICMP từ một cổng cụ thể nên được sử dụng làm lời khuyên tích cực về cổng đó.
- Các gói đến từ một địa chỉ lớp liên kết cụ thể là bằng chứng cho thấy hệ thống tại địa chỉ này còn sống. Tuy nhiên, việc chuyển thông tin này thành lời khuyên về các cổng yêu cầu ánh xạ địa chỉ lớp liên kết thành địa chỉ IP, sau đó kiểm tra địa chỉ IP đó theo các cổng được chỉ ra bởi bộ đệm tuyến. Điều này có lẽ là không hiệu quả.
Khi tôi rời khỏi sự phát triển mạng nhân linux đang hoạt động vào năm 2006, vẫn chưa có quyết định rõ ràng nào về cách thực hiện các thay đổi trạng thái NUD. Một người bạn của tôi và nhà phát triển cốt lõi của LVS, Julian Anastasov, cần phải giải quyết thách thức của bạn vào năm 2002. Vì vậy, vào một buổi tối, anh ấy ngồi xuống và viết một phiên bản làm việc của DGD để định tuyến tĩnh bằng cách thêm trạng thái NUD vào FIB (thông tin chuyển tiếp căn cứ). Bạn có thể tìm thấy bản vá của mình ở đây và các tài liệu ở đây , đây và đây . Điều này sẽ cung cấp cho bạn nhiều thông tin về nhiệm vụ tiếp theo của bạn trong việc giải quyết nhiệm vụ không tầm thường này. Tôi thấy rằng các bản vá vẫn còn được sử dụng rất nhiều và do đó được cập nhật với các hạt nhân gần đây. Bạn có thể muốn bắt đầu với một tập lệnh như sau (được viết bởiRobert Kurjata ):
#!/bin/bash
# This script is done by : Robert Kurjata Sep, 2003.
# feel free to use it in any useful way
# CONFIGURATION
IP=/sbin/ip
PING=/bin/ping
#--------------- LINK PART -----------------
# EXTIFn - interface name
# EXTIPn - outgoing IP
# EXTMn - netmask length (bits)
# EXTGWn - outgoing gateway
#-------------------------------------------
# LINK 1
EXTIF1=eth2
EXTIP1=
EXTM1=
EXTGW1=
# LINK 2
EXTIF2=eth1
EXTIP2=
EXTM2=
EXTGW2=
#ROUTING PART
# removing old rules and routes
echo "removing old rules"
${IP} rule del prio 50 table main
${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} rule del prio 221 table 221
echo "flushing tables"
${IP} route flush table 201
${IP} route flush table 202
${IP} route flush table 221
echo "removing tables"
${IP} route del table 201
${IP} route del table 202
${IP} route del table 221
# setting new rules
echo "Setting new routing rules"
# main table w/o default gateway here
${IP} rule add prio 50 table main
${IP} route del default table main
# identified routes here
${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto static table 201
${IP} route append prohibit default table 201 metric 1 proto static
${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto static table 202
${IP} route append prohibit default table 202 metric 1 proto static
# mutipath
${IP} rule add prio 221 table 221
${IP} route add default table 221 proto static \
nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\
nexthop via ${EXTGW2} dev ${EXTIF2} weight 3
${IP} route flush cache
while : ; do
${PING} -c 1 ${EXTGW1}
${PING} -c 1 ${EXTGW2}
sleep 60
done
Ngoài ra, bạn có thể kiểm tra tùy chọn chạy các giao thức định tuyến động.