Cấu hình dự phòng bằng cách sử dụng tĩnh nổi


7

Tôi muốn đăng bố cục mạng của mình, nhưng tôi không có danh tiếng cần thiết. Vì vậy, tôi đã tạo ra một sơ đồ mạng dưới đây:

       ISP
       / \
      /   \
     /     \
    HQ------Branch
    |         |
  HQ-PC      B-PC

Những gì tôi đang cố gắng làm là sử dụng Liên kết WAN giữa HQ và Chi nhánh làm liên kết dự phòng và nó không được mang bất kỳ dữ liệu nào trừ khi liên kết giữa HQ với ISP hoặc Chi nhánh đến ISP bị hỏng. Có nghĩa là nó chỉ được sử dụng như một liên kết dự phòng.

Những gì tôi đã làm là sử dụng float tĩnh để cấu hình dự phòng. Tuy nhiên, nó không hoàn toàn diễn ra như những gì tôi mong đợi. Những gì tôi đã làm là:

1) tuyến đường mặc định tại HQ và Chi nhánh đến ISP (0.0.0.0 0.0.0.0 NEXT-HOP-IP)

2) tuyến tĩnh tại ISP đến HQ và Chi nhánh (HQ / BRANCH-NETWORK-ĐỊA CHỈ SUBNET-MASK NEXT-HOP-IP)

3) tuyến đường tĩnh (được ưa thích) tại HQ (BRUC-NETWORK-ĐỊA CHỈ SUBNET-MASK NEXT-HOP-IP-TO-ISP)

4) tuyến tĩnh (ưa thích) tại Chi nhánh (HQ-NETWORK-ĐỊA CHỈ SUBNET-MASK NEXT-HOP-IP-TO-ISP)

5) tuyến đường tĩnh (dự phòng) nổi tại HQ (BRUC-NETWORK-ĐỊA CHỈ SUBNET-MASK NEXT-HOP-IP-TO-HQ-THROUGH-BACKUP-LINK)

6) tuyến đường tĩnh (dự phòng) nổi tại Chi nhánh (HQ-NETWORK-ĐỊA CHỈ SUBNET-MASK NEXT-HOP-IP-TO-BRANCH-THROUGH-BACKUP-LINK)

Tuy nhiên, có một vấn đề. Ví dụ: nếu liên kết giữa ISP và HQ không hoạt động, khi tôi muốn ping từ HQ-PC sang B-PC, gói sẽ được gửi thành công từ HQ-PC đến B-PC, nhưng gói trả về từ B-PC sẽ được gửi đến ISP và không thông qua liên kết dự phòng.

Rất xin lỗi vì một bài viết dài như vậy, nhưng có ai có thể giúp tôi không? Nếu lời giải thích của tôi không rõ ràng, xin vui lòng truy vấn. Cảm ơn trước

EDIT: Xin lỗi vì sự nhầm lẫn, không nên có bất kỳ giao thức định tuyến nào chạy với ISP


Bạn đang làm BGP cho ISP? nếu vậy, điều này trở nên dễ dàng hơn, nếu không, vâng ... có nhiều cách nhưng nó sẽ không vui như thế.
Olipro

1
Yêu cầu là họ không muốn chạy bất kỳ giao thức định tuyến nào với ISP
bob

1
@bob, vui lòng cho tôi biết công ty của bạn đang mã hóa lưu lượng liên văn phòng mà họ đang gửi qua internet
Mike Pennington

Có câu trả lời nào giúp bạn không? nếu vậy, bạn nên chấp nhận câu trả lời để câu hỏi không xuất hiện mãi mãi, tìm kiếm câu trả lời. Ngoài ra, bạn có thể cung cấp và chấp nhận câu trả lời của riêng bạn.
Ron Maupin

Câu trả lời:


9

Như bạn đã đề cập, các tuyến tĩnh của bạn bị hỏng, vì không có cách nào để buộc chuyển đổi dự phòng sang liên kết WAN tại cả hai trang web khi một trang web mất liên kết lên internet.

Giải pháp tốt nhất cho vấn đề này là thiết lập một số dạng đường hầm được định tuyến (có nguồn gốc từ các địa chỉ liên kết ISP trên R1 và R2 trong sơ đồ) thông qua internet, chạy giao thức định tuyến động (OSPF / EIGRP) thông qua đường hầm và sao lưu của bạn WAN và đặt các số liệu định tuyến cho liên kết WAN cao hơn nhiều.

Đường hầm dự phòng

