Wydaje mi sie ze nikt tego tematu nie poruszyl jeszcze a jest on raczej
warty uwagi. Otoz w usludze (wg technika) Neostrada sa dwa kluoczwe
routery: 80.50.250.14 i 80.50.250.13. Zachecam do zapuszczenia
tracerouta na dowolny _niedzialajacy_ nr IP Neostrady. Owocuje to
nastepujacym wynikiem:

traceroute to 80.50.229.219 (80.50.229.219), 30 hops max, 38 byte
packets
1 serwer.komorow.home (192.168.10.4) 1.150 ms 0.910 ms 0.755 ms
2 pruszkow.wave.net.pl (80.72.35.254) 16.134 ms 11.260 ms 13.732 ms
3 80.72.35.1 (80.72.35.1) 54.518 ms 27.704 ms 23.710 ms
4 80.72.35.10 (80.72.35.10) 58.456 ms 49.858 ms 102.596 ms
5 80.72.35.5 (80.72.35.5) 24.426 ms 37.372 ms 31.444 ms
6 213.172.174.237 (213.172.174.237) 94.163 ms 116.388 ms 61.907 ms
7 213.172.174.233 (213.172.174.233) 66.479 ms * 131.677 ms
8 pos-2-0.warpe3.net.telenergo.pl (213.172.161.94) 64.669 ms * 116.265 ms
9 213.76.0.193 (213.76.0.193) 158.674 ms 83.816 ms 133.494 ms
10 80.48.55.6 (80.48.55.6) 118.802 ms 103.621 ms 159.449 ms
11 80.50.250.14 (80.50.250.14) 216.680 ms 131.296 ms 91.110 ms
12 80.50.250.13 (80.50.250.13) 107.574 ms 92.608 ms 79.250 ms
13 80.50.250.14 (80.50.250.14) 81.233 ms 106.183 ms 103.731 ms
14 80.50.250.13 (80.50.250.13) 84.080 ms 115.135 ms 66.005 ms

I tak dalej. Co ciekawe wg infolinii neo takie rozwizanie jest jak
najbardziej poprawne i sluszne. Natomiast wg mnie raczej nie.

Kto tutaj ma racje ?

Sytuacja nie jest jednorazowym bledem bo utrzymuje sie od przynajmniej
tygodnia (wiem o niej od tygodnia)

(moje przypusczenia - jak sie myle czy ktos moglby mnie poprawic ?)
Co ciekawe przyjmujac ze sa to 2 rozne maszyny to na kazdy pakiet
(ttl=255) kazda z nich musi taki pakiet obrobic ~128razy. Czyli pare
osob wysyla duze ilosci pakietow i routery zostaja bardzo ladnie
bum.

Pozdrawiam
--
Adam Kułagowski GG:2039793 f...@p...pl

Don't let the computer bugs bite!

do góry

Coz Adam - odkryles wlasnie przyczyne "zawieszania sie routerow" neo+ i
iDSL...;-)
Tak powaznie to pewnie jest fajna optymalizacja sieci TpSy...czemu
mialoby sie to nie odbijac? przeciez to styl naszej szacownej.....
Zobaczymy kiedy ta petelke poprawia...ale jak widac moze prezes lubi
patrzec na migajace diody routerow...ja juz jestem w nalogu patrzenia na
modem neo+ - jak diody migaja to sie ciesze jak nie to smuce, a jak nie
migaja to zawsze jest cien szansy ze akurat modem sie zwiesily lampki i
itak dziala inet....
_pozdrowka
_bartek

do góry

Adam Kułagowski <f...@h...pl> napisał(a):

> Sytuacja nie jest jednorazowym bledem bo utrzymuje sie od przynajmniej
> tygodnia (wiem o niej od tygodnia)

Tak jest od samego poczatku, to samo dzialo sie od zawsze z
SDI. Ostatni router (w przypadku Neostrady pewnie jakis access
concentrator z PPPoE) pewnie nie ma zadnego OSPFa, tylko domyslna trase
do tego wyzej. Jak mu sie down'uje interfejs, to pakiety wracaja przez
default route do wyzszego routera.

--
* Fido: 2:480/124 ** WWW: http://www,frasunek,com/ ** NIC-HDL: PMF9-RIPE *
* Inet: przemyslaw$frasunek,com ** keyId: CD3F1FE5 | C0613BE3 | EC78FAB5 *

do góry

