forum.opennet.ru - "почему не работает маршрутизация" (21)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"почему не работает маршрутизация"

Форум Открытые системы на сервере (Маршрутизация, NAT / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"почему не работает маршрутизация"	+/–
Сообщение от konst2 on 01-Сен-15, 20:19
Почему при назначении маршрута: route add A gw B в таблице маршрутизации появляется маршрут, но traceroute -n A - не показывает, что маршрут отрабатывает. Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.1 192.168.0.18 255.255.255.255 UGH 0 0 0 eth0 192.168.1.2 192.168.0.18 255.255.255.255 UGH 0 0 0 eth0 ... 0.0.0.0 192.168.0.253 0.0.0.0 UG 0 0 0 eth0 traceroute -n 192.168.1.1 traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets 1 192.168.0.253 0.238 ms 0.234 ms 0.196 ms] 2 192.168.0.253 3001.031 ms !H 3001.029 ms !H 3001.024 ms !H
Ответить \| Правка \| Cообщить модератору

Оглавление

почему не работает маршрутизация, Skif, 23:18 , 01-Сен-15, (1)

почему не работает маршрутизация, Konst, 00:11 , 02-Сен-15, (2)

почему не работает маршрутизация, Аноним, 00:38 , 02-Сен-15, (3)

почему не работает маршрутизация, Konst, 00:53 , 02-Сен-15, (4)

почему не работает маршрутизация, Square1, 07:04 , 02-Сен-15, (6) +2

почему не работает маршрутизация, konst2, 16:42 , 02-Сен-15, (7)

почему не работает маршрутизация, Square1, 18:47 , 02-Сен-15, (8)

почему не работает маршрутизация, konst2, 19:18 , 02-Сен-15, (9)

почему не работает маршрутизация, Square1, 19:20 , 02-Сен-15, (11)

почему не работает маршрутизация, konst2, 19:45 , 02-Сен-15, (14)

почему не работает маршрутизация, Square1, 20:16 , 02-Сен-15, (15)

почему не работает маршрутизация, Square1, 21:28 , 02-Сен-15, (16)
почему не работает маршрутизация, Konst, 00:38 , 03-Сен-15, (17)

почему не работает маршрутизация, Etch, 19:28 , 02-Сен-15, (12)

почему не работает маршрутизация, Square1, 19:32 , 02-Сен-15, (13)

почему не работает маршрутизация, Konst, 01:04 , 03-Сен-15, (19)
почему не работает маршрутизация, Etch, 07:37 , 03-Сен-15, (20)

почему не работает маршрутизация, Konst, 00:57 , 03-Сен-15, (18)

почему не работает маршрутизация, Square1, 19:19 , 02-Сен-15, (10)

почему не работает маршрутизация, fantom, 15:57 , 10-Сен-15, (21)

почему не работает маршрутизация, Etch, 05:05 , 02-Сен-15, (5)

Сообщения по теме [Сортировка по времени | RSS]

1. "почему не работает маршрутизация" +/–

Сообщение от Skif (ok) on 01-Сен-15, 23:18

А противоположная сторона знает о вашей сети?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "почему не работает маршрутизация" +/–

Сообщение от Konst (??) on 02-Сен-15, 00:11

> А противоположная сторона знает о вашей сети?
нет. 192.168.0.18 не знает о 192.168.1.0

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "почему не работает маршрутизация" +/–

Сообщение от Аноним (??) on 02-Сен-15, 00:38

>> А противоположная сторона знает о вашей сети?
> нет. 192.168.0.18 не знает о 192.168.1.0
Во первых ты ответил на _другой_ вопрос.
Во вторых - а нафига ты тогда пакеты для 1.0 раутишь на 0.18 ?!?!?! Если оно не знает?

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "почему не работает маршрутизация" +/–

Сообщение от Konst (??) on 02-Сен-15, 00:53

>>> А противоположная сторона знает о вашей сети?
>> нет. 192.168.0.18 не знает о 192.168.1.0
> Во первых ты ответил на _другой_ вопрос.
т.к. в данном случае это актуальнее.
> Во вторых - а нафига ты тогда пакеты для 1.0 раутишь на
> 0.18 ?!?!?! Если оно не знает?
для эксперимента. На самом деле мне надо было связать 2 машины из разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи не появилось. А tracerote показал что и не идет через указанный маршрут.
Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил ту же картину (почти). На самом деле 1-я попытка traceroute была правильной, а далее как указано выше.
Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к исполнению.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "почему не работает маршрутизация" +2 +/–

