Nexus design

Problemy i dyskusje z zakresu rozwiązań i technologii Data Center
Wiadomość
Autor
hustlin
rookie
rookie
Posty: 14
Rejestracja: 10 cze 2005, 01:53
Lokalizacja: Poland, Lodz

Nexus design

#1

#1 Post autor: hustlin »

Hey,

Potrzebuje Waszej pomocy i rady.

Migruje własnie jedno DC z Catalyst 65xx do Nexus 5672UP. Zacząłem właśnie przygotowywać projekt i trochę utknąłem koncepcyjnie.
Planowałem przenieść architekturę z Catalysta do Nexua bez większych zmian w routingu i przełączaniu.

Obecna architektura:

Podłączone L3 routed porty na Firewallu i WAN Routerach do Catalysta poprzez L2 Access Ports.

2 x Catalyst pracuje jako L3 router dla lokalnych VLAN w trybie HSRP. Brak VSS.

Netscreen Firewall Virtual IP address jest domyślną bramką dla Catalysta 0.0.0.0/0.

WAN routery (HSRP IP) jest bramką dla Intranetowych sieci 10.0.0.0/8, etc

[iObrazek

Pytanie jest czy mogę użyć interfejsów na FEX w trybie L2 Access aby osiągać taki sam setup na Nexusie ? FEX oferuje mi 1GBaseT porty, których nie mam dostępnych bezpośrednio na Core 5672UP. Wiem, że porty na FEX mają permamentnie BPDU guard enabled, ale akurat nie podłączam żadego switcha.

Dodatkowo przyszły mi na myśl poniższe problemy:

Czy mogę routować ruch (static routes) pomiędzy WAN routerami (HSRP) a SVI interface na Nexus, który również jest w trybie HSRP. Na Catalyst działa to bez problemu.

Czy muszę zbudować zwykły (non-vPC) link pomiędzy Core switch jak miałem do tej porty w przypadku Catalyst. Jak pakiety hello HSRP pomiędzy Switchami Nexus są wymienianie ?

Czy vPC "loop avoidance" nie zablokuje mi ruchu ?

Czy w ogóle taki setup ma sens czy powinienem zmienić nieco architekturę ?

Obrazek

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2349
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

#2

#2 Post autor: gangrena »

W Twojej propozycji z FEX-ami jest zagrożenie powstania pętli. Podłącz każdy z routerów/FW osobno za pomocą vPC do pary FEX-ów lub do pary N5600 za pomocą portów 1000BASE-T SFP. Moduły 1GE też są wspierane:
http://www.cisco.com/c/en/us/products/c ... 30760.html

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#3

#3 Post autor: lukaszbw »

Trzeba tylko pamiętać, że Nexus to switch do DC a nie na campus core jak 6500. Jeżeli zewnętrzne urządzenia korzystają z dynamicznego routingu i chcesz je wpiąc bezpośrednio do nexus to na bank będziesz miał problemy z VPC. Poczytaj sobie o loop prevention w VPC albo zerknij:

Routing over Nexus 7000 vPC peer-link

Generalnie VPC<>VSS

Z bpdu guard też są problemy na FEXach. Ja odpuściłem, zamiast FEX 2K dałem 4948E a na FEXy (B22HP) poleciały jedynie serwery . Cenowo nie wyszło o wiele gorzej a 4948 daje mi local switching z pominięciem Core.

Inna sprawa to dual homed FEX. Z tym też są problemy na niektórych seriach, 7K wogóle nie obsługuje.

Z VPC wogóle dałem sobie spokój. W samym DC wyszło, że jak ustawie load balancing z poziomu vmware to ruch dobrze rozkłada się na 2 karty NIC i potem spływa do 2 switchy parent. FEX są single homed, każdy serwer ma 2 karty wpinające się do dwóch różnych FEX. Prędkość przełączania w razie awarii FEX czy parent jest natychmiastowa.
Mnie to zaoszczędziło sporo czasu oraz zabawy VPC, oddzielnym vlanem pod OSPF (poza VPC), dodatkowym switchem do keepalive (N7K z dual Supervisor więc dla pełnego HA trzeba spiąć 4 porty management) no i ewentualnych bugów w sofcie związanych z VPC.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2349
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

#4

#4 Post autor: gangrena »

lukaszbw pisze:Trzeba tylko pamiętać, że Nexus to switch do DC a nie na campus core jak 6500. Jeżeli zewnętrzne urządzenia korzystają z dynamicznego routingu i chcesz je wpiąc bezpośrednio do nexus to na bank będziesz miał problemy z VPC. Poczytaj sobie o loop prevention w VPC albo zerknij:

Routing over Nexus 7000 vPC peer-link
Routing over vPC działa dla N5k. Niemniej jeżeli FW dałby radę pod względem wydajności dla ruchu inter-VLAN, to lepiej byłoby zrobić default GW na FW, niż N5k.
lukaszbw pisze: Generalnie VPC<>VSS

Z bpdu guard też są problemy na FEXach. Ja odpuściłem, zamiast FEX 2K dałem 4948E a na FEXy (B22HP) poleciały jedynie serwery . Cenowo nie wyszło o wiele gorzej a 4948 daje mi local switching z pominięciem Core.

Inna sprawa to dual homed FEX. Z tym też są problemy na niektórych seriach, 7K wogóle nie obsługuje.

Z VPC wogóle dałem sobie spokój. W samym DC wyszło, że jak ustawie load balancing z poziomu vmware to ruch dobrze rozkłada się na 2 karty NIC i potem spływa do 2 switchy parent. FEX są single homed, każdy serwer ma 2 karty wpinające się do dwóch różnych FEX. Prędkość przełączania w razie awarii FEX czy parent jest natychmiastowa.
Mnie to zaoszczędziło sporo czasu oraz zabawy VPC, oddzielnym vlanem pod OSPF (poza VPC), dodatkowym switchem do keepalive (N7K z dual Supervisor więc dla pełnego HA trzeba spiąć 4 porty management) no i ewentualnych bugów w sofcie związanych z VPC.
Można wpiąć MLACP z serwera do FEX-ów, które są wpięte na wprost (czyli, jak wspomniałeś single homed) lub do dwóch N5k. Nie ma z tym problemu. Jeżeli aplikacja wspiera load-balancing, to wirtualizacja łączy nie jest potrzebna. W tym wątku spinane są urządzenia sieciowe, nie serwery. Zatem rozwiązanie VSS/vPC/MC-LAG lub pokrewne się przyda. Można też wykorzystać ACI, gdzie MLACP spina się z dowolną parą urządzeń brzegowych. Nie będzie problemów z FEX. :)