On Sat, 8 Feb 2003 08:47:11 +0000 (UTC) I had a dream that Adam Kułagowski
<f...@h...pl> wrote:
>Wydaje mi sie ze nikt tego tematu nie poruszyl jeszcze a jest on raczej
>warty uwagi. Otoz w usludze (wg technika) Neostrada sa dwa kluoczwe
>routery: 80.50.250.14 i 80.50.250.13. Zachecam do zapuszczenia
>tracerouta na dowolny _niedzialajacy_ nr IP Neostrady. Owocuje to
>nastepujacym wynikiem:

Może się i czepiam, ale po co wysyłać pakiety, na jakiś niedziałający adres?

>traceroute to 80.50.229.219 (80.50.229.219), 30 hops max, 38 byte
>packets
> 1 serwer.komorow.home (192.168.10.4) 1.150 ms 0.910 ms 0.755 ms
> 2 pruszkow.wave.net.pl (80.72.35.254) 16.134 ms 11.260 ms 13.732 ms
> 3 80.72.35.1 (80.72.35.1) 54.518 ms 27.704 ms 23.710 ms
> 4 80.72.35.10 (80.72.35.10) 58.456 ms 49.858 ms 102.596 ms
> 5 80.72.35.5 (80.72.35.5) 24.426 ms 37.372 ms 31.444 ms
> 6 213.172.174.237 (213.172.174.237) 94.163 ms 116.388 ms 61.907 ms
> 7 213.172.174.233 (213.172.174.233) 66.479 ms * 131.677 ms
> 8 pos-2-0.warpe3.net.telenergo.pl (213.172.161.94) 64.669 ms * 116.265 ms
> 9 213.76.0.193 (213.76.0.193) 158.674 ms 83.816 ms 133.494 ms
> 10 80.48.55.6 (80.48.55.6) 118.802 ms 103.621 ms 159.449 ms
> 11 80.50.250.14 (80.50.250.14) 216.680 ms 131.296 ms 91.110 ms
> 12 80.50.250.13 (80.50.250.13) 107.574 ms 92.608 ms 79.250 ms
> 13 80.50.250.14 (80.50.250.14) 81.233 ms 106.183 ms 103.731 ms
> 14 80.50.250.13 (80.50.250.13) 84.080 ms 115.135 ms 66.005 ms
>
>I tak dalej. Co ciekawe wg infolinii neo takie rozwizanie jest jak
>najbardziej poprawne i sluszne. Natomiast wg mnie raczej nie.
>Kto tutaj ma racje ?

Wiesz, pętle są wynikiem rutingu statycznego oraz defaulta.

>Sytuacja nie jest jednorazowym bledem bo utrzymuje sie od przynajmniej
>tygodnia (wiem o niej od tygodnia)

Tak jest od zawsze :)
Sam miałem w niektórych sieciach pętle na nieuzywanych adresach.

>(moje przypusczenia - jak sie myle czy ktos moglby mnie poprawic ?)
>Co ciekawe przyjmujac ze sa to 2 rozne maszyny to na kazdy pakiet
>(ttl=255) kazda z nich musi taki pakiet obrobic ~128razy. Czyli pare
>osob wysyla duze ilosci pakietow i routery zostaja bardzo ladnie
>bum.

Nieprawda. Ruter rutowanie pakietów ma dobrze obcykane. Natomiast ten
sam ruter by zdychał, jeśli by obsługiwał ruting dynamiczny - każdorazowe
włączenie czy wyłączenie _dowolnego_ modemu DSL czy Neo+ skutkowałoby
wymianą informacji rutingowych przez wiele ruterów. Przy obecnej
częstotliwości wieszania się modemów, to ruter miałby non stop
updaty rutingu. Sama tablica rutingu brałaby masę pamięci.
Protokoły rutingu dynamicznego tak obciążają systemy, że czasem się
ustawia po prostu ruting statyczny, który może skutkować pętlami na
aktualnie nieaktywnych adresach, ale zajmuje o wiele mniej cpu i pamięci.

A jak ktoś mówi inaczej, to się nie zna i się wymądrza, pętle czasem
są normalne, hough.

--
Grzegorz Janoszka
www.consulta.pl odpowiadając POPRAW adres

Na newsy piszę prywatnie i wyrażam swoje prywatne poglądy, które nie mają
nic wspólnego z moimi byłymi, obecnymi i przyszłymi pracodawcami.

do góry

"Adam Kułagowski" <f...@h...pl> wrote in message
news:slrnb48c0i.9sh.fidor@fidor.komorow.home...
> Wydaje mi sie ze nikt tego tematu nie poruszyl jeszcze a jest on raczej
> warty uwagi. Otoz w usludze (wg technika) Neostrada sa dwa kluoczwe
> routery: 80.50.250.14 i 80.50.250.13. Zachecam do zapuszczenia

