LINUX.ORG.RU
решено ФорумAdmin

Может ли путь A -> B отличаться от пути B -> A?

 , ,


0

1

В учебной лабке про BGP у авторов NetKit путь A->B проходит через иные AS, чем путь B->A. В меру моего понимания вопроса и по результатам опытов при использовании IPv4, расчёте MSS «не в то сторону» и поломанном из-за запрета ICMP P-MTU это приведёт к черной дыре TCP, как только в какой-то AS будет сеть с MTU < 1500.

Так ли это или я параноик? Сам не админ.

(Для юмористов пометка — «отличаться от пути» означает «не быть перестановкой пути в обратном порядке»)

★★★★★

Path MTU может быть поломан и без этого тотальным запретом ICMP на отдельных участках.

А сам вопрос я не понял. BGP это маршрутизация между AS, а внутри AS может быть устроено что угодно. Это с одной стороны. С другой стороны, вроде как BGP и не требует чтобы путь из A->B был перестановкой в обратном порядке пути из B->A. Поэтому на практике отличаться может, а на сколько это хорошо и противоречит ли чему-то, можно обсуждать отдельно.

mky ★★★★★ ()
Ответ на: комментарий от mky

Path MTU может быть поломан и без этого тотальным запретом ICMP на отдельных участках.

Я именно это и имел в виду (иную причины поломки я не знаю просто).

BGP это маршрутизация между AS, а внутри AS может быть устроено что угодно.

Внутри AS, как я полагаю, ещё есть надежда, что в местах избыточной топологии MTU сетей будут одинаковы (иначе TCP точно кирдык). Если же пути разные на уровне AS, то надежды уже нету.

Поэтому на практике отличаться может, а на сколько это хорошо и противоречит ли чему-то, можно обсуждать отдельно.

Я бы сказал, что скорее «в теории — может», а вот с практикой как раз и хотелось бы узнать.

sv75 ★★★★★ ()
Последнее исправление: sv75 (всего исправлений: 2)
Ответ на: комментарий от sv75

Если icmp-пакеты ходят, то path mtu работает, если не проходят, то не работает. Не совсем понимаю, как хождение пакетов туда-обратно по одинаковому маршруту может помочь path mtu при не аботающем icmp. И не понимаю, почему разные пути пакетов туда/обратно создадут проблему path mtu.

mky ★★★★★ ()

если по первому вопросу - «A -> B отличаться от пути B -> A?» - то ассиметрия хождения трафика сплошь и рядом. Это как бы рабочий момент и он бывает как желательным, так и нежелательным.

Насчет проблемы PMTUD в контексте ассиметрии я честно не понял.

xscrew ★★ ()
Ответ на: комментарий от mky

Если путь одинаков, то MSS посчитан будет корректно при Syn/Ack в TCP, если маршрутизаторы меняют MSS, конечно. Если он разный, то (лично у меня) MSS считается неверно, посколько считается на пути к нам, а используется на пути от нас. После чего работоспособность PMTU становится критичной. Где я не прав? )

sv75 ★★★★★ ()
Ответ на: комментарий от sv75

Как при этом избежать TCP black hole, вот в чём мой вопрос?

Разве MSS считается удаленным сторонами не независимо? Ну то есть сторона А посчитала свой MSS для отправки в сторону B и сторона B посчитала свой MSS для отправки в сторону А?

UPD: надо проверить конечно, но по-моему все как я описал.

xscrew ★★ ()
Последнее исправление: xscrew (всего исправлений: 1)
Ответ на: комментарий от xscrew

Независимо. MSS считается при пути пакета от одной стороне к другой, иначе как она его узнает? (у меня так, судя по tcpdump). Но полученный MSS используется для деления данных, идущих в обратном направлении — опс. Или я что-то радикально не так понимаю )

Ну то есть сторона А посчитала свой MSS для отправки в сторону B и сторона B посчитала свой MSS для отправки в сторону А?

Я знаю только о методе раcчета «роутеры меняют MSS у идущего пакета, где есть поле MSS в TCP (это SYN и SYN+ACK, два первых пакета)» (

sv75 ★★★★★ ()
Последнее исправление: sv75 (всего исправлений: 2)
Ответ на: комментарий от sv75

Но полученный MSS используется для деления данных, идущих в обратном направлении — опс

Это максимальное же значение, оно может быть и меньше. Если отправленные пакеты не пролазят с размером объявленным в MSS принимающей стороной - отрабатывает PMTUD и все, пакеты шлются с меньшим размером. Если запрещены icmp needfrag - то беда конечно, но так никто не делает, во всяком случае обычно.

Я знаю только о методе раcчета «роутеры меняют MSS у идущего пакета, где есть поле MSS в TCP

Хардварные маршрутизаторы (ну магистральные скажем) так не делают.

xscrew ★★ ()
Ответ на: комментарий от xscrew

Если запрещены icmp needfrag - то беда конечно, но так никто не делает, во всяком случае обычно.

Как не делает? Я читал, что это чуть ли не штатная практика (

Хардварные маршрутизаторы (ну магистральные скажем) так не делают.

При MTU < 1500 ? То есть там разрешен needfrag?

sv75 ★★★★★ ()
Ответ на: комментарий от xscrew

От яндекса вполне приходит mss 1410, кстати.

sv75 ★★★★★ ()
Ответ на: комментарий от sv75

Как не делает? Я читал, что это чуть ли не штатная практика

Никто в здравом уме не будет запрещать абсолютно _все_ подряд типы icmp.

При MTU < 1500 ? То есть там разрешен needfrag?

Конечно, маршрутизаторы отправляют сообщения icmp, в том числе needfrag.

xscrew ★★ ()
Ответ на: комментарий от xscrew

Никто в здравом уме не будет запрещать абсолютно _все_ подряд типы icmp.

Все нет, а вот это — как раз запрещали же (

Конечно, маршрутизаторы отправляют сообщения icmp, в том числе needfrag.

Так, как бы ещё сиё проверить...

sv75 ★★★★★ ()
Ответ на: комментарий от sv75

Все нет, а вот это — как раз запрещали же (

Ну я к тому, что нормально - не запрещать.

Так, как бы ещё сиё проверить...

Да хотя бы вот из дома (конечно тут не магистральная железка, но поведение такое же):

xscrew@alex-pc ~ % ping -M do -s1472 8.8.8.8

вот дамп:

00:45:04.793454 IP 192.168.0.1 > 192.168.0.102: ICMP 8.8.8.8 unreachable - need to frag (mtu 1400), length 556

192.168.0.1 - роутер, 192.168.0.102 - моя машина.

P.S. все, я спать :)

xscrew ★★ ()
Последнее исправление: xscrew (всего исправлений: 1)
Ответ на: комментарий от sv75

Магистральные точно так же делают, я бы дамп тебе привел на выбор магистрального джунипера или циски или хуавея, но он ничем не отличается от того, что я привел выше, кроме ip адресов, а их палить не охото :)

xscrew ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.