BTW, dla pełnego HA keepalive wystarczy tyle samo przełączników, co dla pojedynczego Supa. W przypadku vPC i tak jest dwóch świadków: peer-link oraz keepalive. Nie trzeba robić HA, do HA, bo zrobi się z tego drugi projekt sieci. ;)

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#5

#5 Post autor: lukaszbw »

Wszystko się da i w środowisku czystego DC wiele rzeczy ma sens. Jednak jak słysze klientów, którzy zakładają, że Nexus zastąpi im 6500 to jestem bardzo ostrożny.

Generalnie sam VPC oraz łączenie tego z dual homed FEX komplikuje sprawe co potem sprowadza się do trudniejszej obsługi. Czasami warto sobie dać spokój i nie kombinować, szczególnie jak nie przerzuca się kilkadziesiąt Gbps jednocześnie. Single homed FEX, RSTP + Etherchannel między Nexusami często wystarcza.
W małych projektach na ogół storage jest wąskim gardłem całego systemu i pomimo wielu portów 10GE większość z nich nie wykorzystuje więcej niż 2Gbps.

Etherchannel na serwerach jest możliwy ale mało osób chce to obsługiwać, no chyba że masz pełną kontrole wraz z Nexus 1KV. Jak wirtualnym switchem zajmują się system engineers to potem sprawa rozchodzi się na 2 działy. Ja miałem z tym złe doświadczenia, niby sprawa prosta ale obejmując 2 teamy często pojawiały się problemy ze zrozumieniem oraz włączaniem obsługi 802.3ad od strony Hypervisora :) Prosty load balancing per VM nie daje ci oczywiście 20Gbps na VM ale domyślne ustawienia działają bez problemów a przy wielu VMach ruch ładnie się rozkłada.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Awatar użytkownika
krisiasty
wannabe
wannabe
Posty: 483
Rejestracja: 07 lut 2006, 22:26
Lokalizacja: Gdańsk

#6

#6 Post autor: krisiasty »

lukaszbw pisze:Wszystko się da i w środowisku czystego DC wiele rzeczy ma sens. Jednak jak słysze klientów, którzy zakładają, że Nexus zastąpi im 6500 to jestem bardzo ostrożny.
Tak jak różnią się te dwa urządzenia, tak różnić się powinny budowane z nich sieci. Część rzeczy należy zrobić po prostu inaczej, część w ogóle być może nie ma sensu, inne z kolei wymagać będą dodatkowych zewnętrznych pudełek (fw / lb zamiast modułów no cat6k).
VPC, FabricPath, OTV i inne protokoły/technologie specyficzne dla Nexusów siłą rzeczy wymuszają pewne zmiany. Przykładowo dla VPC nie ma potrzeby tuningu timerów dla HSRP bo oba switche aktywnie forwardują pakiety, itd.
lukaszbw pisze:Generalnie sam VPC oraz łączenie tego z dual homed FEX komplikuje sprawe co potem sprowadza się do trudniejszej obsługi. Czasami warto sobie dać spokój i nie kombinować, szczególnie jak nie przerzuca się kilkadziesiąt Gbps jednocześnie. Single homed FEX, RSTP + Etherchannel między Nexusami często wystarcza.
Jest takie znane powiedzenie: im większa sieć, tym powinna być prostsza. Ja generalnie jestem przeciwnikiem stosowania szelkich możliwych funkcji/protokołów tylko dlatego że są dostępne, jeśli miałoby to skomplikować sieć i jej utrzymanie bez istotnego wpływu na wydajność / dostępność / bezpieczeństwo / skalowalność.