Vì bạn lấy nguồn đường hầm từ các liên kết internet ở cả hai bên, nếu một trong hai bên mất kết nối internet thì đường hầm bị phá vỡ (và IGP khôi phục lại liên kết WAN của bạn). Nếu bạn làm điều này, hãy chắc chắn rằng PMTUD hoạt động thông qua đường hầm để tính phí trên đường hầm. Loại VPN được mã hóa liên văn phòng này khá phổ biến, vì vậy đây là một cấu trúc liên kết quen thuộc cho bất kỳ ai phải hỗ trợ mạng này trong tương lai.

Vấn đề bạn gặp phải với thiết kế hiện tại của bạn là tất cả lưu lượng truy cập giữa các văn phòng của bạn dường như không được mã hóa (ít nhất là nếu tôi đọc câu hỏi của bạn theo mệnh giá). Nếu bạn chưa làm như vậy, tôi thực sự khuyên bạn nên mã hóa tất cả lưu lượng truy cập giữa các trang web công ty của mình, nếu nó thông qua internet .


@bob, mô hình thiết bị mạng nào bạn có tại mỗi trang web? nếu cisco eqpt, vui lòng bao gồm bộ tính năng ios bạn có
Mike Pennington

5

(Câu trả lời all-BGP ban đầu đã thay đổi, theo yêu cầu của OP không có định tuyến động đến ISP)

Như @Mike đề xuất, đường hầm + định tuyến động, đặc biệt là trong mặt INET là giải pháp vững chắc. Nhưng nếu vì lý do nào đó bạn không muốn đường hầm (không hỗ trợ CTNH, không muốn mất MTU, định tuyến động không được chấp nhận ngay cả trong nội bộ) thì tùy chọn khác của bạn là các tuyến được theo dõi 'IP SLA'.

Tôi sẽ giải thích cách nó giúp trong vấn đề chính xác mà bạn mô tả, nơi chi nhánh tiếp tục trả lại lưu lượng truy cập cho INET, trong khi nó nên sử dụng liên kết trực tiếp.

Trong chi nhánh bạn có:

ip route HQNet HQMask InetIF InetNH track 1 50
ip route HQNet HQMask DirectIF DirectNH 100
ip route HQStableTestIP 255.255.255.255 InetIF InetNH
!
track 1 ip sla 1
!
ip sla 1
 icmp-echo <HQStableTestIP> source-interface InetIF
ip sla schedule 1 start-time now

Bây giờ nếu HQ không thể truy cập qua INET, việc theo dõi sẽ thất bại và tuyến đường cụ thể hơn của INET sẽ bị vô hiệu và bạn nên chuyển sang tuyến tốt nhất tiếp theo chỉ đến liên kết trực tiếp.


thực sự xin lỗi vì sự cố này, đó là sai lầm của tôi khi không nói rằng không nên có bất kỳ giao thức định tuyến nào chạy với isp :(
bob

Sau đó, tốt nhất bạn có thể làm là sử dụng 'IP SLA' để theo dõi các tuyến tĩnh. Để mạnh mẽ chống lại việc theo dõi các vấn đề liên quan, bạn cần ba tuyến 1) chỉ vào chính, theo dõi 2) chỉ vào theo dõi phụ 3) chỉ vào chính, không bị theo dõi (cần thứ 3 vì vậy nếu tất cả theo dõi không thành công, bạn vẫn sẽ cố gắng sử dụng kết nối chính, thay vì từ bỏ). Các câu hỏi khác trong trang web này có ví dụ IP SLA.
ytti

Câu trả lời ban đầu đã thay đổi để phản ánh yêu cầu mới
ytti

1
OP thực sự cần mã hóa lưu lượng truy cập của mình thông qua internet ... sau khi xem xét câu hỏi nhiều lần, tôi ngày càng tin rằng anh ấy hiện đang gửi lưu lượng truy cập nội bộ của mình dưới dạng văn bản rõ ràng.
Mike Pennington

1
Các bộ phim bắt buộc xung quanh sư phạm được ghi nhận. Tin tưởng mọi khóa vào tập lệnh là một giải pháp có thể chấp nhận được, miễn là người khác tự thủ công vào cùng một thiết bị có bật kiểm tra khóa ... khi bạn dành cả đời để tự động hóa các phiên CLI, có một số lựa chọn nhất định bạn sẽ không bao giờ làm cho con người để giữ làm việc từ xoắn ốc thành các giải pháp xác suất thấp. Biểu đồ của OP có thể hoặc không thể phản ánh việc chuyển sang cùng một ISP ... đó có thể chỉ đơn giản là một tạo tác của việc không muốn làm phức tạp một sơ đồ nghệ thuật với những gì anh ta xem xét các chi tiết không cần thiết
Mike Pennington
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.