l2 hálózati összeköttetés megvalósítása ip gerinc felett cisco otv ... · 2012-04-19 ·...

L2 hálózati összeköttetés megvalósítása IP gerinc felett Cisco OTV technológiávalNETWORKSHOP2010 Debrecen

Zeisel TamásCisco Magyarország

© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 2

Miről lesz szó

§ L2 Összeköttetés problematikái

§ Hagyományos L2 VPN-ek korlátai

§ OTV technológia működése

§ OTV technológia előnyei


L2 Összeköttetés problematikáiLAN/Adatközpont összeköttetés,

§ Üzleti igények§ Katasztrófa tűrő redundancia

§ Folyamatos üzemelés

§ Teljesítmény skálázhatóság/mobilitás

Data Center A

§ IT Megvalósítás§ Active/Standby Migráció

§ Szerver HA kluszter, “Geo-clustering”

§ Szerver virtualizálás/konszolidálás“Vmotion”

Data Center B


Miről lesz szó






Hagyományos L2 VPN-ek problematikái

EoMPLS

VPLSDark Fiber


Forgalom Optimalzálás hiányosságai

x2

Site A

Site B

Site C

MAC 1 propagationMAC 1

§ Hagyományos Layer 2 VPN technológiák az egyes eszközök elérhetőségét MAC cím tanulással biztosítják

§ Ismeretlen cím esetén ez szószátyár viselkedést eredményez - minden telephelyet felesleges forgalommal áraszt el

§ Mcast/Bcast replikáció forrás oldalon – nem optimális forgalom szempontból

§ További probléma a kerülő utak kérdése STP protokoll

§ L2 Multipathing hiánya


Pseudo-wire létrehozás/fenntartás § A MAC cím tanulás előtt a teljes elosztott pseudo-wire/tunnel infrastruktúrát létre kell

hozni és fent kell tartani (Tunnel protokol)§ Új telephely be/ki-lépése külön problémás N*(N-1)/2 pseudo-wire§ Multicast /Broadcast kezelés problémáját is meg kell oldani

§ Számos overlay protocolt fejlesztettek a Felhő szerű viselkedés optimalizálásra (pl. DMVPN)


Tervezési alapelvek

§ Data Plane Learning à Control Plane LearningHozzunk létre Control Plane protokolt, ami a megvalósítja a MAC cím hirdetést a hagyományos Data Plane-nen megvalósított MAC cím tanulás helyett

§ Pseudo-wire és Tunnel protokolà Dinamikus EnkapszulációNincs szükség statikus tunnel/pseudo-wire konfigurálásraOptimális Multicast/Brodcast forgalom kezelés – a replikáció nem a tunnel forrás oldalon történik

§ Multi-Homing à Beépített Multi-homing képességIdeális esetben a multi-home bekötésű telephelyek között VLAN-onként megvalósítható load balance megoldás.STP határok létre hozása – minden telephely külön STP tartományt alkot saját root bridge-dzsel


Miről lesz szó






Overlay Transport VirtualizationTechnológia elemei

Protokol alapú tanulás

Beépített hurok mentesítés

Hibahatárok elkülönítése

Egyszerű telephelyhozzáadás/kivétel

Automatikus Multi-homing

Dinamikus Enkapszuláció

Nincs Pseudo-Wire fenntartó protokol

Optimális Bcast/McastReplikáció

OTV “MAC in IP” enkapszulációs technika Layer 2 VPN

létrehozására bármely IP transport hálózat

felett

Multi-point kapcsolódás

Point-to-Cloud Model


OTV működése§ Ethernet forgalom átvitele IP enkapszuláció segítségével:

“MAC in IP”

§ Dinamikus enkapszuláció „MAC routing táblán” alapul

§ Nincs Pseudo-Wire/Tunnel protokol

Kommunikáció két telephely közöttMAC1 (site 1) és MAC2 (site 2)Server 1

MAC 1Server 2MAC 2

OTV OTVMAC IF

MAC1 Eth1

MAC2 IP B

MAC3 IP BIP A IP B

Encap DecapMAC1 à MAC2 IP A à IP B MAC1 à MAC2 MAC1 à MAC2


OTV terminológia: “Edge Device”

