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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 3
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 4
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 5
Hagyományos L2 VPN-ek problematikái
EoMPLS
VPLSDark Fiber
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 6
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 7
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)
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 8
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 9
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 10
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 11
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 12
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 13
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 14
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 15
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 16
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.
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 17
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 18
Szomszéd felderítés/PárosításMulticast
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 19
Szomszéd felderítés/PárosításMulticast
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 20
Szomszéd felderítés/PárosításMulticast
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 21
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 22
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 23
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 24
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 25
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
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 26
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ő.
© 2010 Cisco Systems, Inc. All rights reserved.NetworkShop2010 27
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