Nhãn để ánh xạ tuyến, khả năng mở rộng tạo nhãn


9

Trong các bộ định tuyến hỗ trợ MPLS, một nhãn duy nhất được tạo cho mỗi tiền tố đích trong Bảng định tuyến hay là mỗi Next-hop trong bảng định tuyến nếu không phải cả hai, cách ánh xạ giữa các nhãn duy nhất và mục nhập bảng định tuyến? Ngoài ra, nếu nó là trên mỗi tiền tố đích, nó có thể sclable như thế nào? Theo hiểu biết của tôi, giá trị nhãn tối đa là 2 ^ 20 = 1048576. Điều gì xảy ra nếu số lượng mục trong bảng định tuyến lớn hơn 1048576?


Bạn có nghiêm túc đề xuất rằng bạn đang xem xét một kịch bản mà ai đó đang tiếp cận 1 triệu mục nhập của LFIB hay đây là một câu hỏi lý thuyết?
Mike Pennington

Tôi hiện đang làm việc với L3, tôi đã thấy các kịch bản của khách hàng tiếp cận 1 triệu tuyến (Các tuyến internet hoàn chỉnh) trong các bộ định tuyến Edge. Nó không vượt qua con số đó. Nhưng tôi đã thấy tổng số mục gần nửa triệu.
Hemanth

có bao nhiêu tuyến IGP + nhãn RSVP-TE? Đó là một thiết kế xấu để liên kết một nhãn cho mỗi tuyến internet. Bạn chỉ nên liên kết nhãn với tất cả các bước nhảy tiếp theo BGP trong bảng IGP của bạn.
Mike Pennington

Liên kết một nhãn trên mỗi BGP nexthop có ý nghĩa. Nhưng MPLS không có hướng dẫn chung nào cho việc tạo nhãn? Không có quy tắc chung nào nói rằng một nhãn duy nhất nên được tạo cho mỗi tiền tố đích hay mỗi nexthop? hoặc chỉ là thực hiện cụ thể?
Hemanth

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:


6

là một nhãn duy nhất được tạo cho mỗi tiền tố đích trong Bảng định tuyến hay là mỗi nhãn Next-hop trong bảng định tuyến? ... Tôi đã thấy các kịch bản khách hàng tiếp cận 1 triệu tuyến đường ... Nhưng MPLS không có bất kỳ hướng dẫn chung nào để tạo nhãn? Không có quy tắc chung nào nói rằng một nhãn duy nhất nên được tạo cho mỗi tiền tố đích hay mỗi nexthop? hoặc chỉ là thực hiện cụ thể?

Dường như có một chút nhầm lẫn. Không có khả năng ai đó muốn phân bổ một nhãn duy nhất cho mỗi tuyến internet. Mạng MPLS được thiết kế tốt sẽ phân bổ nhãn dựa trên các tiền tố IGP được liên kết với bước nhảy tiếp theo BGP của bạn (ref RFC 3031, Phần 4.6 ).

Do đó, tôi không thực sự chắc chắn 1 triệu nhãn trong LFIB là một hạn chế thiết kế MPLS nghiêm trọng hiện nay.


Theo rfc3031 mục4.6, tất cả các bộ định tuyến lõi sẽ phân bổ lables cho tiền tố igp. Nhưng BGP sẽ phân bổ một nhãn duy nhất cho mỗi tuyến (tuyến BGp) mà nó gửi đến ngang hàng BGP. Nhưng ở đây một lần nữa BGP có thể quảng cáo hàng ngàn tuyến phải không? Điều gì sẽ xảy ra nếu số tuyến đường BGP vượt quá 2 ^ 20?
Hemanth

1
@Saran bạn đã đúng, có thể hiểu được là hết nhãn trong kịch bản như vậy (như RFC4364, tùy chọn b). Điều gì sẽ xảy ra là, bạn không thể quảng cáo bất kỳ NLRI nào yêu cầu nhãn mới. Tôi nghĩ rằng điều đó khá khó xảy ra và về mặt kỹ thuật miễn là PE xa xôi có cùng bước tiếp theo, với tiền tố, bạn có thể chia sẻ nhãn. Vì opt-B cần thu gọn tất cả nhãn IGP, VPN thành một nhãn, nên việc tưởng tượng kịch bản có thể xảy ra sẽ dễ dàng hơn một chút, nhưng nó không xuất hiện với tôi.
ytti

