Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

Vòng lặp tuyến (Routing loop)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Vòng lặp tuyến (Routing loop)

    Vòng lặp tuyến (Routing loop)
    Routing loop có thể xảy ra trong các trường hợp sau:
    • Một tuyến nhận được bởi một multihomed site từ backbone qua một kết nối mà có thể chuyển tiếp ngược lại backbone qua kết nối khác.
    • Một tuyến xuất phát từ một multihomed site và được gửi tới backbone qua một kết nối có thể trở về từ một kết nối khác.
    Multihomed Site gửi lại các tuyến cho Backbone:

    - Hình sau mô tả một mạng MPLS VPN cho Customer A có 3 site, Site 1, Site 2 và Site 3. Site 3 là multihomed. Site 3 nhận được tuyến EIGRP 172.16.20.0/24 và redistribute lại vào backbone tại PE1-AS1.

    - Thứ tự thực hiện khi tuyến EIGRP được gửi lại vào backbone như sau:

    (1) 172.16.20.0/24 được quảng bá là internal route tới PE2-AS1.
    (2) PE2-AS1 quảng bá 172.16.20.0/24 tới CE4-A qua EIGRP và gửi 172.16.20.0/24 bằng MP-iBGP session tới PE1-AS1.
    (3) CE4-A quảng bá 172.16.20.0/24 là một EIGRP internal route tới CE3-A
    (4) CE3-A quảng bá 172.16.20.0/24 là một EIGRP internal route tới PE1-AS1

    PE1-AS1 phải ra quyết định chọn đường đi:

    - Nếu cập nhật BGP cho 172.16.20.0/24 tới trước, nó sẽ redistribute vào EIGRP và gửi tới CE3-A. Vì composite metric tốt hơn nên nó chọn đường này vì MPLS VPN không thêm vào giới hạn độ trễ (delay) và băng thông (bandwidth). Nghĩa là PE1-AS1 sẽ không bao giờ nhận được một cập nhật thứ hai và chỉ có một đường để đi.
    - Nếu tuyến EIGRP tới trước, nó sẽ redistribute vào BGP và gửi lại cho PE2-AS1. PE2-AS1 vẫn chọn đường được cập nhật từ EIGRP.
    - Hơn nữa, Bảng định tuyến sẽ chọn đường có chỉ số AD (administrative distance) thấp hơn (EIGRP là 90 hoặc 170; iBGP là 200).

    Backbone gửi lại tuyến vào Multihomed Site:

    - Trường hợp truyến 172.16.50.0/24 xuất phát từ multihomed site được gửi ngược lại qua kết nối với PE.

    - Tình trạng này không xảy ra nếu mạng giữ nguyên AD mặc định vì PE ưu tiên cho các tuyến học từ EIGRP hơn.

    Đếm ra vô cực (Count to Infinity)

    - Hình trên cho thấy PE1-AS1 và/hoặc PE2-AS1 có hai đường đi cho 172.16.50.0/24: một học từ MP-iBGP và một học trực tiếp bằng EIGRP. Nếu 172.16.50.0/24 gặp sự cố (down), trình tự xử lý xảy ra như sau:

    (1) CE3-A và CE4-A gửi ra các thông điệp truy vấn (query message).
    (2) Giả sử PE1-AS1 có hai đường đi như trên, khi nhận 1 query message nó sẽ trả lời với một đường đi liên quan và vẫn còn hoạt động qua MP-iBGP.
    (3) CE3-A sẽ nhận được một đường đi tới 172.16.50.0/24 qua PE1-AS1.
    (4) PE1-AS1 nhận được một thông điệp hủy tuyến (withdrawal message) từ PE2-AS1.
    (5) PE1-AS1 sẽ hủy tuyến mà nó quảng bá tới CE3-A, router này quảng bá thông tin đến cho CE4-A, và CE4-A quảng bá lại cho PE3-AS1.
    (6) Query message bắt nguồn từ PE1-AS1 để tìm mạng 172.16.50.0/24. Khi query message đến được PE2-AS1, PE2-AS1 vừa quảng bá một cập nhật tuyến mới đến được cho mạng 172.16.50.0/24 qua MP-iBGP tới PE1-AS1, PE1-AS1 sẽ tạo lại một cập nhật EIGRP để trả lời cho các query trước đó.
    (7) Tiến trình lặp của các thông điệp reachable/unreachable tiếp tục đến khi qua một lượng tối đa các hop.

    Hiện tượng này được gọi là “count to infinity”

    Định tuyến kém tối ưu (Suboptimal Routing)

    Hiện tượng này xảy ra do AD của EIGRP tốt hơn của iBGP. Một bảng định tuyến luôn luôn ưu tiên cho các tuyến học được từ IGP vì có AD nhỏ hơn iBGP. Hình bên dưới cho thấy các gói dữ liệu từ CE1-A tới CE2-A sẽ được chuyển tiếp bởi PE1-AS1 tới cho CE3-A tạo nên định tuyến kém tối ưu.

    Lặp tuyến và định tuyến kém tối ưu có thể tránh được bằng cách sử dụng:
    - BGP cost community có thể dùng để ép BGP so sánh các tuyến xuất phát từ EIGRP và các tuyến MP-iBGP dựa trên EIGRP metric.
    - EIGRP Site of Origin (SoO) trên các router PE và CE có thể dùng để chống lặp tuyến.

    BGP Cost Community

    - BGP cost community (BGP CC) là một thuộc tính community mở rộng mới của BGP. BGP CC là một thuộc tính non-transitive extended community, nó chỉ qua iBGP và các confederation peer nhưng không đến được external BGP peer.
    - BGP CC cho phép PE so sánh các tuyến đến từ các giao thức khác nhau sử dụng giá trị AD khác nhau dựa trên metric của chúng. Các tuyến BGP mang thuộc tính BGP cost community sẽ dùng EIGRP AD thay vì iBGP AD để so sánh mà không cần cấu hình tĩnh giá trị AD.
    - Các tuyến được redistribute từ EIGRP vào MP-BGP, chúng sẽ được đánh dấu (tag) với thuộc tính BGP cost community để mang composite EIGRP metric thêm vào các thuộc tính EIGRP riêng. Thuộc tính BGP CC được mô tả trong hình sau:

    - Giá trị Điểm chèn (POI – point of insertion) để chắc rằng tuyến BGP được chọn sử dụng BGP CC. Điều này cho phép so sánh các tuyến iBGP với các tuyến EIGRP. BGP CC có thể phân biệt giữa các tuyến EIGRP internal và external bằng trường ID: internal có ID là 128, external có ID là 129. Tuyến có BGP CC ID nhỏ nhất sẽ được chọn. Tuyến internal EIGRP có ID thấp hơn tuyến external. Sự lựa chọn tuyến thường dựa trên giá trị trong trường Cost của BGP CC vì nó mang composite EIGRP metric.

    - Trình tự xảy ra với PE1-AS1 để chọn đường đi tốt nhất dựa trên EIGRP metric và không dựa trên AD giữa EIGRP và iBGP (hình trên):
    (1) CE2-A xuất phát tuyến 172.16.20.0/24 tới PE2-AS1.
    (2) PE2-AS1 chuyển tiếp tuyến tới CE4-A qua EIGRP và tới PE1-AS1 qua MP-iBGP.
    (3) PE1-AS1 nhận hai cập nhật cho 172.16.20.0/24, một qua EIGRP từ CE3-A và một qua MP-iBGP từ PE2-AS1. PE1-AS1 sẽ dùng tuyến học từ MP-iBGP nhờ vào thuộc tính BGP CC.
    (4) Các gói từ CE1-A tới CE2-A sẽ được chuyển tiếp bởi PE1-AS1 tới PE2-AS1 vì bảng định tuyến của VRF A chứa tuyến MP-iBGP, tuyến này mang composite EIGRP metric nhỏ hơn.

    EIGRP SoO

    - EIGRP SoO được thêm vào để gắn với các các tuyến internal và external EIGRP. Thuộc tính này được trao đổi tự động giữa các giao thức định tuyến (SoO-cho phép EIGRP và MP-BGP) để chống lặp tuyến trong môi trường multihome nơi có sử dụng redistribute hai chiều. Tất cả các router CE, hay ít nhất tại các multihomed site, phải hỗ trợ đặc tính này để cho phép quảng bá qua VPN. EIGRP SoO được dùng trên PE và CE để chống lặp tuyến hiệu quả nhất. Các tuyến backdoor được cấu hình với EIGRP SoO để hội tụ nhanh nhất cho việc mất tuyến.

    Multihomed Site và EIGRP SoO

    - Các tuyến được đẩy vào một multihomed site và bị tag với một giá trị EIGRP SoO 1:101. Router PE nhận được sẽ kiểm tra mọi cập nhật giá trị SoO được cấu hình trên giao tiếp nhận cập nhật đó. Nếu giá trị bằng nhau, cập nhật đó sẽ bị hủy, giúp chống lặp tuyến và tối ưu việc định tuyến.

    - Trình tự xảy ra khi 172.16.20.0/24 được quảng bá tới CE1-A:

    (1) CE2-A xuất phát một tuyến 172.16.20.0/24.
    (2) PE2-AS1 chuyển tiếp tuyến tới CE4-A qua EIGRP và tới PE1-AS1 qua MP-iBGP. Tuyến EIGRP sẽ được tag với thuộc tính EIGRP SoO 1:101 để các định tuyến này đến từ backbone.
    (3) CE4-A chuyển tiếp cập nhật 172.16.20.0/24 tới CE3-A.
    (4) PE1-AS1 nhận hai cập nhật cho 172.16.20.0/24, một qua EIGRP từ CE3-A và một qua MP-iBGP từ PE2-AS1. PE1-AS1 sẽ sử dụng tuyến học từ BGP; tuyến EIGRP từ CE3-A bị lọc đi vì có cùng giá trị SoO với giao tiếp nhận nó.

    Backdoor Link và EIGRP SoO

    - Tiến trình chọn tuyến như sau:

    (1) CE2-A quảng bá 172.16.20.0/24 tới PE2-AS1.
    (2) PE2-AS1 chuyển tiếp 172.16.20.0/24, tuyến này tới CE4-A qua EIGRP và tới PE1-AS1 qua MP-iBGP. Tuyến EIGRP sẽ bị tag với giá trị EIGRP SoO là 1:20 để xác định nó đến từ MPLS backbone và được gửi vào Site 4 với giá trị 1:20.
    (3) PE1-AS1 nhận hai cập nhật cho 172.16.20.0, một qua EIGRP từ CE2 và một qua MP-iBGP từ PE2. Cập nhật khi đi qua backdoor link sẽ mang EIGRP SoO giá trị 1:20 khi quảng bá tới CE3-A, và CE3-A sử dụng 1:10 để quảng bá tuyến này tới PE1-AS1.
    (4) PE1-AS1 nhận hai cập nhật cho 172.16.20.0/24, một qua EIGRP từ CE3-A với SoO 1:10, tuyến này bị lọc vì chứa trùng giá trị SoO với giao tiếp nhận nó và chỉ nhận tuyến qua MP-iBGP từ PE2-AS1.




    Phan Trung Tín
    Email: phantrungtin@vnpro.org
    .
    Trung Tâm Tin Học VnPro
    149/1D Ung Văn Khiêm, P.25, Q.Bình Thạnh, Tp.HCM
    Tel: (028) 35124257 (028) 36222234
    Fax: (028) 35124314

    Home Page: http://www.vnpro.vn
    Forum: http://www.vnpro.org
    Twitter: https://twitter.com/VnVnpro
    LinkedIn: https://www.linkedin.com/in/VnPro
    - Chuyên đào tạo quản trị mạng và hạ tầng Internet
    - Phát hành sách chuyên môn
    - Tư vấn và tuyển dụng nhân sự IT
    - Tư vấn thiết kế và hỗ trợ kỹ thuật hệ thống mạng

    Videos: http://www.dancisco.com
    Blog: http://www.vnpro.org/blog
    Facebook: http://facebook.com/VnPro
    Zalo: https://zalo.me/1005309060549762169
    ​​​​​​
Working...
X