Zakup nexusa 7k a oczekiwania klienta Temat rozwiązany

[horac]

Mam mala uwage do Cisco. Nie robcie z pudelek Data Center maszynek do golenia, bo to moze sie zawalic jak domek z kart. Albo wprowadzacie rozwiazanie w PELNI albo WCALE. Rozumiem ze to pewnie przez klientow ktorzy kupujac N7K mysla ze to bedzie brain ich sieci i zatreminuje im wszystko co sobie wymarza. Takie podejscie jednak powoduje ze wprowadzacie jakies ulomne wersje protokolow i funkcjonalnosci zeby klient byl zadowolony. Bije do protokolu GRE na kartach M2. Jest GRE ale nie wspiera kluczy. Mozna w VRF zrobic tunel ale GRE da sie zapiac tylko przez VRF w ktorym jest interfejs nie ma FVRF. Dzieki temu jestem zmuszony nocami przegladac Config Guide i sprawdzac ograniczenia i tlumaczyc klientowi ze jak chce GRE na nexusie to tylko takie.. bo jak juz bedzie chcial kilka tuneli do tego samego destination to juz mu to nie zadziala. Gdybyscie nie wprowadzili GRE w takiej postaci jakiej jest na N7k, to nie bylo by problemu bo klient nie mialby wyboru tylko ZROZUMIAL ze nexus to nie maszynka do mielenia tylo switch data center i wydal dodatkowa kase na wlasciwe pudelko do tego typu funkcjonalnosci

Nie wiem kto stoi za jakas dziwna propaganda, ze po zakupie N7K to juz nic wiecej nie trzeba, czas doslownie zaczac mowic klientom ze to jest Switch core DATA CENTER a nie
pudelko do terminowania tuneli, IPseca i innych funkcjonalnosci do ktorych zostaly stworzone routery. Druga opcja to w pelni obslugiwane protokoly a nie czesciowo i z wybranymi features.

[bartekr]

Huh... nie wiem jak sie aktualnie buduje sieci w PL, ale "u nas w londynie :P" robimy najpierw liste wymagan funkcjonalnych, testujemy sprzet ktory mamy zamiar kupic pod katem ww. wymagan (proof of concept) i dopiero skladamy zamowienie. Przy tej metodologii wspomniane przez kolege problemy raczej nie wystepuja.

PS. wyglada na to, ze powiedzenie "jeszcze nikt nie stracil pracy za zakup Cisco" staje sie troche nieaktualne? ;)

[horac]

Hej

Pracuje w IBM, takze tutaj procedury skladanie zapytan, zbieranie wymagan etc itp to naprawde dluuuugie tygodnie i miesiace. Gdy stawiasz nowe DC i masz poczatkowe wymagania wszystko wyglada cacy. Skladasz zapytanie Cisco przydziela NCE lub TSE rozmawiacie uzgadniacie wszystko jest gitara. Robi sie POF w Cisco ECATS albo w DC nastepnie wdraza i jest dobrze i tu nie ma nic do zarzucenia.

Problem pojawia sie pozniej gdy dochodza kolejne wymagania a klient nie chce badz nie ma kasy na nowe pudelka i mowi ze chce polaczenia z A do B. Ty wiesz.. ze nie da sie np tego zrobic inaczej niz przez tunelling i mowisz ze da sie to zrobic ALE... a klient wtedy JAKIE ALE, wydalem XXXXX na pudelko a ty mowisz ze tego sie nie da zrobic, to za co ja zaplacilem i tralalala.

Nie jestes w stanie przewidziec co klient bedzie chcial za X czasu po zakupie... bo ci po prostu o tym nie mowi, albo zarzad trzyma w tajemnicy plany biznesowe i strzela z nich jak z procy gdy przyjdzie wedlug nich ten "wlasciwy czas" co dla nas sieciowcow oznacza ze masz noz na gardle zterminem. Najgorzej gdy klient sam wpisze w google: Tunelling Nexus 7k. Wyswietli mu sie info ze CONFIGURE GRE ON N7k ale juz nie przeczyta dokladnie, on po prostu juz wie ze tunneling na N7K bedzie mozliwy tylko nie wie ze nie w stopni jakim on go potrzebuje miec. I wez mu powiedz ze trzeba inne pudelko bo przeciez on wydal XXX na N7K. Ggdyby nie bylo ulomnego GRE na N7k on by znalazl INFO ze sie nie da i nie staral sie madrzyc ze sie da bo mu google mowi ze sie da i z pokora zlozyl kolejne zamowienie w Cisco na wlasciwe ku temu pudelko.

