onePK - jak zostac sieciowym bogiem cisco

Swobodne rozmowy na nie-sieciowe tematy
Wiadomość
Autor
Awatar użytkownika
Piotrek
wannabe
wannabe
Posty: 143
Rejestracja: 28 sie 2005, 23:12
Lokalizacja: Kraków

#16

#16 Post autor: Piotrek »

Temat jest nowy i jak już tutaj widać wywołujący sporo kontrowersji. Chyba najczęściej występuje obawa co dalej z rolą administratora sieci, a może ogólniej silosami w świecie IT (Network, Storage, Server itd). Role zaczynają się przenikać i chyba to jest największa zmiana. Powstają zespoły devops .. choć ostatnio słyszałem określenie NetOps :)

Jest obecnie kilka rozwiązań (NSX, Contrail, ACI, Opendaylight/OF) jeżeli chodzi o SDN i cięko chyba komukolwiek powiedzieć które rozwiązanie będzie dominujące. Pewnie może się okazać, że w zależności od typu sieci będzie dominował inny kontroler.

Osobiście nie wydaje mi się aby było wiele sytuacji aby programować na niskim poziomie. Raczej w codziennej obsłudze zostanie budowanie sieci dla tenanta , konfigurowanie serwsów LB/FW , planowanie redundancji/skalowalności. Czyli wyjście z poza urządzeń sieciowych do warstwy software i operowanie za pomocą gui czy API.

W przypadku NSX/Contraila dalej zostanie opieka nad siecią underlay (pewnie Clos) która będzie przenosić ruch IP.

Więc dalej będzie potrzebna wiedza sieciowa plus nowa wiedza. Ale chyba w IT ciężko o wiedzię która się nie zmienia.
Te rzeczy też nie staną się już tylko dopiero z jakiś czas. Obecnie SDN jest w fazie dla "early addopters". Pod koniec 2014 roku widziałem na Twitterze wzmiankę na temat pierwszego wdrożenia ACI.
Ostatnio zmieniony 04 sty 2015, 11:58 przez Piotrek, łącznie zmieniany 1 raz.

Awatar użytkownika
maverik
member
member
Posty: 39
Rejestracja: 09 maja 2013, 14:31

#17

#17 Post autor: maverik »

Kyniu pisze:
maverik pisze: Admin też potrafi i powinien programować.
Czy oskryptowanie regularnie wykonywanej i powtarzalnej czynności to już programowanie?

Na poziomie sieci operatorskich/uczelnianych, gdzie skrypt/daemon działa 24h i wykonuje pracę, która pozwala zaoszczędzić sporo adresacji IPv4 - tak.
Ostatnio zmieniony 03 sty 2015, 22:34 przez maverik, łącznie zmieniany 1 raz.

Awatar użytkownika
Sofcik
wannabe
wannabe
Posty: 1026
Rejestracja: 28 mar 2006, 15:29
Lokalizacja: Warszawa

#18

#18 Post autor: Sofcik »

Ale do SDN dochodzą też rozwiązania typu OpenStack (z OpenvSwitch i wszystkimi dodatkami do niego) i to na pewno się będzie rozwijać w jakimś kierunku. Czy będzie się przenikać z ACI/Contrail/NSX? Raczej tak bo chyba wszystkie z nich oferują (bądź będą oferować) integrację z OpenStackiem. Zabawy z wirtualizacją typu RHEV/Hyper-V/VSphere też będą się wiązać z jakimiś tam połączeniami z SDN. Ale pod spodem i tak muszą być serwery, pudełka sieciowe, kable, WiFi itp. Tak więc roboty dla "sprzętowców" (sieci, serwery, storage) nie zabraknie, dla tych od SDN też się pojawi zapewne nisza, programiści i administratorzy od systemów też będą potrzebni.

Myślę, że SDN jest ewolucją a nie rewolucją i (wg mnie) bez względu na wszystko jakieś tam podstawy SDN każdy sieciowiec powinien mieć.

