А якщо зробити різні weight на маршрути? Взагалі-то OSPF та інший динамічний роутинг не дуже добре живе разом з policy routing'ом. Зазвичай вважається що всі адреси всюду доступні всередені Routing Domain. Маршрут же може помінятися на протязі однієї сесії чт, 25 апр. 2024 г. в 13:12, Volodymyr Litovka via UANOG :

Не дивився, дякую. Якщо йти по пунктах (a) - (d), то перший доступний - consult to route-cache, що я маю:

root@host:~# ip a [ ... ] 24: tun2: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 inet 100.100.2.250/30 scope global fks02 25: tun0: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 inet 100.100.0.250/30 scope global nmb02

root@host:~# ip route [ ... ] 100.100.1.3 nhid 37506 proto ospf metric 20 nexthop via 100.100.2.249 dev tun2 weight 1 nexthop via 100.100.0.249 dev tun0 weight 1

й що бачу -

root@host:~# ip route get 100.100.1.3 100.100.1.3 via 100.100.2.249 dev **tun2** src 100.100.2.250 uid 0 cache

root@host:~# tcpdump -i any 'port 53' -n listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 09:56:00.637547 **tun0** Out IP **100.100.2.250**.41102 > 100.100.1.3.53: 11893+ A? i.ua. (22)

тобто - пакет таки формується відповідно до раут-кеш, але лінух його форвардить трішки по іншому :)

Гм... й куди за таких обставин дивитись? тре доку про лінукс-форвардінг курити.

On 4/24/24 18:30, Maksym Tulyuk wrote:

А ти дивився в RFC 1122 3.3.4.2 Multihoming Requirements ?

Best wishes, Maksym (via mobile)

On 24 Apr 2024, at 12:08, Volodymyr Litovka via UANOG wrote:

Привіт,

є лінукс (ubuntu 22) з двома інтерфейсами "А" та "В". Піднято OSPF, через який адресу "С" видно з обох інтерфейсів.

Пакети, сформовані ping "C", виходять з інтерфейсу "А" з src ip "А". А ось, наприклад, системний різолвер (nslookup + resolv.conf->"C") працює по іншому - пакети йдуть в "А" з адресою "В". Ну тобто він не віддав рішення про встановлення src ip мережевому стеку, а встановив сам.

Розумію, що це per app. Вірогідно, питання звучить дивно, але ж: а можна якось маякнути, щоб хоча б системні ліби поменше проявляли ініціативи в цьому питанні? Тому що всяке буває по дорозі, включаючи uRPF, наприклад, й доки знайдеш проблему (почалось то все з того, що "а чому DNS то працює, то не працює?"), пилу наковтаєшся :)

Дякую.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

-- Vladimir Garnick [nic-hdl: VG-RIPE, VG-UANIC]

Так у вас є два equal cost routes, тобто без policy routing (source routing) обидва ці маршрута повинні коректно обробляти усі пакети з усіма source addresses вашого хоста. Навіть якщо б libresolv bind'ився на INADDR_ANY, то в процесі роботи маршрут може змінитися прямо посеред сесії. Напевне це не дуже принципово для DNS, але, наприклад, для RTP, не кажучи вже про TCP - критично. Як на мене - це проблема з дизайном мережі. Я свого часу у подібних конфігураціях з динамічною маршрутизацією намагався ставити потрібні адреси на loopback і усі сервіси bind'ити сами на них, щоб не залежати від інтерфейсних адрес. P.S. RFC1122 не вимагає обирати адресу з Route cache: "The route cache may be consulted" - "may", а не "must". чт, 25 апр. 2024 г. в 14:44, Volodymyr Litovka :

On 4/25/24 12:55, Volodymyr Garnyk wrote:

А якщо зробити різні weight на маршрути?

Взагалі-то OSPF та інший динамічний роутинг не дуже добре живе разом з policy routing'ом. Зазвичай вважається що всі адреси всюду доступні всередені Routing Domain. Маршрут же може помінятися на протязі однієї сесії

Немає там policy routing :)

перше питання було таке - чому libresolv не bind'иться на INADDR_ANY, а самостійно ставить source address. Наступне питання виникло після консультації з RFC1122 - якщо libresolv робить все відповідно до інформації з route cache (according to RFC), то чому нетворк стек форвардить пакет не так, як записано в його route cache :)

Технічно проблему я вирішив й пакети тепер ходять незалежно від src ip та egress interface, просто осадочок залишається у вигляді не до кінця зрозумілого форвардінгу :)

Не дивився, дякую. Якщо йти по пунктах (a) - (d), то перший доступний -

...

consult to route-cache, що я маю:

root@host:~# ip a [ ... ] 24: tun2: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 inet 100.100.2.250/30 scope global fks02 25: tun0: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 inet 100.100.0.250/30 scope global nmb02

root@host:~# ip route [ ... ] 100.100.1.3 nhid 37506 proto ospf metric 20 nexthop via 100.100.2.249 dev tun2 weight 1 nexthop via 100.100.0.249 dev tun0 weight 1

й що бачу -

root@host:~# ip route get 100.100.1.3 100.100.1.3 via 100.100.2.249 dev **tun2** src 100.100.2.250 uid 0 cache

root@host:~# tcpdump -i any 'port 53' -n listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 09:56:00.637547 **tun0** Out IP **100.100.2.250**.41102 > 100.100.1.3.53: 11893+ A? i.ua. (22)

