CCIE.pl

site 4 CCIE wannabies
It is currently 18 Jan 2017, 23:12

All times are UTC+01:00




Post new topic  Reply to topic  [ 19 posts ]  Go to page 1 2 Next
Author Message
Post #1 Posted: 07 May 2016, 13:16 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
EDIT:
Wydzielony wątek z http://ccie.pl/viewtopic.php?p=158109
=====================================

horac wrote:
No chetnie bym to obejrzal, bo jak do tej pory slysze opinie odwrotne ze NSX czy inne rozwiazanie oparte o VXLAN komplikuje infrastrukture Data Center, dlatego ze przenosi to co obecnie jest skomplikowane na warstwie fizycznej sieci DC na warste hypervisora.

Dzięki przeniesieniu funkcji sieciowych blisko maszyn wirtualnych odwzorowanie topologii logicznych jest prostsze. Przykładem jest choćby funkcja Anycast Gateway, czy też Distributed FW. Nie mówiąc już o tym, że można znacząco uprościć sieć podkładową oraz styk z serwerami. Dodatkowo zcentralizowane zarządzanie zmniejsza dodatkowo narzut operacyjny.

horac wrote:
Dodatkowo ukrywa widocznosc tego co sie dzieje przed siecia fizyczna (Fizyczne linki i switche DC musza jedynie posiadac infromacje jak dostac sie do Hypervisora(VTEP))

Ten argument świadczy o uproszczeniu sieci fizycznej i nie jest jednocześnie argumentem, że cała architektura jest bardziej skomplikowana. Jednocześnie wykorzystanie sieci nakładkowej przynosi dodatkowe korzyści związane ze skalowalnością, bezpieczeństwem oraz wymaganiami środowisk multitenant. Zresztą tak, jak w MPLS VPN. Odwzorowanie dzisiaj sieci MPLS VPN za pomocą VLAN-ów, routingu w sieci fizycznej, czy nawet VRF byłoby dużo bardziej skomplikowane.

horac wrote:
W ostatecznosci dostajemy rozwiazanie ktore jest skomplikowane na poziomie hypervisora a uproszczone na fizycznej sieci DC.

Na poziomie hypervisora na pewno sieć jest bardziej skomplikowana. Wszak przenosimy tam funkcje sieciowe. Jednak całościowo, po uwzględnieniu sieci fizycznej oraz problemów, które związane są m.in ze spanning-tree, ruchem rozgłoszeniowym, upgradem urządzeń np. w vPC, narzutem konfiguracyjnym, brakiem kontroli ostatniej mili w DC, itd. architektura jest uproszczona. :)

horac wrote:
I teraz tak, nie wiadomo czy sieciowcy maja douczyc sie NSX zeby miec pelna wiedze o tym co sie dzieje w sieci, czy serwerowcy maja nauczyc sie jak dzialaja sieci i jak dziala NSX.

Dużo łatwiej i szybciej będzie nauczyć się NSX-a sieciowcom, gdyż sposób konstruowania sieci podlega tym samym regułom, które są już znane. Mówimy o NSX, ale generalnie soft overlay sprawia, że dział zarządzania siecią zyskusje w końcu kontrolę od przełącznika dostępowego aż do maszyny wirtualnej. Unika się choćby sytuacji, że administrator sieciowy przydziela VLAN dla określonej aplikacji, zaś administrator serwerów/wirtualizacji przydziela ten VLAN do innego zasobu świadomie lub nieświadomie narażając na leaking lub utratę separacji sieci wirtualnych.

horac wrote:
Zaglosowane

Dzięki :!:


Last edited by gangrena on 08 May 2016, 00:36, edited 1 time in total.

Top
   
 Post subject:
Post #2 Posted: 07 May 2016, 13:47 
Offline
CCIE
CCIE

Joined: 30 Nov 2006, 08:44
Posts: 3782
gangrena wrote:
horac wrote:
No chetnie bym to obejrzal, bo jak do tej pory slysze opinie odwrotne ze NSX czy inne rozwiazanie oparte o VXLAN komplikuje infrastrukture Data Center, dlatego ze przenosi to co obecnie jest skomplikowane na warstwie fizycznej sieci DC na warste hypervisora.

Dzięki przeniesieniu funkcji sieciowych blisko maszyn wirtualnych odwzorowanie topologii logicznych jest prostsze.


Choć jedno z drugim wcale nie musi być połączone. Uproszczenie wynika chyba bardziej z tego, że wszystko się klika i tego nie widać. To jak się pospina VTEPy i gdzie postawi się funkcje sieciowe, może być dowolnie porządne lub dowolnie nieporządne - w obu wykonaniach.

gangrena wrote:
Jednocześnie wykorzystanie sieci nakładkowej przynosi dodatkowe korzyści związane ze skalowalnością, bezpieczeństwem oraz wymaganiami środowisk multitenant.


Skalowalność - mówimy o widoczności adresów i ich przechowywaniu right? Zaczynamy jednak mnożyć tunele. Wspominasz o tym w kontekście popularnego obecnie przenoszenia wszędzie (i często bez sensu L2).

Bezpieczeństwo - separacja ruchu i jak rozumiem NSXowy Distributed FW? Tracimy jednak widoczność z sieci underlay. RFC 1925: "(6a) (corollary). It is always possible to add another level of indirection.". Sieć nakładkowa to zawsze coś więcej niż jedna sieć. Z samej definicji, poziom skomplikowania (przynajmniej teoretycznie) rośnie.

gangrena wrote:
Zresztą tak, jak w MPLS VPN. Odwzorowanie dzisiaj sieci MPLS VPN za pomocą VLAN-ów, routingu w sieci fizycznej, czy nawet VRF byłoby dużo bardziej skomplikowane.


To prawda. Dlatego rzadko się ich w DC używa produkcyjnie :) Inna sprawa, że dzisiaj tworzeniem VXLANów czy VRFów zajmują się już raczej narzędzia realizujące daleko idącą automatyzację. ACI, NSX, OpenContrail i inne tego typu.

gangrena wrote:
horac wrote:
W ostatecznosci dostajemy rozwiazanie ktore jest skomplikowane na poziomie hypervisora a uproszczone na fizycznej sieci DC.

Na poziomie hypervisora na pewno sieć jest bardziej skomplikowana. Wszak przenosimy tam funkcje sieciowe. Jednak całościowo, po uwzględnieniu sieci fizycznej oraz problemów, które związane są m.in ze spanning-tree, ruchem rozgłoszeniowym, upgradem urządzeń np. w vPC, narzutem konfiguracyjnym, brakiem kontroli ostatniej mili w DC, itd. architektura jest uproszczona. :)


Tylko teoretycznie. Ukrywasz całe skomplikowanie pod maską czegoś, czego nie trzeba rozumieć, żeby działało :)

gangrena wrote:
Mówimy o NSX, ale generalnie soft overlay sprawia, że dział zarządzania siecią zyskusje w końcu kontrolę od przełącznika dostępowego aż do maszyny wirtualnej. Unika się choćby sytuacji, że administrator sieciowy przydziela VLAN dla określonej aplikacji, zaś administrator serwerów/wirtualizacji przydziela ten VLAN do innego zasobu świadomie lub nieświadomie narażając na leaking lub utratę separacji sieci wirtualnych.


True. Ale wszelkiego rodzaju pomyłki będą też na większą skalę. Tylko obecnie nikogo to nie interesuje :)

Ech, #poszedłbym #szarpałbym #posłuchałbym ;)


Top
   
 Post subject:
Post #3 Posted: 07 May 2016, 19:40 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
lbromirs wrote:
gangrena wrote:
Dzięki przeniesieniu funkcji sieciowych blisko maszyn wirtualnych odwzorowanie topologii logicznych jest prostsze.