Odnosząc się do twojej wypowiedzi: single-homed FEX - zdecydowanie tak, ale z tym RSTP trochę przesadziłeś - we współczesnych DC dąży się do eliminacji wszelkich form Spanning Tree (m.in. dzięki VPC czy FabricPath).
lukaszbw pisze:W małych projektach na ogół storage jest wąskim gardłem całego systemu i pomimo wielu portów 10GE większość z nich nie wykorzystuje więcej niż 2Gbps.
Być może w starszych sieciach tak jest (jeszcze), ale za chwilę można się mocno zdziwić: macierze all-flash są coraz tańsze a wydajność nawet najmniejszych modeli często znacznie przewyższa pod tym względem najbardziej wypasione klasyczne macierze klasy enterprise, więc ruch storage będzie rósł. Tak samo zdecydowanie większy apetyt na pasmo mają wszystkie rozwiązania typu scale-out storage (np. VMware vSAN, CEPH, macierze all-flash SolidFire, itp.).
lukaszbw pisze:Etherchannel na serwerach jest możliwy ale mało osób chce to obsługiwać, no chyba że masz pełną kontrole wraz z Nexus 1KV. Jak wirtualnym switchem zajmują się system engineers to potem sprawa rozchodzi się na 2 działy. Ja miałem z tym złe doświadczenia, niby sprawa prosta ale obejmując 2 teamy często pojawiały się problemy ze zrozumieniem oraz włączaniem obsługi 802.3ad od strony Hypervisora :)
To trochę nie tak: problem z LACP na VMware polega na tym że dostępny jest tylko na dvSwitchach (w tym Nexusach 1000v), a to wymaga licencji Enterprise Plus. Dużo klientów nie posiada takiej licencji albo nie chce po prostu przepłacać tylko po to żeby mieć LACP.

Natomiast nie widzę powodu żeby nie uruchamiać LACP na standardowych serwerach Linuxowych (aczkolwiek co dystrybucja to zupełnie inaczej się to robi) czy Windowsowych (tu z kolei najlepiej skorzystać z funcjonalności wbudowanej w drivery Intela czy Broadcoma).

hustlin
rookie
rookie
Posty: 14
Rejestracja: 10 cze 2005, 01:53
Lokalizacja: Poland, Lodz

#7

#7 Post autor: hustlin »

gangrena pisze:Routing over Nexus 7000 vPC peer-link[/URL]
Routing over vPC działa dla N5k. Niemniej jeżeli FW dałby radę pod względem wydajności dla ruchu inter-VLAN, to lepiej byłoby zrobić default GW na FW, niż N5k.
Zasadniczo plan jest aby Firewall postawić jedynie na edge'u pomiędzy Nexus a siecią Internet/WAN. Dlatego pomysł z L3 na Nexusie. Czemu odradzasz Inter-VLAN routing na Nexusie ?
gangrena pisze: Można wpiąć MLACP z serwera do FEX-ów, które są wpięte na wprost (czyli, jak wspomniałeś single homed) lub do dwóch N5k. Nie ma z tym problemu. Jeżeli aplikacja wspiera load-balancing, to wirtualizacja łączy nie jest potrzebna. W tym wątku spinane są urządzenia sieciowe, nie serwery. Zatem rozwiązanie VSS/vPC/MC-LAG lub pokrewne się przyda. Można też wykorzystać ACI, gdzie MLACP spina się z dowolną parą urządzeń brzegowych. Nie będzie problemów z FEX. :)

BTW, dla pełnego HA keepalive wystarczy tyle samo przełączników, co dla pojedynczego Supa. W przypadku vPC i tak jest dwóch świadków: peer-link oraz keepalive. Nie trzeba robić HA, do HA, bo zrobi się z tego drugi projekt sieci. ;)
Idea była taka aby wyeliminować "standalone" switche i zastapić je "wyniesionymi" kartami typu FEX, które za zagregowane na dwóch switchach corowych. Do jednej pary FEX podpiąć pozostałe urządzenia sieciowe (nie switche), jak firewalle, routery WAN/MPLS, VPN concentratory - które pracują w tradycyjnej opcji Active/Standby. Każde urządzenie Active byłoby wpiete do jednego FEXa, Standby do drugiego. Zatem o przypadkowej pętli nie ma mowy.

Pozostałe pary FEX byłby w kierunku farmy serwerów.

Zgadzam się, że Enchanced vPC - "dual homed" FEX wprowadza spore zamieszanie z utrzymaniem spójnej konfiguracji. Wprowadza CFSoIP oraz "switch profile" aby utrzymać jednolitą konfigurację, co niestety komplikuje utrzymanie sieci.

Planowałem SVI + HSRP na Nexus w kierunku firewalla i innych urządzeń sieciowych, więc nie ma potrzeby żadnego IGP peeringu pomiędzy Nexus a innymi urządzeniami.

