netdesign.zone

same nowosci
Wiadomość
Autor
lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

netdesign.zone

#1

#1 Post autor: lbromirs »

....powoli jednak rusza. trochę jak lokomotywa :)

Pierwszy artykuł z serii jest tutaj.

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

#2

#2 Post autor: gangrena »

... lub jak slow start w TCP. ;)

Niemniej dwa następne wpisy są dostępne. Zapraszamy do lektury: http://netdesign.zone

Awatar użytkownika
grze
wannabe
wannabe
Posty: 419
Rejestracja: 09 cze 2008, 23:15
Lokalizacja: Warsaw

#3

#3 Post autor: grze »

Wpis pod tytułem "negocjować? czy nie negocjować?" powinni przeczytać wszyscy ludzie którzy ze swoją wiedzą są jeszcze w poprzednim wieku i wymuszają ustawianie dupleksów "na sztywno". Ostatnia mądrość po której spadłem prawie z krzeszła to: "MPLS działa lepiej kiedy dupleksy są ustawione na sztywno!"
It doesn't matter how many certs you've got... it's really all about the pure knowledge behind them...

horac

#4

#4 Post autor: horac »

gangrena pisze:... lub jak slow start w TCP. ;)

Niemniej dwa następne wpisy są dostępne. Zapraszamy do lektury: http://netdesign.zone
No no, fajny art. Mniej alegorii imho bo trzeba
zastanawiac sie nie tam gdzie trzeba nad tym co autor mial na mysli.

Dodajac do rozwazan, tak naprwade po co w ogole jeszcze jest STP. Data Center skutecznie z tego rozwiazania rezygnuje a sieci gdzie sa podpieci uzytkownicy glownie korzystaja z uslug w DC. Wystarczy ze kazdy switch wspiera L3 a wiekszosc juz wspiera. Prosciej odpalic routing. Uniknie sie problemow typu DHCP snooping czy nie ? Bo zadne zapytania broadcastowe L2 nie przejda. Tylko ip helper do DHCP w DC przez WAN. Takze nawet nie potrzeba lokalnych serwerow DHCP. Kolejna rzecz dot1x radius i cala reszta protokolow bezpieczenstwa nie potrzebuje L2 do tego by funkcjonowac. Nawet proxy moze uzywac GRE do enkapsulacji zapytan (switch GRE nie wspiera, ale co za problem mu to zaimplementowac, to itak chyba tansze niz kolejne protezy STP). Takze czy to STP jescze nam potrzebne ?

Generalnie da sie zbudowac siec korporacyjna bez STP, a skoro sie da to czy nie lepiej porzucic starego demona ?

Awatar użytkownika
drake
CCIE
CCIE
Posty: 1593
Rejestracja: 06 maja 2005, 01:32
Lokalizacja: Dortmund, DE
Kontakt:

#5

#5 Post autor: drake »

horac pisze:
gangrena pisze:... lub jak slow start w TCP. ;)

Niemniej dwa następne wpisy są dostępne. Zapraszamy do lektury: http://netdesign.zone
No no, fajny art. Mniej alegorii imho bo trzeba
zastanawiac sie nie tam gdzie trzeba nad tym co autor mial na mysli.

Dodajac do rozwazan, tak naprwade po co w ogole jeszcze jest STP. Data Center skutecznie z tego rozwiazania rezygnuje a sieci gdzie sa podpieci uzytkownicy glownie korzystaja z uslug w DC. Wystarczy ze kazdy switch wspiera L3 a wiekszosc juz wspiera. Prosciej odpalic routing. Uniknie sie problemow typu DHCP snooping czy nie ? Bo zadne zapytania broadcastowe L2 nie przejda. Tylko ip helper do DHCP w DC przez WAN. Takze nawet nie potrzeba lokalnych serwerow DHCP. Kolejna rzecz dot1x radius i cala reszta protokolow bezpieczenstwa nie potrzebuje L2 do tego by funkcjonowac. Nawet proxy moze uzywac GRE do enkapsulacji zapytan (switch GRE nie wspiera, ale co za problem mu to zaimplementowac, to itak chyba tansze niz kolejne protezy STP). Takze czy to STP jescze nam potrzebne ?

Generalnie da sie zbudowac siec korporacyjna bez STP, a skoro sie da to czy nie lepiej porzucic starego demona ?
Hej,
istnieja duze sieci korporacyjne, gdzie w wielu oddzialach - np. fabrykach lub wielkich kampusach, sa spore plaskie sieci L2. Przyklad z zycia - jedna lokalizacja z ponad 60 switchami :D I nie sa to zawsze switche L3... Oczywiscie mozna szeroko dyskutowac o design takiej lokalizacji, ale uciec tam od STP? Nie wierze... Czasem ma byc tanio i juz, kryterium nie do przeskoczenia :)
Na papierze mozne wiele rzeczy fajnie projektowac i przemyslac, jednak zycie i wymagania klienta (niejednokrotnie uwarunkowane "fizycznymi" ograniczeniami lokalizacji) czasem biora gore i nici z super designu...