Choć jedno z drugim wcale nie musi być połączone. Uproszczenie wynika chyba bardziej z tego, że wszystko się klika i tego nie widać. To jak się pospina VTEPy i gdzie postawi się funkcje sieciowe, może być dowolnie porządne lub dowolnie nieporządne - w obu wykonaniach.

Zgadza się, że jedno z drugim nie musi być połączone, ale w tym przypadku uproszczenie nie wynika tylko z samego zcentralizowanego klikania. Wynika to choćby z rozproszonych funkcji takich jak Anycast Gateway, czy dFW, wynika to z mniejszej ilości styków w sieci podkładowej między VLAN-ami i podsieciami.

lbromirs wrote:
gangrena wrote:
Jednocześnie wykorzystanie sieci nakładkowej przynosi dodatkowe korzyści związane ze skalowalnością, bezpieczeństwem oraz wymaganiami środowisk multitenant.

Skalowalność - mówimy o widoczności adresów i ich przechowywaniu right? Zaczynamy jednak mnożyć tunele. Wspominasz o tym w kontekście popularnego obecnie przenoszenia wszędzie (i często bez sensu L2).

VXLAN, to jest tunelowanie, ale nie ma ustanawiania tuneli. Nie tworzymy żadnych stanów tuneli, jak w MPLS-TE. Nie odbijamy się zatem tutaj od limitu wspieranych tuneli. Przenoszenie L2 pomiędzy DC jest często bez sensu, ale w ramach DC wynika tylko i wyłącznie z wymagań aplikacji. Niestety wciąż to wymaganie jest i będzie dopóki aplikacje nie zostaną przepisane/stworzone na nowo. Wówczas będzie szansa na przejście na najprostszą formę architektury, czyli routowalnej sieci IP. O ile nie będzie overlappingu adresacji lub separacji tenantów. Wówczas sieć nakładkowa lub VRF-y wciąż będą potrzebne.

lbromirs wrote:
Bezpieczeństwo - separacja ruchu i jak rozumiem NSXowy Distributed FW?

Między innymi. Dochodzi również możliwość przekierowywania ruchu na poziomie kernela do aplikacji bezpieczeństwa bez tworzenia interfejsów, czy wychodzenia poza serwer.

lbromirs wrote:
Tracimy jednak widoczność z sieci underlay.

To jest standardowo powielany mit. ACI, który reklamowany jest jako to rozwiązanie, które posiada widoczność sieci underlay tak naprawdę ogranicza się do wskazania statusu łączy, urządzeń i prostych liczników danych. To samo jest też w narzędziach VMware, czy innych firm. Można mieć też narysowaną topologię oraz wskazania stanów poszczególnych komponentów. Za pomocą SNMP, CDP, LLDP można pozyskiwać dodatkowe informacje. Low level debugging trzeba i tak wykonać logując się bezpośrednio na każde z urządzeń zarówno w ACI, jak i NSX, który działa on top. Można rzec wręcz bardziej, że dzięki NSX zyskuje się widoczność sieci, gdyż widać przepływy nawet w ramach oddzielnego segmentu sieci. ACI nie wspiera na chwilą obecną Netflow/sFlow (jest w trybie standalone). Nawet jak będzie wspierał w przyszłości, to tylko do urządzeń dostępowych.

lbromirs wrote:
RFC 1925: "(6a) (corollary). It is always possible to add another level of indirection.". Sieć nakładkowa to zawsze coś więcej niż jedna sieć. Z samej definicji, poziom skomplikowania (przynajmniej teoretycznie) rośnie.

Teoretycznie oczywiście tak. Jak pokazuje jednak praktyka utrzymanie sieci MPLS VPN w porównaniu do odwzorowanej struktury za pomocą STP, VLAN-ów, VRF-ów jest dużo prostsze, nie mówiąc o dodatkowych korzyściach takich jak stabilność sieci, skalowalność, czy bezpieczeństwo.

lbromirs wrote:
gangrena wrote:
Zresztą tak, jak w MPLS VPN. Odwzorowanie dzisiaj sieci MPLS VPN za pomocą VLAN-ów, routingu w sieci fizycznej, czy nawet VRF byłoby dużo bardziej skomplikowane.

To prawda. Dlatego rzadko się ich w DC używa produkcyjnie :) Inna sprawa, że dzisiaj tworzeniem VXLANów czy VRFów zajmują się już raczej narzędzia realizujące daleko idącą automatyzację. ACI, NSX, OpenContrail i inne tego typu.

Rzadko się ich używa w DC, dlatego wciąż są nierozwiązane problemy, które można rozwiązać za pomocą sieci overlay. Automatyzacja jest wbudowaną cechą ACI, NSX, OpenContrail itd. która też wpływa zbawiennie na kwestie operacyjne. Jednak nawet z samej sieci nakładkowej wynika uproszczenie architektury. Czy wolałbyś zarządzać siecią złożoną z VLAN-ów, xSTP, MC-LAG, vPC, czy matrycą sieci fizycznej oraz siecią nakładkową? Korzyść jest podobna jak w przypadku MPLS VPN w stosunku do VLAN-ów, xSTP, MC-LAG oraz vPC. Zamiast konfigurować usługi hop by hop, posiada się stabilny szkielet, zaś usługi realizuje się na brzegu. Naturalnie wady płaskiej sieci L2 można by przykryć przez dobry system zarządzania, co jest realizowane przez tworzenie matryc przełączanych przez Cisco, Juniper, Dell, Arista, Huawei itd.

lbromirs wrote:
gangrena wrote:
Na poziomie hypervisora na pewno sieć jest bardziej skomplikowana. Wszak przenosimy tam funkcje sieciowe. Jednak całościowo, po uwzględnieniu sieci fizycznej oraz problemów, które związane są m.in ze spanning-tree, ruchem rozgłoszeniowym, upgradem urządzeń np. w vPC, narzutem konfiguracyjnym, brakiem kontroli ostatniej mili w DC, itd. architektura jest uproszczona. :)

Tylko teoretycznie. Ukrywasz całe skomplikowanie pod maską czegoś, czego nie trzeba rozumieć, żeby działało :)

Po pierwsze nie ukrywasz, tylko uniezależniasz. Po drugie w dalszym ciągu trzeba rozumieć, by zrobić diagnostykę. Po trzecie można zmigrować sieć fizyczną spokojnie do L3, co znacząco upraszcza wszystko. :)

lbromirs wrote:
gangrena wrote:
Mówimy o NSX, ale generalnie soft overlay sprawia, że dział zarządzania siecią zyskusje w końcu kontrolę od przełącznika dostępowego aż do maszyny wirtualnej. Unika się choćby sytuacji, że administrator sieciowy przydziela VLAN dla określonej aplikacji, zaś administrator serwerów/wirtualizacji przydziela ten VLAN do innego zasobu świadomie lub nieświadomie narażając na leaking lub utratę separacji sieci wirtualnych.

True. Ale wszelkiego rodzaju pomyłki będą też na większą skalę. Tylko obecnie nikogo to nie interesuje :)

Zgadza się, przynajmniej teoretycznie. Praktycznie okazuje się, że problemy na ogromną skalę przytrafiły się ustabilizowanemu od nastu lat protokołowi ISIS. Jak wiesz rozpropagował niewłaściwe rozgłoszenie po całej sieci dużych operatorów powodując massive outage. Zatem rozstrzyganie, że sieć SDN spodowuje większą awarię w porównaniu do systemów rozproszonych jest nadinterpretacją skojarzeń i stereotypów. Ponadto w takim NSX awaria systemu zarządzania, czy kontrolerów nie powoduje przerwy działania w płaszczyźnie danych. Można zawsze jeszcze popełnić błąd konfiguracyjny, ale teraz ja poteoretyzuję mówiąc, że łatwiej jest wykryć taką usterkę przy zarządzaniu zcentralizowanym. Praktyka pokaże.