Jeszcze gorsza jest sytuacja taka: "Wiemy ze potrzeba now router, niestety... musimy dzialac na tym co jest, zrobmy narazie TAK, a z czasem albo kupi sie nowy router albo wymysli cos "innego". Tymczasem nawet gdy to ulomne GRE sie zrobi jako PoF klient zadowolony... HAH! mowilem ze bedzie dobrze.. widzisz nie trzeba bylo nowego pudelka, mowilem ci, N7K potrafi wiecej niz ci sie wydaje... a ty na to "YHYM".

Robisz GRE dla klienta na N7k, dziala wszystko super... za miesiac ten sam klient ci mowi. U nas zmienila sie polityka sec, musimy miec 2 osobne zony za end point tunelem.

Ty: Chcecie rozumiem separowac ruch na jednym pudelku totalnie ?
klient: Tak jest
Ty: W myslach... o ja pie.. wiedzialem ze tak bedzie mowilem ze GRE mozna ale jeden tunel per dest, per VRF, a ten chce 2 tunele w tym samym VRF na to samo dest ..iiiiiii DUPA bo akurat N7K nie wspiera kluczy GRE

Ale to nie koniec.. nie powiesz klientowi.. kurde nie da sie Tylko zaczynasz rzezbic. A moze tunnel do loopbacka.. to zmieni sie DEST, a moze da sie jeszcze VLAN zeby miec inne DEST IP albo zrobic MPLS over GRE i zaczynasz zwyczajnie kombinowac ze spelnic wymagania komplikujac sytuacje bo pudelko ma half-GRE

[lbromirs]

Horac,

With all due respect - I don't fucking get it.

Masz pretensje, że na naszych pudełkach można robić WIĘCEJ a nie MNIEJ? I że jeszcze ośmielamy się o tym pisać w publicznie dostępnej dokumentacji?

Masz pretensje, że nie docierasz na poziom podejmujących decyzję i rozgrywają Cię inżynierowie/administratorzy siedzący na dole, dyktując co masz robić i na jakim sprzęcie? I to też nasza wina?

A z drugiej strony - jakoś niedawno sam chwaliłeś się, że masz w jednym palcu projektowanie sieci i zawsze klient wymyśla dziwne rzeczy i rolą architekta (architekta, nie jakiegoś tam inżyniera) jest zaadresować jego problemy na dostępnym sprzęcie lub przygotować konkretne rozwiązanie konieczne do kupienia.

Więc - I don't fucking get it. Określ swoje frustracje jaśniej - i ich adresatów również. Ale postaraj się przy okazji być poważny.

Wywentylowałeś się na nas - i OK, przyjmujemy, że świat nie jest idealny. Wątpię, żebyśmy robili w przyszłości sprzęt o mniejszej ilości funkcjonalności (choć filozoficznie świat powoli zmierza w tą stronę, ale mniejsza o to), a jeśli chodzi o docieranie do klientów - chętnie pomożemy.

Od tego - my w sprzedaży - jesteśmy.

[mzb]

Wiedza musi byc wykuta na kowadle doswiadczenia.

-- M.

[lbromirs]

Wiedza musi byc wykuta na kowadle doswiadczenia.

-- M.

[Sofcik]

Ale to co opisał horac chyba jest normalne w środowisku.
Kazdy kto kupuje sprzęt chciałby, żeby ten sprzęt tańczył, śpiewał, recytował i ...
I niestety jest tak, że jak ktoś zobaczy w dokumentacji do N7K "support for GRE" i nie ma głębszej wiedzy to będzie myślał, że z GRE zrobi wszystko. Jak ktoś zobaczy "Support for BGP" w docach do ASA to też może pomyśleć "po co mi router jak mi ASA to opędzi i jeszcze oszczędzę".

