L2 hálózati összeköttetés megvalósítása IP gerinc felett Cisco OTV technológiával. NETWORKSHOP2010 Debrecen Zeisel Tamás Cisco Magyarország

L2 hálózati összeköttetés megvalósítása IP gerinc felett Cisco OTV technológiával NETWORKSHOP2010 Debrecen Zeisel Tamás Cisco Magyarország

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

NetworkShop2010

© 2010 Cisco Systems, Inc. All rights reserved.

2

L2 Összeköttetés problematikái LAN/Adatközpont összeköttetés, Data Center B

Data Center A

§ IT Megvalósítás

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

§ Active/Standby Migráció

§ Folyamatos üzemelés

§ Szerver HA kluszter, “Geo-clustering”

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

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

NetworkShop2010


3


NetworkShop2010


4

Hagyományos L2 VPN-ek problematikái EoMPLS

Dark Fiber VPLS

NetworkShop2010


5

Forgalom Optimalzálás hiányosságai § 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 x2

Site A

Site C

MAC 1

MAC 1 propagation

Site B

§ További probléma a kerülő utak kérdése STP protokoll §NetworkShop2010 L2 Multipathing hiánya © 2010 Cisco Systems, Inc. All rights reserved.

6

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) NetworkShop2010


7

Tervezési alapelvek § Data Plane Learning à Control Plane Learning Hozzunk 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ásra Optimá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ég Ideális esetben a multi-home bekötésű telephelyek között VLANonké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

NetworkShop2010


8


NetworkShop2010


9

Overlay Transport Virtualization Technológia elemei OTV “MAC in IP” enkapszulációs technika Layer 2 VPN létrehozására bármely IP transport hálózat felett Dinamikus Enkapszuláció

Protokol alapú tanulás

Nincs Pseudo-Wire fenntartó protokol

Beépített hurok mentesítés

Optimális Bcast/Mcast Replikáció

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

Multi-point kapcsolódás

Egyszerű telephely hozzáadás/kivétel

Point-to-Cloud Model

Automatikus Multihoming

NetworkShop2010


10

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 IP A à IP B

MAC1 à MAC2 Encap MAC

IF

MAC1

Eth1

MAC2

IP B

MAC3

IP B

Server 1 MAC 1 NetworkShop2010

MAC1 à MAC2

MAC1 à MAC2 Decap OTV

OTV

IP B

IP A

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


Server 2 MAC 2 11

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. Edge Device OTV

L2

L3

Core

NetworkShop2010


12

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

Intra-Site Traffic

MAC TABLE

Layer 2 Lookup

VLAN

MAC

IF

100

MAC 1

Eth 2

100

MAC 2

Eth 1

OTV

OTV

MAC 4

MAC 2 Eth 1

Eth 1

IP B

IP A

Eth 2

Eth 2 MAC 1 è MAC 2

MAC 1

L2

L3

Core

L3 L2

MAC 3

East

West

NetworkShop2010


13

OTV Data Plane: Unicast továbbítás MAC routing tábla tartalmazza a MAC cím IP címszerinti elérhetőségét MAC TABLE

OTV Inter-Site Traffic 1 Layer 2 Lookup

MAC TABLE

VLAN

MAC

IF

100

MAC 1

Eth 2

100

MAC 2

Eth 1

100

MAC 3

IP B

100

MAC 4

IP B

VLAN

MAC

100

MAC 1

IP A

5

100

MAC 2

IP A

Layer 2 Lookup

100

MAC 3

Eth 3

100

MAC 4

Eth 4

OTV

OTV

MAC 2

Eth 2

MAC 1 è MAC 3

External IP B

External IP A

Eth 1

MAC 1 è MAC 3

L2

2 Encap

MAC 1

MAC 4 Eth 4 Eth 3

1 è 3MACIP3 A è IP B MAC 1MAC è MAC

IP A è IP B

L3

IF

Core 3

6

L3 L2 MAC 1 è MAC 3

4 Decap

MAC 3

East

West § Nincs Pseudo-Wire protokol § Az enkapszuláció a Layer 2 cél MAC szerint történik. NetworkShop2010


14

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 (54Byte overhead mint VPLSoverGRE esetén)

802.1Q DMAC

SMAC

Eth

IP Header

GRE Header

OTV Header

20B

4B

4B

Payload

802.1Q

DMAC

SMAC

Ether Type

6B

6B

2B

CRC Original Frame

4B

42 Bytes Encapsulation NetworkShop2010


15

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 Mode Nem Multicast képes gerinc esetén statikusan (oAL list alapjá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.

NetworkShop2010


16

Szomszéd felderítés/Párosítás Multicast The West Site sends a “hello” 1 Control OTV Hello Plane

Control Plane

2

3 Core Replication

OTV

Encap

OTV Hello

IP A è Mcast G

OTV Hello

IP A è Mcast G

OTV IP B

IP A IGMP Join

West

IGMP Join

Core IGMP Join

Control Plane NetworkShop2010


OTV

East

IP C

South 17

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

The other sites received the West site’s hello

Control Plane 2 Encap

OTV Hello

3 Core Replication

OTV

Control Plane 4

OTV OTV Hello

IP B

Decap IP A è Mcast G

IP A IGMP Join

IGMP Join

West

Core IGMP Join

4 Decap

OTV Hello



OTV

East

IP C

IP A è Mcast G

OTV Hello

South 18


OTV Hello

7

Control Plane

OTV Hello

6 Core Replication

OTV

Decap

OTV Hello

IP C è Mcast G

OTV

Control Plane 7 Decap

IP B

IP A IGMP Join

IGMP Join

West

Core IGMP Join

OTV Adjacency Established 8

5

OTV Hello

OTV

East

IP C

IP Cè Mcast G

Encap

The South Site sends its hello NetworkShop2010

Control Plane


OTV Hello

South 19


Control Plane

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

Control Plane

OTV

OTV IP B IP A IGMP Join

West

IGMP Join

Core IGMP Join



OTV

East

IP C

South 20

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.

MAC Addresses Reachability

Core

IP A

IP B

East

West

IP C

South NetworkShop2010


21

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ő OTV update is replicated by the core

4 VLAN

1 3 New MACs are learned on VLAN 100 Vlan 100

MAC A

Vlan 100

MAC B

Vlan 100

MAC C

MAC A

IP A

100

MAC B

IP A

100

MAC C

IP A

East

2 IP A

VLAN

West 3

MAC MAC A

IP A

100

MAC B

IP A

MAC South-East C


IF

100

100 NetworkShop2010

IF

100

3

Core

MAC

4

IP A 22

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. Site 2

Site 3

IP C

IP B

oAL Site 1, IP Site 2, IP Site 3, IP Site 4, IP Site 5, IP

Site 1 A B C D E

Core IP A

Adjacency Server

NetworkShop2010


IP E

IP D

Site 4

Site 5

23


NetworkShop2010


24

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

No MAC 3 in the MAC Table

MAC TABLE

OTV

MAC 1 è MAC 3

NetworkShop2010


VLAN

MAC

IF

100

MAC 1

Eth1

100

MAC 2

IP B

Core 25

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ő.

NetworkShop2010


26

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.

The BPDUs stop here

OTV

Core NetworkShop2010


27

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

L2 hálózati összeköttetés megvalósítása IP gerinc felett Cisco OTV technológiával. NETWORKSHOP2010 Debrecen Zeisel Tamás Cisco Magyarország

Recommend Documents