Các LER được xác định trong LSP MPLS bằng LDP như thế nào


8

Lời nói đầu; Trong cấu trúc liên kết bên dưới R1 và R6 là PE, tất cả các bộ định tuyến P khác, tất cả các bộ định tuyến đang chạy c7200-jk9s-mz.124-13b.bin. Tại thời điểm này, IGP được hội tụ đầy đủ (OSPF với tất cả các giao diện trong khu vực 0 để đơn giản) và MPLS được bật trên tất cả các giao diện sử dụng LDP. Không có cấu hình BGP tồn tại vào thời điểm này.

nhập mô tả hình ảnh ở đây

Dưới đây là bảng chuyển tiếp MPLS trên R1;

R1#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Pop tag     10.0.0.2/32       0          Fa0/0      10.0.12.2    
17     Pop tag     10.0.0.3/32       0          Fa0/1      10.0.13.3    
18     Pop tag     10.0.24.0/24      0          Fa0/0      10.0.12.2    
19     Pop tag     10.0.35.0/24      0          Fa0/1      10.0.13.3    
20     20          10.0.57.0/24      0          Fa0/1      10.0.13.3    
21     20          10.0.46.0/24      0          Fa0/0      10.0.12.2    
22     21          10.0.76.0/24      0          Fa0/1      10.0.13.3    
       21          10.0.76.0/24      0          Fa0/0      10.0.12.2    
23     23          10.0.0.4/32       0          Fa0/0      10.0.12.2    
24     24          10.0.0.5/32       0          Fa0/1      10.0.13.3    
25     25          10.0.0.6/32       0          Fa0/0      10.0.12.2    
26     26          10.0.0.7/32       0          Fa0/1      10.0.13.3

Nếu sự hiểu biết của tôi là chính xác, thì R1 đã tạo nhãn cho mỗi FEC và R2 và R3 gửi cho R1 các ràng buộc LDP của chúng (mỗi nhãn MPLS) cho mỗi MPLS FEC mà chúng có. Sử dụng thông tin này, R1 (ví dụ) thực hiện tra cứu lưu lượng theo hướng 10.0.0.6 và PUSHes thẻ gửi đi 25 trước khi gửi gói được gắn thẻ MPLS tới 10.0.12.2 (R2).

Một vài câu hỏi phát sinh ở đây cho tôi;

  1. Sau sự hội tụ ban đầu của mạng, các LSP hiện tồn tại giữa tất cả các FEC thường là giao diện trên các LER kết nối với mạng con. R1 là LER cho LSP đối với R6, là LER khác trong LSP đó. Nếu R7 cũng là một bộ định tuyến PE, ví dụ LSP sẽ tồn tại giữa mỗi giao diện R1 và mỗi giao diện R7 và do đó, nhiều LSP sẽ tồn tại sau đó với R1 và R7 là hai LER cho các LSP đó. Có phải tất cả đều đúng?

  2. Giả sử rằng đường cơ sở là chính xác; Làm thế nào để R1 biết đó là LER cho một LSP kéo dài đến R6 chẳng hạn (và tất cả các LSP có thể khác tồn tại trong cấu trúc liên kết này trong đó R1 là một thiết bị đầu cuối của LSP như nếu chúng tôi giới thiệu R7 là PE như trước đây?) . Đây có phải là do IGP (OSPF trong trường hợp này) có khả năng hiển thị đầy đủ của mạng nên nó (tất cả các cạnh) có thể được tính từ cơ sở dữ liệu IGP?

  3. Nếu 2 là chính xác, làm thế nào chúng ta đã đến giai đoạn đó? Khi mạng được hội tụ đầy đủ với các trao đổi IGP và LDP được hoàn thành, bộ định tuyến PE sẽ xem qua FIB (hoặc đó là IGP RIB?) Và tìm ra tất cả các LDP có thể và đó sẽ là LER cho ai, và ai / LER cho đầu kia là gì?

Câu trả lời:


9

Trước tiên, tôi khuyên bạn nên kiểm tra Câu hỏi thường gặp về MPLS dành cho người mới bắt đầu của Cisco hoặc Bản trình bày NANOG "MPLS cho người giả" của Richard A Steenbergen. Cả hai đều có một số thông tin thực sự tốt.


Như đã nói, hãy để tôi giải quyết từng câu hỏi của bạn. (Tôi đã trích dẫn chúng trong phần dưới đây.)

1: Sau khi hội tụ ban đầu của mạng, các LSP hiện tồn tại giữa tất cả các FEC thường là giao diện trên các LER kết nối với mạng con.

Có, LSP tồn tại đối với tất cả các FEC có thể tiếp cận. Và một gói MPLS bây giờ có thể được chuyển qua mạng.

2: Giả sử rằng đường cơ sở là chính xác; Làm thế nào để R1 biết đó là LER cho một LSP kéo dài đến R6 chẳng hạn

R1 không biết đó là một phần của LSP kéo dài đến R6. Nó chỉ quan tâm đến các nhãn địa phương / kết nối và FEC. Đó là một phần của những gì làm cho MPLS Label Switching nhanh chóng và hiệu quả. Nó không phải biết toàn bộ con đường. Các bộ định tuyến chỉ biết rằng để đạt được FEC1, tôi áp dụng nhãn 1234và giao diện thoát XYZ.

Sau đó, các bước nhảy trong đường dẫn sử dụng cùng một quy trình, hoán đổi trong nhãn hop tiếp theo thích hợp và bật gói.