Sorry, taki mamy świat. A przez analogię - kupujesz samochód i ktoś Ci mówi, że pojedzie on w trudnym terenie. Jasne - pojedzie po szutrach i piachu ale w głębszym błocie się zakopie.
I jeśli nie masz wiedzy o tym co dany wóz może dokładnie zrobić to skończysz ze swoim superhiper wypasionym autem na holu przy Ursusie C330.

Za naiwność i wiarę w ludzi (zwłaszcza managerów co to "są pro bo Chipa czytają") często dostaje się kopa w dupsko - jeśli w umowie wdrożeniowej miałeś wypisane warunki to czasami warto dopytać czy przypadkiem w przyszłości klient nie będzie chciał np żeby jego super N7K robił to co robi ASA czy CSR/ASR.

Dasz radę, horac, tylko nie frustruj się tak bo padniesz na zawał przed 40ką

--
Piotrek

[horac]

Horac,

With all due respect - I don't fucking get it.

Masz pretensje, że na naszych pudełkach można robić WIĘCEJ a nie MNIEJ? I że jeszcze ośmielamy się o tym pisać w publicznie dostępnej dokumentacji?

Mam pretensje ze wprowadzacie ulomne funkcjonalnosci na pudelka ktore albo powinny je miec
w pelni albo wcale. Jesli dla ciebie to jest normalne to ciezko mi dodac cos wiecej.

Masz pretensje, że nie docierasz na poziom podejmujących decyzję i rozgrywają Cię inżynierowie/administratorzy siedzący na dole, dyktując co masz robić i na jakim sprzęcie? I to też nasza wina?

A z drugiej strony - jakoś niedawno sam chwaliłeś się, że masz w jednym palcu projektowanie sieci i zawsze klient wymyśla dziwne rzeczy i rolą architekta (architekta, nie jakiegoś tam inżyniera) jest zaadresować jego problemy na dostępnym sprzęcie lub przygotować konkretne rozwiązanie konieczne do kupienia.

Nie ma kasy, a nawet jakby byla to nie chca wydac bo N7K ma GRE i to im starczy, a ja wiem ze taka wersja GRE jaka dysponuje N7K nie wystarczy i jestem zmuszony robic to na N7K teraz rozumiesz ? Innej opcji jak GRE nie ma, musi byc i koniec, dlatego ze cloud DC do ktorego jest polaczenie po WAN ma overlapping adresacji calego IBMa, i nie chca routowac sieci klienta za vyatta przez swoja siec. Dlatego w gre wchodzi tunelling a end pointem jest Vyatta. Musi byc GRE i koniec, dalszej dyskusji nad zastosowanym rozwiazaniem nie mam zamiaru prowadzic bo wiem lepiej co potrzeba, wentyluje sie z powodu tego ze gdy juz musze zrobic GRE to okazuje sie ze N7K ma je czesciowo zaimplementowane co mi sie kloci z wszystkimi wymaganiami klientow. A chodzi o ponad 200 klientow z pewnej czesci europy, wiec to nie jest kwestia jednego a wielu. Nie pytaj mnie dlaczego firma nie chce kupic dodatkowych pudelek... po prostu nie chca bo ktos im wypral mozg ze po zakupie N7K moga juz miec wszystko na przyszlosc co nie jest prawda. Przy zakupie N7K byly wziete wszystkie przeszle wymagania i zostaly SPELNIONE. Pojawily sie natomiast nowe, ale wytlumacz biznesowi ze zakup N7K to nie koniec. Jak chce sie miec wiecej to trzeba wydac wiecej. Do nich to jednak nie dociera bo zyja z przeswiadczeniem ze ich nowe wymagania tez moga byc spelnione bez dodatkowych kosztow poniesionych na infrastrukture DC. Gdyby jednak N7K posiadal pelne GRE mialbym spokoj ;] a tak bede musial kombinowac, oczywiscie cos wymysle bo kreatywnosc jest cecha ludzi inteligentnych ale chcialby uslyszec od Cisco ze half-GRE to zamierzone dzialanie, albo ze planujecie zrobic upgrade do pelnego GRE w niedalekiej przyszlosci

Wywentylowałeś się na nas - i OK, przyjmujemy, że świat nie jest idealny. Wątpię, żebyśmy robili w przyszłości sprzęt o mniejszej ilości funkcjonalności (choć filozoficznie świat powoli zmierza w tą stronę, ale mniejsza o to), a jeśli chodzi o docieranie do klientów - chętnie pomożemy.