lbromirs wrote:
Ech, #poszedłbym #szarpałbym #posłuchałbym ;)

Już niebawem. :D


Top
   
 Post subject:
Post #4 Posted: 07 May 2016, 22:57 
Offline
CCIE
CCIE

Joined: 30 Nov 2006, 08:44
Posts: 3782
gangrena wrote:
VXLAN, to jest tunelowanie, ale nie ma ustanawiania tuneli. Nie tworzymy żadnych stanów tuneli, jak w MPLS-TE. Nie odbijamy się zatem tutaj od limitu wspieranych tuneli.


Chodziło mi bardziej o wskazanie, że z samej definicji, zaczynamy dokładać warstwę do góry. Zgadzam się, że MPLS VPNy też to robią z cięższym control-plane'm. Ale upraszczasz tylko control-plane, dodatkowy data plane zostaje.

gangrena wrote:
lbromirs wrote:
Bezpieczeństwo - separacja ruchu i jak rozumiem NSXowy Distributed FW?

Między innymi. Dochodzi również możliwość przekierowywania ruchu na poziomie kernela do aplikacji bezpieczeństwa bez tworzenia interfejsów, czy wychodzenia poza serwer.


A nie bawem i bezpośrednio do instancji aplikacji, bez hypervisora.

gangrena wrote:
lbromirs wrote:
Tracimy jednak widoczność z sieci underlay.

To jest standardowo powielany mit. ACI, który reklamowany jest jako to rozwiązanie, które posiada widoczność sieci underlay tak naprawdę ogranicza się do wskazania statusu łączy, urządzeń i prostych liczników danych. To samo jest też w narzędziach VMware, czy innych firm.


Nie o to mi chodziło. W tych uwagach daleki jestem od wytykania NSXowi jego słabości i wad, myślałem bardziej o kwestii tego, że mając overlay automatycznie (a i z wygody) przestajemy zastanawiać się tym, co jest pod spodem. Swoją drogą, za pomocą ACI widzisz jednak razem overlay i underlay (z każdą wersją z większą ilością danych), NSX daje Ci tylko wiedzę właśnie o licznikach na swoich interfejsach do świata zewnętrznego, right?

gangrena wrote:
Można rzec wręcz bardziej, że dzięki NSX zyskuje się widoczność sieci, gdyż widać przepływy nawet w ramach oddzielnego segmentu sieci. ACI nie wspiera na chwilą obecną Netflow/sFlow (jest w trybie standalone). Nawet jak będzie wspierał w przyszłości, to tylko do urządzeń dostępowych.


Dane telemetryczne odkładane są per endpoint i EPG na APICu, ale faktycznie nie w postaci Netflowa/sFlowa. Nie dobierałem się do tego i na szybko nie mogę znaleźć, ale są. A co będzie w przyszłości, to będzie. Nie wiesz tego :)

gangrena wrote:
Jednak nawet z samej sieci nakładkowej wynika uproszczenie architektury. Czy wolałbyś zarządzać siecią złożoną z VLAN-ów, xSTP, MC-LAG, vPC, czy matrycą sieci fizycznej oraz siecią nakładkową? Korzyść jest podobna jak w przypadku MPLS VPN w stosunku do VLAN-ów, xSTP, MC-LAG oraz vPC. Zamiast konfigurować usługi hop by hop, posiada się stabilny szkielet, zaś usługi realizuje się na brzegu. Naturalnie wady płaskiej sieci L2 można by przykryć przez dobry system zarządzania, co jest realizowane przez tworzenie matryc przełączanych przez Cisco, Juniper, Dell, Arista, Huawei itd.


No tak, ale dalej tutaj wracamy do rozważań całego bałaganu protokołów (zapomniałeś o ulubionym EtherChannelu! ;) ) vs "czyste" overlaye. Overlaye będą działały wspaniale i cudownie jak będą oparte o czystą sieć L3.

To, że ukrywasz overlayem złożoność L2 pod spodem, nie rozwiązuje Twoich (potencjalnych) problemów tylko je ukrywa. A to nie to samo.

I się prawie zgadzamy, bo potem piszesz:

gangrena wrote:
Po pierwsze nie ukrywasz, tylko uniezależniasz. Po drugie w dalszym ciągu trzeba rozumieć, by zrobić diagnostykę. Po trzecie można zmigrować sieć fizyczną spokojnie do L3, co znacząco upraszcza wszystko. :)


Greenfieldy. Ach te greenfieldy ;)

gangrena wrote:
Zgadza się, przynajmniej teoretycznie. Praktycznie okazuje się, że problemy na ogromną skalę przytrafiły się ustabilizowanemu od nastu lat protokołowi ISIS. Jak wiesz rozpropagował niewłaściwe rozgłoszenie po całej sieci dużych operatorów powodując massive outage. Zatem rozstrzyganie, że sieć SDN spodowuje większą awarię w porównaniu do systemów rozproszonych jest nadinterpretacją skojarzeń i stereotypów.


Eee, bez przesady :) Chodzi mi o to (i na pewno się zgodzisz), że pomyłka ręczna operatora robiącego coś na jednym routerze to jednak w 99% pomyłka impaktująca tylko jedno miejsce w sieci (IS-IS o którym wspominasz to był bug, więc do naszego rozważania "się nie liczy"). Natomiast ta sama pomyłka zautomatyzowana to katastrofa całej sieci :)

Nie twierdzę, że to SDN jest zły ani w ogóle automatyzacja - mówię raczej o realnej skali propagacji błędu - a czy człowieka czy automatu jest już wtórne.

gangrena wrote:
Ponadto w takim NSX awaria systemu zarządzania, czy kontrolerów nie powoduje przerwy działania w płaszczyźnie danych. Można zawsze jeszcze popełnić błąd konfiguracyjny, ale teraz ja poteoretyzuję mówiąc, że łatwiej jest wykryć taką usterkę przy zarządzaniu zcentralizowanym. Praktyka pokaże.


Świadoma próba naruszenia granic administracyjnych tak, bardziej skomplikowane błędy chyba jeszcze długo nie. Ale to już dyskusja o tym, jak szybko AI wejdą do takich rozwiązań. Wróbelki ćwierkają, że jest jedna firma, która sobie z tym eksperymentuje "trenując" swój kontroler eksperymentujący na żywej sieci.

gangrena wrote:
lbromirs wrote:
Ech, #poszedłbym #szarpałbym #posłuchałbym ;)
Już niebawem. :D


Oj taaaak :)


Top
   
 Post subject:
Post #5 Posted: 08 May 2016, 00:28 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
lbromirs wrote:
Chodziło mi bardziej o wskazanie, że z samej definicji, zaczynamy dokładać warstwę do góry. Zgadzam się, że MPLS VPNy też to robią z cięższym control-plane'm. Ale upraszczasz tylko control-plane, dodatkowy data plane zostaje.

Spojrzałbym na tą sprawę troszkę inaczej. Obecny data plane w Data Center są jak dwie łaty zszyte krawędziami ze sobą. Czyli świat wirtualny i fizyczny, dwa data plane, można powiedzieć, tworzą jedną płaszczyznę. W sieci nakładkowej data plane są jak dwie łaty ale naszyta jedna na drugą. Przy czym łata wirtualizacji jest większa. Która płaszczyzna jest prostsza? Na ubraniu mocniejsza i sprawiająca mniej problemów jest konstrukcja łata na łatę. To samo w Data Center. Okazuje się, że architektura bazująca na zszywaniu łat sprawia więcej problemów w zarządzaniu. Dlatego osoby, które operowały płaskimi sieciami L2 oraz MPLS VPN wolą rozwiązania nakładkowe. W obydwu rozwiązaniach są dwa data plane. Tylko w tradycyjnych rozwiązaniach nad jednym z data plane działy sieciowe nie miały kontroli.