§ Az Edge Device csatlakoztatja a telephelyet a (WAN/MAN) gerinchez.

§ Az Edge Device felelős valamennyi OTV funkcióért (ez tartja karban a „MAC routing táblát”)

§ Telephelyenként több OTV Edge Device lehet.

OTVOTV

Core

Edge DeviceEdge

Device

L2 L3


MAC 2

MAC 1

OTVOTV

OTV Data Plane: Unicast továbbítás

Core

MAC TABLE

VLAN MAC IF100 MAC 1 Eth 2

100 MAC 2 Eth 1

MAC 4

MAC 3

OTVOTV

IP A IP B

Intra-Site Traffic

West East

L2 L3 L3 L2

Layer 2Lookup

Eth 1

Eth 2

Eth 1

Eth 2

MAC 1 è MAC 2


Eth 4

Eth 3

MAC TABLE

VLAN MAC IF100 MAC 1 Eth 2

100 MAC 2 Eth 1

100 MAC 3 IP B

100 MAC 4 IP B

MAC 2

MAC 1

OTV Data Plane: Unicast továbbítás

Core

MAC 4

MAC 3

OTVOTV

External IP A

External IP B

West East

L2 L3 L3 L2

OTV Inter-Site Traffic

MAC routing tábla tartalmazza aMAC cím IP címszerinti elérhetőségét

OTVOTV

Encap2

Layer 2Lookup

1

§ Nincs Pseudo-Wire protokol

§ Az enkapszuláció a Layer 2 cél MAC szerint történik.

3 Decap4 MAC 1 è MAC 3

6

MAC TABLE

VLAN MAC IF100 MAC 1 IP A

100 MAC 2 IP A

100 MAC 3 Eth 3

100 MAC 4 Eth 4

Eth 1

Eth 2

Layer 2Lookup

5

MAC 1 è MAC 3

IP A è IP BMAC 1 è MAC 3 MAC 1 è MAC 3IP A è IP BMAC 1 è MAC 3


OTV Data Plane Enkapszuláció§ OTV Ethernet over GRE enkapszulációt használ az OTV headert megfejelve

a VLAN információval

§ A 802.1Q header VLAN mező az OTV fejlécbe másolódik.

§ A gerinc hálózat MTU-nál kell figyelembe venni az enkapszulációt (54Byteoverhead mint VPLSoverGRE esetén)

DMAC SMAC Eth Payload

42 Bytes Encapsulation

6B 6B 2B 20B 4B 4B

DMAC SMACEther Type IP Header

Original Frame 4B

CRCGRE

HeaderOTV

Header

802.1Q

802.1Q


OTV Control Plane:Szomszéd felderítés/Párosítás

§ OTV control plane-hez valamennyi OTV Edge device összepárosított állapotba kell kerüljön

§ Szomszéd felderítés automatikusan két féle módon történik:1. Multicast képes Gerinc

Szomszéd felderítés dinamikusan Multicast IP csomagok segítségével automatikusan zajlik – Ez a preferált mód

2. Adjacency Server ModeNem Multicast képes gerinc esetén statikusan (oAL listalapján) történik a párosítás

§ Ez a két módszer tükröződik a telephelyek közötti Multicast és Broadcast átvitelben is.


Szomszéd felderítés/PárosításMulticast

OTVOTV

Core

OTVOTV

IP A

IP B

West East

IP C

South

OTVOTV

Encap2

OTV Hello

3 CoreReplication

IGMP Join IGMP Join

IGM

P Join

IP A è Mcast GOTV Hello IP A è Mcast GOTV Hello

Control Plane

1The West Site sends

a “hello”Control Plane

Control Plane



OTVOTV

Core

OTVOTV

IP A

IP B

West East

IP C

South

OTVOTVDecap4

OTV Hello

3 CoreReplication

IGMP Join IGMP Join

IGM

P Join

IP A è Mcast GOTV Hello

IP A è Mcast GOTV Hello

Decap4

Encap2

OTV HelloThe other sites received

the West site’s helloControl Plane

Control Plane

Control Plane



OTVOTV

Core

OTVOTV

IP A

IP B

West East

IP C

South

OTVOTV

Encap5

OTV Hello

6 CoreReplication

IGMP Join IGMP Join