N7K to powazna platforma i robienie haly na nim nie swiadczy dobrze o firmie. Sa jeszcze inne kwiatki, o ktorych dowiadujesz sie po zakupie jak chociazby ograniczenie ilosci MAC przy VPC + ASA na patyku do 16k, a bez VPC jest 128k. Ta informacja wyplynela z Cisco juz po zakupie... a nie przed. Dlatego do dzisiaj w Core nie mamy VPC. I jest to problem, bo gdy chcial sie klient podlaczyc swoim DC z 6500 to dostal info ze przykro mi ale nie darady, bo na N7K jest fabric Path, a wymaganiem FP w podlaczaniu domeny STP jest to zeby Spine byly rootem co nie wchodzi w gre. Narazie to N7K ma wiecej ograniczen niz by sie moglo wydawac.

Kolejny mega problem pojawil sie przy VPLS i migracji klientow. Bez VPC i mh-VPLS zrobil sie cyrk z refreshem MACow w domenie FP. 2-3 miesiace trwalo znalezienie przycyzny dlaczego nie dziala redundancja, zaangazowanych bylo kilku CCIE od was i Distinguished inzynier ktory wymyslil rozwizania HA dla VPLS i skonczylo sie na protezie w postaci EEM na spine i leaf dodatkowym IGP i loopbackach tylko po to zeby w zaleznosci od tego czy loopback wyleci z RIB rozglaszany przez core czyscic tablice MAC. Nie jest to eleganckie ale dziala, tylko pytam sie ile jeszcze takich niespodzianek przyniesie N7K na przyszlosc ? Od zakupu platformy same problemy.

MPLS mozna wlaczyc jedynie w admin VDC i trzeba miec dostep do konsoli... tym podobnych absurdow jest pelno.

Jednym slowem wspolpraca N7K i nowymi technologiami dostepnymi w ramach NX-OS stworzonych pod DC z innymi technologiami sieciowymi to lekki koszmar. Dlatego wymyslajac nowe technologie jako vendor myslcie o tym ze swiat to nie jest lab CCIE DC gdzie wszystko jest nexusem a L2 rozciaga sie po OTV albo LISP. Tak to fajnie dziala w labie ale nie w realnym swiecie, gdzie jeszcze wielu.. nie stac na wymiane 6500 na N7K w DC.

[lukaszbw]

Miałem podobne odczucia. Jestem właśnie już w ostatniej fazie wdrażania Nexus 7K i też początkowo byłem zniesmaczony, że na 6500 można było tyle rzeczy zrobić a na 7K brakuje wielu.

Cisco jednak mnie od razu skorygowało, że jest to switch DC i nie jest jego zadaniem zastąpienie 6500, który nadal pozostaje w ofercie ale z przeznaczeniem do campus core.

Niestety w moim przypadku miałem problem taki, że musiałem jedno wybrać. Wymaganiem było 10GE na serwer (mimo, że i tak bardzo rzadko leci ponad 1Gbps) i switch miał być wbudowany w blade i do tego pełen netflow. To mi zawęziło pole działania do Nexus + Blade extender (B22HP). Musiałem też uzbroić się w cierpliwość aż pojawiło się oprogramowanie 6.2, które to dopiero wspiera N7K jako parent switch.

Początkowo było nastawienie, że damy Nexus 7700 ale tutaj też było zaskoczenie bo 7700 nie wspiera modułów M2, z kolei F3 nie obsługują full netflow co było wymaganiem.

Dodając fakt, że w DC mamy cold i hot aisle nexus 7009 odpadł ze względu na niekorzystny airflow. Został 7010 albo 7004. Po przeliczeniu portów wyszło na to, że 2x 7004 z 2x M2 na każdym wystarczy na najbliższy czas, jak zabraknie to dokupią kolejne. Od Panduit kupiliśmy flow converter do 7004 (z side to back na front to back) i dobrze się spisuje.

Na końcu doszła kwestia dystrybucji i ograniczeń w VPC przy routingu. Ponieważ switch miał też robić jako campus core, potrzebowałem switche z portami GE aby podłączać firewalle, routery i inne mniejsze switche. Tutaj pojawiło się ograniczenie bpduguard na nexus fabric extender więc nexus 2K odpadł. Decyzja poszła na sprawdzone 4948E na dystrybucje.