lbromirs wrote:
A nie bawem i bezpośrednio do instancji aplikacji, bez hypervisora.

Na adopcję kontenerów przez rynek, jeżeli je masz na myśli, jeszcze trzeba troszkę poczekać.

lbromirs wrote:
Nie o to mi chodziło. W tych uwagach daleki jestem od wytykania NSXowi jego słabości i wad, myślałem bardziej o kwestii tego, że mając overlay automatycznie (a i z wygody) przestajemy zastanawiać się tym, co jest pod spodem.

Jeżeli przestajemy zastanawiać się, co jest pod spodem, gdyż nie trzeba go ruszać, to jest to dowód na uproszczenie. Nie zwalnia to oczywiście z myślenia o procedurach operacyjnych w przypadku problemów.

lbromirs wrote:
Swoją drogą, za pomocą ACI widzisz jednak razem overlay i underlay (z każdą wersją z większą ilością danych), NSX daje Ci tylko wiedzę właśnie o licznikach na swoich interfejsach do świata zewnętrznego, right?

To, co widzisz w ACI możesz też zobaczyć w NSX+vROps. To, co widzisz w NSX nie zobaczysz w ACI z żadnym dodatkowym narzędziem.

lbromirs wrote:
Dane telemetryczne odkładane są per endpoint i EPG na APICu, ale faktycznie nie w postaci Netflowa/sFlowa. Nie dobierałem się do tego i na szybko nie mogę znaleźć, ale są.

Proste sumaryczne liczniki per EPG, to nie to samo co informacje per flow. Brak też liczników ruchu w ramach EPG lub w ramach leaf node.

lbromirs wrote:
A co będzie w przyszłości, to będzie. Nie wiesz tego :)

Załóżmy, że oficjalnie nie wiem. ;)

lbromirs wrote:
No tak, ale dalej tutaj wracamy do rozważań całego bałaganu protokołów (zapomniałeś o ulubionym EtherChannelu! ;) ) vs "czyste" overlaye. Overlaye będą działały wspaniale i cudownie jak będą oparte o czystą sieć L3.

Nie tylko. Brak konieczności konfiguracji usług na urządzeniach L2 też upraszcza zarządzanie. Jak sam wiesz, klienci odbijają się od limitu skalowalności TCAM.

lbromirs wrote:
To, że ukrywasz overlayem złożoność L2 pod spodem, nie rozwiązuje Twoich (potencjalnych) problemów tylko je ukrywa. A to nie to samo.

Greenfieldy. Ach te greenfieldy ;)

Również rozwiązuje, gdyż część usług sieciowych jest przenoszona na hypervisor. Nie trzeba tak często borykać się z brakiem synchronizacji konfiguracji w vPC. Zatem nie tylko greenfieldy. :D

lbromirs wrote:
Eee, bez przesady :) Chodzi mi o to (i na pewno się zgodzisz), że pomyłka ręczna operatora robiącego coś na jednym routerze to jednak w 99% pomyłka impaktująca tylko jedno miejsce w sieci (IS-IS o którym wspominasz to był bug, więc do naszego rozważania "się nie liczy"). Natomiast ta sama pomyłka zautomatyzowana to katastrofa całej sieci :)

Na siłę szukasz teoretycznych przypadków, w których ktoś ustawia w automacie błędne zmiany dla wszystkich instancji. Poza tym porównujesz coś, co w Data Center nie istnieje, czyli czystą sieć L3. Obecne DC są konstrukcjami L2 i są na tyle zcentralizowane, że błędy popełniane na przełącznikach agregujących wpływają na całe środowisko. Tworzą się pętle, blokują się łącza, rozjeżdżają się podłączone klastry firewalli, serwerów, load-balancerów. Przykładów takich katastrof jest sporo.

lbromirs wrote:
Nie twierdzę, że to SDN jest zły ani w ogóle automatyzacja - mówię raczej o realnej skali propagacji błędu - a czy człowieka czy automatu jest już wtórne.

Obecna architektura DC propaguje błędy na tyle łatwo praktycznie z jednego miejsca w sieci, że póki co, nic tego nie pobije. Nie sądzę, by zarządzany centralnie rozproszony gateway wprowadzał większe ryzyko operacyjne, niż obecny zcentralizowany gateway. A przy tym jest dużo mniejsze ryzyko utraty usługi sieciowej z powodu prac związanych z samym HW, czy innymi instancjami sieciowymi.

lbromirs wrote:
Świadoma próba naruszenia granic administracyjnych tak, bardziej skomplikowane błędy chyba jeszcze długo nie. Ale to już dyskusja o tym, jak szybko AI wejdą do takich rozwiązań. Wróbelki ćwierkają, że jest jedna firma, która sobie z tym eksperymentuje "trenując" swój kontroler eksperymentujący na żywej sieci.

Bardziej skomplikowane błędy? To chyba tylko bugi. Jednocześnie nie chcesz ich brać pod uwagę w rozmowie o protokole, który jest jednym z najbardziej ustabilizowanych. Make up your mind! ;)


Top
   
 Post subject:
Post #6 Posted: 08 May 2016, 01:26 
Offline
CCIE
CCIE

Joined: 30 Nov 2006, 08:44
Posts: 3782
gangrena wrote:
lbromirs wrote:
Chodziło mi bardziej o wskazanie, że z samej definicji, zaczynamy dokładać warstwę do góry. Zgadzam się, że MPLS VPNy też to robią z cięższym control-plane'm. Ale upraszczasz tylko control-plane, dodatkowy data plane zostaje.

Spojrzałbym na tą sprawę troszkę inaczej. Obecny data plane w Data Center są jak dwie łaty zszyte krawędziami ze sobą. Czyli świat wirtualny i fizyczny, dwa data plane, można powiedzieć, tworzą jedną płaszczyznę. W sieci nakładkowej data plane są jak dwie łaty ale naszyta jedna na drugą. Przy czym łata wirtualizacji jest większa. Która płaszczyzna jest prostsza? Na ubraniu mocniejsza i sprawiająca mniej problemów jest konstrukcja łata na łatę. To samo w Data Center. Okazuje się, że architektura bazująca na zszywaniu łat sprawia więcej problemów w zarządzaniu. Dlatego osoby, które operowały płaskimi sieciami L2 oraz MPLS VPN wolą rozwiązania nakładkowe. W obydwu rozwiązaniach są dwa data plane. Tylko w tradycyjnych rozwiązaniach nad jednym z data plane działy sieciowe nie miały kontroli.


No dobrze - o czym właściwie dyskutujemy? Że overlay jest lepsze? Nie jest. Lepsze jest przejście na czyste L3 i ewidentnie w tą stronę idziemy.

Masakra w L2 + overlay, w postaci VXLANów to rozwiązanie przejściowe. Dzisiaj rynek wybrał już raczej rozwiązania "fabric+VXLANy". Proste, fajne, szybko się buduje, ale też z czasem będzie niepotrzebne.

gangrena wrote:
lbromirs wrote:
A niebawem i bezpośrednio do instancji aplikacji, bez hypervisora.
Na adopcję kontenerów przez rynek, jeżeli je masz na myśli, jeszcze trzeba troszkę poczekać.


Mówisz? Ale ewidentnie bardzo szybko w tą stronę idziemy. To, że firmy muszą przepisać stare aplikacje wymagające L2 już się dzieje. A jak masz aplikację, dla której cały świat to socket IP, potem pozostaje już tylko kwestia zapakowania - czy opłaca się inwestować w ciężki hypervisor, czy raczej w kontener w stylu dockera. Jest jeszcze dużo problemów, ale kontenery są prostsze i łatwiejsze w spakowaniu w cały stosik.