Moją największa obawą jest jednak czy będę w stanie utrzymać komunikację L3 (static route) pomiędzy SVI (HSRP) na Nexus a pozostałymi urządzeniami sieciowymi jak routery, firewalle, VPN - które de fakto będą fizycznie wpięte do FEX portami L2 - Access lub Trunk.

Pozdr

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#8

#8 Post autor: lukaszbw »

krisiasty pisze: VPC, FabricPath, OTV i inne protokoły/technologie specyficzne dla Nexusów siłą rzeczy wymuszają pewne zmiany. Przykładowo dla VPC nie ma potrzeby tuningu timerów dla HSRP bo oba switche aktywnie forwardują pakiety, itd.
Jeżeli chodzi o DC to większość danych masz switchowanych, intervlan routing też się wykorzystuje ale nie jest to jakaś masakryczna ilość. Nawet jak dasz zwykły HSRP i dane będą leciały do switcha active to nie jest to jakiś duży problem. Jak masz single homed FEX z NIC rozkładającymi się na 2 FEXy (oraz 2 switche parent) to tylko połowa ruchu poleci między switchami, druga trafi do switcha z aktywnym HSRP.
Generalnie sprawa rozbija się o środowisko, jak masz czysty DC to dajesz VPC, jak chcesz mieć "kombajn" to według mnie prędzej czy później natrafisz na ograniczenia.
krisiasty pisze:
Odnosząc się do twojej wypowiedzi: single-homed FEX - zdecydowanie tak, ale z tym RSTP trochę przesadziłeś - we współczesnych DC dąży się do eliminacji wszelkich form Spanning Tree (m.in. dzięki VPC czy FabricPath).
Ponownie, w czystym DC jak najbardziej ale jak Nexus robi ci też jako campus core i wpinasz do niego zwykłe switche L2/L3 to jakaś forma STP musi być.
krisiasty pisze: Być może w starszych sieciach tak jest (jeszcze), ale za chwilę można się mocno zdziwić: macierze all-flash są coraz tańsze a wydajność nawet najmniejszych modeli często znacznie przewyższa pod tym względem najbardziej wypasione klasyczne macierze klasy enterprise, więc ruch storage będzie rósł. Tak samo zdecydowanie większy apetyt na pasmo mają wszystkie rozwiązania typu scale-out storage (np. VMware vSAN, CEPH, macierze all-flash SolidFire, itp.).
Takie macierze masz przy większych instalacjach. Przy rozwiązaniu na kilkadziesiąt serwerów fizycznych na ogół masz hybryde SSD+HDD. Tego typu rozwiązania na ogół nie oferują prędkości powyżej 10Gbps w rzeczywistych warunkach. Przy kilkuset czy paru tysiącach serwerach fizycznych z kolei infrastrukture nexus masz rozproszoną i FEX generalnie nie terminujesz na core ale w dystrybucji. Nie rozważamy takiego scenariusza tutaj.

krisiasty pisze:
To trochę nie tak: problem z LACP na VMware polega na tym że dostępny jest tylko na dvSwitchach (w tym Nexusach 1000v), a to wymaga licencji Enterprise Plus. Dużo klientów nie posiada takiej licencji albo nie chce po prostu przepłacać tylko po to żeby mieć LACP.
Natomiast nie widzę powodu żeby nie uruchamiać LACP na standardowych serwerach Linuxowych (aczkolwiek co dystrybucja to zupełnie inaczej się to robi) czy Windowsowych (tu z kolei najlepiej skorzystać z funcjonalności wbudowanej w drivery Intela czy Broadcoma).
Akurat w tym przypadku to były HyperV. Generalnie działało to przez jakiś czas ale serwerowcy narzekali po pierwsze na dodatkową konfiguracje oraz problemy ze wsparciem ISCSI z etherchannel. Da się przeskoczyć ale po wdrożeniach doszliśmy do wniosku, że zwykły route based balancing z monitorowaniem link status w zupełności wystarczy. Serwery aktywnie wykorzystują oba łącza i ruch ładnie się rozkłada. Nie trzeba nic kombinować.

Generalnie chodziło mi o wskazanie, że przy prostym scenariuszu jaki omawiamy warto rozważyć uproszczenie sobie życia bez konieczności stosowania VPC i jego rozszerzeń których ilość rośnie. Niedługo będzie jak z VPLS, tyle rodzajów, że jak ktoś na co dzień w tym nie siedzi to może się łatwo pogubić.
Na początku byłem optymistyczny ale przy scenariuszu, gdzie Nexus robi jako uniwersalny core, VPC wporwadzało zbyt dużo ograniczeń w stosunku do zysków przy rozwiązaniu na małą skale.

Hustlin, jak masz routery i firewalle to w do pewnej skali można żąglować statycznym routingiem. Jak dochodzi DMVPN, wiele context na firewallach to dynamiczny routing przydaje się. Warto mieć możliwość dania go na core jak na nim chcesz robić intervlan routing.
Ja generalnie dałem SVI+HSRP+RPVST+ jak podpinam switche bezpośrednio pod nexus. Rootem dla STP jest switch z aktywnym HSRP. Secondary root jest switch standby.
Na FEX nie potrzebujesz żadnego STP.

