LTP-8x и хождение ARP между ONT
Добавлено: 06 авг 2018 22:18
Добрый день!
Имеется LTP-8x (Eltex LTP-8X software version 2.14.0 build 1036 on 29.12.2014 20:49), на одном из pon-портов живут несколько ONT. В том числе с одного сплиттера работают две одинаковые ONT NTP-2. Работают в режиме bridge, к одному из портов каждой из ONT подключен маршрутизатор, которому назначен "белый" IP. Эти адреса находятся в одной подсети. Грустно, но факт - друг друга эти роутеры не видят. Как показали исследования, не проходит ARP-REQUEST до другой ONT. Хосты, которые находятся в той же подсети, но подключены не через LTP-8x, доступны.
Для изучения проблемы я зашел в shell обеих ONT и запустил там команду tcpdump -vvi arp. В опыте роутер, подключенный к ONT-A, пытался отправлять ARP-запросы с целью выяснить MAC-адрес роутера, подключенного к ONT-B.
Итак, с роутера, подключенного к ONT-A, ARP-запросы уходят (выделены как раз эти запросы)
06:36:55.440080 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.123 tell x.y.104.65, length 46
06:36:55.670971 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.189 tell x.y.106.129, length 46
06:36:56.052361 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.188 tell x.y.106.129, length 46
06:36:56.518154 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.134 tell x.y.106.129, length 46
06:36:56.532364 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.158 tell x.y.106.129, length 46
06:36:56.670870 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.184 tell x.y.106.129, length 46
06:36:56.685108 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.105 tell x.y.104.69, length 46
06:36:57.253267 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.71 tell x.y.104.65, length 46
06:36:57.256194 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.178 tell x.y.106.129, length 46
06:36:57.381494 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.65 tell x.y.104.103, length 46
06:36:57.633146 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.152 tell x.y.106.129, length 46
06:36:57.684800 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.105 tell x.y.104.69, length 46
06:36:58.105623 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.96 tell x.y.104.65, length 46
06:36:58.285296 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.97 tell x.y.104.65, length 46
До ONT-B (и до других ONT, подключеных к этой LTP, у которых интерфейс veip0.1 находится в том же VLAN) эти запросы не доходят. До других узлов сети они доходят (делали debugging на коммутаторе, подключенном к агрегатору аналогично LTP-8x):.
03:14:33.315988 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.123 tell x.y.104.65, length 46
03:14:33.546883 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.189 tell x.y.106.129, length 46
03:14:33.928288 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.188 tell x.y.106.129, length 46
03:14:34.394086 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.134 tell x.y.106.129, length 46
03:14:34.408275 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.158 tell x.y.106.129, length 46
03:14:34.546788 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.184 tell x.y.106.129, length 46
03:14:35.129187 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.71 tell x.y.104.65, length 46
03:14:35.132123 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.178 tell x.y.106.129, length 46
03:14:35.257403 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.65 tell x.y.104.103, length 46
03:14:35.509090 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.152 tell x.y.106.129, length 46
03:14:35.981552 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.96 tell x.y.104.65, length 46
03:14:36.161219 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.97 tell x.y.104.65, length 46
Взял побольше вывода, чтобы было понятно, что это одна и та же "пачка" широковещательных APR-запросов, как раз нужный из которых почему-то не доходит до получателя.
Абсолютно аналогичную картинку наблюдал непосредственно у клиента, подключая свой ноутбук вместо роутера.
При этом, как я и говорил, прекрасно видны хосты в той же подсети, но физически подключенные не к LTP, а к другому коммутатору, например хост x.y.104.77 (tcpdump c ONT-A):
06:57:36.216431 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.77 tell x.y.104.69, length 46
06:57:36.230853 ARP, Ethernet (len 6), IPv4 (len 4), Reply x.y.104.77 is-at ec:08:6b:e2:2f:c0 (oui Unknown), length 46
К сожалению, программа tcpdump на LTP почему-то отсутствует, поэтому невозможно точнее установить место "пропадания" ARP-пакета.
Чистили правила iptables на LTP-8x и обеих ONT (хотя ничего подозрительного в них не было), правила по умолчанию во всех цепочках ACCEPT - ситуация не изменилась.
Это какая-то особенность, встроенная блокировка отсылки ARP-пакетов внутри OLT? Получается, что клиент не может обратиться к своей второй точке, а через Интернет от другого провайдера (например, через мобильный) все работает.
Имеется LTP-8x (Eltex LTP-8X software version 2.14.0 build 1036 on 29.12.2014 20:49), на одном из pon-портов живут несколько ONT. В том числе с одного сплиттера работают две одинаковые ONT NTP-2. Работают в режиме bridge, к одному из портов каждой из ONT подключен маршрутизатор, которому назначен "белый" IP. Эти адреса находятся в одной подсети. Грустно, но факт - друг друга эти роутеры не видят. Как показали исследования, не проходит ARP-REQUEST до другой ONT. Хосты, которые находятся в той же подсети, но подключены не через LTP-8x, доступны.
Для изучения проблемы я зашел в shell обеих ONT и запустил там команду tcpdump -vvi arp. В опыте роутер, подключенный к ONT-A, пытался отправлять ARP-запросы с целью выяснить MAC-адрес роутера, подключенного к ONT-B.
Итак, с роутера, подключенного к ONT-A, ARP-запросы уходят (выделены как раз эти запросы)
06:36:55.440080 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.123 tell x.y.104.65, length 46
06:36:55.670971 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.189 tell x.y.106.129, length 46
06:36:56.052361 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.188 tell x.y.106.129, length 46
06:36:56.518154 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.134 tell x.y.106.129, length 46
06:36:56.532364 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.158 tell x.y.106.129, length 46
06:36:56.670870 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.184 tell x.y.106.129, length 46
06:36:56.685108 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.105 tell x.y.104.69, length 46
06:36:57.253267 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.71 tell x.y.104.65, length 46
06:36:57.256194 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.178 tell x.y.106.129, length 46
06:36:57.381494 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.65 tell x.y.104.103, length 46
06:36:57.633146 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.152 tell x.y.106.129, length 46
06:36:57.684800 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.105 tell x.y.104.69, length 46
06:36:58.105623 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.96 tell x.y.104.65, length 46
06:36:58.285296 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.97 tell x.y.104.65, length 46
До ONT-B (и до других ONT, подключеных к этой LTP, у которых интерфейс veip0.1 находится в том же VLAN) эти запросы не доходят. До других узлов сети они доходят (делали debugging на коммутаторе, подключенном к агрегатору аналогично LTP-8x):.
03:14:33.315988 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.123 tell x.y.104.65, length 46
03:14:33.546883 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.189 tell x.y.106.129, length 46
03:14:33.928288 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.188 tell x.y.106.129, length 46
03:14:34.394086 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.134 tell x.y.106.129, length 46
03:14:34.408275 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.158 tell x.y.106.129, length 46
03:14:34.546788 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.184 tell x.y.106.129, length 46
03:14:35.129187 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.71 tell x.y.104.65, length 46
03:14:35.132123 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.178 tell x.y.106.129, length 46
03:14:35.257403 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.65 tell x.y.104.103, length 46
03:14:35.509090 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.106.152 tell x.y.106.129, length 46
03:14:35.981552 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.96 tell x.y.104.65, length 46
03:14:36.161219 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.97 tell x.y.104.65, length 46
Взял побольше вывода, чтобы было понятно, что это одна и та же "пачка" широковещательных APR-запросов, как раз нужный из которых почему-то не доходит до получателя.
Абсолютно аналогичную картинку наблюдал непосредственно у клиента, подключая свой ноутбук вместо роутера.
При этом, как я и говорил, прекрасно видны хосты в той же подсети, но физически подключенные не к LTP, а к другому коммутатору, например хост x.y.104.77 (tcpdump c ONT-A):
06:57:36.216431 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has x.y.104.77 tell x.y.104.69, length 46
06:57:36.230853 ARP, Ethernet (len 6), IPv4 (len 4), Reply x.y.104.77 is-at ec:08:6b:e2:2f:c0 (oui Unknown), length 46
К сожалению, программа tcpdump на LTP почему-то отсутствует, поэтому невозможно точнее установить место "пропадания" ARP-пакета.
Чистили правила iptables на LTP-8x и обеих ONT (хотя ничего подозрительного в них не было), правила по умолчанию во всех цепочках ACCEPT - ситуация не изменилась.
Это какая-то особенность, встроенная блокировка отсылки ARP-пакетов внутри OLT? Получается, что клиент не может обратиться к своей второй точке, а через Интернет от другого провайдера (например, через мобильный) все работает.