Stary my generujemy backbone bgp configi automatycznie wiec jakie snmp czy passwordy .martino76 pisze:freel4ncer pisze:Dlatego trzeba pisac Testy
I testowac kod w labie zanim sie go pchnie do produkcji
Ja osobiscie nei mialem jeszcze zadnej duzej wtopy z powodu autmatyzacji
Wypadki sie zdarzaja , jeden koles w pakistanskim ISP zrobil blackhole youtuba , zdazaja sie typos inzynierom ktorzy konfiguruja z palca.
Wydaje mi sie ze automatyzycja przynosi wiecej dobrego niz zlego i jest wlasnie bardziej odporna na awarie/pomylki niz konfigurowanie z palca
Wszystko zalezy od tego jak to jest zrobione (jak ze wszystkim zreszta)
Ale nikt nie zaprzeczy ze taki jest kierunek networkingu .
Jak ktoś będzie pisał skrypty o czymś, o czym nie ma pojęcia to trudno przewidzieć rezultaty. Poza tym, za skryptami stoi również tylko człowiek, wiec błędy się zdarzają. Z drugiej strony, jeśli robisz automatyzacje snmp, vty password, tacacs itd., ok są to dość proste sprawy i nawet jak się cos wywali to nie będzie to miało wpływu na twój data plane, ale wyobraź sobie stację, że robisz deployment MP-BGP, jakiś IGP itd. na kilkudziesięciu nodach. W razie problemu troubleshooting bedzie bardziej skomplikowany niż jakbyś robił deployment z palca.
Pozdro,
Jeżeli nie Cisco to co?
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
Ja chce Pajtony uzywac bo mi daje flexibility nie potrzebuje "glupich" tooli ktore dzialaja i pozwalaja mi robic tylko to co zamierzyl sobie programista. Ja chce robic to co ja sobie wymysle i jak sobei wymyslekonradrz pisze:To bodaj od Cumulusa: "to err is human; to err a million times is to automate".Kyniu pisze:Właśnie ukułem hasło dnia automatyzacja zarządzania = automatyzacja katastrof na masową skalę albo zautomatyzuj sobie disaster
Tak czy inaczej, jak masz API to nie musisz żadnych pajtonów czy innych węży używać - głupi Postman wystarczy (ze swoim Runner tool). Przykład (odnośnie ACI, ale to nieistotne) tu. Imaginuj jak łatwo te kilkaset VLANów byś zrobił (NXOS "zwykły" ma API).
Re: Jeżeli nie Cisco to co?
Ależ oczywiście.freel4ncer pisze:Ja chce robic to co ja sobie wymysle i jak sobei wymysle
Niemniej, nie każdemu aż takie skryptowanie jest potrzebne. Ba, jak sieciowcowi pokażesz skomplikowany skrypt to zblednie i odpuści sobie temat ("łeee, to nie dla mnie").
A taki głupiutki Postman to delikatne, miękkie wejście w świat automatyzacji. Zrobisz nim sobie w kilka sekund setki VLANów, i pewnie większości wystarczy. Ale co dziesiątemu będzie mało i pomyśli nad tymi pytonami i inszymi.
Wiesz, "nie od razu Rzym" i tak dalej.
Re: Jeżeli nie Cisco to co?
freel4ncer pisze:Stary my generujemy backbone bgp configi automatycznie wiec jakie snmp czy passwordy .martino76 pisze:freel4ncer pisze:Dlatego trzeba pisac Testy
I testowac kod w labie zanim sie go pchnie do produkcji
Ja osobiscie nei mialem jeszcze zadnej duzej wtopy z powodu autmatyzacji
Wypadki sie zdarzaja , jeden koles w pakistanskim ISP zrobil blackhole youtuba , zdazaja sie typos inzynierom ktorzy konfiguruja z palca.
Wydaje mi sie ze automatyzycja przynosi wiecej dobrego niz zlego i jest wlasnie bardziej odporna na awarie/pomylki niz konfigurowanie z palca
Wszystko zalezy od tego jak to jest zrobione (jak ze wszystkim zreszta)
Ale nikt nie zaprzeczy ze taki jest kierunek networkingu .
Jak ktoś będzie pisał skrypty o czymś, o czym nie ma pojęcia to trudno przewidzieć rezultaty. Poza tym, za skryptami stoi również tylko człowiek, wiec błędy się zdarzają. Z drugiej strony, jeśli robisz automatyzacje snmp, vty password, tacacs itd., ok są to dość proste sprawy i nawet jak się cos wywali to nie będzie to miało wpływu na twój data plane, ale wyobraź sobie stację, że robisz deployment MP-BGP, jakiś IGP itd. na kilkudziesięciu nodach. W razie problemu troubleshooting bedzie bardziej skomplikowany niż jakbyś robił deployment z palca.
Pozdro,
Możesz sobie generować co tylko chcesz, BGP, MPLS-TE, SR, ACL, EVPN i bog wie co jeszcze. Ja napisalem, ze jak to wygenerujesz i wrzucisz config na kilkadziesiąt urządzeń, to w razie jakiegoś problemu troubleshooting będzie bardziej skomplikowany, niz jak będziesz implementował to z palca. Ja sie tam nie znam, na tych waszych toolach
Pozdro,
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
Dlaczego tshoot ma byc bardziej skomplikowany ? Konfig bazuje na informacjach z bazy , jest zawsze standardowo opisany uzywajac annotations ja bym wlasnie powiedzial ze jest latwiejszy do troubleshootingu ze wzgledu na standaryzacje. Maszyna jesli cos popsuje to zrobi to w sposob ktory da sie latwiez zbacktrackowac niz jak zrobi to czlowiek , wystarczy przeleciec kod i juz wiesz co i dlaczego sie wykonalo , z czlowiekiem nie jest to takie proste (wiadomo mozna logowac komendy + diff na rancid itp ale czasem ciezko wykoncypowac dlaczego inzynier zrobil cos tak a nie inaczej )martino76 pisze:freel4ncer pisze:Stary my generujemy backbone bgp configi automatycznie wiec jakie snmp czy passwordy .martino76 pisze:
Jak ktoś będzie pisał skrypty o czymś, o czym nie ma pojęcia to trudno przewidzieć rezultaty. Poza tym, za skryptami stoi również tylko człowiek, wiec błędy się zdarzają. Z drugiej strony, jeśli robisz automatyzacje snmp, vty password, tacacs itd., ok są to dość proste sprawy i nawet jak się cos wywali to nie będzie to miało wpływu na twój data plane, ale wyobraź sobie stację, że robisz deployment MP-BGP, jakiś IGP itd. na kilkudziesięciu nodach. W razie problemu troubleshooting bedzie bardziej skomplikowany niż jakbyś robił deployment z palca.
Pozdro,
Możesz sobie generować co tylko chcesz, BGP, MPLS-TE, SR, ACL, EVPN i bog wie co jeszcze. Ja napisalem, ze jak to wygenerujesz i wrzucisz config na kilkadziesiąt urządzeń, to w razie jakiegoś problemu troubleshooting będzie bardziej skomplikowany, niz jak będziesz implementował to z palca. Ja sie tam nie znam, na tych waszych toolach
Pozdro,
Ostatnio zmieniony 23 mar 2017, 18:44 przez freel4ncer, łącznie zmieniany 2 razy.
-
- wannabe
- Posty: 581
- Rejestracja: 27 wrz 2007, 01:13
Re: Jeżeli nie Cisco to co?
Oczywiscie nie ma co sie na muche z dzialem szykowackonradrz pisze:Ależ oczywiście.freel4ncer pisze:Ja chce robic to co ja sobie wymysle i jak sobei wymysle
Niemniej, nie każdemu aż takie skryptowanie jest potrzebne. Ba, jak sieciowcowi pokażesz skomplikowany skrypt to zblednie i odpuści sobie temat ("łeee, to nie dla mnie").
A taki głupiutki Postman to delikatne, miękkie wejście w świat automatyzacji. Zrobisz nim sobie w kilka sekund setki VLANów, i pewnie większości wystarczy. Ale co dziesiątemu będzie mało i pomyśli nad tymi pytonami i inszymi.
Wiesz, "nie od razu Rzym" i tak dalej.
Ja juz jestem troche skrzywiony pod tym wzgledem bo to moja dzialka i wszystko co nie daje mi pelnej swobody jest dla mnie poporstu bleh
Chociaz uczylem sie wlasnei piszac proste rzeczy ktore mozna bylo zalatwiac toolami (jak to sie mowi odkrywalem kolo na nowo ) i mimo tego iz poczatkowo moglo by sie to wydawac strata czasu , w dluzszej perspektywie zaprocentowalo
Re: Jeżeli nie Cisco to co?
Panowie, vendorzy dostarczają API i chwała im za to. Dlatego każdy ma wybór czy chce coś zautomatyzować czy nie.
Dla analogii fabryki samochodów są również zautomatyzowane. I jak się zdarzają wpadki to również na masową skale.
Czy to oznacza, że rezygnują one z automatyzacji? Nie. Analiza potencjalnych zysków i strat podpowiada im pozostanie przy automatyzacji. Dlaczego? Ponieważ są oni w stanie wyprodukować tanio więcej samochodów w krótkim czasie niż robiąć to ręcznie. Nie oznacza to że wszystkie samochody są produkowane masowo. Zawsze będą istniały reczne manufaktury.
Analogicznie w świecie IP są miejsca gdzie automatyzacja się oplaca, a nawet jest niezbędna, jak i pozostaną miejsca gdzie nie będzie ona miała zastosowania.
Najważniejsze, że mamy wybór;)
Dla analogii fabryki samochodów są również zautomatyzowane. I jak się zdarzają wpadki to również na masową skale.
Czy to oznacza, że rezygnują one z automatyzacji? Nie. Analiza potencjalnych zysków i strat podpowiada im pozostanie przy automatyzacji. Dlaczego? Ponieważ są oni w stanie wyprodukować tanio więcej samochodów w krótkim czasie niż robiąć to ręcznie. Nie oznacza to że wszystkie samochody są produkowane masowo. Zawsze będą istniały reczne manufaktury.
Analogicznie w świecie IP są miejsca gdzie automatyzacja się oplaca, a nawet jest niezbędna, jak i pozostaną miejsca gdzie nie będzie ona miała zastosowania.
Najważniejsze, że mamy wybór;)
Re: Jeżeli nie Cisco to co?
Buuuuuuu, a ja chciałem się tylko dowiedzieć, na czym innym niż Cisco warto zawiesić oko.
Re: Jeżeli nie Cisco to co?
Na ładnej kobiecie ;Pziolek pisze:Buuuuuuu, a ja chciałem się tylko dowiedzieć, na czym innym niż Cisco warto zawiesić oko.
CCNA: R&S, Security, Wireless, Collaboration. MCSE: Cloud Platform and Infrastructure, Server Infrastructure. ITIL: Foundation. PPL(A)
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
Re: Jeżeli nie Cisco to co?
Weź na testy przełączniki Huawei z serii CloudEngine, dobierz sobie model z odpowiednimi portami i sprawdź interesujące Cię ficzery.ziolek pisze:Buuuuuuu, a ja chciałem się tylko dowiedzieć, na czym innym niż Cisco warto zawiesić oko.
It doesn't matter how many certs you've got... it's really all about the pure knowledge behind them...
Re: Jeżeli nie Cisco to co?
Jak chcesz glownie L2 i czasem cos z L3 to przetestuj X670-G2.ziolek pisze:Buuuuuuu, a ja chciałem się tylko dowiedzieć, na czym innym niż Cisco warto zawiesić oko.
Jak chcesz glownie L3 a czasem kawalek L2, to proponuje przyjrzec sie dokladnie ACX5048.
Re: Jeżeli nie Cisco to co?
ziolek pisze:No właśnie co do rdzenia małej serwerowni jeżeli nie chcemy rozpatrywać Cisco:
Istotne warunki brzegowe:
- porty 10Gbps;
- możliwość rozciągnięcia linków (LAG, LACP, inne wynalazki) z serwerów do dwóch niezależnych switchy bez utraty komunikacji jeżeli wpadnę na pomysł upgrade jednego z nich;
- głównie szybkie L2, ale OSPFa + jakieś tworzenie ACLek pomiędzy vlanami też powinien mieć;
- VTEP na przyszłość
Do wyboru zaproponowano mi (poza Cisco)
- Dell model S4048-ON
- Extreme X670-2
- Juniper QFX5100
- HP 5940
Raczej wszystko ma podobne funkcjonalności (przynajmniej na papierze) wiec chciałbym prosić czytających moje wypociny o uwagi dotyczące praktycznej eksploatacji ww. a w szczególności dostępności szkoleń, serwisu, innych aspektów dlaczego warto (albo i nie warto) kupować coś innego.
O Della-ch już się nasłuchałem w innym wątku.
Z góry dzięki za wszystkie odpowiedzi.
Kod: Zaznacz cały
marketing mode on
Jak bez VXLAN (bez VTEP'a) to niższa seria czyli CE6850EI (pełne wsparcie dla L3 ale bez VXLAN).
Serii LI nie proponuję bo to raczej access.
Szkolenia są, serwis jest (bez tego Huawei nic by nie zrobił na rynku telco - ale i nie tylko, na którym jest mocno obecny).
Kod: Zaznacz cały
marketing mode off
Re: Jeżeli nie Cisco to co?
Pomysł jeszcze o:ziolek pisze:No właśnie co do rdzenia małej serwerowni jeżeli nie chcemy rozpatrywać Cisco:
Istotne warunki brzegowe:
- porty 10Gbps;
- możliwość rozciągnięcia linków (LAG, LACP, inne wynalazki) z serwerów do dwóch niezależnych switchy bez utraty komunikacji jeżeli wpadnę na pomysł upgrade jednego z nich;
- głównie szybkie L2, ale OSPFa + jakieś tworzenie ACLek pomiędzy vlanami też powinien mieć;
- VTEP na przyszłość
Arista 7150
Arista 7050SX2
Brocade VDX6740
Re: Jeżeli nie Cisco to co?
Arista 7050SX albo TX wystarczy z nawiązką. Uplinki 40G można 'przerobić' na 4x10 i jest 64x10G. Albo wykorzystać do active/active MLAGa (jako inter-chassis). 7050X2 wydaje się nadmiarowe bo bez kupy spine'ów nie trzeba chyba 128way ECMP ani powiększonych buforów. VTEPy, API, REST i integracja z NSX jest. Możesz sobie ściągnąć OS Aristy (vEOS) jako VM i zrobić małego laba na kompie z GNS3. Miła niespodzianka jest taka że L2 działa i konfigi są prawie paste-copy Cisco.
z pobocznej beczki, moja kontrowersyjna teza: 'Automatyzacja jest jedynym lekarstwem na katastrofy!!!!' . Dowód: w całym systemie błędy popełnia właściwie tylko człowiek => mniej człowieka mniej błędów.
Gdyby Amazon był konfigurowany przez 1000 xCCIE to przy ich ilości workloadów awarie mieliby co tydzień....
z pobocznej beczki, moja kontrowersyjna teza: 'Automatyzacja jest jedynym lekarstwem na katastrofy!!!!' . Dowód: w całym systemie błędy popełnia właściwie tylko człowiek => mniej człowieka mniej błędów.
Gdyby Amazon był konfigurowany przez 1000 xCCIE to przy ich ilości workloadów awarie mieliby co tydzień....