@Saran, trong kịch bản bạn đã đề cập, đó là VPN MPLS liên AS . Định tuyến BGP đơn giản mà bạn dường như hỏi về câu hỏi ban đầu của bạn không phân bổ nhãn cho các tuyến BGP theo mặc định. Bất kỳ kịch bản VPN MPLS nào cũng có thể chạy ra khỏi các nhãn được phân phối bởi VPNv4; tại thời điểm đó, bạn cần phân khúc cơ sở khách hàng của mình trên các bộ định tuyến riêng nếu bạn không chạy liên AS.
Mike Pennington

Tùy chọn C chia tỷ lệ như MPLS bình thường, như ngăn xếp [IGP, VPN] bình thường. Tuy nhiên, Tùy chọn B chỉ là [nhãn], cuối cùng cần ánh xạ trong ASBR thành [IGP, VPN]. Vì vậy, trong khi ở OptionC, phần VPN không phải là duy nhất cho hai PE, trong OptionB, mỗi kết hợp [IGP, VPN] cần phải là duy nhất qua liên kết ASBR <-> ASBR.
ytti

@ytti - "Tôi nghĩ rằng điều đó khá khó xảy ra và về mặt kỹ thuật miễn là PE xa xôi có cùng bước nhảy, đối với tiền tố, bạn có thể chia sẻ nhãn." Không có quy tắc cứng nào mà Nhãn cần được tạo ra cho mỗi PRefix (tiền tố BGp)? Tôi hoàn toàn hiểu rằng tốt hơn là chia sẻ một nhãn cho nhiều tiền tố, nếu chúng đi theo cùng một đường dẫn để chuyển đổi. Nhưng câu hỏi là, điều này được quyết định như thế nào? Làm thế nào để bộ định tuyến hạ lưu biết hoặc quyết định tuyến đường nào để chia sẻ một Nhãn. Có phải chỉ là nexthop? nếu nhiều tuyến chia sẻ cùng một nexthop, chúng sẽ chỉ được cung cấp một nhãn?
Hemanth

3

Kịch bản thực tế chính xác khi các nhãn có thể hết. Có một số vấn đề giữ nhà cũng không liên quan trực tiếp đến nhãn hết nhưng đóng góp vào hiệu ứng đó.

Các nhà quản lý nhãn ngày nay trong các nhà cung cấp lớn (ít nhất là CSCO, JNPR) được lập trình để họ cần khối liên tục cho mỗi ứng dụng nhãn. Tất nhiên điều này có thể được khắc phục, với một số chi phí về hiệu suất và độ phức tạp, nhưng chắc chắn là một vấn đề khác cần xem xét.

Một số dịch vụ MPLS khá khao khát không gian nhãn trong lõi, ở rìa hầu như không liên quan vì chúng ta có thể che giấu chúng dưới 'nhãn IGP' của mình.
Chúng ta cần nhớ MPLS không chỉ là về IP, mà là về FEC, nếu chúng ta cần cung cấp một số dịch vụ / đường dẫn khác nhau trong lõi, chúng ta cần FEC mới.

Có một số cuộc thảo luận về việc hỗ trợ nhãn lớnnhãn lớn , trường hợp sử dụng của chúng , mặc dù nhiều khả năng thực hiện sẽ thông qua nhãn mục đích đặc biệt . Cá nhân tôi hy vọng / hy vọng định dạng dây MPLS sẽ được thay đổi trước khi 2 ^ 20 trở thành một vấn đề. Vì MPLS chủ yếu chỉ được sử dụng trong một mạng của nhà điều hành, việc thay đổi định dạng dây cực kỳ dễ dàng so với di chuyển IPv4-> IPV6, do đó, những vấn đề chúng tôi gặp phải sẽ gặp phải, việc giải quyết chúng sẽ khá đơn giản. Một số vấn đề tôi muốn được giải quyết:

  1. Khả năng lưu lại lịch sử nhãn quá cảnh
  2. Chi phí byte thấp (TTL, TC là dự phòng trong các nhãn xếp chồng)
  3. Loại bỏ nhu cầu về tải trọng MPLS P 'vịt gõ' (phá ECMP ngay hôm nay)
  4. Mở rộng theo thiết kế (nhãn mục đích đặc biệt giới thiệu chi phí byte lớn)
  5. Không gian nhãn tăng
  6. Cùng tồn tại với MPLSv1
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.