Đối với câu hỏi dưới cùng, các LER được xác định như thế nào? , bản thân một bộ định tuyến không thực sự biết hoặc quan tâm nếu đó là LER. Nó chỉ biết rằng khi nó nhận được một gói tin được gửi đến đích cục bộ, không có thẻ, nó sẽ cung cấp nó.

Trong đầu ra của bạn ở trên, bạn có thể thấy rằng 4 FEC đi đầu tiên đã Pop tagđược liệt kê là Thẻ gửi đi. Một gói rời khỏi R1 cho một trong các mạng con cục bộ trên R2 hoặc R3 chỉ đơn giản là thẻ của nó được bật lên và chuyển tiếp giao diện thích hợp.

Khi R2 hoặc R3 nhận gói tin đó, họ không thấy nhãn và xử lý nó thông qua quy trình định tuyến thông thường sẽ đưa nó đến giao diện cục bộ.

Để trích dẫn bài viết Wikipedia về MPLS :

Tại bộ định tuyến đầu ra, khi nhãn cuối cùng được bật, chỉ còn lại tải trọng. Đây có thể là một gói IP hoặc bất kỳ loại gói tải trọng nào khác. Do đó, bộ định tuyến đầu ra phải có thông tin định tuyến cho tải trọng của gói, vì nó phải chuyển tiếp nó mà không cần sự trợ giúp của các bảng tra cứu nhãn. Một bộ định tuyến quá cảnh MPLS không có yêu cầu như vậy.


1
Brett, trong khi bạn thực hiện một số điểm công bằng, một điểm chính là định nghĩa LSP của bạn. Bản trình bày NANOG mà bạn trích dẫn không định nghĩa chúng giống như cách mà IETF thực hiện trong RFC 3031 Mục 3.15 ; lưu ý rằng RFC3031 cho phép các LSP LDP và không yêu cầu LSP phải có độ sâu ngăn xếp nhãn lớn hơn 1. Nói cách khác, mạng OSPFv2 có tất cả các nút trong Vùng 0, cũng chạy LDP sẽ tạo LSP duy nhất cho mỗi tuyến trong Bảng IPv4. Đồng thời xem RFC 5283 Phần 4 để biết thêm bằng chứng.
Mike Pennington

1
@MikePennington Rất đúng ... Tôi đã từng nghĩ về các LSP là các đường hầm được cấu hình thủ công hoặc nhiều hơn dọc theo các dòng của RFC 4206 cho kỹ thuật giao thông. Tôi cần phải nghiền ngẫm điều này và cố gắng chỉnh sửa câu trả lời của mình một cách thích hợp. Cảm ơn bạn về thông tin.
Brett Lykins

2
@jwbensley, "LSP tồn tại với tất cả các FEC" và "MP-BGP VPNv4 liên kết các LSP cấp 2 mới cho mỗi tiền tố, mỗi VRF". Aseaudi có ba downvote vì lý do tốt. Tôi chỉ mong mọi người sẽ quan sát downvote và bỏ upvote trừ khi họ thực sự hiểu liệu câu trả lời có đúng không
Mike Pennington

1
@aseaudi, bạn không nói gì về một mạng lưới LSP đầy đủ. Bạn đã nói "Mạng lưới MPLS hoàn toàn bất kỳ" (bất cứ điều gì được cho là). Sau đó, bạn chạy nước rút vào một số cuộc thảo luận về MP-BGP, mặc dù thực tế rằng câu hỏi nói "Không có cấu hình BGP tồn tại vào thời điểm này" . Bạn không trả lời trực tiếp các câu hỏi, bạn đưa cho anh ta một câu trả lời vẫy tay mơ hồ. Tôi tự hào sở hữu một trong những điều đó và sẽ tiếp tục bỏ phiếu trả lời về chất lượng này
Mike Pennington

2
Đây là lý do tại sao giải thích downvote hiếm khi hữu ích. Khi đối mặt với những quan niệm sai lầm của họ, hầu hết mọi người đều hợp lý hóa.
Mike Pennington

-2

Nếu không có cấu hình BGP, bạn chưa có PE, đó là một mạng MPLS hoàn toàn bất kỳ.

Tuy nhiên, khi bạn thêm MP-BGP trên R1 và R6, cả hai có thể được xác định ngay bây giờ là PE, R1 và R6 sẽ thêm một Nhãn MPLS khác và sẽ yêu cầu nhảy áp chót từ bộ định tuyến P áp chót, do đó PE hiện đang là LER cho LSP giữa chúng.

Các bộ định tuyến P không biết về các tuyến đường BGP, họ chuyển tiếp lưu lượng truy cập mpls được gắn nhãn từ các PE dựa trên đường dẫn tốt nhất.

Ngoài ra, PseudoWires có thể được tạo thay vì BGP cho các triển khai như Ethernet qua MPLS và AToM, và sau đó các điểm cuối của bộ định tuyến PW sẽ là LER.

Đây là một mô tả cơ bản, Kiểm tra sách Cơ bản MPLS của CiscoPress.


Cảm ơn thông tin aseaudi. Vì vậy, những gì bạn đang nói là bằng cách thiết lập VPN ngang hàng BGP giữa hai bộ định tuyến, chính hành động đó tạo ra một LSP giữa hai bộ định tuyến?
jwbensley

... Đây có phải là do MPLS phân bổ nhãn cho bước nhảy tiếp theo của BGP?
jwbensley

1
Bộ định tuyến PE đi ra quảng cáo nhãn VPN cùng với tiền tố vpnv4 đến các bộ định tuyến PE xâm nhập có thể thông qua MP-BGP. Đây là Nhãn VPN MPLS cấp độ 2 mà Bộ định tuyến MPLS P không biết.
Aseaudi
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.