Ponieważ większość routerów i Firewalli miało porty gigabitowe dałem switche 4948E zamiast bawić się z FEXami. Na dzień dobry mam local switching, 2 zasilacze a do nexusa wchodzą 10GE. Gdyby core wyleciał (nie było problemów póki co żadnych) 4948 dają mi połączenie między routerami i firewallami no i co najważniejsze komunikacje z terminalami konsol :). Przy FEX wszystko ci wylatuje jak tracisz switcha parent, warto to rozważyć według mnie.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2349
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

#9

#9 Post autor: gangrena »

hustlin pisze:Czemu odradzasz Inter-VLAN routing na Nexusie ?
Gdyż w bardziej skalowalny sposób zapewnisz bezpieczeństwo na FW, niż na przełącznikach. Chyba, że bezpieczeństwo East-West nie jest tutaj istotne.
hustlin pisze:Idea była taka aby wyeliminować "standalone" switche i zastapić je "wyniesionymi" kartami typu FEX, które za zagregowane na dwóch switchach corowych. Do jednej pary FEX podpiąć pozostałe urządzenia sieciowe (nie switche), jak firewalle, routery WAN/MPLS, VPN concentratory - które pracują w tradycyjnej opcji Active/Standby. Każde urządzenie Active byłoby wpiete do jednego FEXa, Standby do drugiego. Zatem o przypadkowej pętli nie ma mowy.
Z rysunku, który wkleiłeś wynika, że mogą się tworzyć pętle. Jeżeli planujesz podpiąć każde urządzenie za pomocą MLACP, to co innego.
hustlin pisze:Planowałem SVI + HSRP na Nexus w kierunku firewalla i innych urządzeń sieciowych, więc nie ma potrzeby żadnego IGP peeringu pomiędzy Nexus a innymi urządzeniami.
Brak IGP nie oznacza braku routingu.
hustlin pisze:Moją największa obawą jest jednak czy będę w stanie utrzymać komunikację L3 (static route) pomiędzy SVI (HSRP) na Nexus a pozostałymi urządzeniami sieciowymi jak routery, firewalle, VPN - które de fakto będą fizycznie wpięte do FEX portami L2 - Access lub Trunk.
Urządzeń sieciowych jak routery, FW, LB nie wpinałbym do FEX-ów. FEX-y będą działać, ale większe możliwości jak coś daje sam N5k. Dodatkowo nie musisz się martwić o pętlę, jeżeli na routerze lub FW zbridżują się VLAN-y. Wykorzystaj porty wkładki 1GE i wepnij je do N5k.

hustlin
rookie
rookie
Posty: 14
Rejestracja: 10 cze 2005, 01:53
Lokalizacja: Poland, Lodz

#10

#10 Post autor: hustlin »

gangrena pisze:
hustlin pisze:Czemu odradzasz Inter-VLAN routing na Nexusie ?
Gdyż w bardziej skalowalny sposób zapewnisz bezpieczeństwo na FW, niż na przełącznikach. Chyba, że bezpieczeństwo East-West nie jest tutaj istotne.
hustlin pisze:Idea była taka aby wyeliminować "standalone" switche i zastapić je "wyniesionymi" kartami typu FEX, które za zagregowane na dwóch switchach corowych. Do jednej pary FEX podpiąć pozostałe urządzenia sieciowe (nie switche), jak firewalle, routery WAN/MPLS, VPN concentratory - które pracują w tradycyjnej opcji Active/Standby. Każde urządzenie Active byłoby wpiete do jednego FEXa, Standby do drugiego. Zatem o przypadkowej pętli nie ma mowy.
Z rysunku, który wkleiłeś wynika, że mogą się tworzyć pętle. Jeżeli planujesz podpiąć każde urządzenie za pomocą MLACP, to co innego.
hustlin pisze:Planowałem SVI + HSRP na Nexus w kierunku firewalla i innych urządzeń sieciowych, więc nie ma potrzeby żadnego IGP peeringu pomiędzy Nexus a innymi urządzeniami.
Brak IGP nie oznacza braku routingu.
hustlin pisze:Moją największa obawą jest jednak czy będę w stanie utrzymać komunikację L3 (static route) pomiędzy SVI (HSRP) na Nexus a pozostałymi urządzeniami sieciowymi jak routery, firewalle, VPN - które de fakto będą fizycznie wpięte do FEX portami L2 - Access lub Trunk.
Urządzeń sieciowych jak routery, FW, LB nie wpinałbym do FEX-ów. FEX-y będą działać, ale większe możliwości jak coś daje sam N5k. Dodatkowo nie musisz się martwić o pętlę, jeżeli na routerze lub FW zbridżują się VLAN-y. Wykorzystaj porty wkładki 1GE i wepnij je do N5k.

Posiłkująć się Waszymi sugestiami, zrobiłem nowy design.

