Nếu một người cố gắng định cấu hình các adjacencys lân cận mà không khớp MTU, các bộ định tuyến không thể trở thành hàng xóm. Tôi giả sử điều này là để tự bảo vệ giao thức định tuyến khỏi nó nhưng tôi không hiểu nó đang tự cứu nó từ đâu? Điều gì sẽ (có thể) hậu quả sẽ không có MTU phù hợp?

Pete nói :

Tôi không thể nghĩ về một tình huống mà bạn sẽ cần điều này. Tôi chỉ muốn biết logic là gì làm cho điều này kiểm tra rõ ràng trong các giao thức định tuyến này.

Câu trả lời ngắn

Giao thức định tuyến là một số khối xây dựng cơ bản nhất trên internet; chúng ta cần họ rất đáng tin cậy trong mọi trường hợp có thể. Sẽ không tốt khi đưa ra một sự phụ thuộc OSPF hoặc EIGRP trên một MTU không khớp.

Các giao thức định tuyến phải loại bỏ bất kỳ MTU không khớp nào tiềm năng khỏi đường dẫn chuyển tiếp của bộ định tuyến.

Câu trả lời dài

Tôi có thể nghĩ về ba tình huống có thể xảy ra khi bạn tìm thấy các MTU IGP không khớp ...

1. MTU không cố ý không khớp ở Layer2 (ví dụ: nếu ai đó vô tình không khớp MTU trên một dòng nối tiếp hoặc các nhà cung cấp khác nhau có MTU mặc định khác nhau trên cùng một phương tiện)
2. Phù hợp với MTU Layer2, nhưng việc triển khai bộ định tuyến có lỗi làm tính toán sai giao diện IP MTU cần thiết
3. MTU cố ý không phù hợp

Các MTU IP có tương quan trực tiếp với MTU Layer2 (ít nhất là đối với Trường hợp 1 trở lên). Bất kể chúng tôi làm gì, chúng tôi luôn sẵn sàng giảm thiểu các vấn đề từ sự không phù hợp của Lớp 2 MTU không chủ ý, vì không có cơ chế phát hiện MTU Lớp 2 (không giống như IP, có thông báo lỗi ICMP).

Điều này có nghĩa là chúng tôi phải làm mọi cách có thể để tránh sự không phù hợp của Lớp 2 MTU, ngay cả khi Trường hợp 2 và 3 ở trên là thương vong trong việc giảm thiểu các vấn đề với Trường hợp số 1. Trường hợp 1 có ý nghĩa khổng lồ trừ khi chúng tôi giải quyết; tức là bao trùm tất cả lưu lượng truy cập chỉ vì chúng tôi cho phép MTU không khớp.

Chúng tôi luôn giới hạn mẫu số ít phổ biến nhất trên liên kết. Các khung lớn hơn MTU nhận được của một giao diện sẽ bị loại bỏ một cách âm thầm và bộ định tuyến không có cách nào để biết liệu MTU có bị trùng khớp một cách cố ý hay không, liệu nó có vô tình xảy ra hay không.

Do đó, EIGRP và OSPF yêu cầu điều chỉnh Lớp 2 hợp lệ ^{Lưu ý 1} (bao gồm MTU).

Điều gì sẽ (có thể) hậu quả sẽ không có MTU phù hợp?

Trích dẫn John Moy (tác giả của OSPF) trong RFC 2329 Trang 4 :

• Sự cố với tất cả chuyển tiếp IP
• Vấn đề OSPF

Cũng trích dẫn anh ta từ danh sách gửi thư OSPF :

^{Lưu ý 1} một số người hiểu sai ý nghĩa của kề là một khái niệm giao thức định tuyến IP. Khẳng định này bỏ lỡ thực tế rằng mọi thứ (bao gồm IP) đều yêu cầu MTU layer2 phù hợp , để các miền Layer2 hoạt động chính xác.

Một trong những chức năng quan trọng nhất của giao thức định tuyến là xây dựng bảng chuyển tiếp FIB / CEF / hợp lệ. Bảng đó ánh xạ thông tin đã học thông qua các giao thức định tuyến đến thông tin viết lại layer2 . Các mối quan hệ Layer2 trên cùng một liên kết vật lý là điều mà Cisco cũng gọi là kề.

Theo OSPF RFC 2328 (10.6):

Nếu trường Giao diện MTU trong gói Mô tả cơ sở dữ liệu cho biết kích thước datagram IP lớn hơn bộ định tuyến có thể chấp nhận trên giao diện nhận mà không bị phân mảnh, gói Mô tả cơ sở dữ liệu sẽ bị từ chối.

Câu trả lời đơn giản là tiêu chuẩn được thiết kế để bỏ các datagram quá lớn thay vì phân mảnh chúng. Lưu lượng phân mảnh làm tăng gánh nặng CPU của thiết bị và giảm hiệu suất do nhu cầu phân mảnh cần thêm lưu lượng. Xem xét mục tiêu của một giao thức định tuyến động là nó là một giao thức hội tụ ổn định và nhanh chóng, bất cứ điều gì trái với những mục tiêu đó nên được loại bỏ. Đặt yêu cầu cho MTU phù hợp sẽ giúp thực thi yêu cầu hiệu suất này.

Thông tin khác từ OSPF RFC:

4.3.  Routing protocol packets

    The OSPF protocol runs directly over IP, using IP protocol 89.
    OSPF does not provide any explicit fragmentation/reassembly
    support.  When fragmentation is necessary, IP
    fragmentation/reassembly is used.  OSPF protocol packets have
    been designed so that large protocol packets can generally be
    split into several smaller protocol packets.  This practice is
    recommended; IP fragmentation should be avoided whenever
    possible.