A swoją droga tytuł tego wątku jest ciekawy :D Czyżby mała megalomania 8) ?

--
Piotrek

Keadwen
wannabe
wannabe
Posty: 192
Rejestracja: 03 paź 2011, 07:14

#19

#19 Post autor: Keadwen »

garfield pisze: Tam sie SDN świetnie sprawdzi ze wzgledu na skalę i ze wzgledu na to ze tam nikt nie zada pytania "ale co nam to da poza tym ze sieciowcy się pobawią" - wiem ze w Google to bedzie wręcz powód żeby to wdrażac
Od dawna jest to już wdrażane. Ilość sieciowców z umiejętnością pisania Python/Go/C++ jest zdecydowanie większa niż tych co nie potrafią.
I mówienie, że:
Kyniu pisze:Zaś dopuszczanie programistów do sieci to już będzie totalna porażka.
jest troszkę niepoprawne. Większość osób piszących bardzo zaawansowany i istotny kod to doświaczeni w sieciach eksperci (również certyfikowani).
Ostatnio zmieniony 04 sty 2015, 12:20 przez Keadwen, łącznie zmieniany 1 raz.

mzb
wannabe
wannabe
Posty: 163
Rejestracja: 16 cze 2009, 14:14

#20

#20 Post autor: mzb »

Keadwen pisze:
Kyniu pisze:Zaś dopuszczanie programistów do sieci to już będzie totalna porażka.
jest troszkę niepoprawne. Większość osób piszących bardzo zaawansowany i istotny kod to doświaczeni w sieciach eksperci (rówieniż certyfikowani) .
I tutaj jest istota problemu - jest tona firm, w których kodujący sieciowiec to norma (duże wymienione, startup'y, CDN'y), które kodują na własne potrzeby i osobiście uważam to za super sprawę, gdyż pokazuje to jak nowoczesna jest dana organizacja - trend zaczyna się od oczywiście od Kalifornii. :)
W temacie dyskusji - kolega @Piotrek ujął to w dobry sposób - pod terminem sdn kryje się wiele różnych technologii - w tym overlay'e, APIs, scripting, automatyzacja - zasada z punktu widzenia pracy w IT jest ciągle ta sama - nieustanny rozwój, od nadmiaru wiedzy i umiejętności raczej nikomu nic złego się nie stanie.

-- M.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#21

#21 Post autor: lbromirs »

Za dużo do napisania tutaj - swoje przemyślenia wrzuciłem tutaj:

http://lukasz.bromirski.net/2015/01/czy ... -dla-ccie/

horac

#22

#22 Post autor: horac »

lbromirs pisze:Za dużo do napisania tutaj - swoje przemyślenia wrzuciłem tutaj:

http://lukasz.bromirski.net/2015/01/czy ... -dla-ccie/
Jedno pytanie, na ktore z pewnoscia Cisco jest w stanie odpowiedziec, czy API w Pythonie ma ograniczenia wydajnosciowe w porownaniu z C. Bo nie chcialbym sie rozczarowac odczytuajac eventy z CDP do APKi czy grzebiac w pakietach ze cos mi zamuli, jak moglem np od poczatku zrobic to w C.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#23

#23 Post autor: lbromirs »

horac pisze:
lbromirs pisze:Za dużo do napisania tutaj - swoje przemyślenia wrzuciłem tutaj:

http://lukasz.bromirski.net/2015/01/czy ... -dla-ccie/
Jedno pytanie, na ktore z pewnoscia Cisco jest w stanie odpowiedziec, czy API w Pythonie ma ograniczenia wydajnosciowe w porownaniu z C. Bo nie chcialbym sie rozczarowac odczytuajac eventy z CDP do APKi czy grzebiac w pakietach ze cos mi zamuli, jak moglem np od poczatku zrobic to w C.
horac, pytaj raczej tutaj: https://communities.cisco.com/community ... -one/onepk. Z tego co pamiętam, wąskim gardłem jest tylko strona klienta, po stronie OSu calle z OnePK są obsługiwane jednakowo - API jest to samo po stronie urządzenia.

