[dsparill]

Коллеги, добрый день. Имеется следующая схема: мир <-> cisco asr1001-x <-> eltex mes3324f

Если абоненты терминируются на asr - и приходят с eltex во vlan - проблем нет. Если же поднять ospf между cisco - eltex и терминировать абонентов на eltex - скорость не поднимается выше 2-х Мбит. Ограничений, полисеров и т.д. ничего не включено, при переключении абонента обратно на Cisco - скорость по максимуму. Нашел похожую проблему на форуме eltex, но так как обычно отписались, что вязли в работу и конечного решения не выложено. Если кто сталкивался с таким, просьба помочь. Спасибо.

[Умник]

33 минуты назад, dsparill сказал:

Если же поднять ospf между cisco

А если не поднимать и статикой?

 

33 минуты назад, dsparill сказал:

скорость не поднимается выше 2-х Мбит

Какая при этом загрузка CPU на Eltex? Меняются ли задержки при ping IP свитча и тразитных IP?

 

34 минуты назад, dsparill сказал:

Нашел похожую проблему на форуме eltex

Пришлите ссылку.

[iMPoSsibLe_iT]

Вы с АСР точно не пытаетесь какой-нить FV по OSPF в элтекс влить?

[dsparill]

Статикой не пробовали, спасибо, попробуем.

Процессор в порядке, задержек между устройствами нет.

Ссылка: http://forum.eltex-co.ru/viewtopic.php?t=9310

 

Ну и конечно один дефолт в стороны аср, без FV 😉

[Умник]

sh cpu input-rate detailed

Что говорит?

 

ARP-запись и MAC-адрес в FDB до абонента на месте? Верные?

[Умник]

VLAN 1 случайно для тестов не используете? http://forum.eltex-co.ru/viewtopic.php?t=8057

[orlik]

mtu проверьте

[dsparill]

Убрали ospf, сделали статикой - результат аналогичный. Vlan 1 не используем, mtu на интерфейсе циски 9000, на eltex включен jumbo. В момент спидтеста загрузка cpu 25%. Уже и не знаю в какую сторону копать...

 

sh cpu input-rate detailed

     Traffic type       Rate in pps  Packets count
---------------------- ------------- -------------
stack                  0             0             
http                   0             0             
telnet                 0             240           
ssh                    0             0             
snmp                   0             0             
ip                     0             1506          
arp                    34            6086984       
arp inspection         0             0             
stp                    0             88639         
ieee*                  0             6119          
route unknown          233           41633         
ip hop by hop          0             0             
mtu exceeded           0             0             
ipv4 multicast         0             18705         
ipv6 multicast         0             0             
dhcp snooping          0             0             
igmp snooping          0             0             
mld snooping           0             0             
ttl exceeded           0             0             
ipv4 illegal address   0             0             
ipv4 header error      0             0             
ip DA mismatch         0             0             
sflow                  0             0                
log deny ACEs          0             0             
vrrp                   0             0             
log permit ACEs        0             0             
ipv6 header error      0             0             
multicast routing      0             0             
multicast rpf fail     0             0             
tcp syn                0             109           
vpc                    0             0           

[Умник]

В 11.08.2023 в 18:20, Умник сказал:

ARP-запись и MAC-адрес в FDB до абонента на месте? Верные?

Аналогично и для IP/MAC nexthop, который смотрит в сторону Cisco проверьте. Сколько у вас MAC-адресов в таблице? Может не повезло и хеш-коллизию поймали?

[dsparill]

Mac/arp верные. Коммутатор тестовый, подключен один клиент, циска тоже пустая, специально собрали тестовый стенд для перевода клиентов. Смущает то что доступ есть, но не более 2-3 Мбит, по l2 вопросов нет, все стабильно.

[Умник]

3 часа назад, dsparill сказал:

arp                    34            6086984  

Один тестовый клиент и ARP 34 пакета в секунду + суммарно накоплено 6 миллионов. Интересно.

[myst]

В 11.08.2023 в 23:06, Умник сказал:

А если не поднимать и статикой?

 

какое отношение роут (неважно откуда полученный)  имеет к скорости? Он либо есть в таблички маршрутизации либо его нет. Либо есть связность L3 либо её нет.

[Умник]

3 часа назад, myst сказал:

какое отношение роут (неважно откуда полученный)  имеет к скорости?

Абсолютно никакого если все работает как задумано. Если же есть проблема, можно подозревать баг в ПО. Например некорректные действия процесса OSPF, которые приводят к тому, что маршрут устанавливается в FIB так, что трафик на него начинает коммутироваться не на wire-speed в ASIC, а в CPU. Отсюда низкая скорость.

Но теперь понятно, что дело в чем-то другом. Как я выше писал, у топик-стартера, судя по счетчикам самого Eltex, большой ARP-трафик в тестовой сети с одним абонентом. Либо там по факту не один абонент и льются broadcast-ы из какого-то крупного VLAN, либо так быть не должно.

 

При этом рост "route unknown" на форуме Элтекса обычно связывают с отсутствием ARP-записи для next-hop. Вот, например http://forum.eltex-co.ru/viewtopic.php?t=9389

[myst]

8 минут назад, Умник сказал:

Например некорректные действия процесса OSPF, которые приводят к тому, что маршрут устанавливается в FIB так, что трафик на него начинает коммутироваться не на wire-speed в ASIC, а в CPU

Ещё раз, оно либо есть в FIB либо нет. Как-то "не так" маршрут туда установить невозможно. Если оно обрабатывается на CPU это ошибка никак не связана с источником получения маршрута и уж тем более никак источник не связан с дальнейшей _коммутацией_ обработкой пакетов. Вы вообще путаете RIB и FIB но и это не относится к процессу прохождения пакетов с интерфейса на интерфейс.

[Умник]

3 минуты назад, myst сказал:

Ещё раз, оно либо есть в FIB либо нет.

Я неправильно написал, что "маршрут устанавливается в FIB". Получилось, что я приравнял ASIC и FIB. На самом деле имел ввиду аппаратные таблицы.

Не в этом дело. "Оно" может в любом случае быть в FIB так как его, как и RIB, выбирает и готовит для установки в железо ПО, но запись в HW при этом не обязательно будет внесена корректно. Такое бывает. Например, в случае переполнения аппаратной таблицы. В этом случае будет рассинхронизация между FIB, который должен быть (как его видит софт), и который по факту использует железо. Мысль, что у ТС могло быть непосильное для этого свитча число маршрутов в OSPF у меня тоже была.

Вы говорите о том, как должно быть, когда все работает корректно. Да, тогда, что в FIB, что в железе - это одно и то же. Я же о пограничных ситуациях.

 

Вот о чем я говорю, только в понятиях Cisco

[myst]

31 минуту назад, Умник сказал:

Я неправильно написал, что "маршрут устанавливается в FIB". Получилось, что я приравнял ASIC и FIB. На самом деле имел ввиду аппаратные таблицы.

Не в этом дело. "Оно" может в любом случае быть в FIB так как его, как и RIB, выбирает и готовит для установки в железо ПО, но запись в HW при этом не обязательно будет внесена корректно. Такое бывает. Например, в случае переполнения аппаратной таблицы. В этом случае будет рассинхронизация между FIB, который должен быть (как его видит софт), и который по факту использует железо. Мысль, что у ТС могло быть непосильное для этого свитча число маршрутов в OSPF у меня тоже была.

Вы говорите о том, как должно быть, когда все работает корректно. Да, тогда, что в FIB, что в железе - это одно и то же. Я же о пограничных ситуациях.

 

Вот о чем я говорю, только в понятиях Cisco

Ещё раз #3 если в FIB есть запись, она в принципе уже никак не может обрабатываться "как-то по другому". На вашей же схеме это розовая стрелочка. Она там не бывает "настолько не корректной" что вдруг начнет обрабатываться CPU. Она может вести в "некорретном" направлении но процесс отправки в данном случае уже фрейма будет обработан штатно.

