Se si tenta di configurare le adiacenti adiacenti senza abbinare MTU, i router non riescono a diventare vicini. Presumo che questo sia per proteggere il protocollo di routing da se stesso, ma non capisco da cosa si stia salvando? Quale sarebbe (potrebbe) la conseguenza senza abbinare MTU?

Pete disse :

Non riesco a pensare a una situazione in cui ne avresti bisogno. Volevo solo sapere quale fosse la logica che lo rende un controllo esplicito in questi protocolli di routing.

Risposta breve

I protocolli di routing sono alcuni dei mattoni fondamentali su Internet; abbiamo bisogno che siano molto affidabili in ogni possibile caso. Non serve a nulla far apparire un adiacenza OSPF o EIGRP su un MTU non corrispondente.

I protocolli di routing devono rimuovere eventuali MTU non corrispondenti dal percorso di inoltro del router.

Risposta lunga

Mi vengono in mente tre possibili situazioni in cui potresti trovare MTU IGP non corrispondenti ...

1. Mancata corrispondenza involontaria di MTU su Layer2 (ad esempio, se qualcuno ha accidentalmente non corrispondente MTU su una linea seriale o fornitori diversi avevano MTU predefiniti diversi sullo stesso supporto)
2. Corrispondenza tra MTU Layer2, ma un'implementazione del router presenta un bug che calcola erroneamente l'MTU IP dell'interfaccia richiesta
3. Mancata corrispondenza intenzionale MTU

Le MTU IP sono direttamente correlate alle MTU Layer2 (almeno per il caso 1, sopra). Indipendentemente da ciò che facciamo, siamo sempre in balia della mitigazione dei problemi da disallineamenti MTU Layer2 non intenzionali, poiché non esiste un meccanismo di rilevamento MTU Layer2 (a differenza dell'IP, che presenta messaggi di errore ICMP).

Ciò significa che dobbiamo fare tutto il possibile per evitare disallineamenti MTU Layer2, anche se i Casi 2 e 3 sopra sono vittime di problemi di mitigazione con il Caso numero 1. Il Caso 1 ha implicazioni colossali a meno che non lo risolviamo; vale a dire oscurare tutto il traffico solo perché abbiamo consentito MTU non corrispondenti.

Siamo sempre limitati al minimo comune denominatore sul link. I frame più grandi dell'MTU di ricezione di un'interfaccia vengono scartati silenziosamente e il router non ha modo di sapere se l'MTU era intenzionalmente non corrispondente o se è successo accidentalmente.

Di conseguenza, EIGRP e OSPF richiedono una ^{nota di} adeguamento Layer2 valida ¹ (inclusi gli MTU).

Quale sarebbe (potrebbe) la conseguenza senza abbinare MTU?

Citando John Moy (autore di OSPF) in RFC 2329 Pagina 4 :

• Problemi con tutto l'inoltro IP
• Problemi OSPF

Anche citandolo dalla mailing list OSPF :

^{Nota 1} alcune persone fraintendono il significato di adiacenza come concetto strettamente di protocollo di routing IP. Questa affermazione manca della realtà che tutto (incluso IP) richiede MTU layer2 corrispondenti , affinché i domini Layer2 funzionino correttamente.

Una delle funzioni più importanti di un protocollo di routing è la creazione di una tabella FIB / CEF / forwarding valida. Quella tabella mappa le informazioni apprese tramite i protocolli di routing per riscrivere le informazioni layer2 . Queste relazioni Layer2 sullo stesso collegamento fisico sono ciò che Cisco chiama anche adiacenze.

Secondo la OSPF RFC 2328 (10.6):

Se il campo Interfaccia MTU nel pacchetto Descrizione database indica una dimensione del datagramma IP maggiore di quella che il router può accettare sull'interfaccia di ricezione senza frammentazione, il pacchetto Descrizione database viene rifiutato.

La semplice risposta è che lo standard è stato progettato per eliminare solo datagrammi troppo grandi invece di frammentarli. Il traffico frammentato aumenta l'onere della CPU di un dispositivo e diminuisce le prestazioni a causa della necessità della frammentazione necessaria di traffico aggiuntivo. Considerando l'obiettivo di un protocollo di routing dinamico è che si tratta di un protocollo di convergenza stabile e veloce, qualsiasi cosa contraria a tali obiettivi dovrebbe essere eliminata. L'impostazione del requisito affinché gli MTU corrispondano aiuta a far rispettare questo requisito di prestazioni.

Altro da 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.