[...]

Poruszalem kiedys ten temat (ponad rok temu, w wakacje 2002). Akurat
dotyczylo to SDI. Wtedy (i z tego co piszesz, jest tak do teraz) ping na IP
SDI powodowal wlasnie taki efekt, gdy abonent nie mial wlaczonego terminala
(czy gdy poprostu nie byl polaczony z internetem). Skoro wiec ta sytuacja ma
miejsce od tak dlugiego czasu (minimum) , mozna byc pewnym, ze jest to
zamierzone. A jak to wplywa na wydajnosc tych urzadzen nie potrafie
powiedziec - niech zrobia to ludzie obeznani ze sprawami 'sieciowymi'. Ale
nawet mi, niewtajemniczonemu, cos mowi, ze raczej routery sie od tego
przemeczaja i ze chyba lepiej byloby, zeby w w/w przypadku dawaly odpowiedz
"request timed out" :). Ale TP ma jak widac inne zdanie.

tom

do góry

"Grzegorz Janoszka" <G...@p...onet.pl-----USUN-TO> wrote in
message news:slrnb4aivc.cn5.Grzegorz.Janoszka@kier.icsr.agh.
edu.pl...

> A jak ktoś mówi inaczej, to się nie zna i się wymądrza, pętle czasem
> są normalne, hough.

I o to wyjasnienie wlasnie chodzilo - dzieki. Przynajmniej mozna spac
spokojnie i nie martwic sie, ze u mojego providera cos zle dziala ;).

tom

do góry

On Sat, 8 Feb 2003 21:11:37 +0000 (UTC), Grzegorz Janoszka
<G...@p...onet.pl-----USUN-TO> wrote:

> Może się i czepiam, ale po co wysyłać pakiety, na jakiś niedziałający adres?

Zauwazylem to jak padla Nestrada u kolegi jak zaczalem pingowac jego IP
a on nie mogl go podniesc bo padlo logowanie/dhcp. Potem zauwazylem ze
to dotyczy wszystkich nieaktywnych IP.

> Wiesz, pętle są wynikiem rutingu statycznego oraz defaulta.

Ja wiem jak to zrobic. Nawet domyslam sie czemu tak jest (oba routery
zarzadzaja ta sama klasa IP a nie osobnymi). Ale to jest dla mnie
chore...

> Nieprawda. Ruter rutowanie pakietów ma dobrze obcykane. Natomiast ten
> sam ruter by zdychał, jeśli by obsługiwał ruting dynamiczny - każdorazowe
> włączenie czy wyłączenie _dowolnego_ modemu DSL czy Neo+ skutkowałoby
> wymianą informacji rutingowych przez wiele ruterów. Przy obecnej
> częstotliwości wieszania się modemów, to ruter miałby non stop
> updaty rutingu. Sama tablica rutingu brałaby masę pamięci.
> Protokoły rutingu dynamicznego tak obciążają systemy, że czasem się
> ustawia po prostu ruting statyczny, który może skutkować pętlami na
> aktualnie nieaktywnych adresach, ale zajmuje o wiele mniej cpu i pamięci.

Hmmm - ale po co. Nie prosciej rozdzielic klasy IP na dwa routery ?
(chyba ze TPSA nie ma pojecia ile modemow ma na dany router)
Zreszta w kazdej specyfikacji Cisco stoi ze dany router potrafi obsluzyc
tyle a tyle pakietow na sekunde. Takie rozwizanie zmniejsza ta liczbe o
dwa rzedy wielkosci. Po za tym bardzo ladnie rozwiazalo by to modyfikacja
ttl'i w locie i obcianie ich do 2 (skoro to i tak ostatni hop to
neostrady) Roboty niewiele a i ryzko zafloodowania jakby mniejsze. Tak na
zdrowy chlopski rozum.

Pozdrawiam
--
Adam Kułagowski GG:2039793 f...@p...pl

Anything will fit if you push hard enough

do góry