IGM

P Join

IP Cè Mcast GOTV Hello

Decap7

IP C è Mcast GOTV Hello

Decap7

OTV AdjacencyEstablished 8

The South Site sends its hello

OTV Hello Control Plane

Control Plane

Control Plane

OTV Hello



OTVOTV

Core

OTVOTV

IP A

IP B

West East

IP C

South

OTVOTV

IGMP Join IGMP Join

IGM

P Join

OTV párok a mcast group alapján jönnek létreControl

PlaneControl Plane

Control Plane


MAC routing tábla felépítés§ Az OTV control plane proactív MAC routing tábla hirdetést végez

(control-plane tanulás).

§ A MAC routing tábla hirdetés az OTV elindítása után háttérben fut.

§ Nem igényel külön konfigurációt.

Core

IP A IP B

IP C

West East

South

MAC AddressesReachability


MAC tábla felépítés– Multicast§ Minden esetben amikor az Edge Device új MAC címet tanul meg az

OTV control plane meghirdeti a hozzátartozó VLAN ID-vel és IP next hop címmel együtt valamennyi szomszédjának

§ Az IP next hop az Edge Device(ok) címe, amin keresztül az adott MAC cím elérhető

Core

IP AWest

East

3 New MACs are learned on VLAN 100

Vlan 100 MAC A

Vlan 100 MAC B

Vlan 100 MAC C

South-East

VLAN MAC IF

100 MAC A

IP A

100 MAC B

IP A

100 MACC

IP A

4

OTV update is replicated by the core

3

3

2

VLAN MAC IF

100 MAC A

IP A

100 MAC B

IP A

100 MACC

IP A

4

3 New MACs are learned on VLAN 100

1


Szomszéd felderítés/Párosítás Adjacency Server mód§ A kijelölt Adjacency Server kezdetben nem ismeri a többi OTV Edge Device-t mert

valmennyi oAL üres.

§ Amennyiben a többi OTV Edge Device elkezdi küldeni saját site-id és IP cím azonosítóját az Adjacency Server felépíti saját oAL-jét

§ Az oAL tartalma unicast csomag formájában hirdetődik az oAL listában szereplő eszközöknek. Ezután az Edge Device-ok párt alkotnak és kommunikálnak egymással.

IP A

Site 1

Site 2 Site 3

Site 4 Site 5

Core

IP BIP C

IP D IP EAdjacency Server

oALSite 1, IP ASite 2, IP BSite 3, IP CSite 4, IP DSite 5, IP E


Miről lesz szó






Ismeretlen Unicast csomag kezelés§ Ismeretlen Unicast csomag továbbítása a gerinc felé szükségtelen és

így eldobásra kerül.

§ A végberendezésekkel szemben elvárás, hogy ne csak fogadjanak csomagot, hanem küldjenek is csomagokat.

§ A csak vételt képviselő eszközök MAC címei ARP táblába történő beírása után Proxy ARP segítségével hirdetődnek

OTVOTV

Core

No MAC 3 in theMAC Table

MAC 1 è MAC 3

MAC TABLE

VLAN MAC IF100 MAC 1 Eth1

100 MAC 2 IP B


Proxy ARP

§ Az Edge Device-ok kezelik az eszközök ARP információit az egyes telephelyek között.

§ Az Edge Device-ok válaszolnak az egyes hostok helyett az OTV telephelyekre irányuló ARP kérésekre - Proxy ARP képesség

§ Proxy ARP segítségéval a gerinc hálózat ARP broadcast forgalma jelentősen csökkenthető.


STP BPDU kezelés

§ Az STP telephelyen belül marad és az Edge Device-ok csak a belső interface-ükön adnak és fogadnak BPDUs csomagokat.

§ Az OTV Edge Device nem indít és továbbít BPDU csomagokat a gerinc felé.

§ Az OTV Edge Device lehet (de nem feltétlenül) a root bridge a telephelyen belüli spanning tree-nek.

OTVOTV

Core

The BPDUsstop here

http://www.cisco.com/en/US/partner/prod/switches/ps9441/nexus7000_promo.html

l2 hálózati összeköttetés megvalósítása ip gerinc felett cisco otv ... · 2012-04-19 ·...

Documents