Awatar użytkownika
konradrz
CCIE
CCIE
Posty: 400
Rejestracja: 23 sty 2008, 14:21
Lokalizacja: Singapore, SG
Kontakt:

Re: onePK - jak zostac sieciowym bogiem cisco

#24

#24 Post autor: konradrz »

horac pisze:Grzebanie w data plane i control plane z poziomu frameworka na pudelkach
Wszystko cacy, ale pamiętaj że _nigdy_ nie osiągniesz wysokiej przepustowości. Raz, że CoPP (jasne, można wyłączyć/pozmieniać), dwa to sama wydajność CPU na supervisorach, [edit] a trzy to szerokość pasma między kartą a supervisorem (np dla Nexusa 9k w życiu nie przeskoczysz 1 Gbit, bo tam taki mały słiczyk jest i tyle).
Nie pamiętam dokładnych liczb, ale coś mi świta że max to ~2 Gbps (chłopaki musieli dla klienta zmieniać ruch multikastowy na wiele-unikastowy).

Awatar użytkownika
konradrz
CCIE
CCIE
Posty: 400
Rejestracja: 23 sty 2008, 14:21
Lokalizacja: Singapore, SG
Kontakt:

#25

#25 Post autor: konradrz »

dorvin pisze:Tylko widzisz... SDN niekiedy zaczyna być postrzegany jako sieć programowana przez programistów aplikacji (!!!).
Wiesz, tak naprawdę (w sieciach intra-DC) to się spokojnie da zrobić. Tu właśnie widzę przyszłość dla (szeroko pojętego) "prostego" SDN.
Sieciowcy prekonfigurują sieć fizyczną (underlay), robią jakieś tam założenia (dozwolone zakresy IP, zakresy VLAN/VXLAN, itd itp) - po prostu "niech se robią w tej sieci co chcą, ale tak by nie miało to szans na stworzenie problemów u innych użytkowników" i tyle. A potem app-dev już sobie "wykraja" logiczną sieć dla siebie (wewnętrznie to będzie VXLAN+VRF, ale app-dev gość nawet nie musi o tym wiedzieć). Przy odpowiednio skonstruowanej sieci fizycznej (pasmo, latency) jak najbardziej to może działać. A dodanie większego pasma przy obecnych technologiach (BiDi etc) jest naprawdę niskokosztowe.

"Duże" SDN (ten co to dotyka tablic BGP) to faktycznie zostawmy Guglom i Fejsbukom.

Czekanie tydzień na akceptację jakiegoś security officera jest bez sensu, jeśli i tak poświęca on na analizę zagadnienia 20-30 minut.
Uch, jak ja mam z tymi sekjuritami na pieńku... Kompletna zgoda.

Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:

#26

#26 Post autor: Kyniu »

konradrz pisze:Sieciowcy prekonfigurują sieć fizyczną (underlay), robią jakieś tam założenia (dozwolone zakresy IP, zakresy VLAN/VXLAN, itd itp) - po prostu "niech se robią w tej sieci co chcą, ale tak by nie miało to szans na stworzenie problemów u innych użytkowników" i tyle. A potem app-dev już sobie "wykraja" logiczną sieć dla siebie (wewnętrznie to będzie VXLAN+VRF, ale app-dev gość nawet nie musi o tym wiedzieć).