gangrena wrote:
lbromirs wrote:
Nie o to mi chodziło. W tych uwagach daleki jestem od wytykania NSXowi jego słabości i wad, myślałem bardziej o kwestii tego, że mając overlay automatycznie (a i z wygody) przestajemy zastanawiać się tym, co jest pod spodem.

Jeżeli przestajemy zastanawiać się, co jest pod spodem, gdyż nie trzeba go ruszać, to jest to dowód na uproszczenie. Nie zwalnia to oczywiście z myślenia o procedurach operacyjnych w przypadku problemów.


Uproszczenie pozorne.

gangrena wrote:
lbromirs wrote:
Swoją drogą, za pomocą ACI widzisz jednak razem overlay i underlay (z każdą wersją z większą ilością danych), NSX daje Ci tylko wiedzę właśnie o licznikach na swoich interfejsach do świata zewnętrznego, right?

To, co widzisz w ACI możesz też zobaczyć w NSX+vROps. To, co widzisz w NSX nie zobaczysz w ACI z żadnym dodatkowym narzędziem.


Zobaczysz, w wersji wirtualnej, sprzętowej i dla konternerów. Jak chcesz masz nawet SDK w Pythonie, można sobie to samemu ściągać. A vROps nie jest chyba za darmo?

gangrena wrote:
lbromirs wrote:
Dane telemetryczne odkładane są per endpoint i EPG na APICu, ale faktycznie nie w postaci Netflowa/sFlowa. Nie dobierałem się do tego i na szybko nie mogę znaleźć, ale są.

Proste sumaryczne liczniki per EPG, to nie to samo co informacje per flow. Brak też liczników ruchu w ramach EPG lub w ramach leaf node.


No nie, są. EPG do EPG, EPG<>endpoint, EPG w dowolne miejsce (w tym zewnętrzne - i odwrotnie). To nie flow, zgadza się, ale są per aplikacja.

gangrena wrote:
lbromirs wrote:
A co będzie w przyszłości, to będzie. Nie wiesz tego :)

Załóżmy, że oficjalnie nie wiem. ;)


No to załóżmy ;)

gangrena wrote:
lbromirs wrote:
No tak, ale dalej tutaj wracamy do rozważań całego bałaganu protokołów (zapomniałeś o ulubionym EtherChannelu! ;) ) vs "czyste" overlaye. Overlaye będą działały wspaniale i cudownie jak będą oparte o czystą sieć L3.

Nie tylko. Brak konieczności konfiguracji usług na urządzeniach L2 też upraszcza zarządzanie. Jak sam wiesz, klienci odbijają się od limitu skalowalności TCAM.


TCAM w kontekście L3 w DC? Raczej nie szybko, skoro mamy do dyspozycji overlay. TCAMy w kontekście L3 w ogólności - tak, ale to scenariusze typu SD WAN i/lub styk z internetem.

gangrena wrote:
lbromirs wrote:
To, że ukrywasz overlayem złożoność L2 pod spodem, nie rozwiązuje Twoich (potencjalnych) problemów tylko je ukrywa. A to nie to samo.
[...]
Greenfieldy. Ach te greenfieldy ;)

Również rozwiązuje, gdyż część usług sieciowych jest przenoszona na hypervisor. Nie trzeba tak często borykać się z brakiem synchronizacji konfiguracji w vPC. Zatem nie tylko greenfieldy. :D


Tam gdzie od vPC uciec się nie da, rozmowa o synchronizacji lub jej braku będzie zawsze ciekawa, podobnie jak o całej reszcie L2 - czy to z czy bez hypervisora, a nie tylko hypervisorami dzisiaj żyjemy. Ale mamy już coraz więcej sieci zbudowanych jako uniwersalna matryca bez trudnych operacji na L2 w stylu MC-LAGów czy vPC i tutaj nie ma żadnego problemu. Dokładanie overlaya p.t. "VXLAN" dodaje niepotrzebnej złożoności.

gangrena wrote:
lbromirs wrote:
Eee, bez przesady :) Chodzi mi o to (i na pewno się zgodzisz), że pomyłka ręczna operatora robiącego coś na jednym routerze to jednak w 99% pomyłka impaktująca tylko jedno miejsce w sieci (IS-IS o którym wspominasz to był bug, więc do naszego rozważania "się nie liczy"). Natomiast ta sama pomyłka zautomatyzowana to katastrofa całej sieci :)

Na siłę szukasz teoretycznych przypadków, w których ktoś ustawia w automacie błędne zmiany dla wszystkich instancji.


No nie szukam na siłę. Pomyłki tego typu robione masowo z użyciem Ansible i innych frameworków do automatyzacji już się zaczynają wydarzać. Będzie ich więcej. Zapewne (paradoksalnie trochę), błędów robionych za pomocą interfejsu vSphere czy APICa będzie mniej.

gangrena wrote:
Poza tym porównujesz coś, co w Data Center nie istnieje, czyli czystą sieć L3. Obecne DC są konstrukcjami L2 i są na tyle zcentralizowane, że błędy popełniane na przełącznikach agregujących wpływają na całe środowisko. Tworzą się pętle, blokują się łącza, rozjeżdżają się podłączone klastry firewalli, serwerów, load-balancerów. Przykładów takich katastrof jest sporo.


Tak. Ale tutaj overlay nic nie da - mimo pozornego 'uproszczenia', sieć się i tak zawali i tak.

gangrena wrote:
lbromirs wrote:
Nie twierdzę, że to SDN jest zły ani w ogóle automatyzacja - mówię raczej o realnej skali propagacji błędu - a czy człowieka czy automatu jest już wtórne.

Obecna architektura DC propaguje błędy na tyle łatwo praktycznie z jednego miejsca w sieci, że póki co, nic tego nie pobije. Nie sądzę, by zarządzany centralnie rozproszony gateway wprowadzał większe ryzyko operacyjne, niż obecny zcentralizowany gateway. A przy tym jest dużo mniejsze ryzyko utraty usługi sieciowej z powodu prac związanych z samym HW, czy innymi instancjami sieciowymi.


O jakim zcentralizowanym gatewayu mówisz?

Tą parę bramek w NSXie można ściągnąć do ilu... 6s failoveru? To bardzo dużo w porównaniu do dobrze stuningowanego styku L3 z ACI.

No i ponownie - co Ci daje overlay skoro sprzęt pod spodem zawiódł?

gangrena wrote:
lbromirs wrote:
Świadoma próba naruszenia granic administracyjnych tak, bardziej skomplikowane błędy chyba jeszcze długo nie. Ale to już dyskusja o tym, jak szybko AI wejdą do takich rozwiązań. Wróbelki ćwierkają, że jest jedna firma, która sobie z tym eksperymentuje "trenując" swój kontroler eksperymentujący na żywej sieci.

Bardziej skomplikowane błędy? To chyba tylko bugi. Jednocześnie nie chcesz ich brać pod uwagę w rozmowie o protokole, który jest jednym z najbardziej ustabilizowanych. Make up your mind! ;)


Nieee, mówię raczej o błędach logicznych wyższego rzędu. Uwaga, wydumany przykład: arbitralnie zdefiniowany próg obciążenia danego zasobu zostaje przekroczony prawidłowym ruchem w wyniku rekonfiguracji polityki rozkładania ruchu pomiędzy endpointy. W wyniku tego część ruchu jest obcinana żeby utrzymać ten próg - zobaczysz to w systemie monitoringu, ale może nie od razu. Czym więcej masz warstw na których coś może pójść źle i czego nie wyłapie walidator sprawdzający lokalnie dane operacyjne (w rozwiązaniu rozproszonym to wręcz niemożliwe) tym bardziej prawdopodobne, że to nie prosty błąd rozłoży Ci czy uszkodzi działający system, ale właśnie nałożenie się polityk - coraz bardziej skomplikowanych.


