Изпечатай

[Astor]

Здравейте, искам да ви питам защо когато се опитам да пинг-на компютър от локалната мрежа на доставчика ми (с ip адрес: 213.Х.Х.90)дава това:

Цитат

guest@darkstar:~$ ping 213.Х.Х.90 PING 213.Х.Х.90 (213.Х.Х.90) 56(84) bytes of data. From 213.Х.Х.41 icmp_seq=1 Time to live exceeded From 213.Х.Х.41 icmp_seq=2 Time to live exceeded From 213.Х.Х.41 icmp_seq=3 Time to live exceeded From 213.Х.Х.41 icmp_seq=4 Time to live exceeded

Доставчика ни раздава реални IP адреси, аз съм с IP адрес: 213.Х.Х.45 и моят geutway е: 213.Х.Х.41. Т.е. НЕ ми връща отговор компютъра който се опитвам да ping-на, а самият gateway.
Да не би доставчика ми да е решил да не може да се пингва от другата страна на рутера, и защо рутера връща такъв отговор, какво означава той (реже TLL-a)? Но освен този копютър имам пинг към всички интернет хостове.

И още нещо, компютъра който се опитвам да пингна има gateway 213.Х.Х.89, защо не връща отказа от него, ами от моя?

[vic_semionov]

пробвай с ping -m 256

EDIT: иглежда прожлема е просто че между тебе и другата машина дето пингваш има прекалено много рутери, с опцията m се увеличава на 256 максималния им брой.

[Astor]

Здравей, благодаря за отговора, нотова: "ping -m 256" го няма като опция и мах TLL  е 255, да не би да си имал в предвид ping -t 255? Ето какво дава:

Цитат

root@darkstar:/home/guest# ping -t 255 213.222.61.90 PING 213.222.61.90 (213.222.61.90) 56(84) bytes of data. From 213.222.61.41 icmp_seq=1 Time to live exceeded From 213.222.61.41 icmp_seq=2 Time to live exceeded From 213.222.61.41 icmp_seq=3 Time to live exceeded From 213.222.61.41 icmp_seq=4 Time to live exceeded

Не мисля че има прекалено много рутери до този комп (комшия ми е човека все пак) според мен са мах 2.
Според мен нещо реже tll-a по пътя към този компютър, но не виждам логика защо точно моя getaway го прави? По принцип доставчика не реже по Tll но точно този пиребител да не е решил да го резне?

[vic_semionov]

Да, това имах предвид. Сори, просто съм с друга ОС и опцията е с друга буква при мене, мислех че трябва и в линукс да е същата.

Не мога да кажа със сигурност, но ми се струва че нещо рутера на доставчика ти не е настроен добре щом те ти връщат TTL exceeded. Нещо сигурно са омазали рутирането. Май е най-добре да ги питаш тях.

[George Andonov]

