Prima di aggiungere OTV, scrivete il contratto Ethernet che vi serve

Un carico di lavoro si sposta in un secondo data center e inizia ad andare in timeout su un servizio che dal primo rispondeva bene. Qualcuno propone OTV, perché il Layer 2 VPN esistente «non fa broadcast». Questa conclusione è di solito prematura. La categoria di servizio e il contratto specifico che avete acquistato sono due domande diverse, e il timeout non è ancora stato attribuito a nessuna delle due.

Il sintomo che avvia il confronto

Scrivete ciò di cui l’applicazione ha realmente bisogno prima di confrontare i prodotti. Il numero di sedi, l’ambito VLAN, l’apprendimento degli indirizzi, la tolleranza al flooding e il comportamento in caso di guasto descrivono il requisito. «Layer 2» e «OTV» descrivono architetture, e nessuno dei due è un requisito di per sé. Cinque proprietà su una pagina sopravvivranno a qualsiasi confronto tra fornitori.

Poi verificate se il servizio attuale soddisfa già queste cinque proprietà. Un Layer 2 VPN gestito dal provider può includere inoltro multipoint e apprendimento nel piano di controllo che un’occhiata rapida alla fattura non menzionava.

Se il servizio attuale le soddisfa, il timeout è altrove: un problema di MTU, un’asimmetria di routing, una regola del firewall che differisce tra le sedi. Cambiare l’overlay lascerebbe quella causa al suo posto e aggiungerebbe una migrazione.

Ciò che l’etichetta non vi dice

Un Layer 2 VPN è una categoria, non un prodotto. VPWS punto-punto e VPLS multipoint inoltrano in modo diverso, e la categoria comprende servizi con apprendimento nel piano di controllo e gestione dei loop oltre a quelli più semplici. Presumere che ogni Layer 2 VPN colleghi esattamente due sedi e inondi tutto è il modo in cui si fa il confronto sbagliato. Il nome sul contratto non dice nulla sulla tabella di inoltro che sta dietro.

Chiedete quale modello di inoltro implementa il servizio esistente, e quale serve all’applicazione. Un requisito hub-and-spoke e un requisito full-mesh producono progetti diversi anche quando entrambi sono descritti come Layer 2.

Dove OTV traccia il suo confine

OTV funziona su un trasporto IP con raggiungibilità MAC nel piano di controllo e ruoli edge definiti. Le informazioni spanning-tree locali restano locali invece di essere estese come un unico dominio non controllato attraverso il trasporto. Questa è una differenza reale rispetto a una semplice estensione bridged, ed è il motivo per cui le persone vi ricorrono.

Il confine conta quanto il beneficio. La gestione di unicast, broadcast e multicast sconosciuti dipende dalla piattaforma e dalla sua configurazione, e una coppia edge deve cooperare tramite il meccanismo di multihoming supportato. Due dispositivi indipendenti che inoltrano lo stesso VLAN non sono lo stesso progetto, e producono una modalità di guasto diversa.

Il flooding è ridotto, non rimosso

Sopprimere parte del flooding non necessario non è lo stesso che garantire che nessun frame broadcast o multicast attraversi mai l’estensione. Una tempesta che inizia su una sede può ancora consumare il trasporto, e una funzione della piattaforma che filtra una classe di traffico non filtra le altre. Da questa distinzione deriva la maggior parte della delusione con qualsiasi overlay.

Quindi la domanda non è se OTV ferma le tempeste broadcast. È quali classi di traffico attraversano, a quali condizioni, e cosa limita la velocità quando lo fanno.

Confermate l’underlay mentre siete lì: consegna supportata, dimensione dei pacchetti, routing e l’adiacenza richiesta dalla versione scelta. Niente di tutto ciò è gratuito con l’overlay, e un tunnel che contiene un frame di 1500 byte non è automaticamente un tunnel che contiene i vostri frame etichettati.

Il contratto da chiedere, per iscritto

Per qualunque servizio scegliate, chiedete le stesse sei risposte: ambito punto-punto o multipoint, gestione del frame e del tag del cliente, modello di apprendimento MAC, limiti di flooding, comportamento di ripristino e dimensione massima del frame da estremo a estremo. Due servizi con lo stesso nome possono differire su ciascuna di esse. Ottenete le risposte per iscritto, perché l’ingegnere che ha configurato il servizio potrebbe non essere quello che risponde alla domanda.

Scegliete un cambiamento solo per un requisito che il servizio attuale dimostrabilmente non può soddisfare. Estendere un VLAN ulteriormente estende anche le dipendenze dell’applicazione e di Ethernet con esso; un nuovo nome di overlay non le elimina.

Il quadro RFC 4664 espone le categorie di servizio e i loro modelli di inoltro, che è il vocabolario necessario per porre la domanda giusta. Portate le sei risposte e il test fallito alla stessa riunione, e la decisione smette di riguardare le etichette.