Pozdruffka! ;)
Never stop exploring :)

https://iverion.de

martino76
CCIE
CCIE
Posty: 883
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Barczewo

#6

#6 Post autor: martino76 »

horac pisze:
gangrena pisze:... lub jak slow start w TCP. ;)

Niemniej dwa następne wpisy są dostępne. Zapraszamy do lektury: http://netdesign.zone
No no, fajny art. Mniej alegorii imho bo trzeba
zastanawiac sie nie tam gdzie trzeba nad tym co autor mial na mysli.

Dodajac do rozwazan, tak naprwade po co w ogole jeszcze jest STP. Data Center skutecznie z tego rozwiazania rezygnuje a sieci gdzie sa podpieci uzytkownicy glownie korzystaja z uslug w DC. Wystarczy ze kazdy switch wspiera L3 a wiekszosc juz wspiera. Prosciej odpalic routing. Uniknie sie problemow typu DHCP snooping czy nie ? Bo zadne zapytania broadcastowe L2 nie przejda. Tylko ip helper do DHCP w DC przez WAN. Takze nawet nie potrzeba lokalnych serwerow DHCP. Kolejna rzecz dot1x radius i cala reszta protokolow bezpieczenstwa nie potrzebuje L2 do tego by funkcjonowac. Nawet proxy moze uzywac GRE do enkapsulacji zapytan (switch GRE nie wspiera, ale co za problem mu to zaimplementowac, to itak chyba tansze niz kolejne protezy STP). Takze czy to STP jescze nam potrzebne ?

Generalnie da sie zbudowac siec korporacyjna bez STP, a skoro sie da to czy nie lepiej porzucic starego demona ?
Niektore aplikacje by poprawnie dzialac potrzebuja L2 np. vMotion, gdzie bez L2 nie bedzie dzialac, ale i tutaj przychodz nam z pomoca VXLAN czy NVGRE :)

Do tego mamy TRILL, SPB oraz FP. Szkoda, ze FP jest wspierany tylko na switchach Nexus, fajnie by bylo gdyby Cisco wspieralo to rowniez na innych pudelkach, wtedy mysle ludzie zrezygnowali by z STP :)

Pozdro,

horac

#7

#7 Post autor: horac »

martino76 pisze:
Niektore aplikacje by poprawnie dzialac potrzebuja L2 np. vMotion, gdzie bez L2 nie bedzie dzialac, ale i tutaj przychodz nam z pomoca VXLAN czy NVGRE :)

Do tego mamy TRILL, SPB oraz FP. Szkoda, ze FP jest wspierany tylko na switchach Nexus, fajnie by bylo gdyby Cisco wspieralo to rowniez na innych pudelkach, wtedy mysle ludzie zrezygnowali by z STP :)

Pozdro,
Hej hej, ale ja pisze o sieci dla uzyszkodnikow a nie DC. Natomiast pani Joli w placowce firmy ABC nie potrzebny jest vmotion ani VXLAN. To sa technologie DC i zamykaja sie w obrebie DC.
drake pisze: istnieja duze sieci korporacyjne, gdzie w wielu oddzialach - np. fabrykach lub wielkich kampusach, sa spore plaskie sieci L2. Przyklad z zycia - jedna lokalizacja z ponad 60 switcham
Oczywiscie ze sa takie sieci, ale to ze kiedys cos powstalo w taki a nie inny sposob nie oznacza ze nalezy to powielac w nieskonczonosc. Jesli nie odzywczaimy sie od starych powielanych bledow to bedziemy krazyc w kolko tych samych zawodnych technologii zmieniajac jedynie ich nazwe i forme, a w srodku zawsze bedzie to STP jakie ono by nie bylo. W dodatku to ze 100 hostow ma adres z jednej podsieci nadal nie eliminuje routingu.
Zobacz na mechaniz IP device tracking. Sam sie uczy adresu IP na porcie switch odpytujac JEDYNIE JEDEN port. Skoro jest w stanie rozpoznac ze pod portem gi0/10 jest IP 10.1.1.1 to po co ARP i zapytania broadcastowe od hosta do hosta. Czy nie wystarczy ze switch bedzie posiadal baze adresow IP na portach zamiast mac adresow ? I wtedy routing decyduje gdzie wyslac pakiet. I pomijamy caly problem STP.

drake pisze: Na papierze mozne wiele rzeczy fajnie projektowac i przemyslac, jednak zycie i wymagania klienta (niejednokrotnie uwarunkowane "fizycznymi" ograniczeniami lokalizacji) czasem biora gore i nici z super designu...

Pozdruffka! ;)
To sie zgadza ale nawiazujemy do netdesign czy jakis pomyslow sieciowcow w celu optymalizacji nie biorac pod uwage rozwiazan typu fekalioplastyka z powodu ograniczen budzetowych.