Разбира се, че проблема не е в "твърде много маршрутизатори" по пътя! От теб до другия край на света (където и да е това '>  ) са около 30 хопа.

Проблема е в неправилно конфигуриран Default Router или събнет маска на някои от гейтуеите.

При сбъркана subnet, ефектът е следния:
1. Първият пинг минава. Някои от рутерите по пътя си update-ва рутинг таблицата и избира по-добър маршрут.
2. Вторият пинг минава по по-добрия маршрут! Като резултат двата съседни рутера си подхвърлят пакета докато той умре от старост (TTL).

При сбъркан Default Router, ефектът е следния:
1. Нито един пинг не минава Защото двата съседни рутера си подхвърлят пакета докато той умре от старост (TTL).

Пусни traceroute IP_address
и ще видиш

Примерен код

1. Твоят_DG 2. Router_1 3. Router_2 4. Router_1 5. Router_2 6. Router_1 7. Router_2 8. Router_1 9. Router_2 10. Router_1 ...................

И се сещаш какво става  '>

[vic_semionov]

'> мерси за корекцията, звучи доста интересно това явление '>

[zeridon]

В интерес на истината е или зле конфигуриран рутер или умишлено изпълнение

за да се информираш traceroute
ще видиш как се развъртат пакетите. Най-често подобна ситуация се получава когато доставчика си променя мрежовата топологи и съседните системи все още не са се осъзнали.

[George Andonov]

//offtopic Такъв ефект се получава и ако имаш Static NAT на машина от локалната ти мрежа.
Ако, от локално PC, направиш:

Примерен код

ping EXTERNAL_IP_address

Първият пинг минава и всички следващи - не.

Като си провериш рутинг таблицата на твоето PC виждаш:
   EXTERNAL_IP_address -> internal_IP_address(на изнесената машина)

//ontopic Според мен тук е подобна ситуацията.

[George Andonov]

Цитат (zeridon @ Авг. 24 2005,17:30)

.... когато доставчика си променя мрежовата топологи и съседните системи все още не са се осъзнали.

Какво има да се осъзнават?
Аз мисля, че надали твоят доставчик е пуснал протоколи за динамично маршрутизиране между теб и съседите ти.    / Ама ще е голям майтап ако ви е пуснал OSPF, BGP или друга щуротия в локалната мрежа '> /

По-вероятно е неподходяща конфигурация и като резултат ти и съседа ти нямате ping, fileshareing, торенти, няма игри в мрежа и т.н. Няма и вируси!

Към Astor: Абе ти какво гледаш на съседа в канчето?  

[Astor]

Здравейте пак. Ето какво дава traceroute 213.X.X.90:

Цитат

traceroute to 213.X.X.90 (213.X.X.90), 30 hops max, 38 byte packets  1  10.0.0.1 (10.0.0.1)  0.601 ms  0.553 ms  0.525 ms  2  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.Х.Х.41)  18.636 ms  13.969 ms  7.888 ms  3  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  11.613 ms *  29.554 ms  4  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  56.434 ms  18.041 ms  34.458 ms  5  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  27.540 ms  40.080 ms *  6  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  37.156 ms  6.835 ms  17.374 ms  7  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  19.182 ms  8.432 ms  4.823 ms  8  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  6.311 ms  23.839 ms  23.063 ms  9  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.421 ms *  2.315 ms 10  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  10.125 ms  9.532 ms  9.291 ms 11  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  2.758 ms *  6.790 ms 12  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  4.080 ms  9.432 ms  9.870 ms 13  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.515 ms *  8.243 ms 14  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  6.489 ms  8.404 ms  7.273 ms 15  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  8.487 ms *  13.899 ms 16  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  3.570 ms  19.473 ms  11.798 ms 17  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  7.484 ms *  18.194 ms 18  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.542 ms  9.464 ms  9.754 ms 19  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  8.811 ms *  6.710 ms 20  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.848 ms  20.543 ms  40.560 ms 21  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.844 ms *  10.083 ms 22  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.619 ms  6.934 ms  7.210 ms 23  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.600 ms *  12.843 ms 24  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  7.956 ms  25.628 ms  14.683 ms 25  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  9.268 ms *  3.426 ms 26  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  11.778 ms  9.917 ms  12.204 ms 27  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  5.026 ms *  3.644 ms 28  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  7.342 ms  9.538 ms  4.449 ms 29  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  14.062 ms *  2.439 ms 30  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.X.X.41)  2.366 ms  6.047 ms  8.774 ms

Понеже съм зад домашния рутер за това се получава първия хоп, но нататък....?
Та тази команда traceroute (tracert в win) не показва ли от къде минава пакета докато стигне до дадената цел?
@gandonov: май не се получава точно както ти казваш, въобще не се появява рутер2. И под това StatikNAT какво разбираш?

Цитат

Като си провериш рутинг таблицата на твоето PC виждаш:   EXTERNAL_IP_address -> internal_IP_address(на изнесената машина)

и това също не го разбирам. Ето какво пише в рутинг таблицата ми (т.е. на домашния рутер зад който съм):

Примерен код

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 213.Х.Х.40   *               255.255.255.248 U     0      0        0 eth1 localnet        *               255.255.255.0   U     0      0        0 eth0 loopback        *               255.0.0.0       U     0      0        0 lo default         213.Х.Х.41   0.0.0.0         UG    0      0        0 eth1

Едит: За въпроса за канчето на съседа, просто ми е странно защо се получава така (по-точно не мога да си го обясня) и така все пак и аз се обучавам малко нали.

[George Andonov]

Относно "Static NAT" - Това беше само с образователна цел. Няма нищо общо с твоя случай. Игнорирай го и не се разсейвай с него.

Относно резултатите от твоя trace:
Пинга от твоето PC(10.0.0.1) отива при Default Router-а ти (213.Х.Х.41) и тъпия рутер не го предава натам.
Troubleshooting:
1. Направи trace до други IP адреси и виж какъв е ефекта:
   - Ако с всеки IP адрес е същото - проблема е че не му е конфигуриран Default Router (Но в този случай ти няма да имаш интернет)
   - Ако нямаш трасе до адресите от мрежата на доставчика - проблема е в неподходящ маршрут на рутера. (Това разбира се може да е нарочно, но ти си длъжен да изтормозиш доставчика си.)