Сообщение от Square1 on 02-Сен-15, 07:04

>[оверквотинг удален]
>> 0.18 ?!?!?! Если оно не знает?
> для эксперимента. На самом деле мне надо было связать 2 машины из
> разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи
> не появилось. А tracerote показал что и не идет через указанный
> маршрут.
> Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил
> ту же картину (почти). На самом деле 1-я попытка traceroute была
> правильной, а далее как указано выше.
> Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную
> - обязателен к исполнению.
Неверные выводы из ошибочной интерпретации результатов некорректно поставленного эксперимента.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "почему не работает маршрутизация" +/–

Сообщение от konst2 on 02-Сен-15, 16:42

>>[оверквотинг удален]
>> Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную
>> - обязателен к использованию.
> Неверные выводы из ошибочной интерпретации результатов некорректно поставленного эксперимента.
давайте вместе поставим :)
локальная сеть:
имеем 192.168.0.226/24
имеем 192.168.0.18/24 (1 сетевая и 1 ip на нем)
имеем 192.168.0.253/24 на котором есть alias 192.168.1.253/24
Проверяем доступность 192.168.1.253 с 192.168.0.226
На 226-м:
# route -n
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.253   0.0.0.0         UG    0      0        0 eth0
192.168.1.253 - доступен
# route add 192.168.1.253 gw 192.168.0.18
# route -n
192.168.1.253   192.168.0.18    255.255.255.255 UGH   0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.253   0.0.0.0         UG    0      0        0 eth0
#  traceroute -n 192.168.1.253
traceroute to 192.168.1.253 (192.168.1.253), 30 hops max, 60 byte packets
1  192.168.0.18  0.253 ms  0.239 ms  0.233 ms
....
192.168.1.253 - пока недоступен
# ping -w3 192.168.1.253
# traceroute -n 192.168.1.253
traceroute to 192.168.1.253 (192.168.1.253), 30 hops max, 60 byte packets
1  192.168.1.253  0.232 ms  0.226 ms  0.221 ms
192.168.1.253 - стал доступен (напрямую), хотя команда:
#ip route get 192.168.1.253
выдает:
192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
    cache  mtu 1500 advmss 1460 hoplimit 64
==========
ну и чем некорректен эксперимент/вывод ?
Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к использованию.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "почему не работает маршрутизация" +/–

Сообщение от Square1 on 02-Сен-15, 18:47

>[оверквотинг удален]
> ms
> 192.168.1.253 - стал доступен (напрямую), хотя команда:
> #ip route get 192.168.1.253
> выдает:
> 192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
>     cache  mtu 1500 advmss 1460 hoplimit 64
> ==========
> ну и чем некорректен эксперимент/вывод ?
> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
> использованию.
Тем что вы работаете с алиасом, который стал доступен после арп-запроса

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "почему не работает маршрутизация" +/–

Сообщение от konst2 on 02-Сен-15, 19:18

>[оверквотинг удален]
>> 192.168.1.253 - стал доступен (напрямую), хотя команда:
>> #ip route get 192.168.1.253
>> выдает:
>> 192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
>>     cache  mtu 1500 advmss 1460 hoplimit 64
>> ==========
>> ну и чем некорректен эксперимент/вывод ?
>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
>> использованию.
> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на хост A через шлюз B (циска) (при ненастроенном шлюзе)
traceroute на host A - не показывает попытку идти через шлюз B
?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "почему не работает маршрутизация" +/–

Сообщение от Square1 on 02-Сен-15, 19:20

>[оверквотинг удален]
>>>     cache  mtu 1500 advmss 1460 hoplimit 64
>>> ==========
>>> ну и чем некорректен эксперимент/вывод ?
>>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
>>> использованию.
>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
> Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на
> хост A через шлюз B (циска) (при ненастроенном шлюзе)
> traceroute на host A - не показывает попытку идти через шлюз B
> ?
вы не тем смотрите инструментом.
смотрите tcpdump-ом

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

