IPv6 trong một VPN MPLS: ba lựa chọn, không phải một họ địa chỉ
Các tuyến VPN của khách hàng, phiên BGP giữa các PE và vận chuyển trong lõi là những quyết định riêng. Một phiên có thể chạy trong một họ địa chỉ và chở một họ khác.
Nói „chạy một L3VPN IPv6 trên BGP IPv6” trong một buổi đánh giá thiết kế, và trong đúng câu đó ẩn ba quyết định riêng. Những tiền tố nào thuộc VPN của khách hàng, những địa chỉ nào chở phiên định tuyến giữa các biên của nhà cung cấp và lõi nào di chuyển gói có nhãn là những lựa chọn độc lập. Tất cả đều có thể là IPv6, có thể trộn lẫn, và việc trộn được cho phép có chủ ý. Chính việc tách ba thứ đó ra làm biến một yêu cầu mơ hồ thành thứ có thể kiểm thử trên một nền tảng.
Tách ba công việc
Công việc thứ nhất là tuyến của khách hàng: các tiền tố IPv6 thuộc một ngữ cảnh định tuyến VPN và phải nằm ngoài mọi ngữ cảnh khác. Thứ hai là kết nối định tuyến giữa các bộ định tuyến biên của nhà cung cấp trao đổi những tiền tố đó. Thứ ba là vận chuyển đưa gói của khách hàng có nhãn xuyên qua lõi tới biên xa. Chỉ kể tên một trong ba thì vẫn chưa phải là thiết kế.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Mỗi công việc có họ địa chỉ riêng, kiểu hỏng riêng và thường có đội riêng. Bảng này hữu ích chính vì một câu trong tài liệu thiết kế thường có xu hướng ép cả ba dòng thành một.
Họ của tuyến là VPN-IPv6, không phải IPv6 unicast
RFC 4659 định nghĩa họ BGP/MPLS IPv6 VPN, và tư cách thành viên trong đó cụ thể hơn từ IPv6 gợi ý. Tuyến ở đó là bộ phân biệt tuyến gắn với một tiền tố IPv6, được mã hóa dưới AFI 2 và SAFI 128. IPv6 unicast thông thường là họ khác, nên một quảng bá trông giống tiền tố trong looking glass có thể không phải cùng một đối tượng. Đọc sai họ là cách đầu tiên thiết kế này đi chệch.
Khác biệt cắn ở biên, nơi tuyến phải hạ xuống đúng ngữ cảnh VPN trước khi làm bất cứ điều gì. Nhận được tiền tố chứng minh trao đổi đã xảy ra và không nói gì về cài đặt. Khoảng trống đó tạo ra báo cáo kinh điển khi phiên đã lên mà khách hàng vẫn tối.
Phiên có thể chạy trong một họ khác với VPN
Không gì buộc kết nối BGP giữa hai biên phải dùng chính họ của VPN. Đặc tả cho phép phiên IPv4 hoặc IPv6, và bản thân vận chuyển IPv6 VPN được định nghĩa trên cả hai loại lõi. Vì vậy một phiên IPv6 không nói gì về họ của thứ nó chở, và cũng không chọn mặt phẳng dữ liệu. Ba bit độc lập, và thiết kế nên mang cả ba riêng rẽ.
Điều đó giải phóng và đồng thời dễ đọc sai trong cùng một hơi. Các tuyến khách hàng IPv6 có thể đi trên một phiên có địa chỉ IPv4, và tuyến IPv4 đi trên phiên IPv6, miễn là nền tảng hỗ trợ tổ hợp đó và bước nhảy tiếp theo phân giải được. Điều không được xảy ra là để phiên ngụ ý tải trọng, trong tài liệu thiết kế hay trong giám sát về sau chứng minh dịch vụ.
Bước nhảy tiếp theo trên lõi IPv4 có cách mã hóa riêng
Khi lõi bên dưới VPN là IPv4, tuyến không xuất hiện với bước nhảy tiếp theo mà biên vào có thể dùng trực tiếp. Nó đến ở dạng IPv6 được ánh xạ vào IPv4, và đó là cách đặc tả diễn đạt biên ra khi vận chuyển bên dưới là IPv4. Bộ định tuyến vào sau đó phải biến địa chỉ đã ánh xạ ấy thành thứ nó thực sự với tới được qua lõi, và phân giải chính là bước âm thầm thất bại.
Đọc đây như một phụ thuộc chuyển tiếp chứ không phải chuỗi để sao chép giữa các thiết bị. Xác nhận ba điều trên nền tảng bạn thực sự vận hành: bước nhảy tiếp theo được quảng bá phân giải thành đường dùng được, chồng nhãn được chấp nhận, và đích hạ xuống đúng ngữ cảnh VPN dự kiến. Nếu một trong số đó hỏng, còn lại một phiên trông khỏe mạnh mà không chuyển tiếp gì, vì vậy việc kiểm tra thuộc về lượt nghiệm thu chứ không phải một sự cố về sau.
Viết yêu cầu trong bốn dòng
Một yêu cầu đáng kiểm thử nêu bốn thứ: họ của VPN, vận chuyển của phiên, cách mã hóa bước nhảy tiếp theo và cách bố trí lõi. Sau đó nêu một tiền tố khách hàng để theo từ đầu đến cuối: qua trao đổi, cài đặt, phân giải nhãn và đường quay về. „Hỗ trợ BGP IPv6” không bao phủ điều nào trong bốn thứ và giấu chỗ sự không khớp thực sự nằm.
Một phiên khỏe mạnh mà thiếu trao đổi VPN-IPv6 là chưa đầy đủ, và một tuyến VPN nhận được mà thiếu chuyển tiếp hoạt động cũng chưa đầy đủ như vậy. Giữ chúng thành các dòng nghiệm thu riêng giúp cuộc trao đổi xử lý sự cố lần sau ngắn lại, vì dòng đang hỏng đã được ghi sẵn.