W końcu VPC. Z tym było mnóstwo myślenia ze względu na ograniczenia routingu. W końcu stwierdziłem, że nie ma sensu walczyć z ograniczeniami (można było dać od biedy OSPF na nonVPC vlan). Jeszcze doszła kwestia VPC keepalive przy dual sup.

Ostatecznie wyszło, że VPC nie będzie a serwery będą robić load balancing na switche 7K (multihomed flexlink nie jest obsługiwany) od strony Vmware/HyperV. Rozłożenie przepustowości jest dalekie do idealnego ale ponieważ chcieliśmy uniknąć etcherchannel na serwerach i mieć konfiguracje core w miare prostą zeszło na standardowy RPVST+. Mimo, że serwery korzystają z SAN (po iSCSI) to nie ma problemów z przepustowością.

Generalnie troche niesmak pozostaje ale musze przyznać, że po wielu rozmowach z ASami dostałem wszystkie informacje, które były mi potrzebne do projektu.
Gdyby nie wymaganie full netflow to bym zdecydował się na cat 6800 + Nexus 6K. 6800 jako campus core a N6K jako DC core.

Cisco dąży do stworzenia wielu specjalizowanych urządzeń. Warto zwrócić uwagę, że dotyczy to też innych serii - choćby cat6800 już nie ma opcji portów z PoE więc już jako switch access/dystrybucja/core odpada.

Przy standardowych wymaganiach nikt nie każe kupować od razu N7K, jest wiele opcji pośrednich jak choćby 6K czy 5.5K. Niestety czasami wymagania i dostępne finanse są takie, że trzeba kombinować. Proponuję wtedy zagadać z account manager w cisco aby umówić się na rozmowe z kimś z AS. Można wtedy przenalizować różne opcje i z pierwszej ręki dowiedzieć się jak wygląda kwestia wsparcia wymaganej funkcjonalności w aktualnym sofcie.


Pozdr.

[robhass]

Mam mala uwage do Cisco. Nie robcie z pudelek Data Center maszynek do golenia, bo to moze sie zawalic jak domek z kart.

Kilka slow, moze nie do Ciebie horac ale refleksji apropo Twojego zdenerwowania.

Jak by to powiedziec, vendor mowi - nasze pudlo umie GRE, a pozniej Partner ma problem

Ale to troche nie tak - bo tutaj vendor jest boga ducha winny - jako ze jest to dobrze opisane w dokumentacji. W ogole to cieszmy sie, ze w ogole GRE jest vrf-aware na N7K mimo swoich ograniczen .

Po latach doswiadczen przyzwyczailem sie, ze jesli cos jest vrf-aware to sa ograniczenia szczegolnie dotyczace platform gdzie wszystko realizuje hardware.

Na pocieszenie u kolegow od innych vendorow takie rzeczy tez wystepuja - trzeba byc bardzo obytym z platforma (duzo przeczytac, dopytac, doswiadczenie). Albo czegos nie ma w VRF'ach - bo to za duzo roboty i za malo klientow na to (czytaj za malo $$$).

Rob

[horac]

robhass jestem ciekaw jak duzo osob testowalo GRE na N7k albo w ogole go ma. Zeby bylo jasne ja od poczatku wiedzialem ze GRE jest ograniczone na N7k i nie zaliczylem zadnej wtopy. Bo mam w zwyczaju doczytac dokumentacje zanim odpowiem czy cos dziala na danej platformie czy nie. Musialem jedynie zakomunikowac ze GRE da sie zrobic ale nie jest tak funkcjonalne jak na routerze i ma ograniczenia. Dlatego wentyluje sie tutaj i chce sie dowiedziec o co chodzi, ze N7K ma half-GRE a nie pelna funkcjonalnosc. Szkoda ze nie ma HALF-MPLSa...

[martino76]