Opowiem Ci historyjkę z życia wziętą. Programiści przekazali do użytku aplikację, pracującą w modelu klient-serwer. Rzekomo super wytestowana, sprawdzona, super działająca. No ale jakoś tak wyszło, że im działa a użyszkodnikom nie działa. Oczywiście programiści, że to na pewno sieciowcy coś skopali, ich aplikacja jest super, mucha nie siada i żeby od nich się odczepić. I nawet zapytać ich o cokolwiek to obraza majestatu bo przecież oni są tacy nieomylni, bóstwa wręcz. No to wireshark, dokładna analiza pakietów, składanie wszystkiego do kupy, sprawdzanie zależności czasowych i .... wyszło szydło z worka. Aplikacja kliencka się sypie bo szanowni programiści założyli że klient na odpowiedź z serwera, w dużej, rozległe sieci, gdzie aplikacja pracuje na VPN'ach pokleconych na łączach od rożnych dostawców, czeka, uwaga, ..... 25 ms po czym wywala jakieś głupie , niezrozumiałe komunikaty błędów. A co na to programiści? No że nie ich wina, bo w LAnie im działa. I to wina sieciowców że na WANie mają i do 100 ms opóźnienia. A Ty postulujesz by dać programistom jeszcze więcej możliwości psucia? Najpierw wszystko zdemolują a potem przyjdą z pretensjami do sieciowców i każą naprawiać.
Uch, jak ja mam z tymi sekjuritami na pieńku... Kompletna zgoda.
No tak, bo przecież programista nie wie na jakim porcie będzie działała jego aplikacja, nie wie jakiego protokołu będzie potrzebowała i kto to widział by blokować jakieś porty. Programista ma mieć wszystko otwarte i dostępne bo a "nóż widelec" mu się koncepcja odmieni albo każde połączenie będzie losowo szło na inny, dowolny numer portu. Przecież to całe "sekjurity" to wymyślili złośliwi sieciowcy zazdrośni o wysokość zarobków programistów.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#27

#27 Post autor: lbromirs »

konradrz pisze:Wiesz, tak naprawdę (w sieciach intra-DC) to się spokojnie da zrobić. Tu właśnie widzę przyszłość dla (szeroko pojętego) "prostego" SDN.

[...]

"Duże" SDN (ten co to dotyka tablic BGP) to faktycznie zostawmy Guglom i Fejsbukom.
Nie zgadzam się z tą klasyfikację. Nie ma "małego" i "dużego" SDNu, OpenStack z Quantum, Open Daylight i inne kontrolerzy traktują protokoły jako pluginy - i to czy używają SNMP, OpenFlow czy BGP jest już tylko szczegółem konfiguracyjnym platformy. Inna sprawa, na ile "wygrzane" są te pluginy. Na razie, są żałośnie niedogrzane.

Awatar użytkownika
Sofcik
wannabe
wannabe
Posty: 1026
Rejestracja: 28 mar 2006, 15:29
Lokalizacja: Warszawa

#28

#28 Post autor: Sofcik »

lbromirs pisze:
konradrz pisze:Wiesz, tak naprawdę (w sieciach intra-DC) to się spokojnie da zrobić. Tu właśnie widzę przyszłość dla (szeroko pojętego) "prostego" SDN.

[...]

"Duże" SDN (ten co to dotyka tablic BGP) to faktycznie zostawmy Guglom i Fejsbukom.
Nie zgadzam się z tą klasyfikację. Nie ma "małego" i "dużego" SDNu, OpenStack z Quantum, Open Daylight i inne kontrolerzy traktują protokoły jako pluginy - i to czy używają SNMP, OpenFlow czy BGP jest już tylko szczegółem konfiguracyjnym platformy. Inna sprawa, na ile "wygrzane" są te pluginy. Na razie, są żałośnie niedogrzane.
I sadzisz, że kiedykolwiek się "dogrzeją" tak by dorównać np sprzętowym rozwiązaniom? Czy kiedykolwiek powstanie (hipotetycznie) Nexus 7000v tak by dorównać wydajnością Nexusowi 7000 (pomijając już liczbę interfejsów i ich rodzaje)? Raczej chyba tak nie będzie - zawsze sprzęt będzie szybszy od programu. Choć z drugiej strony program zawsze będzie bardziej elastyczny niż sprzęt i łatwiej być może będzie zaimplementować zmiany w algorytmie niż zaprojekotwać nowy specjalizowany układ.