С две думи: дай резултатите и ще помагаме с въпросите към ISP-то.

Малко инфо за traceroute(за Astor):
 traceroute изпраща ICMP пакети с променен TTL.
 Първият е с TTL - 1 . Вторият с 2. Третият - 3 и т.н.
 Маршрутизаторите по пътя връщат "Time to live exceeded" и traceroute ти трасира пътя.

[George Andonov]

Цитат

... За въпроса за канчето на съседа, просто ми е странно защо се получава така (по-точно не мога да си го обясня) ...

Отговор на въпроса: Защо се получава така?
Най-добре да ти дам пример. Може да го пробваш в къщи.
Трябват ти две машини, с IP адреси A и B.
 На A Default Router е B
 На B Default Router е A

На която и да е машина пишеш:

Примерен код

traceroute C

C е произволен IP адрес, но не от мрежата на A и B.

Анализът на резултата ти остава за домашно.  '>

[Astor]

Здравейте, Благодаря за отговора ти gandonov. Ето например traceroute към още един компютър от локалната мрежа (не го познавам човека и не знам даже дали е комшия) 213.Х.Х.93:

Цитат

traceroute to 213.Х.Х.93 (213.Х.Х.93), 30 hops max, 38 byte packets  1  10.0.0.1 (10.0.0.1)  0.625 ms  0.567 ms  0.558 ms  2  gw.orion-z.bg.Х.Х.213.in-addr.arpa (213.Х.Х.41)  11.833 ms  9.484 ms  9.488 ms  3  213.Х.Х.93 (213.Х.Х.93)  62.054 ms  57.509 ms  308.330 ms

Ta този другия компютър ме съмнямва (по IP адреса съдя) че и той е със същия GW и пак е зад същия рутер където е и предния компютър (213.Х.Х90).
А ето към някакъв сайт например:

Цитат

traceroute to mail.bg (193.201.172.98), 30 hops max, 38 byte packets  1  10.0.0.1 (10.0.0.1)  0.730 ms  0.570 ms  0.546 ms  2  gw.orion-z.bg.X.X.213.in-addr.arpa (213.X.X.41)  65.799 ms  69.703 ms  89.435 ms  3  router.somewere.net (213.X.X.1)  35.816 ms  98.657 ms  34.957 ms  4  faste0-0-13-vta-ar2.0rbitel.net (195.24.45.209)  57.088 ms  11.701 ms  6.892 ms  5  fa0-0-1-vta-br1.0rbitel.net (212.95.168.1)  10.056 ms  8.399 ms  9.967 ms  6  atm0-1-0-6-sof-br4.0rbitel.net (195.24.32.237)  11.915 ms  29.480 ms  12.429 ms  7  212.95.167.13 (212.95.167.13)  17.693 ms  13.312 ms  22.902 ms  8  evronet-gw.Peer.0rbitel.net (213.222.51.22)  93.334 ms  90.313 ms  110.287 ms  9  fiber12.evro.net (80.72.67.70)  134.285 ms  79.893 ms  123.541 ms 10  web1.mail.bg (193.201.172.98)  110.741 ms  100.189 ms  105.993 ms

От тези два цитата съдя че май има НАРОЧНА намеса на доставчика, но защо, и защо точно от рутера 213.X.X.41 (а дали е точно от този или от някой друг). Какво може да предодвратява с тази своя намеса ISP-то ми? Не сме правили чак такъв трансфер с комшията ми, че да му тварим мрежата и защо точно ще ни резне по TLL? Не схващам логика тук.

Едит:

Цитат

На A Default Router е B На B Default Router е A

че ако това се получава м/у моя комп и defult gw-я ми то тогава ми звучи доста идиотско от страна на доставчика ми.

[Uvigii]

//off

Цитат

При сбъркана subnet, ефектът е следния: 1. Първият пинг минава. Някои от рутерите по пътя си update-ва рутинг таблицата и избира по-добър маршрут.

И как точно го решава след първия пинг ? ?!?

Цитат

... Такъв ефект се получава и ако имаш Static NAT на машина от локалната ти мрежа.

Това може ли малко по-подробно да го обясните, че ме заинтригува !

Дали на х.х.х.90 няма стартирани услуги които не се харесват на доставчика ?
А защо не опиташ с tcptraceroute

[Astor]

Здравейте, Uvigii поне аз не знам за такива услуги да са стартирани. А ето какво става при:

Цитат

root@darkstar:/home/guest# tcptraceroute 213.222.61.90 bash: tcptraceroute: command not found

Нема такава команда май