pifpaf Posted December 8, 2021 Posted December 8, 2021 (edited) Добрый день, уважаемые форумчане. Помогите решить такую дилемму. Дано сабж, vlan повешаны на switch chip. С тегированными портами проблем нет. С access портами такое чудо. Порты добавлены в бридж по этой статье. /interface ethernet switch ingress-vlan-translation add ports=ether12 customer-vid=0 new-customer-vid=100 Пинги ходят без проблем, любого размера, а вот с трафиком через нат (например, RDP или VoIP) беда. Жутко тормозит RDP, в телефонах то слышно звонящего, то нет. Но стоит мне встать на порт Ether12 и сделать Torch - сразу все работает отлично. Похоже, что есть какой-то глюк с передачей VID в CPU. С тегированными портами такого глюка нет. Помогите, пожалуйста, разобраться. Edited December 8, 2021 by pifpaf Вставить ник Quote
SUrov_IBM Posted December 8, 2021 Posted December 8, 2021 Pifpaf, здравствуйте. Возможно проблема в MTU, в пределах локальной сети, оно должно быть 1500. С компьютера под управлением OS WINDOWS, в пределах локальной сети, проверьте прохождение не фрагментированного IP пакета до IP адреса маршрутизатора. Примечание: при тестировании утилитой Ping под WINDOWS, значение MTU 1500, это 1472. C:\>ping *IP адреса маршрутизатора* -l 1472 -f Ответ от *IP адреса маршрутизатора*: число байт=1472 время<1мс TTL=64 Вставить ник Quote
pifpaf Posted December 8, 2021 Author Posted December 8, 2021 (edited) @SUrov_IBM доброго времени суток. MTU на портах по дефолту 1500, L2MTU 1588 /interface ethernet print Flags: X - disabled, R - running, S - slave # NAME MTU MAC-ADDRESS ARP SWITCH ..... 11 RS ;;; LAN 6 Phone ether12 1500 *:*:*:*:*:* enabled switch1 .... пинги проходят как и положено. наружу тоже пингуется все хорошо. пока я стою на в Torch на любом access интерфейсе с нужным VID, проблем с трафиком нет. На пинги это никак не влияет (пинги всегда хорошо проходят). Edited December 8, 2021 by pifpaf Убрал MAC Вставить ник Quote
SUrov_IBM Posted December 8, 2021 Posted December 8, 2021 В 08.12.2021 в 11:52, pifpaf сказал: C:\Users\Admin>ping 192.168.1.1 -l 2500 А если в Интернет не фрагментированным стукнутся? C:\>ping ya.ru -l 1472 -f Сам доступ к Интернет по Ethernet 1500 организован или по дороге от оператора есть PPPoE? Вставить ник Quote
pifpaf Posted December 8, 2021 Author Posted December 8, 2021 (edited) C:\Users\Admin>ping ya.ru -l 1472 -f Обмен пакетами с ya.ru [87.250.250.242] с 1472 байтами данных: Ответ от 87.250.250.242: число байт=1472 время=53мс TTL=244 Ответ от 87.250.250.242: число байт=1472 время=54мс TTL=244 Ответ от 87.250.250.242: число байт=1472 время=53мс TTL=244 Ответ от 87.250.250.242: число байт=1472 время=53мс TTL=244 Статистика Ping для 87.250.250.242: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 53мсек, Максимальное = 54 мсек, Среднее = 53 мсек C:\Users\Admin>ping ya.ru -l 1473 -f Обмен пакетами с ya.ru [87.250.250.242] с 1473 байтами данных: Требуется фрагментация пакета, но установлен запрещающий флаг. тут тоже все ок. Цитата Сам доступ к Интернет по Ethernet 1500 организован или по дороге от оператора есть PPPoE? от провайдера приходит оптика в SFP, порт sfp объединен в бридж с 24 портом, оттуда витая пара идет на их телевидение и гостевой WiFi, этим трафиком я не управляю. WAN IP висит на этом бридже. Пробовал перевесить на SFP - ничего не меняется. /interface bridge add name=bridge_internet /interface bridge port add bridge=bridge_internet hw=no interface=ether24 add bridge=bridge_internet hw=no interface=sfp-GW Edited December 8, 2021 by pifpaf Вставить ник Quote
SUrov_IBM Posted December 8, 2021 Posted December 8, 2021 Временно для теста, попробуйте "занизить" TCP MSS на интерфейсе смотрящим в сторону Интернет провайдера: /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=*название WAN интерфеса* tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=*название WAN интерфеса* tcp-mss=1300-65535 log=no Перезагрузите маршрутизатор и посмотрите снова на примере RDP, будут залагивания? Вставить ник Quote
pifpaf Posted December 8, 2021 Author Posted December 8, 2021 Я правильно понимаю, что WAN IP надо будет перевесить на SFP и указать его в качестве WAN интерфейса? Или же на бридже оставить и указать bridge_internet? Сервер RDP я перевел в тег, обратно в access смогу перекинуть только вечером, когда все разойдутся. Вставить ник Quote
SUrov_IBM Posted December 8, 2021 Posted December 8, 2021 В 08.12.2021 в 08:38, pifpaf сказал: вот с трафиком через нат (например, RDP или VoIP) беда В 08.12.2021 в 12:19, pifpaf сказал: Я правильно понимаю, что WAN IP надо будет перевесить на SFP и указать его в качестве WAN интерфейса? Поскольку Вы диагностируете, что проблема с "залагиваниями", наблюдается с трафиком проходящим через NAT. Вышеуказанные правила mangle, нужно назначить на внешний по отношению к NAT интерфейс (на котором назначен IP адрес, полученный от провайдера). Вставить ник Quote
jffulcrum Posted December 8, 2021 Posted December 8, 2021 А какой трафик через устройство? Просто у вас мост без HW offload, да еще и NAT, а процессор в железке слабенький одноядерный MIPS, это коммутатор, а не маршрутизатор. Вставить ник Quote
pifpaf Posted December 8, 2021 Author Posted December 8, 2021 (edited) В 08.12.2021 в 18:27, jffulcrum сказал: А какой трафик через устройство? Просто у вас мост без HW offload, да еще и NAT, а процессор в железке слабенький одноядерный MIPS, это коммутатор, а не маршрутизатор. до прошлой недели все и работало на этом слабеньком CPU. Затем добавили больше IP камер и начались проблемы с загрузкой процессора до 100%. Перевели всю внутреннюю коммутацию на switch chip и начались вот такие вот странности. Трафика наружу не много, "стандартный офисный интернет". Вот графики за сегодня. Сомневаюсь, что занижение TCP MSS даст результат, но все-таки попробую. Сомневаюсь потому, что если конечное оборудование перевести в тег, и перекинуть порт из таблицы Ingress в Egress, то таких проблем нет. И опять же вопрос, почему если открыть Torch на микротике на 1 access порту , то все становится нормально? причем на всех access портах! Чудо чудное же) Подозреваю, что где-то осталась помеха от предыдущей конфигурации. Или то, что WAN висит на CPU. Или или, но мой мозг уже сломался на этой железке. Edited December 8, 2021 by pifpaf Вставить ник Quote
pifpaf Posted December 8, 2021 Author Posted December 8, 2021 (edited) Итак, для теста взял порт Ether1 и перевел режим hybrid: /interface ethernet switch egress-vlan-tag print Flags: X - disabled, I - invalid, D - dynamic # VLAN-ID TAGGED-PORTS 0 99 ether2 ether3 ether4 ether6 ether14 ether22 ether23 switch1-cpu 1 100 ether1 ether2 ether3 ether4 ether14 ether22 ether23 switch1-cpu 2 101 ether2 ether3 ether4 ether14 ether23 switch1-cpu 3 102 ether23 switch1-cpu 4 D 4095 /interface ethernet switch ingress-vlan-translation print Flags: X - disabled, I - invalid, D - dynamic 0 ports=ether6 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 1 ports=ether7 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=101 pcp-propagation=no sa-learning=yes 2 ports=ether8 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=101 pcp-propagation=no sa-learning=yes 3 ports=ether9 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=101 pcp-propagation=no sa-learning=yes 4 ports=ether10 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=101 pcp-propagation=no sa-learning=yes 5 ports=ether11 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 6 ports=ether12 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 7 ports=ether13 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 8 ports=ether15 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 9 ports=ether16 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 10 ports=ether17 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 11 ports=ether18 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 12 ports=ether20 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=102 pcp-propagation=no sa-learning=yes 13 ports=ether21 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=100 pcp-propagation=no sa-learning=yes 14 ports=ether1 service-vlan-format=any customer-vlan-format=any customer-vid=0 new-customer-vid=101 pcp-propagation=no sa-learning=yes 15 D ports=ether5,ether17,ether19,ether20,ether24,sfp-GW service-vlan-format=any customer-vlan-format=any new-customer-vid=4095 pcp-propagation=no sa-learning=no То есть, все что без тега заворачивается во Vlan 101, а так же принимается тегом Vlan 100. Прописал таблицу вланов /interface ethernet switch vlan print Flags: X - disabled, I - invalid, D - dynamic # VLAN-ID PORTS SVL LEARN FLOOD INGRESS-MIRROR QOS-GROUP 0 99 ether2 no yes no no none ether3 ether4 ether6 ether14 ether22 ether23 switch1-cpu 1 100 ether1 no yes no no none ether2 ether3 ether4 ether6 ether11 ether12 ether13 ether14 ether15 ether16 ether17 ether18 ether21 ether22 ether23 switch1-cpu 2 101 ether1 no yes no no none ether2 ether3 ether4 ether7 ether8 ether9 ether10 ether14 ether23 switch1-cpu 3 102 ether20 no yes no no none ether23 switch1-cpu 4 D 4095 ether5 no no no no none ether17 ether19 ether20 ether24 sfp-GW switch1-cpu Ip адреса следующие: /ip address print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK INTERFACE 0 192.168.0.1/24 192.168.0.0 VLAN99-MGMT 1 192.168.1.1/24 192.168.1.0 VLAN100-LAN 2 9.9.9.9/24 9.9.9.0 bridge_internet 3 192.168.2.1/24 192.168.2.0 VLAN101-VIDEO 4 192.168.3.1/24 192.168.3.0 VLAN102-GWF На другом конце патчкорда поднял HyperV. Хостовая система без тега (по логике Vlan 101), а так же поднял виртуалку и повесил на неё тег 100. Прокинул NAT до обоих RDP серверов: /ip firewall nat print Flags: X - disabled, I - invalid, D - dynamic 0 ;;; defconf: masquerade chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix="" 1 ;;; RDP Vlan101 chain=dstnat action=dst-nat to-addresses=192.168.2.5 to-ports=3389 protocol=tcp src-address-list=TRUST in-interface-list=WAN dst-port=53389 log=no log-prefix="" 2 ;;; RDP Vlan100 chain=dstnat action=dst-nat to-addresses=192.168.1.50 to-ports=3389 protocol=tcp in-interface-list=WAN dst-port=54389 log=no log-prefix="" В результате без проблем работаю на виртуалке в тегированном Vlan 100, а вот в хосту во Vlan 101 подключиться смог с нескольких попыток, испытывал жуткие тормоза, потерю соединения. Открыл Torch на Ether12 - без проблем подключился и работаю на обоих RDP серверах. Остановил Torch - Vlan100 без проблем, Vlan101 стал по кадрам, затем вообще отключился. Попробовал подключиться из локальной сети (из Vlan99) - результат точно такой же, как и через NAT! Vlan100 подключился без проблем, Vlan101 - с десятой попытки, тормоза, потеря соединения. Попробовал /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp out-interface=bridge_internet tcp-mss=1300-65535 log=no /ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=no tcp-flags=syn protocol=tcp in-interface=bridge_internet tcp-mss=1300-65535 log=no и Reboot. Картина не изменилась. Пинги в локальной сети проходят как и раньше (в данном примере пинг из Vlan99 во Vlan101): ~$ ping -s 1472 -M do 192.168.2.5 PING 192.168.2.5 (192.168.2.5) 1472(1500) bytes of data. 1480 bytes from 192.168.2.5: icmp_seq=1 ttl=127 time=0.906 ms 1480 bytes from 192.168.2.5: icmp_seq=2 ttl=127 time=0.737 ms ^C --- 192.168.2.5 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1004ms rtt min/avg/max/mdev = 0.737/0.821/0.906/0.084 ms ~$ ping -s 1473 -M do 192.168.2.5 PING 192.168.2.5 (192.168.2.5) 1473(1501) bytes of data. ping: local error: message too long, mtu=1500 ping: local error: message too long, mtu=1500 ^C --- 192.168.2.5 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1004ms ~$ ping -s 2048 192.168.2.5 PING 192.168.2.5 (192.168.2.5) 2048(2076) bytes of data. 2056 bytes from 192.168.2.5: icmp_seq=1 ttl=127 time=0.966 ms 2056 bytes from 192.168.2.5: icmp_seq=2 ttl=127 time=0.892 ms 2056 bytes from 192.168.2.5: icmp_seq=3 ttl=127 time=0.965 ms ^C --- 192.168.2.5 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 0.892/0.941/0.966/0.034 ms Попробовал подключиться по RDP из Vlan101 - успешно вошел и работаю. Отсюда вывод: проблема появляется при переходе пакетов из одного VLAN в другой. Как видно из конфига, все не активные порты (ether5,ether17,ether19,ether20 вообще не добавлены ни в 1 бридж, порты пустые), а так же порты без Hardware offload из bridge_internet пихаются динамически в свитч во влан 4095. Если пакеты прилетают на микротик тегом, обрабатываются с тегом, то без проблем проходят по таблице вланов. Если пакет прилетает без тега, на него навешивается тег и начинаются чудеса. Какой-то трафик (пинги например) без проблем гуляют по таблице вланов, а какой-то нет. Встает вопрос: как с этим бороться и как заставить нормально общаться вланы. Edited December 8, 2021 by pifpaf Вставить ник Quote
DeLL Posted December 8, 2021 Posted December 8, 2021 Поставить выше маршрутизатор и делать роутинг там, а коммутатору оставьте коммутацию. Очень слаба эта железка, сами споткнулись недавно Вставить ник Quote
SUrov_IBM Posted December 8, 2021 Posted December 8, 2021 В 08.12.2021 в 18:14, pifpaf сказал: На другом конце патчкорда поднял HyperV. Pifpaf, Форумчанин DeLL, посоветовал правильную идею. Если рядом с коммутатором, у Вас имеется сервер с гипервизор, на него можно установить Mikrotik RouterOS x86 или CHR (оптимизированный под виртуализацию) и перенести на него роль маршрутизатора, пробросив все необходимые VLAN между виртуальным Mikrotik и коммутатором CRS. Дополнительно: на сайте Mikrotik, для RouterOS CHR можно получить лицензию на месяц, позволяющую интерфейсам виртуального маршрутизатора работать на скорости 1 Гб/сек. После истечения лицензии, скорость на интерфейсах останется 1 Гб/сек, но CHR перестанет обновляться. Это тоже можно обойти или купить лицензию на скорость в 1 Гб/сек, она не очень дорога в цене. Вставить ник Quote
pifpaf Posted December 9, 2021 Author Posted December 9, 2021 (edited) @DeLL @SUrov_IBM идея понятна и логична. Но толку то, если в рамках свитча между вланами трафик нормально не проходит (как выяснилось вчера в тестах). Обновление железки, конечно, запланирую, но в этом году уже не согласуют. Может есть у кого идеи, почему пинги ходят нормально, а RDP и SIP нет? Проблема с UDP трафиком? какие есть варианты диагностирования? Обновленная проблема выглядит так: если клиент и сервер находятся в 1 влане - то любой трафик проходит нормально. Если разные вланы - клиент и сервер идут тегами, то трафик работает нормально, если порт в access (в таблице Inrgess) - то все плохо. Port Isolation не делал, firewall'ом не перекрывал. На данный момент приходится держать открытым Winbox с Torch на порту, чтобы всё работало. Жутчайший костыль в моей практике) Edited December 9, 2021 by pifpaf Вставить ник Quote
pifpaf Posted December 9, 2021 Author Posted December 9, 2021 @DeLL @SUrov_IBM идея понятна и логична. Но толку то, если в рамках свитча между вланами трафик нормально не проходит (как выяснилось вчера в тестах). Обновление железки, конечно, запланирую, но в этом году уже не согласуют. Может есть у кого идеи, почему пинги ходят нормально, а RDP и SIP нет? Проблема с UDP трафиком? какие есть варианты диагностирования? Обновленная проблема выглядит так: если клиент и сервер находятся в 1 влане - то любой трафик проходит нормально. Если разные вланы - то нет. Port Isolation не делал, firewall'ом не перекрывал. На данный момент приходится держать открытым Winbox с Torch на порту, чтобы всё работало. Жутчайший костыль в моей практике) В настройках свитча нет ошибки? /interface ethernet switch print name: switch1 type: QCA-8513L bridge-type: customer-vid-used-as-lookup-vid drop-if-no-vlan-assignment-on-ports: drop-if-invalid-or-src-port-not-member-of-vlan-on-ports: unknown-vlan-lookup-mode: svl forward-unknown-vlan: yes use-svid-in-one2one-vlan-lookup: no use-cvid-in-one2one-vlan-lookup: yes mac-level-isolation: no multicast-lookup-mode: dst-ip-and-vid-for-ipv4 override-existing-when-ufdb-full: no unicast-fdb-timeout: 5m ingress-mirror0: switch1-cpu,unmodified ingress-mirror1: switch1-cpu,unmodified ingress-mirror-ratio: 1/1 egress-mirror0: switch1-cpu,modified egress-mirror1: switch1-cpu,modified egress-mirror-ratio: 1/1 fdb-uses: mirror0 vlan-uses: mirror0 mirror-egress-if-ingress-mirrored: no mirror-tx-on-mirror-port: no mirrored-packet-qos-priority: 0 mirrored-packet-drop-precedence: green bypass-vlan-ingress-filter-for: bypass-ingress-port-policing-for: bypass-l2-security-check-filter-for: UPDATE!!! Я ДОКОПАЛСЯ! КТО СТОЛКНУЛСЯ С ТАКИМ ЖЕ ЧУДО ПОВЕДЕНИЕМ ПРИ ВКЛЮЧЕННОМ TORCH ВОЗЬМИТЕ НА ЗАМЕТКУ. Похоже, что все-таки дело было в firewall, по крайней мере RDP заработал на ура, телефонию проверим завтра. Проблема была в правиле: /ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related Согласно документации, Fasttrack требует, чтобы не был включен sniffer, torch и traffic generator. Именно по этому, когда я включал Torch на любом интерфейсе, все начинало работать как надо, т.к. fasttrack отключался. Век живи, век учись ) Но все таки, fastrack полезная фича, и его хотелось бы сохранить. Need help again. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.