--
Piotrek

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#29

#29 Post autor: lbromirs »

Sofcik pisze:
lbromirs pisze:Nie zgadzam się z tą klasyfikację. Nie ma "małego" i "dużego" SDNu, OpenStack z Quantum, Open Daylight i inne kontrolerzy traktują protokoły jako pluginy - i to czy używają SNMP, OpenFlow czy BGP jest już tylko szczegółem konfiguracyjnym platformy. Inna sprawa, na ile "wygrzane" są te pluginy. Na razie, są żałośnie niedogrzane.
I sadzisz, że kiedykolwiek się "dogrzeją" tak by dorównać np sprzętowym rozwiązaniom? Czy kiedykolwiek powstanie (hipotetycznie) Nexus 7000v tak by dorównać wydajnością Nexusowi 7000 (pomijając już liczbę interfejsów i ich rodzaje)? Raczej chyba tak nie będzie - zawsze sprzęt będzie szybszy od programu. Choć z drugiej strony program zawsze będzie bardziej elastyczny niż sprzęt i łatwiej być może będzie zaimplementować zmiany w algorytmie niż zaprojekotwać nowy specjalizowany układ.
Chyba się niezrozumieliśmy. Nie chodziło mi o wydajność, tylko dojrzałość implementacji algorytmów/optymalizacje. Niby kod BGP jest dostępny w otwartych rozwiązaniach w postacii Quagii, OpenBGPd, BIRDa i paru innych implementacji od ładnych -nastu lat. Jedyną implementacją, która jako tako radzi sobie z DWOMA tylko rodzinami protokołów - unicastem IPv4 i IPv6 - jest BIRD. A gdzie multicasty? A MPLS? A całe BGP LS? Reszta jest nigdzie.

A zapytajmy o IS-IS... :)

Zamiast usiąść (tak jak chciał zrobić Google, ale mu się przestało chcieć) i włożyć fundusze w dopracowanie tych protokołów, wymyśla się nowe, odkrywając koło na nowo i popełniając znowu te same błędy. Przypomina to historię kolegów z dalkiego wschodu, którzy po paru latach pracy nad separacją ruchu aplikacji w overlayach odkryli od nowa VLANy... czyli tag który ma "na razie" 4094 różnych wartości, "ale na razie tyle wystarczy".

Oczywiście tania przeciętność bije drogą doskonałość (vide zakończona walka między Ethernetem a ATMem), ale to chyba nie o to nam chodzi. W końcu zależy nam na profesjonalizmie, right? :)

Awatar użytkownika
Sofcik
wannabe
wannabe
Posty: 1026
Rejestracja: 28 mar 2006, 15:29
Lokalizacja: Warszawa

#30

#30 Post autor: Sofcik »

Ale patrząc ze strony "managera IT", który zobaczy że różnica w cenie urządzenia i software jest kilkukrotna (na korzyść softu), dojrzałość implementacji nie będzie miała większego znaczenia. Kasa i tabelki przesłonią na 99% oczy i potem biedny sieciowiec będzie się tłumaczył, że 1010 działa szybciej niż 1000v, a manager będzie mu podtykał pod nos ulotki reklamowe, że przecież "to to samo".

Jeśli zaś chodzi o ten "tag, który na razie wystarczy" to dwa lata temu po jednej rozmowie ze specem od rozwiązań z firmy na literkę "B" też się dowiedziałem, że niby ich implementacja VXLAN pozwala na ponad 16mln VLANów ale na urządzeniu nie może być ich więcej jednocześnie niż (chyba) 4096. Ale już niedługo z nowym firmware ma być ich więcej :D Do dziś chyba nie ma ...

Tania przeciętność od zawsze biła drogą doskonałość - choćby VHS i BetaMax (ktoś to jeszcze pamięta?), ale światem rządzi kasa a profesjonalizmem garnka się nie napełni :)

--
Piotrek

ODPOWIEDZ