Se alguém tentar configurar os adjacentes adjacentes sem combinar o MTU, os roteadores falharão em se tornar vizinhos. Suponho que isso seja para proteger o protocolo de roteamento, mas não entendo do que ele está se salvando. Qual seria (poderia) a consequência sem combinar o MTU?

Pete disse :

Não consigo pensar em uma situação em que você precisaria disso. Eu só queria saber qual era a lógica que torna essa verificação explícita nesses protocolos de roteamento.

Resposta curta

Os protocolos de roteamento são alguns dos blocos de construção mais fundamentais da Internet; precisamos que eles sejam muito confiáveis ​​em todos os casos possíveis. Não é bom exibir uma adjacência OSPF ou EIGRP em uma MTU incompatível.

Os protocolos de roteamento devem remover possíveis MTUs incompatíveis do caminho de encaminhamento do roteador.

Resposta longa

Posso pensar em três situações possíveis em que você encontraria MTUs IGP incompatíveis ...

1. Incompatibilidade não intencional da MTU na Camada2 (por exemplo, se alguém acidentalmente incompatível com MTUs em uma linha serial ou fornecedores diferentes tinham MTUs padrão diferentes na mesma mídia)
2. Correspondência de MTUs da camada 2, mas a implementação do roteador possui um erro que calcula mal a MTU IP da interface necessária
3. Incompatibilidade intencional de MTU

As MTUs IP estão diretamente correlacionadas às MTUs da camada2 (pelo menos no caso 1, acima). Independentemente do que fazemos, estamos sempre à mercê de atenuar os problemas de incompatibilidades involuntárias da MTU da Camada 2, pois não há mecanismo de descoberta da MTU da Camada 2 (ao contrário do IP, que possui mensagens de erro do ICMP).

Isso significa que precisamos fazer todo o possível para evitar incompatibilidades da camada 2 MTU, mesmo que os casos 2 e 3 acima sejam vítimas de problemas de mitigação com o número de caso 1. O caso 1 tem implicações colossais, a menos que seja resolvido; ou seja, colocar o tráfego em preto todo o tráfego apenas porque permitimos MTUs incompatíveis.

Sempre estamos limitados ao denominador menos comum no link. Os quadros maiores que o MTU de recebimento de uma interface são silenciosamente descartados e o roteador não tem como saber se o MTU foi intencionalmente incompatível ou se ocorreu acidentalmente.

Conseqüentemente, o EIGRP e o OSPF requerem adjacências válidas da Camada ^{2, Nota 1} (incluindo MTUs).

Qual seria (poderia) a consequência sem combinar o MTU?

Citando John Moy (autor do OSPF) na RFC 2329 Página 4 :

• Problemas com todo o encaminhamento de IP
• Problemas OSPF

Também o citando na lista de discussão do OSPF :

^{Nota 1:} algumas pessoas entendem mal o significado de adjacência como estritamente um conceito de protocolo de roteamento IP. Essa afirmação perde a realidade de que tudo (incluindo IP) requer MTUs da camada 2 correspondentes , para que os domínios da Camada 2 funcionem corretamente.

Uma das funções mais importantes de um protocolo de roteamento é a construção de uma tabela FIB / CEF / encaminhamento válida. Essa tabela mapeia as informações aprendidas por meio de protocolos de roteamento para reescrever as informações da camada2 . Esses relacionamentos da Camada 2 no mesmo link físico são o que a Cisco também chama de adjacências.

De acordo com o OSPF RFC 2328 (10.6):

Se o campo Interface MTU no pacote Descrição do banco de dados indicar um tamanho de datagrama IP maior que o roteador pode aceitar na interface de recebimento sem fragmentação, o pacote Descrição do banco de dados será rejeitado.

A resposta simples é que o padrão foi projetado para descartar datagramas muito grandes em vez de fragmentá-los. O tráfego fragmentado aumenta a carga da CPU de um dispositivo e diminui o desempenho devido à necessidade de tráfego extra necessário à fragmentação . Considerando o objetivo de um protocolo de roteamento dinâmico, seja um protocolo de convergência estável e rápido, qualquer coisa contrária a esses objetivos deve ser eliminada. Definir o requisito para a correspondência das MTUs ajuda a impor esse requisito de desempenho.

Mais do RFC OSPF:

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.