1. Switche Nexus pracują w warstwie 2.
2. FEX są single homed z uruchomionym vPC. Ułatwione zarządzanie Nexus oraz możliwość uruchomienia MLACP w kierunku hostów i urządzeń sieciowych.
3. Default gatewayem dla hostów za Nexusem jest Firewall wpięty bezpośrednio do Core Nesus, który robi Inter-VLAN routing.
4. W kirunku upstream, Firewall jest wpięty do pary switchy C3750, które pracują w L2 normalnym trybie Rapid-PVST+.
5. Do Catalystów wpięte są pozostałe urządzenia sieciowe. Routery WAN/MPLS/BGP i urządzenia VPN.

Jakieś sugestie ?

Obrazek

Awatar użytkownika
krisiasty
wannabe
wannabe
Posty: 483
Rejestracja: 07 lut 2006, 22:26
Lokalizacja: Gdańsk

#11

#11 Post autor: krisiasty »

Trochę odbiegamy od głównego tematu, ale myślę że warto podyskutować też o innych rzeczach które wyszły po drodze... jeśli komuś to będzie bardzo przeszkadzać to możemy się przenieść do osobnego wątku.
lukaszbw pisze:Nawet jak dasz zwykły HSRP i dane będą leciały do switcha active to nie jest to jakiś duży problem. Jak masz single homed FEX z NIC rozkładającymi się na 2 FEXy (oraz 2 switche parent) to tylko połowa ruchu poleci między switchami, druga trafi do switcha z aktywnym HSRP.
Już pisałem - przy VPC i HSRP oba nexusy aktywnie forwardują ruch, więc generalnie nie powinien on latać po peer-linku, chyba że gadają ze sobą dwa hosty wpięte pojedynczm linkiem do różnych nexusów (lub jest awaria jakiegoś linku).
lukaszbw pisze:Generalnie sprawa rozbija się o środowisko, jak masz czysty DC to dajesz VPC, jak chcesz mieć "kombajn" to według mnie prędzej czy później natrafisz na ograniczenia.
Ok, rozwiń co rozumiesz pod pojęciem "kombajn" który uniemożliwia stosowanie VPC (przy prawidłowo zaprojektowanym rozwiązaniu)?
lukaszbw pisze:Ponownie, w czystym DC jak najbardziej ale jak Nexus robi ci też jako campus core i wpinasz do niego zwykłe switche L2/L3 to jakaś forma STP musi być.
Zawsze jakaś forma ochrony przed pętlami L2 musi być, to oczywiste. Ale w przypadku nexusów to powinna być raczej "ostatnia deska ratunku" niż podstawowy mechanizm.
Oczywiście na styku L2 z tradycyjnymi switchami zwykle nie ma innego wyjścia jak STP, ale też nie zawsze musi to być styk L2.
lukaszbw pisze:Takie macierze masz przy większych instalacjach. Przy rozwiązaniu na kilkadziesiąt serwerów fizycznych na ogół masz hybryde SSD+HDD. Tego typu rozwiązania na ogół nie oferują prędkości powyżej 10Gbps w rzeczywistych warunkach.
co znaczy większych instalacjach? kilku-nodowy klaster vmware czy jakieś Oracle z najmniejszym modelem macierzy PureStorage (FA-405) albo jakiś NetApp EF560 z jedną są w stanie wygenerować więcej ruchu niż 10GE, a to nie są "większe instalacje".
Jeszcze większy ruch storage potrafi generować mały klaster ESX-ów z vSAN-em, szczególnie przy odbudowie dysku po awarii.
Storage bardzo mocno i bardzo szbko się zmienia a wraz z tym zmieniają się wymogi co do sieci (pasmo, opóźnienia). To już nie te czas kiedy tradycyjni vendorzy (typu EMC) wypuszczali nowy model macierzy co kilka lat który przynosił kilku(nasto) procentowy wzrost wydajności czy po prostu większą pojemność. Teraz stawia się małe macierze flash pod kluczowe systemy i są to często małe klastry składające się ledwo z kilku serwerów, ale za to potrzebujące bardzo dużej wydajności sieci.
lukaszbw pisze:Akurat w tym przypadku to były HyperV. Generalnie działało to przez jakiś czas ale serwerowcy narzekali po pierwsze na dodatkową konfiguracje oraz problemy ze wsparciem ISCSI z etherchannel.
Bo ISCSI nie powinno latać po etherchannelach - od zapewnienia redundancji i load-balancingu jest multipathing. Oczywiście różni dostawcy macierzy w różny sposób implementują na nich mechanizmy wysokiej dostępności, ale generalnie ISCSI traktowałbym podobnie jak sieć SAN opartą o FC/FCoE, czyli robiłbym dwa fabric-i - w tym przypadku dla VLAN-y, z których jeden puszczony byłby do hosta tylko jednym linkiem, a drugi tylko drugim. Ruch lan puszczasz trzecim vlanem przez oba linki.
Ten sposób bez problemów działa u nas na produkcji z macierzą all-flash (co prawda na Linuxach, ale robiliśmy także testy na Windowsie). Co więcej, udało mi się nawet w takiej konfiguracji zbootować Windowsa po iSCSI, ale wymagało to trochę więcej zachodu (vlan-y iscsi były skonfigurowane jako native, bo iscsi boot w biosie nie pozwalał na konfigurację vlanów).
lukaszbw pisze:Da się przeskoczyć ale po wdrożeniach doszliśmy do wniosku, że zwykły route based balancing z monitorowaniem link status w zupełności wystarczy. Serwery aktywnie wykorzystują oba łącza i ruch ładnie się rozkłada. Nie trzeba nic kombinować.
jeśli w tym konkretnym przypadku wystarczy, to ok - jak już mówiłem nie ma sensu komplikować rzeczy bez potrzeby.
lukaszbw pisze:Hustlin, jak masz routery i firewalle to w do pewnej skali można żąglować statycznym routingiem. Jak dochodzi DMVPN, wiele context na firewallach to dynamiczny routing przydaje się. Warto mieć możliwość dania go na core jak na nim chcesz robić intervlan routing.
tutaj chyba nie mówimy o jakiejś większej skali, więc jak jest dobrze zaprojektowana adresacja to spokojnie można się obejść bez dynamicznego routingu pomiędzy brzegiem sieci a rdzeniem. oczywiście jak zaczniesz kombinować to może okazać się że będzie potrzebny, ale może wtedy warto się zastanowić czy nie ma prostszego rozwiązania.