On Sun, 9 Feb 2003 10:34:25 +0000 (UTC) I had a dream that Adam Kułagowski
<f...@h...pl> wrote:
>> Nieprawda. Ruter rutowanie pakietów ma dobrze obcykane. Natomiast ten
>> sam ruter by zdychał, jeśli by obsługiwał ruting dynamiczny - każdorazowe
>> włączenie czy wyłączenie _dowolnego_ modemu DSL czy Neo+ skutkowałoby
>> wymianą informacji rutingowych przez wiele ruterów. Przy obecnej
>> częstotliwości wieszania się modemów, to ruter miałby non stop
>> updaty rutingu. Sama tablica rutingu brałaby masę pamięci.
>> Protokoły rutingu dynamicznego tak obciążają systemy, że czasem się
>> ustawia po prostu ruting statyczny, który może skutkować pętlami na
>> aktualnie nieaktywnych adresach, ale zajmuje o wiele mniej cpu i pamięci.
>Hmmm - ale po co. Nie prosciej rozdzielic klasy IP na dwa routery ?
>(chyba ze TPSA nie ma pojecia ile modemow ma na dany router)
>Zreszta w kazdej specyfikacji Cisco stoi ze dany router potrafi obsluzyc
>tyle a tyle pakietow na sekunde. Takie rozwizanie zmniejsza ta liczbe o
>dwa rzedy wielkosci. Po za tym bardzo ladnie rozwiazalo by to modyfikacja
>ttl'i w locie i obcianie ich do 2 (skoro to i tak ostatni hop to
>neostrady) Roboty niewiele a i ryzko zafloodowania jakby mniejsze. Tak na
>zdrowy chlopski rozum.

Hmmm... nie rozumiem. Ale jeśli masz dobre pomysły, to napisz jakieś RFC
albo zgłoś się do Cisco - zaprojektujesz nowy, odjechany ruter :)

A na poważnie - pętle to zerowe obciążenie rutera, a nie jakieś "kilka rzędów
wielkości". Po drugie nie można zmniejszać TTL - kto mi przeszkodzi mieć
na Neo+ 10 ruterów, a dopiero potem swojego PC?

Poza tym jakby TPSA zaczęła się bawić w modyfikacje przelatujących przez nią
pakietów (już się kiedyś bawiła, hehe), to wiesz, jakie by się tu głosy
sprzeciwu podniosły? :)

--
Grzegorz Janoszka
www.consulta.pl odpowiadając POPRAW adres

Na newsy piszę prywatnie i wyrażam swoje prywatne poglądy, które nie mają
nic wspólnego z moimi byłymi, obecnymi i przyszłymi pracodawcami.

do góry

On Sat, 8 Feb 2003 21:12:02 +0000 (UTC) I had a dream that tm <e...@p...fm> wrote:
>zamierzone. A jak to wplywa na wydajnosc tych urzadzen nie potrafie
>powiedziec - niech zrobia to ludzie obeznani ze sprawami 'sieciowymi'. Ale
>nawet mi, niewtajemniczonemu, cos mowi, ze raczej routery sie od tego
>przemeczaja i ze chyba lepiej byloby, zeby w w/w przypadku dawaly odpowiedz
>"request timed out" :). Ale TP ma jak widac inne zdanie.

Nie przemęczają się. Już bardziej by się przemęczały obsługując dziesiątki
updatów dynamicznego rutingu na sekundę oraz wielomegabajtowe tablice rutingu.

--
Grzegorz Janoszka
www.consulta.pl odpowiadając POPRAW adres

Na newsy piszę prywatnie i wyrażam swoje prywatne poglądy, które nie mają
nic wspólnego z moimi byłymi, obecnymi i przyszłymi pracodawcami.

do góry

On Sun, 9 Feb 2003 15:17:02 +0000 (UTC), Grzegorz Janoszka
<G...@p...onet.pl-----USUN-TO> wrote:

> A na poważnie - pętle to zerowe obciążenie rutera, a nie jakieś "kilka rzędów
> wielkości". Po drugie nie można zmniejszać TTL - kto mi przeszkodzi mieć
> na Neo+ 10 ruterów, a dopiero potem swojego PC?

Przyjmujac ze nie maskuja istnienia routerow, to te sa przedostatnie.

Imho:

Hmm petla to po prostu przeroutowanie pakietu. Nie wazne dokad i gdzie.
Nie twierdze ze "szum" (normalny ruch) powiesi routery. I na pewno nie
zerowe obciazenie ale bardzo male. A to jest juz roznica. Dodajac Acces
listy ... jakos to zerowe obciazenie to brzmi zbyt optymistycznie.

> Poza tym jakby TPSA zaczęła się bawić w modyfikacje przelatujących przez nią
> pakietów (już się kiedyś bawiła, hehe), to wiesz, jakie by się tu głosy
> sprzeciwu podniosły? :)

Hm ich routery ich zabawa :-)

Ale to chyba nie prowadzi do niczego ja nie potrafie przekonac Ciebie,
Ty nie przedstawile argumwntow ktore przekonuja mnie ze petla to zerowy
koszt dla routera. wiec EOT ?

Pozdrawiam
--
Adam Kułagowski GG:2039793 f...@p...pl

Gargle twice daily - see if your neck leaks.

do góry