Top
   
 Post subject:
Post #7 Posted: 08 May 2016, 02:34 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
lbromirs wrote:
No dobrze - o czym właściwie dyskutujemy? Że overlay jest lepsze? Nie jest. Lepsze jest przejście na czyste L3 i ewidentnie w tą stronę idziemy.

Masakra w L2 + overlay, w postaci VXLANów to rozwiązanie przejściowe. Dzisiaj rynek wybrał już raczej rozwiązania "fabric+VXLANy". Proste, fajne, szybko się buduje, ale też z czasem będzie niepotrzebne.

Rozwiązanie L2 + overlay jest lepsze, niż samo L2 ze względu na przesunięcie częsci funkcji sieciowych, które sprawiają, że sieć jest stabilniejsza, bardziej skalowalna i łatwiej zarządzalna. Oczywiście, że lepszy jest fabric + overlay. Nikt tego nie kwestionuje. Jeszcze lepsze L3 + overlay. A najlepsze natywne L3 od końca do końca. Tylko ostatni model nie wszędzie się sprawdzi. Tylko tam, gdzie nie będzie nakładającej się adresacji oraz środowiska multitenant.

lbromirs wrote:
Mówisz? Ale ewidentnie bardzo szybko w tą stronę idziemy. To, że firmy muszą przepisać stare aplikacje wymagające L2 już się dzieje. A jak masz aplikację, dla której cały świat to socket IP, potem pozostaje już tylko kwestia zapakowania - czy opłaca się inwestować w ciężki hypervisor, czy raczej w kontener w stylu dockera. Jest jeszcze dużo problemów, ale kontenery są prostsze i łatwiejsze w spakowaniu w cały stosik.

W skali wszystkich firm posiadających swoje DC pozbywanie się zależności od L2 dzieje się bardzo powoli. Jedna, czy dwie nowe aplikacje w ramach firmy nie zmieniają reszty aplikacji. Wyczuwam też, że doklejasz rozwiązanie nakładkowe tylko do aplikacji bazujących na hypervisorze, co jest błędem. Konteneryzacja nie zmienia niczego w naszej dyskusji o sieciach nakładkowych.

lbromirs wrote:
Uproszczenie pozorne.

Uproszczenie konkretne, gdy przeniesie się Default GW, czy ACL ze switchy agregujących na serwery.

lbromirs wrote:
Zobaczysz, w wersji wirtualnej, sprzętowej i dla konternerów. Jak chcesz masz nawet SDK w Pythonie, można sobie to samemu ściągać. A vROps nie jest chyba za darmo

No nie zobaczysz, gdyż ACI nie wspiera Netflow/sFlow, ACI nie ma dostępu do NetX, ACI nie ma liczników w ramach EPG. A o cenę NSX + vROps się nie martw. ;)

lbromirs wrote:
No nie, są. EPG do EPG, EPG<>endpoint, EPG w dowolne miejsce (w tym zewnętrzne - i odwrotnie). To nie flow, zgadza się, ale są per aplikacja.

Tylko pakiety, które przechodzą przez fabric są liczone. Lokalnie zawijane na przełączniku lub na hypervisorze nie są liczone. Dodatkowe obostrzenia można znaleźć tutaj:
http://www.cisco.com/c/en/us/td/docs/sw ... 6e859a1635

lbromirs wrote:
TCAM w kontekście L3 w DC? Raczej nie szybko, skoro mamy do dyspozycji overlay. TCAMy w kontekście L3 w ogólności - tak, ale to scenariusze typu SD WAN i/lub styk z internetem.

TCAM w kontekście L2/L3 w DC bez overlaya. Mówisz ciągle, że nie ma korzyści na architekturze L2 + overlay. No właśnie jest, choćby ze względu na TCAM.

lbromirs wrote:
Tam gdzie od vPC uciec się nie da, rozmowa o synchronizacji lub jej braku będzie zawsze ciekawa, podobnie jak o całej reszcie L2 - czy to z czy bez hypervisora, a nie tylko hypervisorami dzisiaj żyjemy. Ale mamy już coraz więcej sieci zbudowanych jako uniwersalna matryca bez trudnych operacji na L2 w stylu MC-LAGów czy vPC i tutaj nie ma żadnego problemu. Dokładanie overlaya p.t. "VXLAN" dodaje niepotrzebnej złożoności.

Również dla matrycy jest zysk z overlaya. Choćby ze względu na funkcje rozproszonej bramy, dFW, LB, optymalizacji przepływów czy też kontroli ostatniej mili w DC.

lbromirs wrote:
No nie szukam na siłę. Pomyłki tego typu robione masowo z użyciem Ansible i innych frameworków do automatyzacji już się zaczynają wydarzać. Będzie ich więcej. Zapewne (paradoksalnie trochę), błędów robionych za pomocą interfejsu vSphere czy APICa będzie mniej.

Póki co pomyłki konfiguracyjne na przełącznikach agregacyjnych powodujących katastrofę w całym DC jest dużo więcej. Automatyzacja właśnie może pomóc je ograniczyć.

lbromirs wrote:
Tak. Ale tutaj overlay nic nie da - mimo pozornego 'uproszczenia', sieć się i tak zawali i tak.

Mniej powodów do katastrofy, ale twierdzisz, że ryzyko to samo. Czyli uważszasz, że przeniesienie funkcji sieciowych na serwery, nie upraszcza sieci fizycznej?

lbromirs wrote:
O jakim zcentralizowanym gatewayu mówisz?

O parze vPC, która pełni w DC rolę GW.

lbromirs wrote:
Tą parę bramek w NSXie można ściągnąć do ilu... 6s failoveru? To bardzo dużo w porównaniu do dobrze stuningowanego styku L3 z ACI.

Możesz skorzystać z ECMP, czyli 3 sekundy. A nawet 6 sekund, to nie jest dużo przy klastrowaniu ASA, czy OTV. W DC nie jest wymagana konwergencja subsecond. To w sieciach IPTV. Nawet w testach dla instytucji finansowych, które wykonywałem w Cisco maksymalny czas konwergencji był określony na poziomie 5 sekund. Dlatego design sieci DC zawsze warto zacząć od wymagań aplikacji, a nie od bicia piany o każde 50 ms. :)

lbromirs wrote:
No i ponownie - co Ci daje overlay skoro sprzęt pod spodem zawiódł?

Ale co, cały sprzęt zawiódł? W takim przypadku overlay nic nie daje oczywiście. Ale nie o tym była mowa. Podałem przykład, że zastosowanie overlaya powoduje przeniesienie funkcji sieciowych ze switchy agregujących. Zmniejsza to ryzyko popełnienia błędu w środowisku fizycznym. Ktoś powie, że to ryzyko przenosi się w takim razie na środowisko wirtualne, ale dzięki rozproszonym usługom, kontrolerom oraz zarządzaniu ryzyko jest mniejsze.

lbromirs wrote:
Nieee, mówię raczej o błędach logicznych wyższego rzędu. Uwaga, wydumany przykład: arbitralnie zdefiniowany próg obciążenia danego zasobu zostaje przekroczony prawidłowym ruchem w wyniku rekonfiguracji polityki rozkładania ruchu pomiędzy endpointy. W wyniku tego część ruchu jest obcinana żeby utrzymać ten próg - zobaczysz to w systemie monitoringu, ale może nie od razu. Czym więcej masz warstw na których coś może pójść źle i czego nie wyłapie walidator sprawdzający lokalnie dane operacyjne (w rozwiązaniu rozproszonym to wręcz niemożliwe) tym bardziej prawdopodobne, że to nie prosty błąd rozłoży Ci czy uszkodzi działający system, ale właśnie nałożenie się polityk - coraz bardziej skomplikowanych.