[orlik]

снимите дамп трафика , и посмотрите почему у вас tcp сессия рассыпается (в первую очередь mss)
запустите iperf с udp со скоростью в 50mbps и проверьте какие у вас при этом будут дропы. 
А то устроили тут гадание ...

 

[sirmax]

Я не знаю что такое Eltex MES3324F но все же вангую что дело в MTU  уж больно симптомы похожие

В целом если есть возможность то
 - мерять скорость не спидтестом а iperf
 - воткнуть в другой интерфейс MES3324F тестовую железку и гонять трафик на нее исключая циску и прочее - только L3 в пределах 1 свитча (а еще лучше сначала проверить L2 между портами а потом переделать на routed интерфейсы и конечно на каждом шаге пинг размером МТУ в флагом DF
 - jumbo_frames это может быть про коммутацию больших пакетов а mtu  на интерфейсе может настраиваться отдельно

 

[Умник]

Не пытаясь опровергнуть тезис "дело в MTU", прошу все же его авторов рассказать, каким образом потеря TCP-пакетов (сегментов) больше чем N байт где-то по пути может привести к симптому "работает, но скорость не выше 2 Мбит/с"?

Изменено 16 августа, 2023 пользователем Умник

[orlik]

ну а ты попробуй дропать пакеты размером в 1500 байт , и посмотри на результакт

[Умник]

Попробовал. Подтвердился мой старый опыт. Подключаешься куда-нибудь по SSH, набираешь команды с коротким выводом - все ОК, набираешь команду, которая должна выдать хотя бы 20 полных строк - TCP сессия намертво зависает. Аналогично с сайтами. Какой-нибудь example.com открывается (самый большой сегмент в ответе - 1288 байт, пролезет даже с инкапсуляцией), почти все остальное - просто не работает.

Вот так всю жизнь выглядело описание проблемы "дело в MTU": https://www.opennet.ru/base/net/pppoe_mtu.txt.html (первый абзац)

Конечно, я ничем не могу опровергнуть, что в этом случае может быть и скорость "до 2 Мбит/с", поэтому очень интересен механизм, как потеря всех пакетов размером больше N байт могу дать эффект деградации скорости TCP, при сохранении в целом его работоспособности?

[Borizz.k]

А нафига там jumbo?
Верните mtu в дефолт
Сталкивались с подобным только в связке циски и телесиса
Победить не смогли

Забили

 

Изменено 16 августа, 2023 пользователем Borizz.k

[QWE]

в Элтекс саппорт пишите, они отвечают быстро

[dsparill]

Коллеги, спасибо всем за ответы. Проблема кроется в случае назначения ip unnmbered на интерфейс.

То есть  конфиг:

interface loopback 2
ip address x.x.48.17 255.255.255.240

interface vlan 2
ip unnambered loopback 2

 

Скорость будет не выше 3-х Мбит

А если просто:

interface vlan 102
 ip address 212.42.48.17 255.255.255.240

interface tengigabitethernet1/0/1

switchport access vlan 102 - все идеально.

Пробовали по мануалу элтекса вешать unnambered не на loopback, а на vlan - маршрут не попадает в ospf. Кто то использует ip unnambered на loopback у Элтекса? Может есть какой то нюанс.

[sirmax]

2 часа назад, dsparill сказал:

Коллеги, спасибо всем за ответы. Проблема кроется в случае назначения ip unnmbered на интерфейс.

То есть  конфиг:

interface loopback 2
ip address x.x.48.17 255.255.255.240

interface vlan 2
ip unnambered loopback 2

 

Скорость будет не выше 3-х Мбит

А если просто:

interface vlan 102
 ip address 212.42.48.17 255.255.255.240

interface tengigabitethernet1/0/1

switchport access vlan 102 - все идеально.

Пробовали по мануалу элтекса вешать unnambered не на loopback, а на vlan - маршрут не попадает в ospf. Кто то использует ip unnambered на loopback у Элтекса? Может есть какой то нюанс.

Вот уж век живи - век учись 😞