View Full Version : Cập nhật thông tin trạng thái với giải thuật DUAL_EIGRP ??
1''hpSky
26-02-2004, 02:14 PM
Topology table của router chạy EIGRP chứa tất cả các path quảng bá bởi neighbor tới các known netwoks. Giải thuật cập nhật thông tin định tuyến phân tán (DUAL) sẽ chạy trên table này để tìm ra các successor và feasible successor đồng thời.
Nếu tiêu chuẩn để chọn successor chỉ là cost function tối thiểu (hiểu là hàm mục tiêu, composite metric), và feasible successor chỉ là the next best-cost function, mà không có thêm các tiêu chuẩn gì khác, thì trừ trường hợp node nguồn chỉ có một neighbor đến đích, các trường hợp còn lại luôn cho kết quả ít nhất 2 hoặc successor hoặc successor+ feasible successor => không cần đến Query packets trong các trường hợp này??
Vậy phải chăng query packets chỉ được sử dụng trong trường hợp kiểu như sau:
http://vnpro.org/forum/files/topo_202.jpg
Theo topo này thì mặc dù node nguồn có tới 3 đường đi tới đích, nhưng lại chỉ có một neighbor quảng bá chúng, nên trong bảng topology vẫn chỉ mô tả được một entry, và DUAL chỉ chọn được duy nhất một successor. Nếu successor down nhưng không phải trên link nối tới neighbor của source, cần đến Queries packets, cần đến Replies... Đây có thể là hạn chế không tránh khỏi của định tuyến kiểu next-hop truyền thống??
Mong mọi người cho ý kiến.
themask
26-02-2004, 03:21 PM
??? Mình không hiểu ý bạn HpSky!
" Nếu successor down nhưng không phải trên link nối tới neighbor của source, cần đến Queries packets, cần đến Replies "
"định tuyến kiểu next-hop truyền thống"
1''hpSky
26-02-2004, 04:18 PM
(1) Định tuyến kiểu next-hop được sử dụng bởi các giao thức định tuyến truyền thống trong mô hình chuyển mạch TCP/IP, các router chỉ dùng destination IP address để xây dựng path, và chỉ quan tâm đến việc cần forward gói tin đến next-hop Router nào, thay vì tạo ra một vệt đường đi đến đích (MPLS là một ví dụ). Định tuyến kiểu này có nhiều hạn chế trong việc áp dụng các kỹ thuật QoS, cũng như việc tích hợp công nghệ gói IP với hệ thống chuyển mạch WAN lớp 2 (bạn phải manual config tất cả các PVC trong ATM hay FR switch để định hướng luồng thông tin lớp 3 bởi WAN switch không hiểu IP header, oK?).
(2) Path từ nguồn đến đích là một tập các links (hops). Successor được chọn dựa trên trạng thái của các link này và hàm mục tiêu của path, trong trường hợp distance vector là số hop count, hoặc là một hàm của các metric với EIGRP. Successor sẽ down nếu một trong số các link thuộc path down, oK? Câu trên của mình có nghĩa là successor down vì một link nào đó trên path nhưng không phải là link nối giữa Source Node với Neighbor
Mọi người cho ý kiến nhé.
dangquangminh
26-02-2004, 10:14 PM
Topology table của router chạy EIGRP chứa tất cả các path quảng bá bởi neighbor tới các known netwoks. Giải thuật cập nhật thông tin định tuyến phân tán (DUAL) sẽ chạy trên table này để tìm ra các successor và feasible successor đồng thời.
Nếu tiêu chuẩn để chọn successor chỉ là cost function tối thiểu (hiểu là hàm mục tiêu, composite metric), và feasible successor chỉ là the next best-cost function, mà không có thêm các tiêu chuẩn gì khác, thì trừ trường hợp node nguồn chỉ có một neighbor đến đích, các trường hợp còn lại luôn cho kết quả ít nhất 2 hoặc successor hoặc successor+ feasible successor => không cần đến Query packets trong các trường hợp này??
Vậy phải chăng query packets chỉ được sử dụng trong trường hợp kiểu như sau:
http://vnpro.org/forum/files/topo_202.jpg
Theo topo này thì mặc dù node nguồn có tới 3 đường đi tới đích, nhưng lại chỉ có một neighbor quảng bá chúng, nên trong bảng topology vẫn chỉ mô tả được một entry, và DUAL chỉ chọn được duy nhất một successor. Nếu successor down nhưng không phải trên link nối tới neighbor của source, cần đến Queries packets, cần đến Replies... Đây có thể là hạn chế không tránh khỏi của định tuyến kiểu next-hop truyền thống??
Mong mọi người cho ý kiến.
hi,
query packet chỉ đường dùng khi có một đường đi đến một network nào đó bị down. Query không được dùng để build bảng topology cũng như là bảng neighbor.
Mình không kịp nghiên cứu định tuyến trong MPLS nên cũng không thể kết luận được đây có phải là nhược điểm của kiểu định tuyến next-hop hay không.
Chúc vui,
theo em thì:các sucessor được tạo thành khi router chạy giải thuật DUAL trên topo table, topo table chứa tất cả các link mà router biết đến để đến tất cả các đích, sau khi chạy DUAL, router sẽ add các sucessor vào routing table để tham khảo cho 1 đích cụ thể, succesor==best path to a specific destination, nhưng vì một lý do nào đó, succesor đó bị down, có 2 trường hợp xảy ra:
1. Nếu router tìm thấy trong bảng topo của mình có 1 route thoả Feasible condition(AD<=FD) thì nó không cần chuyển đường đó thành active mà sẽ sử dụng đường thoả FC làm đường thay thế và add vào routing table.
2. Nếu sau khi tìm trong bảng topo mà không thấy có đường nào thoả FC, nó sẽ chuyển đường đó thành active, và gửi các query cho các neighbor với hi vọng sẽ tìm được 1 đường thay thế.Nếu gửi query cho neighbor thì neighbor sẽ gửi lại successor của mình để đến mạng đích, router cụa bộ(gửi query) sẽ sử dụng thông tin đó để tìm đường thay thế.
1''hpSky
27-02-2004, 01:00 PM
Đồng ý. Chỉ một bổ sung nhỏ là Feasible Condition được check với hai điều kiện, là neighbor có AD <=current FD của Successor và minimum computed cost tới đích. Quá trình tìm kiếm 3 bước này diễn ra sau khi successor down. Thật khó giữa việc ưu tiên khả năng tồn tại Feasible Successor trước, hay chuyển trạng thái active-passive trước, bới đằng nào cũng phải giải quyết trường hợp no FC is available ;))
Vậy thì việc chọn Successor đồng thời với Feasible Successor có chính xác hay ko? Ý tưởng mà EIGRP đưa ra là chọn Feasible khi Successor không còn available, điều này đảm bảo rằng FC chỉ được chọn khi có nhu cầu (nếu chọn luôn mà không cần dùng đến không phải là phí hay sao)??
Thế nhưng show ip eigrp topology vẫn thấy FC, và trường hợp topo dẫn ra vẫn là một hạn chế điển hình mà EIGRP gặp phải??
Tiện đây hỏi mọi người: Trường Smooth RoundTrip Timer trong neighbor table được sử dụng trong việc tính toán RTO, vậy RTO được tính với giải thuật ntn??
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.