14. "почему не работает маршрутизация" +/–

Сообщение от konst2 on 02-Сен-15, 19:45

>[оверквотинг удален]
>>>> ну и чем некорректен эксперимент/вывод ?
>>>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
>>>> использованию.
>>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
>> Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на
>> хост A через шлюз B (циска) (при ненастроенном шлюзе)
>> traceroute на host A - не показывает попытку идти через шлюз B
>> ?
> вы не тем смотрите инструментом.
> смотрите tcpdump-ом
Посмотрел на удаленном объекте.
tcpdump доступен только на исходном хосте (откуда делается traceroute).
Так вот там:
при прописанном роутинге через шлюз "B" (циска)
tcpdump - не показывает участия "B"  при traceroute -n -T <A>
только при traceroute -n -T -g B <A>
есть рез-т:
B > A: ICMP B unreachable - source route failed, length 80
=====
ну в принципе я уже давно понял, что причина того, что я не могу достучаться до "A" в том, что шлюз "B" (циска) недонастроен. (PS. Это чужая железка)
Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный шлюз.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "почему не работает маршрутизация" +/–

Сообщение от Square1 on 02-Сен-15, 20:16

>[оверквотинг удален]
> tcpdump - не показывает участия "B"  при traceroute -n -T <A>
> только при traceroute -n -T -g B <A>
> есть рез-т:
> B > A: ICMP B unreachable - source route failed, length 80
> =====
> ну в принципе я уже давно понял, что причина того, что я
> не могу достучаться до "A" в том, что шлюз "B" (циска)
> недонастроен. (PS. Это чужая железка)
> Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный
> шлюз.
О том, что сеть А находится за шлюзом В - должен знать ваш шлюз,  а не ваша хостовая машина.
Ваша хостовая машина- ничего кроме дефолтного роутинга на ваш шлюз знать не должна.
Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А.
Шлюз В должен знать что за ним находиться хост А.
Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост находится за вашим шлюзом...

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "почему не работает маршрутизация" +/–

Сообщение от Square1 on 02-Сен-15, 21:28

>[оверквотинг удален]
>> Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный
>> шлюз.
> О том, что сеть А находится за шлюзом В - должен знать
> ваш шлюз,  а не ваша хостовая машина.
> Ваша хостовая машина- ничего кроме дефолтного роутинга на ваш шлюз знать не
> должна.
> Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А.
> Шлюз В должен знать что за ним находиться хост А.
> Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост
> находится за вашим шлюзом...
И вот тут мы подходим к вопросу :) который я вообще говоря хотел задать в самом начале...
А сети которые вы связываете, часом не серые?
Потому что если вам надо связать между собой две серые сети через интернет- то вы мягко говоря подошли к решению задачи вообще не с того конца... :)

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "почему не работает маршрутизация" +/–

Сообщение от Konst (??) on 03-Сен-15, 00:38

>[оверквотинг удален]
>> Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А.
>> Шлюз В должен знать что за ним находиться хост А.
>> Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост
>> находится за вашим шлюзом...
> И вот тут мы подходим к вопросу :) который я вообще говоря
> хотел задать в самом начале...
> А сети которые вы связываете, часом не серые?
> Потому что если вам надо связать между собой две серые сети через
> интернет- то вы мягко говоря подошли к решению задачи вообще не
> с того конца... :)
да нет. Все тривиальнее. Наш сервер находится в некоем учреждение в местной localnet-1, там же есть отдельная localnet-2. Задача была связать наш сервер (из localnet-1) с машиной из localnet-2. Задействовали циску, котрая смотрит "1-м концом" с localnet-1, а "2-м концом" в localnet-2. Мне надо было только прописать роутинг на своем сервере.
В рез-те - связи не появилось. Вопрос - почему?
traceroute -n на хост из localnet-2 не показал, что он пытается использовать указанный шлюз (циску). Вот это и вызывает недоумение.
PS. К циске и localnet-2 я не имею никакого отношения. Все сети имеют серые addr.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

12. "почему не работает маршрутизация" +/–

Сообщение от Etch on 02-Сен-15, 19:28

> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
Не совсем так. Если я что-то понимаю в сетях, то запрос уходит на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.
А ответ приходит сразу от конечного IP лишь потому, что узел шлюза содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е. шлюз не знает, что в данном случае он шлюз - он просто получает пакет, видит что его не надо маршрутизировать дальше, и поэтому просто присылает ответ от нужного IP.
И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса для данного IP.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "почему не работает маршрутизация" +/–

Сообщение от Square1 on 02-Сен-15, 19:32

>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
> Не совсем так. Если я что-то понимаю в сетях, то запрос уходит
> на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.
> А ответ приходит сразу от конечного IP лишь потому, что узел шлюза
> содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е.
> шлюз не знает, что в данном случае он шлюз - он
> просто получает пакет, видит что его не надо маршрутизировать дальше, и
> поэтому просто присылает ответ от нужного IP.
> И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса
> для данного IP.
192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял схему

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

19. "почему не работает маршрутизация" +/–

Сообщение от Konst (??) on 03-Сен-15, 01:04

>[оверквотинг удален]
>> на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.
>> А ответ приходит сразу от конечного IP лишь потому, что узел шлюза
>> содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е.
>> шлюз не знает, что в данном случае он шлюз - он
>> просто получает пакет, видит что его не надо маршрутизировать дальше, и
>> поэтому просто присылает ответ от нужного IP.
>> И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса
>> для данного IP.
> 192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял
> схему
у 192.168.0.18-го дефолтный gw = 0.253. Его запросили о 192.168.1.253, о котором он ничего не знает, и передел запрос на 0.253, который знает... Как-то так, наверное.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

20. "почему не работает маршрутизация" +/–

Сообщение от Etch on 03-Сен-15, 07:37

> 192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял схему
а, да - невнимательно посмотрел. Тогда на 192.168.0.18 должен быть маршрут до 192.168.1.253, и он по ICMP Redirect выслал исходной машине новый маршрут.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "почему не работает маршрутизация" +/–

Сообщение от Konst (??) on 03-Сен-15, 00:57

>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса
> Не совсем так. Если я что-то понимаю в сетях, то запрос уходит
> на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'.
> А ответ приходит сразу от конечного IP лишь потому, что узел шлюза
> содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е.
> шлюз не знает, что в данном случае он шлюз - он
> просто получает пакет, видит что его не надо маршрутизировать дальше, и
> поэтому просто присылает ответ от нужного IP.
> И команда 'arp -an |grep 192.168.1.253' покажет отсутствие соответствия MAC адреса
> для данного IP.
Тоже так подумал. Только с последнем скорее не согласен. В arp будут mac и для 192.168.1.253 и для 192.168.0.253, причем в данном случае одинаковые.
Последний мой эксперимент действительно в этом случае - некорректен.
---
А в целом по теме: почему при прописанном роутинге traceroute не показывает попытку дойти до шлюза - ответ видимо в разных типах/настройках роутеров. В моем случае недонастроенная циска просто сразу топырит запрос (refuse route), и tracerote ничего и не выдает. Другие роутеры в подобной ситуации (не настроен шлюз) не топырят, и только по timeout отваливаются. И в этом случае tracerote покажет, что дошел до шлюза.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

10. "почему не работает маршрутизация" +/–

Сообщение от Square1 on 02-Сен-15, 19:19

>[оверквотинг удален]
> ms
> 192.168.1.253 - стал доступен (напрямую), хотя команда:
> #ip route get 192.168.1.253
> выдает:
> 192.168.1.253 via 192.168.0.18 dev eth0  src 192.168.0.226
>     cache  mtu 1500 advmss 1460 hoplimit 64
> ==========
> ну и чем некорректен эксперимент/вывод ?
> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к
> использованию.
Чтобы рассуждать о маршрутизации, вам надо собрать вот такую примерно схему
_________192.168.0.226/24
________________/\
192.168.0.253/24  192.168.0.18/24
_____________(1)\/(2)
___________192.168.1.253/24
И никаких "необязательных в ручную роутингов" :)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

21. "почему не работает маршрутизация" +/–

Сообщение от fantom (??) on 10-Сен-15, 15:57