Ehh... Z takiego teoretyzowania nie uzyskamy jednoznaczych konkluzji. Jak problemy w SDN dojdą do poziomu i częstości występowania problemów w sieci L2, to możemy wrócić do tej części dyskusji. Systemy centralnie zarządzane, nie chodzi tylko o sieci, pokazują, że nie jest tak, jak mówisz.


Top
   
 Post subject:
Post #8 Posted: 08 May 2016, 10:55 
Offline
CCIE
CCIE

Joined: 30 Nov 2006, 08:44
Posts: 3782
gangrena wrote:
lbromirs wrote:
No dobrze - o czym właściwie dyskutujemy? Że overlay jest lepsze? Nie jest. Lepsze jest przejście na czyste L3 i ewidentnie w tą stronę idziemy.

Masakra w L2 + overlay, w postaci VXLANów to rozwiązanie przejściowe. Dzisiaj rynek wybrał już raczej rozwiązania "fabric+VXLANy". Proste, fajne, szybko się buduje, ale też z czasem będzie niepotrzebne.

Rozwiązanie L2 + overlay jest lepsze, niż samo L2 ze względu na przesunięcie częsci funkcji sieciowych, które sprawiają, że sieć jest stabilniejsza, bardziej skalowalna i łatwiej zarządzalna. Oczywiście, że lepszy jest fabric + overlay. Nikt tego nie kwestionuje. Jeszcze lepsze L3 + overlay. A najlepsze natywne L3 od końca do końca. Tylko ostatni model nie wszędzie się sprawdzi. Tylko tam, gdzie nie będzie nakładającej się adresacji oraz środowiska multitenant.


To nie przeszkadza. Zawsze sobie możesz zrobić NAT na wyjściu z tenanta i dzisiaj to już nie jest dla nikogo problem.

Skracając nieco przydługie wywody:

1. Tak, sieć overlay upraszcza architekturę DC.
2. Upraszcza dodając dodatkowy poziom abstrakcji, który ukrywa potencjalną (obecnie jednak dominującą w DC) złożoność L2 pod sobą, czyli w tzw. underlayu.
3. Samo uproszczenie jest wartością, ale bez prawdziwej elastyczności z jasną i istniejącą drogą do przejścia z dzisiejszego L2 w underlayu do L3 w przyszłości, ryzykujemy budowę kolejnego artefaktu, który za rok/dwa/trzy będzie miał tą samą charakterystykę co dzisiejsze tradycyjne rozwiązania - będzie kanapką wielu protokołów z VXLANem na górze.


Top
   
 Post subject:
Post #9 Posted: 08 May 2016, 11:38 
Offline
member
member

Joined: 18 Apr 2016, 21:04
Posts: 38
Location: CCIE
Panowie a co z MPLSem end to end. Pamietam ze jeszcze dwa do trzech lat temu padaly takie hasla od Cisco ze "pracujemy nad rozciagnieciem MPLSa do hypervisora a nawet za do vmek". Rozumiem ze efektem tej pracy jest CSR1000v i IOS XRv(Tylko dla L3 VPN na chwile obecna)?.

Czy probowaliscie badz widzieliscie juz rozwiazanie w DC oparte w 100% na zbudowaniu sieci MPLS od hypervisora do hypervisora(scislej VMki bo hypervisory jeszcze MPLSa chyba nie obsluguja, poprawcie jak sie myle). Nastepnie polaczenie ewentualnie wirtualnej sieci MPLS w DC ze szkieletem. Zakladam ze wowczas jako minimum stoi Nexus7k z kartami M ktory jest w stanie zbudowac LDP z CSR1000v. Jako core lata IS-IS czy tam OSPF i w zasadzie VLANy jako tako nie sa nigdzie uzyte w sieci fizycznej. Pytanie czy takie rozwiazanie ma sens tylko w przypadku jednego DC, czy spokojnie da rade miedzy DC na wieksze odleglosci. Mamy wtedy w zasadzie control plane oparty o MP-BGP i LDP.

Wymagania dotyczace L2 miedzy vmkami rozwiazane jako BGP Autodiscovery + signaling po H-VPLS.


Top
   
 Post subject:
Post #10 Posted: 08 May 2016, 11:51 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
lbromirs wrote:
gangrena wrote:
Rozwiązanie L2 + overlay jest lepsze, niż samo L2 ze względu na przesunięcie częsci funkcji sieciowych, które sprawiają, że sieć jest stabilniejsza, bardziej skalowalna i łatwiej zarządzalna. Oczywiście, że lepszy jest fabric + overlay. Nikt tego nie kwestionuje. Jeszcze lepsze L3 + overlay. A najlepsze natywne L3 od końca do końca. Tylko ostatni model nie wszędzie się sprawdzi. Tylko tam, gdzie nie będzie nakładającej się adresacji oraz środowiska multitenant.


To nie przeszkadza. Zawsze sobie możesz zrobić NAT na wyjściu z tenanta i dzisiaj to już nie jest dla nikogo problem.

Jeżeli w DC nie ma sieci overlay lub choćby VRF, to trzeba wydzielić osobne routery fizyczne brzegowe dla każdego z tenantów. Translację owszem stosuje się, ale tam, gdzie nie ma routingu i za pomocą L2 separuje się tenantów lub już istnieje sieć overlay. Rozmawiamy jednak o Data Center, gdzie potrzebny jest inter-VLAN routing między aplikacjami. Czy spotkałeś wdrożenie odzielnych routerów dla ruchu inter-VLAN w DC + NAT na wyjściu z tenanta? To nie jest używalny model w DC nawet przy zastosowaniu NAT. Jeżeli operator wynajmuje w swoim DC miejsca w racku lub całe routery, to oczywiście tak można zrobić. Ale operatorzy DC chcą zarabiać na wynajmie vCPU, pamięci RAM oraz storage. Stąd zastosowanie sieci nakładkowych/VRF/VNF.

Możesz też jeszcze mieć na myśli model wdrożeniowy AWS, ale tutaj też korzystamy z VRF oraz z tunelowania, czyli sieci nakładkowej. Oczywiście możesz powiedzieć, że są aplikacje, które tego nie potrzebują. Zgadza się, ale wciąż też będą aplikacje, które będą tego potrzebowały lub nie będą stosowane w public cloud.

lbromirs wrote:
Skracając nieco przydługie wywody:

1. Tak, sieć overlay upraszcza architekturę DC.
2. Upraszcza dodając dodatkowy poziom abstrakcji, który ukrywa potencjalną (obecnie jednak dominującą w DC) złożoność L2 pod sobą, czyli w tzw. underlayu.
3. Samo uproszczenie jest wartością, ale bez prawdziwej elastyczności z jasną i istniejącą drogą do przejścia z dzisiejszego L2 w underlayu do L3 w przyszłości, ryzykujemy budowę kolejnego artefaktu, który za rok/dwa/trzy będzie miał tą samą charakterystykę co dzisiejsze tradycyjne rozwiązania - będzie kanapką wielu protokołów z VXLANem na górze.

Odnośnie ostatniego punktu, to elastyczność uzyskuje się już dzięki wprowadzeniu SDN (overlay+funkcje sieciowe+zarządzanie+automatyzacja). Zgadzam się, że warto zaplanować przejście z L2 przynajmniej do sieci fabric. Jednak ryzyko nie jest związane z siecią overlay, ale z procedurami oraz polityką firmy/działu sieciowego. Zabić można się każdym protokołem/rozwiązaniem, jeżeli stosuje się go niewłaściwie.


Top
   
 Post subject:
Post #11 Posted: 08 May 2016, 11:54 
Offline
CCIE
CCIE

