Mời thảo luận một câu hỏi hay BGP

[firey]

@nhbduoc: EIGRP là Distance Vector, đặc điểm của Distance Vector là chỉ gửi update cho connected neighbor, vì thế nên trong AS domain, originatorID luôn là next-hop, OrginatorID khác next-hop chỉ trong trường hợp redistribution, khi đó OriginatorID là RouterID (OriginatorID là Originating router). Tại sao redistribution lại cần routerID?

Giả sử topo: (R1--iBGP--(R2)--EIGRP--R3--EIGRP--R4) R2 là điểm Redistribution, giả sử ko có RouterID

R2 redistribute route (1) từ BGP vào EIGRP, external route, AD 170, R4 update route (1). Bây giờ cho R2 và R4 adjacency, R4 update route (1) cho R2, R2 so sánh AD 170 < 200. R2 update route (1) qua R4 --> loop.

Bài toán trên, nếu có RouterID, R2 thấy originatorID trong update R4 là RouterID của mình, discard. Đây là ví dụ loop khi redistribute từ domain AD cao vào domain AD thấp, nhưng dễ hơn rất nhiều vì dữ kiện đầu bài đã bỏ đi RouterID :)) Nói vậy có nghĩa là RouterID trong EIGRP cũng có thể đc dùng để filter external route.

Còn câu“router ID chỉ dùgn chống loop cho distance vector và các giao thư ccó behavior tương tự” có thể có bug, bạn thông cảm. Ý mình là việc sử dụng RouterID để chống loop như trường hợp trên chỉ áp dụng với Distance Vector. Ví dụ với OSPF, OSPF chỉ xem như Link-state trong mỗi area, việc inter-area routing có behaviour giống Distance Vector, nhưng OSPF có cái hay tạo nên thương hiệu “loop-free” của nó là rule “Mọi area phải bám vào area 0” và rule “ABR không inject inter-area route vào area 0” để chống discontigous backbone area, chứ nếu ko thì chắc cũng phải dùng RouterID (hoặc 1 cách khác) để chống loop đấy.

[nbhduoc]

@nhbduoc: EIGRP là Distance Vector, đặc điểm của Distance Vector là chỉ gửi update cho connected neighbor, vì thế nên trong AS domain, originatorID luôn là next-hop, OrginatorID khác next-hop chỉ trong trường hợp redistribution, khi đó OriginatorID là RouterID (OriginatorID là Originating router). Tại sao redistribution lại cần routerID?

Giả sử topo: (R1--iBGP--(R2)--EIGRP--R3--EIGRP--R4) R2 là điểm Redistribution, giả sử ko có RouterID

R2 redistribute route (1) từ BGP vào EIGRP, external route, AD 170, R4 update route (1). Bây giờ cho R2 và R4 adjacency, R4 update route (1) cho R2, R2 so sánh AD 170 < 200. R2 update route (1) qua R4 --> loop.

Bài toán trên, nếu có RouterID, R2 thấy originatorID trong update R4 là RouterID của mình, discard. Đây là ví dụ loop khi redistribute từ domain AD cao vào domain AD thấp, nhưng dễ hơn rất nhiều vì dữ kiện đầu bài đã bỏ đi RouterID :)) Nói vậy có nghĩa là RouterID trong EIGRP cũng có thể đc dùng để filter external route.
.

Cám ơn câu trả lời khá đầy đủ của bạn. Cũng có thể cisco đưa router ID vào giao thức EIGRP để chống loop khi redis như bạn nói, nhưng mình nghĩ kỹ thuật chính trong vấn đề này vẫn là split horizone của EIGRP, R4 không bao giờ quảng bá ngược cái route (1) về lại và nhũng tài liêu mình đọc được về EIGRP, ông cisco cũng nói rất ít về vấn đề Router ID trong EIGRP, chủ yếu họ chỉ cảnh báo về duplicate router ID khi redis. Còn khi khôgn redis, trong AS tất cả router có chung 1 router ID duy nhất nó vẫn chạy tốt.

Ngoài ra mình nghĩ cũng không thể xem originator ID là next-hop được. Ý nghĩa 2 chữ này khác nhau: Originator là người khởi tạo cái route. Trong khi next-hop là ông neighbor nó học được route.

[firey]

OriginatorID là next-hop chỉ là cách nói khi mình so sánh thôi, chứ trong mỗi AS domain thì ko có khái niệm OriginatorID, vì rõ ràng việc update hay bất cứ trao đổi nào cũng chỉ xảy ra giữa connected neighbor với nhau, trong mỗi AS domain thì RouterID vì thế ko có ý nghĩa (ko như Link State, i.e OSPF thì Router LSA và net LSA phải sync trong cả area nên RouterID phải consistent).