Biorac pod uwage obecny rozwoj technologii i wymagania, widze jedna zasadnicza roznice miedzy rozwiazaniami L2 a L3. Otoz ramki L2 nie da sie kontrolowac mozna co najwyzej zablokowac jakas droge, natomiast nie wyrutujesz ramki. W L3 routing i pakiet mozna w pelni kontrolowac co powoduje ze nie musimy slepo ufac syganalizacji swietlnej. Jak jest czerwone... stop jak zielone droga wolna.

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

#8

#8 Post autor: gangrena »

horac pisze:
drake pisze: Na papierze mozne wiele rzeczy fajnie projektowac i przemyslac, jednak zycie i wymagania klienta (niejednokrotnie uwarunkowane "fizycznymi" ograniczeniami lokalizacji) czasem biora gore i nici z super designu...

Pozdruffka! ;)
To sie zgadza ale nawiazujemy do netdesign czy jakis pomyslow sieciowcow w celu optymalizacji nie biorac pod uwage rozwiazan typu fekalioplastyka z powodu ograniczen budzetowych.
W projekcie sieci praktycznie zawsze trzeba uwzględnić argumenty nietechniczne. Najważniejszy z nich, to koszt rozwiązania vs. budżet. Inny argument, to ten z artykułu, czyli "dual vendor". Inny, to znajomość protokołów i rozwiązań przez zespół sieciowy. Zdarza się też "job protection", jak to ma miejsce w przypadku SDH i przejścia na MPLS-TP. W każdym z tych przypadków xSTP stanowi konkurencję, choć technicznie jest rozwiązaniem gorszym na większą skalę, niż obecnie dostępne. Jest jednocześnie prostym i wystarczającym do zastosowania na małą skalę. Artykułem chciałem m.in zwrócić uwagę na to, że można zawsze zrewitalizować STP lub inny mechanizm poprzez rozszerzenia. Swoją drogą kiedyś rozważałem, żeby nie było nagłówka L2 lub by był on okrojony. Byłby tylko routing. Wymagałoby to niestety zbyt dużo zmian w kartach sieciowych. Poza tym wciąż L2 zwiększa skalowalność sieci. Samo L3 p2p nie wyskalowałoby się.
horac pisze:Biorac pod uwage obecny rozwoj technologii i wymagania, widze jedna zasadnicza roznice miedzy rozwiazaniami L2 a L3. Otoz ramki L2 nie da sie kontrolowac mozna co najwyzej zablokowac jakas droge, natomiast nie wyrutujesz ramki. W L3 routing i pakiet mozna w pelni kontrolowac co powoduje ze nie musimy slepo ufac syganalizacji swietlnej. Jak jest czerwone... stop jak zielone droga wolna.
Ramkę L2 jak najbardziej da się kontrolować poprzez MAC routing.

horac

#9

#9 Post autor: horac »

gangrena pisze: Ramkę L2 jak najbardziej da się kontrolować poprzez MAC routing.
Ale to sie dzieje pod spodem. Nie wlaczasz procesu per MAC. W przypadku routingu IP jednak jest bezposredni wplyw na to na jakim interfejsie lub jaka siec ma zostac przeroutowana.

Co do idei, tylko L3. Mozna to zrealizowac, wystarczy wykluczyc zapytania ARP na broadcast i odpowiedzi host to host. Ta role spokojnie moze pelnich switch. Wystarczy ze odpyta przez ip device tracking host o IP na okreslonym porcie i zapisze IP. Wtedy juz wkracza routing w przesylaniu pakietow czy to miedzy hostami w tej samej podsieci czy tez w innej. W ten sposob mozna pozbyc sie STP i mozna pozbyc sie zbednych broadcastow w sieci.

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

#10

#10 Post autor: gangrena »

horac pisze:
gangrena pisze: Ramkę L2 jak najbardziej da się kontrolować poprzez MAC routing.
Ale to sie dzieje pod spodem. Nie wlaczasz procesu per MAC. W przypadku routingu IP jednak jest bezposredni wplyw na to na jakim interfejsie lub jaka siec ma zostac przeroutowana.
Ale co się dzieje pod spodem? Routing L3, czy MAC routing? To nie ma znaczenia. Overlay, to po prostu dodatkowy poziom rekursji. Dla natywnego L3 też są minimum dwa poziomy, a często więcej poziomów rekursji.

BTW, dla L3 też nie włączasz procesu per IP.
horac pisze:Co do idei, tylko L3. Mozna to zrealizowac, wystarczy wykluczyc zapytania ARP na broadcast i odpowiedzi host to host. Ta role spokojnie moze pelnich switch. Wystarczy ze odpyta przez ip device tracking host o IP na okreslonym porcie i zapisze IP. Wtedy juz wkracza routing w przesylaniu pakietow czy to miedzy hostami w tej samej podsieci czy tez w innej. W ten sposob mozna pozbyc sie STP i mozna pozbyc sie zbednych broadcastow w sieci.
Co do idei: L3, ale tak, jak pisałem, samo L3 się nie skaluje. Chyba, żeby zastosować wiele sieci nakładkowych, uporządkowaną agregującą się adresację i serwery mapujące.

ODPOWIEDZ