lukaszbw pisze:Ja generalnie dałem SVI+HSRP+RPVST+ jak podpinam switche bezpośrednio pod nexus. Rootem dla STP jest switch z aktywnym HSRP. Secondary root jest switch standby.
jak już koniecznie musisz podpinać "tradycyjne" switche L2, to tak...
lukaszbw pisze:Na FEX nie potrzebujesz żadnego STP.
uściślając: na FEX-ach w ogóle nie ma STP - na wszystkich portach na stałe zapięty jest bpdu guard i nie da się tego wyłączć (przynajmniej oficjalnie)...
lukaszbw pisze:Przy FEX wszystko ci wylatuje jak tracisz switcha parent, warto to rozważyć według mnie.
trzeba pamiętać o jednym - FEX to nie switch, to w zasadzie wyniesiona karta liniowa bez lokalnego przełączania. tak jak w 6500 jeśli padnie ci sup to nie działają ci karty liniowe, tak i tu jeśli padnie nexus to nie działają podpięte do niego fex-y (pomijam sytuacje typu redundantne sup-y czy fexy dual-homed). więc albo wpinamy urządzenia/hosty do dwóch fex-ów i robimy vpc (lub zwykłą redundancję active-passive), albo liczymy się ze skutkami awarii danego switcha (i należących do niego fexów).

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#12

#12 Post autor: lukaszbw »

krisiasty pisze:
lukaszbw pisze:Generalnie sprawa rozbija się o środowisko, jak masz czysty DC to dajesz VPC, jak chcesz mieć "kombajn" to według mnie prędzej czy później natrafisz na ograniczenia.
Ok, rozwiń co rozumiesz pod pojęciem "kombajn" który uniemożliwia stosowanie VPC (przy prawidłowo zaprojektowanym rozwiązaniu)?
Intervlan routing przy scenariuszu, gdzie switche dystrybucyjne mają dynamiczny routing z core i wpinają się do obu przełączników core. To samo dotyczy scenariusza gdy masz 2 urządzenia wpięte do oddzielnych nexusów. Generalnie routing przez peer link.

Przykłady masz tutaj :

http://bradhedlund.com/2010/12/16/routi ... es-and-no/

Mimo, że informacja sprzed paru lat to nadal aktualna. Jedyna metoda to wykluczenie vlanu pod dynamiczny routing z VPC, przy wielu routerach, firewallach i switchach uczestniczących nie zawsze jest to proste a i to powoduje problemy z komunikacją między VPC a nonVPC vlan.

Jak masz sam ruch L2 to nie ma problemu.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Awatar użytkownika
krisiasty
wannabe
wannabe
Posty: 483
Rejestracja: 07 lut 2006, 22:26
Lokalizacja: Gdańsk

#13

#13 Post autor: krisiasty »

lukaszbw pisze:
krisiasty pisze: Ok, rozwiń co rozumiesz pod pojęciem "kombajn" który uniemożliwia stosowanie VPC (przy prawidłowo zaprojektowanym rozwiązaniu)?
Intervlan routing przy scenariuszu, gdzie switche dystrybucyjne mają dynamiczny routing z core i wpinają się do obu przełączników core. To samo dotyczy scenariusza gdy masz 2 urządzenia wpięte do oddzielnych nexusów. Generalnie routing przez peer link.
Przykłady masz tutaj :[...]
Łukasz, znam ten dokument i problem do którego się odnosisz, ale zauważ że wynika on z niewłaściwego design-u. Jak chcesz spinać się z nexusami po l3, to rób to na linkach l3. A jak chcesz wpiąć jakieś firewalle active-passive i MUSISZ koniecznie używać na nich dynamicznego routingu w kierunku core to pozostaje dołożyć jakąś małą warstwę dystrybucyjną (np. na Catalystach 4948E/4500X, o czym zresztą sam pisałeś). To nie jest jakaś wada Nexusów tylko ich specyficzna cecha którą trzeba po prostu uwzględnić w projekcie. Zwykle nie można w istniejącej sieci po prostu wyjąć sobie Catalysta 6500 i w jego miejsce wsadzić Nexusa. Tak samo zwykle nie da się tego zrobić w drugą stronę.