Powiem tak jest to dość nowy sprzęt i jego funkcjonalność będzie rozwijana. Zauważ, że na początku miałeś karty M1, F1 później M2 i F2 a teraz masz tylko F3. Wiązało się to z tym, że miałeś różne restrykcje co do rożnego typu kart itd, teraz masz tylko F3 i wszystko się zmienia. To samo tyczy się OTV jeśli chcesz mieć SVI to musisz tworzyć Datkowy VDC i robić link miedzy VDC, w którym masz OTV a tym w którym masz SVI. Nic na to nie poradzimy porostu trzeba z tym żyć i mieć nadzieje, że Cisco z czasem pozbędzie się takich kwiatków.

Myślę, ze wiele problemów wiąże się z tym, ze sporo rzeczy robionych jest w hardware i może Cisco z niektórymi problemami nie może sobie poradzić dlatego mamy takie kwiatki, bo jeśli mona było by to zrobić inaczej na pewno by to zrobili

Mnie, tez irytuje, ze network QOS możesz zdefiniować tylko w admin VDC i ma wpływ na cały switch i inne VDC i nie można tego zmienić per VDC.

Rozumiem, że za taką kasę klient oczekuje dobrego sprzętu ale czasem parcie biznesu by być pierwszym na rynku z dana funkcjonalności nie przekłada się na jakoś produktu


Pozdro,

[gangrena]

Mam pretensje ze wprowadzacie ulomne funkcjonalnosci na pudelka ktore albo powinny je miec
w pelni albo wcale. Jesli dla ciebie to jest normalne to ciezko mi dodac cos wiecej.

Przy takim ujęciu, to praktycznie każda funkcjonalność jest ułomna, gdyż zawsze czegoś brakuje, gdy klient zechce kombinować. Również MPLS. Nie ma przykładowo jeszcze implementacji LDP dla IPv6.

Nie ma kasy, a nawet jakby byla to nie chca wydac bo N7K ma GRE i to im starczy, a ja wiem ze taka wersja GRE jaka dysponuje N7K nie wystarczy i jestem zmuszony robic to na N7K teraz rozumiesz ? Innej opcji jak GRE nie ma, musi byc i koniec

Jeżeli klient postępuje wbrew rekomendacjom, to odpowiedzialność za design spada na niego. Chyba, że vendor dał takie rekomendacje, które nie działają. Jednak z tego, co piszesz, to klient uparł się na GRE. Twoją rolą przekonać klienta do swojej opcji lub zrobić GRE, które również w obecnej postaci na N7k można zrobić w sposób redundantny i odseparowany.

Gdyby jednak N7K posiadal pelne GRE mialbym spokoj ;]

Gdyby architekci posiadali pełną wiedzę mieliby spokój

Sa jeszcze inne kwiatki, o ktorych dowiadujesz sie po zakupie jak chociazby ograniczenie ilosci MAC przy VPC + ASA na patyku do 16k, a bez VPC jest 128k. Ta informacja wyplynela z Cisco juz po zakupie... a nie przed.

Tutaj nie chodzi o ASA. Jeżeli na karcie F VLAN-y są populowane na każdym porcie, to adresy MAC muszą być synchronizowane między układami SoC, które mają ograniczenie do 16k. To jest podstawowa wiedza na temat platformy dostępna również w dokumentacji. Należało spozycjonować kartę M.

..., a wymaganiem FP w podlaczaniu domeny STP jest to zeby Spine byly rootem co nie wchodzi w gre. Narazie to N7K ma wiecej ograniczen niz by sie moglo wydawac.

Switche Spine mają być rootem STP w FP? Chyba nie masz na myśli Fabric Path, w którym STP jest terminowane na brzegu? To switche Leaf są rootem, a nie switche Spine.

Kolejny mega problem pojawil sie przy VPLS i migracji klientow. Bez VPC i mh-VPLS zrobil sie cyrk z refreshem MACow w domenie FP. 2-3 miesiace trwalo znalezienie przycyzny dlaczego nie dziala redundancja, zaangazowanych bylo kilku CCIE od was i Distinguished inzynier ktory wymyslil rozwizania HA dla VPLS i skonczylo sie na protezie w postaci EEM na spine i leaf dodatkowym IGP i loopbackach tylko po to zeby w zaleznosci od tego czy loopback wyleci z RIB rozglaszany przez core czyscic tablice MAC.

Case TAC, który tej sprawy dotyczył został rozwiązany nie poprzez manipulacje na EEM, ale poprzez włączenie MAC learningu.