Cái vd thì thực ra cũng chỉ là vd thôi, nhưng đâu có quảng bá ngược gì đâu, R4 nhận update từ R3, nó advertise sang R2, 2 link khác nhau mà. Còn RouterID đc sử dụng khi redistribution thì mục đích là xác định và phân biệt các điểm redistribution. Rõ ràng bây giờ redistribute tại nhiều hơn 1 điểm thì vấn đề sẽ phức tạp hơn nhiều. Lúc này vấn đề tách biệt giữa originating router với next-hop là cần thiết đối với bất kỳ giao thức nào. Ngoài ra thì RouterID còn có vai trò gì nữa đâu? (ý mình là mình chưa nghĩ ra vai trò nào khác)

[MrArido]

Cảm ơn ý kiến của bạn,

Nếu bạn đưa RouterID vào:
- Sử dụng RouterID, nghĩa là phải có quá trình trao đổi lúc đầu và keepalive để directly connected router xác định đc routerID hàng xóm của nó. Có cần thiết ko với behaviour của RIP? Có convergence nhanh hơn ko? có tối ưu BW của link ko?

Không cần keepalive đâu bạn à. Tại sao phải xác định RouterID của hàng xóm? Ở đây mình giả sử RIP vẫn làm như cũ: gởi cho tất cả neighbors nên không cần biết neịghbors' RouterIDs --> không thay đổi ảnh hưởng link BW.

- Loop Prevention sẽ xảy ra tại Router nhận update, nghĩa là router gửi update vẫn phải xử lý và gửi toàn bộ route của nó.

"router gửi update vẫn phải xử lý và gửi toàn bộ route của nó" --> Cách làm cũ của RIP cũng là gởi toàn bộ Routes rồi. Ý tưởng này cũng gởi update như cách làm cũ. (EIGRP cũng chống loop ở router nhận update).

- Việc thêm/ sửa RouterID mỗi khi qua một hop ko chỉ làm thay đổi cấu trúc header còn làm giảm performance, chắc chắn giảm Convergence Timing
- Định tuyến trong RIP là flat, non-hierarchical, thế thì originator chính là next-hop, ko những split horizon là quá đủ và gọn nhẹ, mà RouterID hoàn toàn trở thành ko cần thiết

Mình không nghĩ cách làm này làm giảm performance mà mình thấy nó đơn giản hơn nhiều so với việc dùng hold-down timer (không phải chờ hết hold time), split horizon with poison reverse (không phải gởi poison reverse message <-- ảnh hưởng một phần link BW),... <--- cách làm cũ của RIP là kết hợp những kĩ thuật trên. Theo mình ý tưởng này gọn nhẹ, không làm giảm performance.

[firey]

Không cần keepalive đâu bạn à. Tại sao phải xác định RouterID của hàng xóm? Ở đây mình giả sử RIP vẫn làm như cũ: gởi cho tất cả neighbors nên không cần biết neịghbors' RouterIDs --> không thay đổi ảnh hưởng link BW.

À vâng, vậy nghĩa là RouterID ko cần phải consistent, nghĩa là nếu RouterID của các node khác nhau mà giống nhau thì sao? thế thì chúng bảo rằng thế là loop rồi drop luôn à ! Ngoài ra, nếu tại thời điểm này bạn đặt Router A có RouterID là A, loop xảy ra, vì 1 lý do gì đó bạn đổi routerID của RouterA là B, thì lại càng loop à?

"router gửi update vẫn phải xử lý và gửi toàn bộ route của nó" --> Cách làm cũ của RIP cũng là gởi toàn bộ Routes rồi. Ý tưởng này cũng gởi update như cách làm cũ. (EIGRP cũng chống loop ở router nhận update).

Bây giờ nó nhận 1 cái update, nó lại phải đọc thêm 1 chuỗi các RouterID, xử lý (valid thì lại thêm RouterID của nó vào còn invalid thì discard) trong khi với split-horzion thì nó tránh việc gửi những update ko cần thiết với neighbor. Với Reverse Poison thì metric là trường có sẵn trong header, với length = constant, bạn thử so sánh với sử dụng 1 chuỗi routerID thì cấu trúc header sẽ như thế nào?

Mình không nghĩ cách làm này làm giảm performance mà mình thấy nó đơn giản hơn nhiều so với việc dùng hold-down timer (không phải chờ hết hold time), split horizon with poison reverse (không phải gởi poison reverse message <-- ảnh hưởng một phần link BW),... <--- cách làm cũ của RIP là kết hợp những kĩ thuật trên. Theo mình ý tưởng này gọn nhẹ, không làm giảm performance.

Bạn ko thể nói 1 cách định tính là việc xử lý gói tin thế này thế kia là đơn giản, vì router phải xử lý từng gói tin một. Hold-down mặc dù ko tối ưu về tốc độ hội tụ nhưng nó có những ưu điểm của nó mà giao thức đơn giản sử dụng hop-count là metric như RIP có thể triển khai đc, còn việc có đưa Hold-down vào RIP hay DV khác hay ko là tùy thuộc vào vendor. Vấn đề ở đây là routerID ko phù hợp và ko cần thiết với operation của behaviour của RIP, nếu chỉ là vấn đề lịch sử thì sao người ta ko đưa RouterID vào RIPng trong IPv6?