Wydaje mi się że niektórzy przez wiele lat po prostu nauczyli się projektować rozwiązania pod Catalysta w jeden określony sposób i mają teraz problem z przesiadką na Nexusa.
Zresztą duża w tym zasługa Cisco które przez wiele lat wbijało ludziom do głów trójwarstwowy model sieci (który oczywiście świetnie się sprawdzał w w tamtych czasach), ale tak jak i zmeniają się technologie, produkty i wymagania, tak i powinien zmieniać się sposób projektowania sieci. Czasami warto poświęcić trochę więcej czasu czy zasobów aby pozbyć się z sieci pewnych zaszłości które będą potem i tak kulą u nogi albo potencjalnym źródłem problemów.

lukaszbw
CCIE
CCIE
Posty: 516
Rejestracja: 23 mar 2008, 11:41

#14

#14 Post autor: lukaszbw »

Dlatego od początku pisałem, że trzeba być ostrożnym zastępując 6500 nexusem. Kolega już w pierwszej wiadomości wspomniał o zastąpieniu 6500 nexusem.

Jak to niewłaściwego designu ? Po prostu trzeba wziąść pod uwagę ograniczenia VPC i platformy.

Co rozumiesz pod pojęciem trójwarstrowy? To jest właśnie dwuwarstrowy model gdzie masz collapsed core. Core wtedy spina ci wiele przełączników, routerów i firewalli. Przy niektórych scenariuszach wole kupić 2 sztuki N7K niż 2x Cat6800 + kilka N5K. W końcu po coś moduły M2 obsługują 1M w FIB, chybe nie po to, żeby robić tylko switching.

Wiele sieci korporacyjnych to nadal mieszanka sieci dostępowej i data center. Jak masz czysty data center to VPC nie jest problemem.
Cat6K nadal nie ma odpowiednika VDC więc nexus jest ciekawą alternatywą dla mieszanego środowiska.

To, że są ograniczenia w sprzęcie czy oprogramowaniu to nie znaczy, że cały design jest zły i należy zapomnieć wszystko co było przed nexusami. Co więcej, ograniczenia o których mówimy już dawno temu (ponad 10 lat) rozwiązał Nortel (RIP) za pomocą SMLT i RSMLT.

Pozdr.
Lukasz Wisniowski MSc CCNA CCNP CCIE #20319
Tandem Networks
ul. Sztormowa 34
94-117 Łódź
NIP: 727-257-72-37
tel: +48 (42) 2091825

Awatar użytkownika
krisiasty
wannabe
wannabe
Posty: 483
Rejestracja: 07 lut 2006, 22:26
Lokalizacja: Gdańsk

#15

#15 Post autor: krisiasty »

lukaszbw pisze:Jak to niewłaściwego designu ? Po prostu trzeba wziąść pod uwagę ograniczenia VPC i platformy.
Niewłaściwego w sensie nie uwzględniającego specyfiki platformy Nexus 7000 i VPC.
lukaszbw pisze:Co rozumiesz pod pojęciem trójwarstrowy? To jest właśnie dwuwarstrowy model gdzie masz collapsed core.
sorry, to była uwaga ogólna na temat budowy większości sieci opartych na Cat6k, a nie tego konkretnego przypadku. chodziło mi o to że współczesne sieci DC projektuje się zupełnie inaczej niż kiedyś.
lukaszbw pisze:Cat6K nadal nie ma odpowiednika VDC więc nexus jest ciekawą alternatywą dla mieszanego środowiska.
dla enterprise-u czy dc? bo to spora różnica... nie wiem jaki jest sens wpychania nexusów do typowej sieci kampusowej czy core enterprise-u.
lukaszbw pisze:To, że są ograniczenia w sprzęcie czy oprogramowaniu to nie znaczy, że cały design jest zły i należy zapomnieć wszystko co było przed nexusami. Co więcej, ograniczenia o których mówimy już dawno temu (ponad 10 lat) rozwiązał Nortel (RIP) za pomocą SMLT i RSMLT.
nie zgodzę się. design który nie uwzględnia specyfiki (w tym ograniczeń) sprzętu jest zły, tak samo jak stosowanie na siłę starych rozwiązań. trudno mieć w takim przypadku pretensje do sprzętu czy jego producenta że coś nie działa (albo działa inaczej niż na innych pudełkach). nexus jest inny i tak, należy zapomnieć o większości rzeczy których nauczyliśmy się w erze cat6k. to jak przesiadka z samochodu na motocykl (lub odwrotnie) - niby przepisy te same, ale technika jazdy zupełnie inna i wielu rzeczy trzeba uczyć się od nowa.

ODPOWIEDZ