>[оверквотинг удален]
>> 0.18 ?!?!?! Если оно не знает?
> для эксперимента. На самом деле мне надо было связать 2 машины из
> разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи
> не появилось. А tracerote показал что и не идет через указанный
> маршрут.
> Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил
> ту же картину (почти). На самом деле 1-я попытка traceroute была
> правильной, а далее как указано выше.
> Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную
> - обязателен к исполнению.
Дык все правильно... УЧИТЕ МАТЧАСТЬ! А конкретнее - что такое ICMP Redirect....

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "почему не работает маршрутизация" +/–

Сообщение от Etch on 02-Сен-15, 05:05

1 - вы не показали маршрут до 192.168.0.18
2 - полагаю, нужно сбросить кэш маршрутизации:  ip route flush cache
3 - покажите вывод команды:  ip route get 192.168.1.1

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "почему не работает маршрутизация"	+/–
Сообщение от Skif (ok) on 01-Сен-15, 23:18
А противоположная сторона знает о вашей сети?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "почему не работает маршрутизация"	+/–
	Сообщение от Konst (??) on 02-Сен-15, 00:11
	> А противоположная сторона знает о вашей сети? нет. 192.168.0.18 не знает о 192.168.1.0
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "почему не работает маршрутизация"	+/–
	Сообщение от Аноним (??) on 02-Сен-15, 00:38
	>> А противоположная сторона знает о вашей сети? > нет. 192.168.0.18 не знает о 192.168.1.0 Во первых ты ответил на _другой_ вопрос. Во вторых - а нафига ты тогда пакеты для 1.0 раутишь на 0.18 ?!?!?! Если оно не знает?
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "почему не работает маршрутизация"	+/–
	Сообщение от Konst (??) on 02-Сен-15, 00:53
	>>> А противоположная сторона знает о вашей сети? >> нет. 192.168.0.18 не знает о 192.168.1.0 > Во первых ты ответил на _другой_ вопрос. т.к. в данном случае это актуальнее. > Во вторых - а нафига ты тогда пакеты для 1.0 раутишь на > 0.18 ?!?!?! Если оно не знает? для эксперимента. На самом деле мне надо было связать 2 машины из разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи не появилось. А tracerote показал что и не идет через указанный маршрут. Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил ту же картину (почти). На самом деле 1-я попытка traceroute была правильной, а далее как указано выше. Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к исполнению.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "почему не работает маршрутизация"	+2 +/–
	Сообщение от Square1 on 02-Сен-15, 07:04
	>[оверквотинг удален] >> 0.18 ?!?!?! Если оно не знает? > для эксперимента. На самом деле мне надо было связать 2 машины из > разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи > не появилось. А tracerote показал что и не идет через указанный > маршрут. > Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил > ту же картину (почти). На самом деле 1-я попытка traceroute была > правильной, а далее как указано выше. > Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную > - обязателен к исполнению. Неверные выводы из ошибочной интерпретации результатов некорректно поставленного эксперимента.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	7. "почему не работает маршрутизация"	+/–
	Сообщение от konst2 on 02-Сен-15, 16:42
	>>[оверквотинг удален] >> Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную >> - обязателен к использованию. > Неверные выводы из ошибочной интерпретации результатов некорректно поставленного эксперимента. давайте вместе поставим :) локальная сеть: имеем 192.168.0.226/24 имеем 192.168.0.18/24 (1 сетевая и 1 ip на нем) имеем 192.168.0.253/24 на котором есть alias 192.168.1.253/24 Проверяем доступность 192.168.1.253 с 192.168.0.226 На 226-м: # route -n 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.253 0.0.0.0 UG 0 0 0 eth0 192.168.1.253 - доступен # route add 192.168.1.253 gw 192.168.0.18 # route -n 192.168.1.253 192.168.0.18 255.255.255.255 UGH 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.253 0.0.0.0 UG 0 0 0 eth0 # traceroute -n 192.168.1.253 traceroute to 192.168.1.253 (192.168.1.253), 30 hops max, 60 byte packets 1 192.168.0.18 0.253 ms 0.239 ms 0.233 ms .... 192.168.1.253 - пока недоступен # ping -w3 192.168.1.253 # traceroute -n 192.168.1.253 traceroute to 192.168.1.253 (192.168.1.253), 30 hops max, 60 byte packets 1 192.168.1.253 0.232 ms 0.226 ms 0.221 ms 192.168.1.253 - стал доступен (напрямую), хотя команда: #ip route get 192.168.1.253 выдает: 192.168.1.253 via 192.168.0.18 dev eth0 src 192.168.0.226 cache mtu 1500 advmss 1460 hoplimit 64 ========== ну и чем некорректен эксперимент/вывод ? Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к использованию.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "почему не работает маршрутизация"	+/–
	Сообщение от Square1 on 02-Сен-15, 18:47
	>[оверквотинг удален] > ms > 192.168.1.253 - стал доступен (напрямую), хотя команда: > #ip route get 192.168.1.253 > выдает: > 192.168.1.253 via 192.168.0.18 dev eth0 src 192.168.0.226 > cache mtu 1500 advmss 1460 hoplimit 64 > ========== > ну и чем некорректен эксперимент/вывод ? > Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к > использованию. Тем что вы работаете с алиасом, который стал доступен после арп-запроса
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "почему не работает маршрутизация"	+/–
	Сообщение от konst2 on 02-Сен-15, 19:18
	>[оверквотинг удален] >> 192.168.1.253 - стал доступен (напрямую), хотя команда: >> #ip route get 192.168.1.253 >> выдает: >> 192.168.1.253 via 192.168.0.18 dev eth0 src 192.168.0.226 >> cache mtu 1500 advmss 1460 hoplimit 64 >> ========== >> ну и чем некорректен эксперимент/вывод ? >> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к >> использованию. > Тем что вы работаете с алиасом, который стал доступен после арп-запроса Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на хост A через шлюз B (циска) (при ненастроенном шлюзе) traceroute на host A - не показывает попытку идти через шлюз B ?
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	11. "почему не работает маршрутизация"	+/–
	Сообщение от Square1 on 02-Сен-15, 19:20
	>[оверквотинг удален] >>> cache mtu 1500 advmss 1460 hoplimit 64 >>> ========== >>> ну и чем некорректен эксперимент/вывод ? >>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к >>> использованию. >> Тем что вы работаете с алиасом, который стал доступен после арп-запроса > Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на > хост A через шлюз B (циска) (при ненастроенном шлюзе) > traceroute на host A - не показывает попытку идти через шлюз B > ? вы не тем смотрите инструментом. смотрите tcpdump-ом
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	14. "почему не работает маршрутизация"	+/–
	Сообщение от konst2 on 02-Сен-15, 19:45
	>[оверквотинг удален] >>>> ну и чем некорректен эксперимент/вывод ? >>>> Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к >>>> использованию. >>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса >> Хорошо. Тогда какое может быть объяснение тому, что при установленном роутинге на >> хост A через шлюз B (циска) (при ненастроенном шлюзе) >> traceroute на host A - не показывает попытку идти через шлюз B >> ? > вы не тем смотрите инструментом. > смотрите tcpdump-ом Посмотрел на удаленном объекте. tcpdump доступен только на исходном хосте (откуда делается traceroute). Так вот там: при прописанном роутинге через шлюз "B" (циска) tcpdump - не показывает участия "B" при traceroute -n -T <A> только при traceroute -n -T -g B <A> есть рез-т: B > A: ICMP B unreachable - source route failed, length 80 ===== ну в принципе я уже давно понял, что причина того, что я не могу достучаться до "A" в том, что шлюз "B" (циска) недонастроен. (PS. Это чужая железка) Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный шлюз.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	15. "почему не работает маршрутизация"	+/–
	Сообщение от Square1 on 02-Сен-15, 20:16
	>[оверквотинг удален] > tcpdump - не показывает участия "B" при traceroute -n -T <A> > только при traceroute -n -T -g B <A> > есть рез-т: > B > A: ICMP B unreachable - source route failed, length 80 > ===== > ну в принципе я уже давно понял, что причина того, что я > не могу достучаться до "A" в том, что шлюз "B" (циска) > недонастроен. (PS. Это чужая железка) > Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный > шлюз. О том, что сеть А находится за шлюзом В - должен знать ваш шлюз, а не ваша хостовая машина. Ваша хостовая машина- ничего кроме дефолтного роутинга на ваш шлюз знать не должна. Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А. Шлюз В должен знать что за ним находиться хост А. Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост находится за вашим шлюзом...
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	16. "почему не работает маршрутизация"	+/–
	Сообщение от Square1 on 02-Сен-15, 21:28
	>[оверквотинг удален] >> Меня просто смущало, что traceroute не показывает даже ПОПЫТКИ идти через указанный >> шлюз. > О том, что сеть А находится за шлюзом В - должен знать > ваш шлюз, а не ваша хостовая машина. > Ваша хостовая машина- ничего кроме дефолтного роутинга на ваш шлюз знать не > должна. > Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А. > Шлюз В должен знать что за ним находиться хост А. > Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост > находится за вашим шлюзом... И вот тут мы подходим к вопросу :) который я вообще говоря хотел задать в самом начале... А сети которые вы связываете, часом не серые? Потому что если вам надо связать между собой две серые сети через интернет- то вы мягко говоря подошли к решению задачи вообще не с того конца... :)
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	17. "почему не работает маршрутизация"	+/–
	Сообщение от Konst (??) on 03-Сен-15, 00:38
	>[оверквотинг удален] >> Ваш шлюз должен знать, за каким шлюзом находиться хост в сети А. >> Шлюз В должен знать что за ним находиться хост А. >> Ну и в обратную сторону соответственно....шлюз В должен знать что ваш хост >> находится за вашим шлюзом... > И вот тут мы подходим к вопросу :) который я вообще говоря > хотел задать в самом начале... > А сети которые вы связываете, часом не серые? > Потому что если вам надо связать между собой две серые сети через > интернет- то вы мягко говоря подошли к решению задачи вообще не > с того конца... :) да нет. Все тривиальнее. Наш сервер находится в некоем учреждение в местной localnet-1, там же есть отдельная localnet-2. Задача была связать наш сервер (из localnet-1) с машиной из localnet-2. Задействовали циску, котрая смотрит "1-м концом" с localnet-1, а "2-м концом" в localnet-2. Мне надо было только прописать роутинг на своем сервере. В рез-те - связи не появилось. Вопрос - почему? traceroute -n на хост из localnet-2 не показал, что он пытается использовать указанный шлюз (циску). Вот это и вызывает недоумение. PS. К циске и localnet-2 я не имею никакого отношения. Все сети имеют серые addr.
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	12. "почему не работает маршрутизация"	+/–
	Сообщение от Etch on 02-Сен-15, 19:28
	> Тем что вы работаете с алиасом, который стал доступен после арп-запроса Не совсем так. Если я что-то понимаю в сетях, то запрос уходит на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'. А ответ приходит сразу от конечного IP лишь потому, что узел шлюза содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е. шлюз не знает, что в данном случае он шлюз - он просто получает пакет, видит что его не надо маршрутизировать дальше, и поэтому просто присылает ответ от нужного IP. И команда 'arp -an \|grep 192.168.1.253' покажет отсутствие соответствия MAC адреса для данного IP.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	13. "почему не работает маршрутизация"	+/–
	Сообщение от Square1 on 02-Сен-15, 19:32
	>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса > Не совсем так. Если я что-то понимаю в сетях, то запрос уходит > на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'. > А ответ приходит сразу от конечного IP лишь потому, что узел шлюза > содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е. > шлюз не знает, что в данном случае он шлюз - он > просто получает пакет, видит что его не надо маршрутизировать дальше, и > поэтому просто присылает ответ от нужного IP. > И команда 'arp -an \|grep 192.168.1.253' покажет отсутствие соответствия MAC адреса > для данного IP. 192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял схему
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	19. "почему не работает маршрутизация"	+/–
	Сообщение от Konst (??) on 03-Сен-15, 01:04
	>[оверквотинг удален] >> на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'. >> А ответ приходит сразу от конечного IP лишь потому, что узел шлюза >> содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е. >> шлюз не знает, что в данном случае он шлюз - он >> просто получает пакет, видит что его не надо маршрутизировать дальше, и >> поэтому просто присылает ответ от нужного IP. >> И команда 'arp -an \|grep 192.168.1.253' покажет отсутствие соответствия MAC адреса >> для данного IP. > 192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял > схему у 192.168.0.18-го дефолтный gw = 0.253. Его запросили о 192.168.1.253, о котором он ничего не знает, и передел запрос на 0.253, который знает... Как-то так, наверное.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	20. "почему не работает маршрутизация"	+/–
	Сообщение от Etch on 03-Сен-15, 07:37
	> 192.168.0.18 не содержит 192.168.1.253 ни на каком интерфейсе.... если я правильно понял схему а, да - невнимательно посмотрел. Тогда на 192.168.0.18 должен быть маршрут до 192.168.1.253, и он по ICMP Redirect выслал исходной машине новый маршрут.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	18. "почему не работает маршрутизация"	+/–
	Сообщение от Konst (??) on 03-Сен-15, 00:57
	>> Тем что вы работаете с алиасом, который стал доступен после арп-запроса > Не совсем так. Если я что-то понимаю в сетях, то запрос уходит > на шлюз (192.168.0.18), как и говорит 'ip route get 192.168.1.253'. > А ответ приходит сразу от конечного IP лишь потому, что узел шлюза > содержит этот адрес среди прочих (не важно на каком интерфейсе). Т.е. > шлюз не знает, что в данном случае он шлюз - он > просто получает пакет, видит что его не надо маршрутизировать дальше, и > поэтому просто присылает ответ от нужного IP. > И команда 'arp -an \|grep 192.168.1.253' покажет отсутствие соответствия MAC адреса > для данного IP. Тоже так подумал. Только с последнем скорее не согласен. В arp будут mac и для 192.168.1.253 и для 192.168.0.253, причем в данном случае одинаковые. Последний мой эксперимент действительно в этом случае - некорректен. --- А в целом по теме: почему при прописанном роутинге traceroute не показывает попытку дойти до шлюза - ответ видимо в разных типах/настройках роутеров. В моем случае недонастроенная циска просто сразу топырит запрос (refuse route), и tracerote ничего и не выдает. Другие роутеры в подобной ситуации (не настроен шлюз) не топырят, и только по timeout отваливаются. И в этом случае tracerote покажет, что дошел до шлюза.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	10. "почему не работает маршрутизация"	+/–
	Сообщение от Square1 on 02-Сен-15, 19:19
	>[оверквотинг удален] > ms > 192.168.1.253 - стал доступен (напрямую), хотя команда: > #ip route get 192.168.1.253 > выдает: > 192.168.1.253 via 192.168.0.18 dev eth0 src 192.168.0.226 > cache mtu 1500 advmss 1460 hoplimit 64 > ========== > ну и чем некорректен эксперимент/вывод ? > Напомню вывод: Развеялось мое заблуждение, что роутинг указанный вручную - обязателен к > использованию. Чтобы рассуждать о маршрутизации, вам надо собрать вот такую примерно схему _________192.168.0.226/24 ________________/\ 192.168.0.253/24 192.168.0.18/24 _____________(1)\/(2) ___________192.168.1.253/24 И никаких "необязательных в ручную роутингов" :)
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	21. "почему не работает маршрутизация"	+/–
	Сообщение от fantom (??) on 10-Сен-15, 15:57
	>[оверквотинг удален] >> 0.18 ?!?!?! Если оно не знает? > для эксперимента. На самом деле мне надо было связать 2 машины из > разных подсетей на удаленном объекте. Мне сообщили ip-шлюза. Роутинг прописал. Связи > не появилось. А tracerote показал что и не идет через указанный > маршрут. > Вот и сделал в своей локалке эксперимент, указав заведомо нерабочий вариант. Получил > ту же картину (почти). На самом деле 1-я попытка traceroute была > правильной, а далее как указано выше. > Сейчас почитал еще об роутинге. Развеялось мое заблуждение, что роутинг указанный вручную > - обязателен к исполнению. Дык все правильно... УЧИТЕ МАТЧАСТЬ! А конкретнее - что такое ICMP Redirect....
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору

5. "почему не работает маршрутизация"	+/–
Сообщение от Etch on 02-Сен-15, 05:05
1 - вы не показали маршрут до 192.168.0.18 2 - полагаю, нужно сбросить кэш маршрутизации: ip route flush cache 3 - покажите вывод команды: ip route get 192.168.1.1
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору