MTU와 일치하지 않고 인접 인접성을 구성하려고하면 라우터가 인접이되지 않습니다. 나는 이것이 라우팅 프로토콜을 스스로 보호하는 것이라고 가정하지만 그것이 무엇을 절약하고 있는지 이해하지 못합니까? MTU와 일치하지 않으면 결과는 무엇입니까?

피트는 말했다 :

나는 이것이 필요할 상황을 생각할 수 없다. 방금 이러한 라우팅 프로토콜에서이를 명시 적으로 확인하는 논리가 무엇인지 알고 싶었습니다.

짧은 답변

라우팅 프로토콜은 인터넷에서 가장 기본적인 구성 요소 중 하나입니다. 가능한 모든 경우에 매우 신뢰할 수 있어야합니다. 일치하지 않는 MTU에서 OSPF 또는 EIGRP 인접성을 표시하는 것은 좋지 않습니다.

라우팅 프로토콜은 라우터의 전달 경로에서 일치하지 않는 잠재적 MTU를 제거해야합니다.

긴 대답

일치하지 않는 IGP MTU를 발견 할 수있는 세 가지 가능한 상황을 생각할 수 있습니다.

1. 의도하지 않은 MTU 불일치 계층 2 (예를 들어 누군가가 실수로 직렬 회선의 MTU를 불일치했거나 다른 공급 업체가 동일한 미디어에서 다른 기본 MTU 를 가졌을 경우 )
2. Layer2 MTU와 일치하지만 라우터 구현 에 필요한 인터페이스 IP MTU를 잘못 계산하는 버그 가 있습니다.
3. 의도적 인 MTU 불일치

IP MTU는 Layer2 MTU와 직접 상관됩니다 (적어도 위의 사례 1의 경우). 우리가 무엇을하든 IC2 오류 메시지가있는 IP와 달리 Layer2 MTU 검색 메커니즘이 없기 때문에 의도하지 않은 Layer2 MTU 불일치로 인한 문제를 완화 할 수 있습니다.

즉, 위의 사례 2와 3이 사례 번호 1의 문제를 완화하는 데 피해를 입었더라도 Layer2 MTU 불일치를 피하기 위해 가능한 모든 조치를 취해야한다는 것을 의미합니다. 사례 1은 해결하지 않으면 큰 영향을 미칩니다. 일치하지 않는 MTU를 허용했기 때문에 모든 트래픽을 블랙홀 링합니다.

우리는 항상 링크에서 최소 공통 분모로 제한됩니다. 인터페이스의 수신 MTU보다 큰 프레임은 자동으로 삭제되며 라우터는 MTU가 의도적으로 일치하지 않았는지 또는 실수로 발생했는지 알 수있는 방법 이 없습니다 .

따라서 EIGRP 및 OSPF에는 유효한 Layer2 인접 ^{비고 1} (MTU 포함)이 필요합니다 .

MTU와 일치하지 않으면 결과는 무엇입니까?

RFC의 John Moy (OSPF의 저자) 인용 2329 Page 4 :

• 모든 IP 전달 문제
• OSPF 문제

또한 OSPF 메일 링리스트 에서 그를 인용 :

^{참고 1} 일부 사람들은 엄격하게 IP 라우팅 프로토콜 개념으로 인접성의 의미를 오해합니다. 이 주장 은 Layer2 도메인이 제대로 작동하기 위해 모든 IP (IP 포함) 에 일치하는 layer2 MTU가 필요 하다는 현실을 놓치고 있습니다.

라우팅 프로토콜의 가장 중요한 기능 중 하나는 유효한 FIB / CEF / 전달 테이블을 만드는 것입니다. 이 테이블은 라우팅 프로토콜을 통해 학습 된 정보를 layer2 rewrite info에 매핑합니다 . 동일한 물리적 링크에 대한 이러한 Layer2 관계는 Cisco에서도 인접성이라고합니다.

OSPF RFC 2328 (10.6) 에 따르면 :

데이터베이스 설명 패킷의 인터페이스 MTU 필드에 라우터가 조각화없이 수신 인터페이스에서 허용 할 수있는 것보다 큰 IP 데이터 그램 크기가 표시되면 데이터베이스 설명 패킷이 거부됩니다.

간단한 대답은 표준이 조각화하는 대신 너무 큰 데이터 그램을 삭제하도록 설계되었다는 것입니다. 조각화 된 트래픽은 장치의 CPU 부담을 증가시키고 조각화에 필요한 추가 트래픽 이 필요하므로 성능이 저하됩니다 . 동적 라우팅 프로토콜의 목표는 안정적이고 빠른 수렴 프로토콜이라는 점을 고려하면 이러한 목표와 반대되는 것은 제거해야합니다. MTU가 일치하도록 요구 사항을 설정하면이 성능 요구 사항을 적용하는 데 도움이됩니다.

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.