Înainte de a adăuga OTV, scrieți contractul Ethernet de care aveți nevoie

O încărcătură de lucru se mută într-un al doilea centru de date și începe să depășească timpul pe un serviciu care răspundea bine din primul. Cineva propune OTV, pentru că Layer 2 VPN existent „nu face broadcast”. Această concluzie este de obicei prematură. Categoria de serviciu și contractul concret pe care l-ați cumpărat sunt două întrebări diferite, iar depășirea timpului nu a fost încă atribuită niciuneia dintre ele.

Simptomul care începe comparația

Scrieți ce are nevoie de fapt aplicația înainte de a compara produse. Numărul de locații, sfera VLAN, învățarea adreselor, toleranța la flooding și comportamentul la defecțiune descriu cerința. „Layer 2” și „OTV” descriu arhitecturi, iar niciunul dintre ele nu este o cerință în sine. Cinci proprietăți pe o pagină vor supraviețui oricărei comparații de furnizori.

Apoi verificați dacă serviciul actual îndeplinește deja cele cinci proprietăți. Un Layer 2 VPN administrat de furnizor poate include forwarding multipoint și învățare în planul de control pe care o privire rapidă la factură nu le-a menționat.

Dacă serviciul actual le îndeplinește, depășirea timpului este în altă parte: o problemă de MTU, o asimetrie de rutare, o regulă de firewall care diferă între locații. Schimbarea overlay-ului ar lăsa cauza pe loc și ar adăuga o migrare.

Ce nu vă spune eticheta

Un Layer 2 VPN este o categorie, nu un produs. VPWS punct-la-punct și VPLS multipoint forwardează diferit, iar categoria include servicii cu învățare în planul de control și gestionare a buclelor, precum și altele mai simple. Presupunerea că fiecare Layer 2 VPN conectează exact două locații și inundă tot este modul în care se face comparația greșită. Numele de pe contract nu spune nimic despre tabela de forwarding din spate.

Întrebați ce model de forwarding implementează serviciul existent, și de care are nevoie aplicația. O cerință hub-and-spoke și o cerință full-mesh produc proiecte diferite chiar și atunci când ambele sunt descrise ca Layer 2.

Unde OTV își trasează granița

OTV rulează peste un transport IP cu accesibilitate MAC în planul de control și roluri edge definite. Informațiile locale despre spanning-tree rămân locale în loc să fie extinse ca un singur domeniu necontrolat prin transport. Aceasta este o diferență reală față de o extindere simplă în punte, și este motivul pentru care oamenii apelează la el.

Granița contează la fel de mult ca beneficiul. Tratarea unicast, broadcast și multicast necunoscute depinde de platformă și de configurația ei, iar o pereche edge trebuie să coopereze prin mecanismul de multihoming acceptat. Două dispozitive independente care forwardează același VLAN nu sunt același proiect și produc un mod de defectare diferit.

Flooding-ul este redus, nu eliminat

Suprimarea unei părți din flooding-ul inutil nu este același lucru cu garantarea că nicio ramă broadcast sau multicast nu va traversa vreodată extensia. O furtună care începe într-o locație poate consuma în continuare transportul, iar o funcție a platformei care filtrează o clasă de trafic nu le filtrează pe celelalte. Din această distincție vine cea mai mare parte a dezamăgirii cu orice overlay.

Așadar întrebarea nu este dacă OTV oprește furtunile broadcast. Este ce clase de trafic traversează, în ce condiții și ce limitează rata când o fac.

Confirmați underlay-ul cât timp sunteți acolo: livrare acceptată, dimensiunea pachetului, rutare și adiacența cerută de versiunea aleasă. Nimic din toate acestea nu vine gratuit cu overlay-ul, iar un tunel care încape o ramă de 1500 de octeți nu este automat un tunel care încape ramele dumneavoastră etichetate.

Contractul de cerut, în scris

Pentru orice serviciu alegeți, cereți aceleași șase răspunsuri: sferă punct-la-punct sau multipoint, tratarea ramei și a etichetei clientului, modelul de învățare MAC, limitele de flooding, comportamentul de recuperare și dimensiunea maximă a ramei de la un capăt la altul. Două servicii cu același nume pot diferi în fiecare dintre ele. Obțineți răspunsurile în scris, pentru că inginerul care a configurat serviciul poate să nu fie cel care răspunde la întrebare.

Alegeți o schimbare doar pentru o cerință pe care serviciul actual demonstrabil nu o poate îndeplini. Extinderea unui VLAN mai departe extinde și dependențele aplicației și ale Ethernet-ului odată cu el; un nume nou de overlay nu le elimină.

Cadrul RFC 4664 expune categoriile de serviciu și modelele lor de forwarding, adică vocabularul de care aveți nevoie pentru a pune întrebarea corectă. Aduceți cele șase răspunsuri și testul eșuat la aceeași ședință, iar decizia nu mai este despre etichete.