Nie jest to eleganckie ale dziala, tylko pytam sie ile jeszcze takich niespodzianek przyniesie N7K na przyszlosc ? Od zakupu platformy same problemy.

To, co już zostało wspomniane przez kolegę bartekr, po wykonaniu PoC wspomniane przez Ciebie problemy raczej nie występują. Odkąd jestem w Cisco nie doświadczyłem sytuacji, w której zwalidowane rozwiązanie w PoC wykazywałoby się limitami, które byłyby wbrew wstępnym założeniom. Od tego właśnie są testy. Jeżeli coś jednak kogoś zaskoczyło, to znaczy, że:
a) Rozwiązanie nie zostało właściwie rozpoznane na poziomie funkcjonalnym.
b) Nie zostały wykonane wszystkie konieczne testy.
c) Albo ktoś ma zbyt małą wiedzę i doświadczenie.

MPLS mozna wlaczyc jedynie w admin VDC i trzeba miec dostep do konsoli... tym podobnych absurdow jest pelno.

Jednym slowem wspolpraca N7K i nowymi technologiami dostepnymi w ramach NX-OS stworzonych pod DC z innymi technologiami sieciowymi to lekki koszmar. Dlatego wymyslajac nowe technologie jako vendor myslcie o tym ze swiat to nie jest lab CCIE DC gdzie wszystko jest nexusem a L2 rozciaga sie po OTV albo LISP. Tak to fajnie dziala w labie ale nie w realnym swiecie, gdzie jeszcze wielu.. nie stac na wymiane 6500 na N7K w DC.

To już brzmi jak użalanie się kapryśnego chłopca, który chce być wielkim architektem. Bez przesady. Weź się chłopie w garść.

[horac]

Jeżeli klient postępuje wbrew rekomendacjom, to odpowiedzialność za design spada na niego. Chyba, że vendor dał takie rekomendacje, które nie działają. Jednak z tego, co piszesz, to klient uparł się na GRE. Twoją rolą przekonać klienta do swojej opcji lub zrobić GRE, które również w obecnej postaci na N7k można zrobić w sposób redundantny i odseparowany.

Co mozna zrobic to ja wiem, po prostu dodatkowa vyatta per zona zeby byl inny DSTp dla kazdego tunelu GRE i nie bedzie problemu. Wszystko jest w fazie testow i PoC ktory robie sam, zglaszam swoje uwagi publicznie na forum. Nie jestem samobojca nie jest to problem produkcyjny obecnie. Dziwi mnie wasze podejscie do tematu, w zasadzie dla was nie ma problemu ze N7K ma half-GRE, a jeszcze nikt nie napisal dlaczego tak jest.

Gdyby jednak N7K posiadal pelne GRE mialbym spokoj ;]

Gdyby architekci posiadali pełną wiedzę mieliby spokój

Rola architekta nie jest studiowanie funkcjonalnosci kart liniowych i ograniczenia software. To raczej rola pre-sales.
Powtorze jednak po raz kolejny ze temat GRE na N7k pojawil sie pol roku po zakonczonym projekcie gdzie wszystkie PoC, etc zostaly wykonane i nie bylo problemow na podstawie tamtych wymagan.

Tutaj nie chodzi o ASA. Jeżeli na karcie F VLAN-y są populowane na każdym porcie, to adresy MAC muszą być synchronizowane między układami SoC, które mają ograniczenie do 16k. To jest podstawowa wiedza na temat platformy dostępna również w dokumentacji. Należało spozycjonować kartę M.

Skoro to jest podstawowa wiedza czemu nie zostala przedstawiona przed zakupem ? przez NCE i TSA. Moze wy w Cisco macie czas
na studiowanie kart i hardware ja osobiscie nie mam i to jest odpowiedzialnosc ktora przerzucam na was w projektach. Cisco ma za zadanie dobrac platforme pod wymagania ktore postawie. Temat GRE nie byl w fazie wspolpracy i zakupu produktu wiec nie czepiam sie ani Cisco TSA ani NCE, czepiam sie samego produktu bo przyszlo sie zmierzyc z kolejnym wymaganiem ktore nie bylo testowane wczesniej bo nie bylo takiej potrzeby, nikt nie zakladal tunelowania na Nexusie, fakt jednak jest faktem i trzeba to zrobic. Odpalilem podstawowe ograniczone GRE testowo w VRF i licze na to ze nie spotka mnie nic zlego.