тобто - пакет таки формується відповідно до раут-кеш, але лінух його форвардить трішки по іншому :)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Vladimir Garnick [nic-hdl: VG-RIPE, VG-UANIC]

Постав бінд на локалхост і не мороч людям голову :) чт, 25 квіт. 2024 р. о 18:11 Volodymyr Litovka via UANOG пише:

On 4/25/24 15:46, Volodymyr Garnyk wrote:

...

Так у вас є два equal cost routes, тобто без policy routing (source routing) обидва ці маршрута повинні коректно обробляти усі пакети з усіма source addresses вашого хоста. Навіть якщо б libresolv bind'ився на INADDR_ANY, то в процесі роботи маршрут може змінитися прямо посеред сесії. Напевне це не дуже принципово для DNS, але, наприклад, для RTP, не кажучи вже про TCP - критично.Як на мене - це проблема з дизайном мережі. Я свого часу у подібних конфігураціях з динамічною маршрутизацією намагався ставити потрібні адреси на loopback і усі сервіси bind'ити сами на них, щоб не залежати від інтерфейсних адрес.

Факт - треба біндитись до лупбека, якщо є така можливість. Подумавши над цим, я гадаю, що питань до лінуху немає. Питання є до libresolv, яка (а) не дає можливості явно вказати src ip (напр це можна було б мати опцією в resolv.con) та (б) біндиться на свій розсуд Тікєт шолі відкрити? :) Уявляю, скільки там одразу в панамку насують :-D

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

Вітаю. Чи не буде в цьому випадку достатньо штатно встановленого systemd-resolved? 25.04.24 21:09, Maksym Tulyuk:

ІМХО є дві опції: 1) подивитися, що можна законфігуряти в resolv.conf 2) поставили собі recursing nameserver - я колись користувався резолвером з PowerDNS, але думаю, що є і інші

Максим

...

On 25 Apr 2024, at 17:10, Volodymyr Litovka wrote:

On 4/25/24 15:46, Volodymyr Garnyk wrote:

...

Так у вас є два equal cost routes, тобто без policy routing (source routing) обидва ці маршрута повинні коректно обробляти усі пакети з усіма source addresses вашого хоста. Навіть якщо б libresolv bind'ився на INADDR_ANY, то в процесі роботи маршрут може змінитися прямо посеред сесії. Напевне це не дуже принципово для DNS, але, наприклад, для RTP, не кажучи вже про TCP - критично.Як на мене - це проблема з дизайном мережі. Я свого часу у подібних конфігураціях з динамічною маршрутизацією намагався ставити потрібні адреси на loopback і усі сервіси bind'ити сами на них, щоб не залежати від інтерфейсних адрес. Факт - треба біндитись до лупбека, якщо є така можливість. Подумавши над цим, я гадаю, що питань до лінуху немає. Питання є до libresolv, яка (а) не дає можливості явно вказати src ip (напр це можна було б мати опцією в resolv.con) та (б) біндиться на свій розсуд Тікєт шолі відкрити? :) Уявляю, скільки там одразу в панамку насують :-D

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

25.04.2024 18:10, Volodymyr Litovka via UANOG:

On 4/25/24 15:46, Volodymyr Garnyk wrote:

...

Так у вас є два equal cost routes, тобто без policy routing (source routing) обидва ці маршрута повинні коректно обробляти усі пакети з усіма source addresses вашого хоста. Навіть якщо б libresolv bind'ився на INADDR_ANY, то в процесі роботи маршрут може змінитися прямо посеред сесії. Напевне це не дуже принципово для DNS, але, наприклад, для RTP, не кажучи вже про TCP  - критично.Як на мене - це проблема з дизайном мережі. Я свого часу у подібних конфігураціях з динамічною маршрутизацією намагався ставити потрібні адреси на loopback і усі сервіси bind'ити сами на них, щоб не залежати від інтерфейсних адрес.

Факт - треба біндитись до лупбека, якщо є така можливість. Подумавши над цим, я гадаю, що питань до лінуху немає. Питання є до libresolv, яка (а) не дає можливості явно вказати src ip (напр це можна було б мати опцією в resolv.con) та (б) біндиться на свій розсуд Тікєт шолі відкрити? :) Уявляю, скільки там одразу в панамку насують :-D

Якийсь (досить помітний) час назад були дуже принципові претензії до nslookup, через те, що у нього були криві ліби резолвінгу. Що воно не працювало нормально. Тому при таких перевірках краще користуватися dig'ом. Тобто коли ти питаєш nslookup, то не факт, що воно працює так само, як системна бібліотека резолвінгу (stub resolver, AFAIR). Але я б не покладався, що DNS, то тільки UDP. З тим, що з'явилося DNSSEC (і здається там іще є щось велике), запити можуть цілком переходити в TCP і тоді може статися весело. -- tasic@

26.04.2024 20:03, Volodymyr Litovka via UANOG: [skip]

Кароч, воно виглядає так, що якщо у хоста(-ів) є multipath, то треба бути готовим до будь-яких несподіванок. Тому що далеко не всі софти вміють bind to specific interface / address й глюки можуть вилазити будь-якої миті :-\ "Це класика, чувак!" (С) Тачки

-- tasic@