Mielőtt hozzáadja az OTV-t, írja le a szükséges Ethernet-szerződést

Egy munkaigény második adatközpontba költözik, és időkorlátba fut egy szolgáltatásnál, amely az elsőből jól válaszolt. Valaki OTV-t javasol, mert a meglévő Layer 2 VPN „nem csinál broadcastot”. Ez a következtetés általában korai. A szolgáltatáskategória és a megvásárolt konkrét szerződés két különböző kérdés, és az időtúllépés még egyikhez sem kötődött.

A tünet, amely elindítja az összehasonlítást

Írja le, mire van az alkalmazásnak valóban szüksége, mielőtt termékeket hasonlít össze. A helyszínek száma, a VLAN-tartomány, a címek tanulása, a flooding-tolerancia és a hiba viselkedése írja le a követelményt. A „Layer 2” és az „OTV” architektúrákat írnak le, és egyik sem követelmény önmagában. Öt tulajdonság egy lapon tovább él, mint bármely szállító-összehasonlítás.

Ezután ellenőrizze, hogy a jelenlegi szolgáltatás már megfelel-e annak az öt tulajdonságnak. A szolgáltató által kezelt Layer 2 VPN tartalmazhat multipoint továbbítást és vezérlő síkbeli tanulást, amelyet a számla gyors átnézése nem említett.

Ha a jelenlegi szolgáltatás megfelel nekik, az időtúllépés máshol van: MTU-probléma, útválasztási aszimmetria, két helyszín között eltérő tűzfalszabály. Az overlay módosítása ott hagyná ezt az okot, és migrációt is hozzáadna.

Amit a címke nem mond el

A Layer 2 VPN kategória, nem termék. A pont-pont VPWS és a multipoint VPLS másképp továbbít, és a kategória tartalmaz vezérlő síkbeli tanulást és hurkok kezelését is nyújtó szolgáltatásokat, valamint egyszerűbbeket. Feltételezni, hogy minden Layer 2 VPN pontosan két helyszínt kapcsol össze és mindent floodol, a rossz összehasonlítás elkészítésének módja. A szerződésen lévő név semmit sem mond a mögötte lévő továbbítási tábláról.

Kérdezze melyik továbbítási modellt alkalmazza a meglévő szolgáltatás, és melyikre van szüksége az alkalmazásnak. A hub-and-spoke követelmény és a full-mesh követelmény különböző terveket ad, még akkor is, ha mindkettőt Layer 2-ként írják le.

Hol húzza meg OTV a határát

Az OTV IP-transzporton fut, MAC-elérhetőséggel a vezérlő síkban és meghatározott edge-szerepekkel. A helyi spanning-tree információ helyi marad, nem terjed ki egy ellenőrizetlen tartományként a transzporton át. Ez valódi különbség egy egyszerű híd-alapú kiterjesztéshez képest, és ezért fordulnak felé az emberek.

A határ ugyanolyan fontos, mint az előny. Az ismeretlen unicast, broadcast és multicast kezelése a platformtól és annak konfigurációjától függ, és az edge-párnak a támogatott multihoming-mechanizmuson keresztül kell együttműködnie. Két független eszköz, amely ugyanazt a VLAN-t továbbítja, nem ugyanaz a terv, és eltérő hibamódot eredményez.

A flooding csökken, nem eltűnik

Némi felesleges flooding elnyomása nem ugyanaz, mint garancia arra, hogy egyetlen broadcast vagy multicast keret sem jut soha át a kiterjesztésen. Egy helyszínen induló storm még mindig felemésztheti a transzportot, és az egy forgalmi osztályt szűrő platformfunkció nem szűri a többit. Ebből a különbségből fakad a bármilyen overlay miatti csalódás nagy része.

Tehát nem az a kérdés, hogy az OTV megállítja-e a broadcast stormokat. Hanem az, hogy mely forgalmi osztályok lépnek át, milyen feltételek mellett, és mi korlátozza a sebességet, amikor átlépnek.

Ellenőrizze az underlayt, amíg ott van: támogatott bevitel, csomagméret, útválasztás és az a szomszédság, amelyet a választott kiadás igényel. Ezek egyike sem jön ingyen az overlay-jel, és az 1500 bájtos keretet befogadó tunnel nem automatikusan fogadja be a címkézett kereteket.

A szerződés, amelyet írásban kérni kell

Bármelyik szolgáltatást választja, kérje ugyanazt a hat választ: pont-pont vagy multipoint tartomány, az ügyfélkeret és címke kezelése, a MAC-tanulás modellje, a flooding határai, a helyreállítási viselkedés és a maximális keretméret végponttól végpontig. Két azonos nevű szolgáltatás mindegyikben különbözhet. Szerezze be a válaszokat írásban, mert a szolgáltatást konfiguráló mérnök lehet, hogy nem ő válaszol a kérdésre.

Csak olyan követelményhez válasszon változást, amelyet a jelenlegi szolgáltatás bizonyíthatóan nem tud teljesíteni. A VLAN további kiterjesztése az alkalmazás és az Ethernet függőségeit is kiterjeszti vele; az új overlay-név nem távolítja el ezeket.

Az RFC 4664 keretrendszer ismerteti a szolgáltatáskategóriákat és azok továbbítási modelljeit, ez az a szókincs, amelyre szüksége van a helyes kérdés feltevéséhez. Vigye a hat választ és a sikertelen tesztet ugyanarra a megbeszélésre, és a döntés többé nem címkékről szól.