dima89 Опубликовано 16 июля, 2015 (изменено) · Жалоба доброго времени с уток, уважаемые. имеется l3 связность, взятая в аренду у некого оператора - то есть 2 статических адреса на 2 точках. с помощью 2хRB2011 с FW 6.30 между точками поднят EoIP, в который завернуто несколько VLAN. проблема в наличии потерь и неровной задержке - при проверке пингом на адреса, висящие на бриджах микротиков (в бриджах интерфейс, куда завёрнуты вланы и EoIP туннель) и на адреса внутри вланов. между адресами выданными оператором потерь нет. также, некоторые проблемы с производительностью - но, думаю, напрямую связаны с возникающими потерями. методом тыка изменил на одном из микротиков на интерфейсах L2MTU до значения 1500 (по умолчанию 1598) - и потери ушли. как ушло и управление роутерами - стал через минуту подключения отваливаться winbox, да и тот перестал показывать интерфейсы. может сталкивался кто с подобным? что за загадочный параметр L2MTU? гугл не проявил ситуацию. я в смятении. Изменено 16 июля, 2015 пользователем dima89 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 16 июля, 2015 · Жалоба Вам нужно сделать следующее - убрать из бриджей с EoIP все порты с каждой стороны, повесить на эти бриджы 2 IP адреса, между которыми запускаете пинг пакетами 1500 байт. Если пакеты проходят без проблем, включаете выключенные порты бриджей, опять запускаете тесты между роутерами по указанным адресам. Смотрите, если задержка увеличилась, то по туннелю ходит какой-то трафик, который и создает неприятности, нужно его найти и устранить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 16 июля, 2015 (изменено) · Жалоба А на каких интерфейсах вы уменьшили L2MTU ? А какой L2MTU счас на туннеле? Какой был трафик через туннель когда наблюдались потери и какая была загрузка цпу на них? Микротик вещь, конечно, сама в себе, но уменьшив L2MTU до 1500 на каком либо из интерфейсов задействованных в организации туннеля Вы вообще то должны были получить не работающий туннель для всех пакетов с размером на L2 большим 1500. PS: для ТС - https://ru.wikipedia.org/wiki/Maximum_transmission_unit Изменено 16 июля, 2015 пользователем NikAlexAn Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 16 июля, 2015 · Жалоба Еще уточните у своего оператора на предмет каких-либо манипуляций с трафиком, в частности с GRE. Нарывались уже на такое в подобных конфигурациях. Также, исходя из опыта, не пытайтесь засунуть кучу вланов в один eoip. Создавайте для каждого влана отдельный туннель. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dima89 Опубликовано 16 июля, 2015 · Жалоба А на каких интерфейсах вы уменьшили L2MTU ? на физических ether1 и ether2: в первом - влан в сторону стыка с оператором, во втором - несколько вланов, засовываемых в EoIP. А какой L2MTU счас на туннеле? сейчас пришлось сбросить оба роутера, потому что у них отвалилось управление с описанными симптомами. после сброса - 1598. Какой был трафик через туннель когда наблюдались потери и какая была загрузка цпу на них? на уровне 30-40 мбит. пролазило до 90, но с серьёзными потерями. нагрузка в пределах 30% при 90мбит/с. и да, спасибо, я знаю что такое MTU. я пытаюсь понять что в терминологии микротика значит L2MTU, почему он отличается от устройства к устройству, на некоторых коробках - от порта к порту, откуда вообще взято значение, и тут, кажется, не обойтись без демагогии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 16 июля, 2015 · Жалоба L2MTU на сетевом интерфейсе это максимальный размер ethernet фрейма, который аппаратно может пропустить сетевой чип. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dima89 Опубликовано 24 июля, 2015 · Жалоба Также, исходя из опыта, не пытайтесь засунуть кучу вланов в один eoip. Создавайте для каждого влана отдельный туннель. сделал как вы посоветовали - причём в 2 вариантах. 1. с обеих сторон по VLAN на EoIP и на ethernet - и для каждой такой пары отдельный бридж. 2. с обеих сторон отдельный EoIP на каждый VLAN, по VLAN на EoIP и на ethernet - и отдельный бридж для каждой пары. потери под реальным трафиком продолжаются, причём, если отключить клиентский трафик - и гнать тестом нагрузку, например в 50мбит и 5кппс на адрес в EoIP - потерь нет. мультикаст в фильтре в бриджах забанил (мало ли). ЧЯДНТ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 24 июля, 2015 · Жалоба Также, исходя из опыта, не пытайтесь засунуть кучу вланов в один eoip. Создавайте для каждого влана отдельный туннель. сделал как вы посоветовали - причём в 2 вариантах. 1. с обеих сторон по VLAN на EoIP и на ethernet - и для каждой такой пары отдельный бридж. 2. с обеих сторон отдельный EoIP на каждый VLAN, по VLAN на EoIP и на ethernet - и отдельный бридж для каждой пары. потери под реальным трафиком продолжаются, причём, если отключить клиентский трафик - и гнать тестом нагрузку, например в 50мбит и 5кппс на адрес в EoIP - потерь нет. мультикаст в фильтре в бриджах забанил (мало ли). ЧЯДНТ? попробуйте параллельно работающему eoip сделать еще один eoip и на него повесьте два адреса и попингуйте его удаленную сторону. потери при этом будут? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 24 июля, 2015 · Жалоба попробуйте параллельно работающему eoip сделать еще один eoip суть микротика?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Serejka Опубликовано 24 июля, 2015 · Жалоба Для себя сделал вывод что на микротике mtu лучше не трогать вообще. Был подобный случай, запускали qinq на одну из точек, намаялся с тестированием. Схема MT CCR1036 (терминирован в транспортной сети), extreme x670 ( q-in-q делающий - тоже терминирован), в опеределённых сборках 2ой тег снимался не на extreme, а на включенном в него cisco catalyst 3560G (так же терминировался ip адресом в транспортном вилане). Дальше сеть транспортного провайдера, на дальнейшей стороне Dlink DES1210 разбирает qinq (манаджмент интерфейс перевешивался в так же на транспортную сеть) и за ним MT RB750 - в той же сети. С ближней стороны опционально появлялся ноутбук. При увеличении mtu на дальнем МТ (например 1501) - вылазили потери до 40%, при том что в транспортной сети была включена джамба. На Длинк - потерь не было. Так же вылазили непонятные потери на ближний CCR (особенно с экстрима, я так понял это специфические глюки л3 терминации на vman). После установки mtu на микротиках 1500 всё возвращалось в норму. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 25 июля, 2015 · Жалоба Проверьте MAC адреса виртуальных интерфейсов микротика. У нас бывало, что они совпадали :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dima89 Опубликовано 28 июля, 2015 · Жалоба Проверьте MAC адреса виртуальных интерфейсов микротика. У нас бывало, что они совпадали :( одинаковые на всех VLAN-интерфейсах на одном физическом. по идее так и должно быть - на циске так же: Internet 10.1.x.1 - xxxx.xxxx.eb81 ARPA GigabitEthernet0/0/1.1Internet 10.2.x.1 - xxxx.xxxx.eb81 ARPA GigabitEthernet0/0/1.2Internet 10.3.x.1 - xxxx.xxxx.eb81 ARPA GigabitEthernet0/0/1.3Internet 10.4.x.1 - xxxx.xxxx.eb81 ARPA GigabitEthernet0/0/1.4Internet 10.5.x.1 - xxxx.xxxx.eb81 ARPA GigabitEthernet0/0/1.5Internet 10.6.x.1 - xxxx.xxxx.eb81 ARPA GigabitEthernet0/0/1.6 выяснилось другое. убрал из EoIP все вланы и стал засовывать по одному - и потери наблюдаются только когда засовываешь один определенный клиентский влан. у клиента эзернет кончается на сервере - на нём белый адрес. никакого криминала я не увидел (с обеих сторон). заново перенастроил, проверил - всё один в один так как и на других вланах. какой трафик может не нравиться микротику? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 28 июля, 2015 (изменено) · Жалоба какой трафик может не нравиться микротику? а загрузка проца микротика в порядке? до добавления этого влана и после. Изменено 28 июля, 2015 пользователем Giga-Byte Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dima89 Опубликовано 29 июля, 2015 · Жалоба а загрузка проца микротика в порядке? до добавления этого влана и после. не меняется. в пределах 30% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaist Опубликовано 13 сентября, 2015 · Жалоба исходя из опыта, не пытайтесь засунуть кучу вланов в один eoip. Создавайте для каждого влана отдельный туннель. можно узнать в чем заключается горький опыт? какие траблы возникли при этой схеме? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dima89 Опубликовано 21 сентября, 2015 (изменено) · Жалоба короче ССЗБ. в схеме были вперемешку линки 1Гб\с и 100Мб\с. можно узнать в чем заключается горький опыт? какие траблы возникли при этой схеме? сделали так 2 линка, пока проблем не наблюдаем. в каждом по ~20 вланов. Изменено 21 сентября, 2015 пользователем dima89 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...