Switche Spine mają być rootem STP w FP? Chyba nie masz na myśli Fabric Path, w którym STP jest terminowane na brzegu? To switche Leaf są rootem, a nie switche Spine.

Mam na mysli fabric Path miedzy spine i leaf, gdzie trzeba podlaczyc domene STP do spine. Wtedy spine musza byc rootem dla STP. Taka informacje otrzymalem z Cisco, sam o tym nie wiedzialem bo FP jest dla mnie nowa rzecza a tym bardziej laczenie z domenami STP. Spytalem wiec Cisco i dostalem info takie jak przedstawilem

Case TAC, który tej sprawy dotyczył został rozwiązany nie poprzez manipulacje na EEM, ale poprzez włączenie MAC learningu.

To ciekawe, moze oficjalnie tak zostal zamkniety, nie mam dostepu bo to ATT zakladalo, ale rozwiazanie jest zupelnie inne, zreszta przedstawione przez Cisco TSA. Moge ci podeslac konfig. Zostal wdrozony EEM na spine i Leaf oraz IGP na wszystkicg 6 nexusach tylko po to by sprawdzac czy loopback rozglaszany przez spine wylatuje z RIB na leaf, jesli tak czyszczona jest tablica MAC. To dopiero rozwiazalo problem z VPLS.

Prawda jest taka ze TAC sobie z tym nie poradzil i nie dal rady rozwiazac problemu, mimo testowania w labie. Osoba ktora rozwiazala ten problem byl TSA z Cisco, ktoremu za to serdecznie dziekuje. Jesli jednak taki cerowany kondom ma zostac na stale to slabo to wyglada. Bo nie bylo zalozeniem aby SPINE i LEAF mialy miedzy soba domene IGP. Na SZCZESCIE mielismy licencje L3 na leaf zeby wprowadzic ta proteze.

To już brzmi jak użalanie się kapryśnego chłopca, który chce być wielkim architektem. Bez przesady. Weź się chłopie w garść.

Kaprys to powstal przy wprowadzeniu GRE na N7K, dla kaprysu czesc rzeczy dziala czesc nie.

To forum powoli zamienia sie w klike fanatykow dla ktorych jakie kolwiek zle slowo o produkcie czy sofcie przejawia sie odruchem obronnym. To oczywiste ze nie przyznacie mi racji, ale chociaz napiszcie dlaczego GRE jest w takiej postaci na N7K a nie innej bo tylko wy macie dostep do takich informacji.

Wracajac do tematu, keepalive w GRE tez wam sie nie chcialo zrobic

https://supportforums.cisco.com/discuss ... -keepalive

ale to ja mam kaprys zeby mi sie tunele skladaly... Oczywiscie nexus by mogl ich nie miec, bo wystarczy z jeden end-point tunelu ma, ale vyatta tez nie ma


Sorry... taki mamy klimat a raczej Sorry... taki mamy NX-OS

[mzb]

To oczywiste ze nie przyznacie mi racji, ale chociaz napiszcie dlaczego GRE jest w takiej postaci na N7K a nie innej bo tylko wy macie dostep do takich informacji.

Odkąd pamiętam, różnego rodzaju niestandardowe/niepopularne rzeźby, obarczone są dozą ryzyka, o takich rzeczach się wie, że wymagają precyzyjnego testowania, i też wie się, że mogą różnie się zachowywać w różnych okolicznościach. Zawsze (i wszystkich vendorów) tak było, że coś działa, coś nie działa, a coś działa częściowo, a coś innego ma bug'a...

Nie pracuję w Cisco, ale podpowiem Ci kilka opcji, wedle których to coś czego szukasz może nie działać:

- bo hardware nie jest profilowany,
- bo ktoś tego jeszcze nie zaprogramował,
- bo nie da się tego zaprogramować optymalnie bez rezygnacji z innych zasobów hardware,
- inne.

BTW - to jak publicznie odsłaniasz klientów i rzucasz nazwami i problemami jest niesamowite. Pełna poufność informacji - pro.

-- M.