Joined: 30 Nov 2006, 08:44
Posts: 3782
horac wrote:
Panowie a co z MPLSem end to end. Pamietam ze jeszcze dwa do trzech lat temu padaly takie hasla od Cisco ze "pracujemy nad rozciagnieciem MPLSa do hypervisora a nawet za do vmek". Rozumiem ze efektem tej pracy jest CSR1000v i IOS XRv(Tylko dla L3 VPN na chwile obecna)?.


MPLS jest jedną z dróg, ale skomplikowaną. Dzisiaj idziemy raczej w stronę Segment Routingu, który nie wymaga wszędzie etykiet MPLS, może pracować np. z IPv6 EH.

horac wrote:
Czy probowaliscie badz widzieliscie juz rozwiazanie w DC oparte w 100% na zbudowaniu sieci MPLS od hypervisora do hypervisora(scislej VMki bo hypervisory jeszcze MPLSa chyba nie obsluguja, poprawcie jak sie myle).


gangrena pewnie będzie bardziej zainteresowany tematem, ale IMHO taki model trochę już dzisiaj nie ma sensu. Obciążanie VMki stosem LDP albo RSVP, ew. etykietowanie (statycznie?) na poziomie hypervisora ruchu z VMki tylko po to, żeby zapewnić ciągłość LSP to bardzo dużo zachodu.

Ze strony Cisco rozwiązaniem architekturalnym jest ACI, które zapewnia uniwersalną 'fabric' do przenoszenia ruchu z dowolnych endpointów. Powoli powstaje też rozwiązanie oparte o Segment Routing - opowiem o tym na bootcampie. MPLS w DC byłby raczej sztuką dla sztuki, aczkolwiek jest parę startupów, które uparcie wynajdują koło od nowa i proponują analogiczne rozwiązania ze swoim kontrolerem (aby ukryć złożoność).


Top
   
 Post subject:
Post #12 Posted: 08 May 2016, 11:59 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
horac wrote:
Panowie a co z MPLSem end to end. Pamietam ze jeszcze dwa do trzech lat temu padaly takie hasla od Cisco ze "pracujemy nad rozciagnieciem MPLSa do hypervisora a nawet za do vmek". Rozumiem ze efektem tej pracy jest CSR1000v i IOS XRv(Tylko dla L3 VPN na chwile obecna)?.

Czy probowaliscie badz widzieliscie juz rozwiazanie w DC oparte w 100% na zbudowaniu sieci MPLS od hypervisora do hypervisora(scislej VMki bo hypervisory jeszcze MPLSa chyba nie obsluguja, poprawcie jak sie myle). Nastepnie polaczenie ewentualnie wirtualnej sieci MPLS w DC ze szkieletem. Zakladam ze wowczas jako minimum stoi Nexus7k z kartami M ktory jest w stanie zbudowac LDP z CSR1000v. Jako core lata IS-IS czy tam OSPF i w zasadzie VLANy jako tako nie sa nigdzie uzyte w sieci fizycznej. Pytanie czy takie rozwiazanie ma sens tylko w przypadku jednego DC, czy spokojnie da rade miedzy DC na wieksze odleglosci. Mamy wtedy w zasadzie control plane oparty o MP-BGP i LDP.

Wymagania dotyczace L2 miedzy vmkami rozwiazane jako BGP Autodiscovery + signaling po H-VPLS.

MPLS w Data Center, to problemy związane z połączeniem urządzeń. Jest masa urządzeń bezpieczeństwa, które MPLS nie wspierają. VXLAN, który jest na bazie IP będzie forwardowany przez dowolny przełącznik lub router. Można stosować translację adresów, agregację prefiksów. Wraz z rozwojem sieci nakładkowych na bazie IP nie oczekiwałbym, że coś będzie rozwijane na bazie MPLS.


Top
   
 Post subject:
Post #13 Posted: 08 May 2016, 12:05 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
lbromirs wrote:
gangrena pewnie będzie bardziej zainteresowany tematem, ale IMHO taki model trochę już dzisiaj nie ma sensu. Obciążanie VMki stosem LDP albo RSVP, ew. etykietowanie (statycznie?) na poziomie hypervisora ruchu z VMki tylko po to, żeby zapewnić ciągłość LSP to bardzo dużo zachodu.

Tak, jak lubię MPLS, tak uważam, że w Enterprise Data Center nie ma on sensu. Zwłaszcza, że jest VXLAN. :)
Może w środowisku operatorskim miałoby to większy sens, gdyż tam realizowany jest transport do usług sieciowych, które MPLS wspierają. Np. ASR5000 może być węzłem PE.


Top
   
 Post subject:
Post #14 Posted: 08 May 2016, 12:16 
Offline
CCIE
CCIE

Joined: 30 Nov 2006, 08:44
Posts: 3782
gangrena wrote:
lbromirs wrote:
gangrena wrote:
Rozwiązanie L2 + overlay jest lepsze, niż samo L2 ze względu na przesunięcie częsci funkcji sieciowych, które sprawiają, że sieć jest stabilniejsza, bardziej skalowalna i łatwiej zarządzalna. Oczywiście, że lepszy jest fabric + overlay. Nikt tego nie kwestionuje. Jeszcze lepsze L3 + overlay. A najlepsze natywne L3 od końca do końca. Tylko ostatni model nie wszędzie się sprawdzi. Tylko tam, gdzie nie będzie nakładającej się adresacji oraz środowiska multitenant.


To nie przeszkadza. Zawsze sobie możesz zrobić NAT na wyjściu z tenanta i dzisiaj to już nie jest dla nikogo problem.

Jeżeli w DC nie ma sieci overlay lub choćby VRF, to trzeba wydzielić osobne routery fizyczne brzegowe dla każdego z tenantów.


W sytuacji z pełnym, czystym L3 end-to-end nie o tym rozmawiamy. To, że można sobie NATa robić jako NfV jest raczej oczywiste - dla L3 będzie to tylko wymagało zbudowania odpowiedniego łańcucha w DC. Tym zajmuje się dzisiaj SR, a że takich DC jest jeszcze relatywnie bardzo mało (poza dużymi - tj. Googlem, Amazonem i Azure którzy wszystko robią w L3), temat posuwa się powoli.


Top
   
 Post subject:
Post #15 Posted: 08 May 2016, 12:28 
Offline
CCIE/CCDE
CCIE/CCDE
User avatar

Joined: 08 Mar 2004, 12:17
Posts: 2283
Location: Wawa
lbromirs wrote:
W sytuacji z pełnym, czystym L3 end-to-end nie o tym rozmawiamy. To, że można sobie NATa robić jako NfV jest raczej oczywiste - dla L3 będzie to tylko wymagało zbudowania odpowiedniego łańcucha w DC.

Czysty L3 end-to-end nadal wymaga odseparowania tego łańcucha, czyli sieci overlay, VRF lub osobnych instancji routerów.

lbromirs wrote:
Tym zajmuje się dzisiaj SR, a że takich DC jest jeszcze relatywnie bardzo mało (poza dużymi - tj. Googlem, Amazonem i Azure którzy wszystko robią w L3), temat posuwa się powoli.

SR jest przecież tunelowaniem, formą sieci overlay. Czyli mówimy jednym głosem - overlay jest potrzebny. :)


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 19 posts ]  Go to page 1 2 Next

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
This Website is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco, Cisco Systems, CCDA, CCNA, CCDP, CCNP, CCIE, CCSI, CCIP, the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Używamy informacji zapisanych za pomocą cookies i podobnych technologii m.in. w celach reklamowych i statystycznych oraz w celu dostosowania naszych serwisów do indywidualnych potrzeb użytkowników. Mogą też stosować je współpracujące z nami firmy. W programie służącym do obsługi internetu można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.



Powered by phpBB® Forum Software © phpBB Limited