maxkst

Цыска вроде по дефолту внешний влан делает 8100 ethertype для улучшения совместимости, хотя по стандарту Q in Q IEEE 802.1ad должно быть 88a8. На микротиках то же самое, по дефолту сервис влан не включен. Я ваиршарком смотрел, как выглядит двойное тегирование с внешним сервисным тегом, и с обычным. Только если сервинсый тег установлен - шарк показывает что это QinQ.

Зачем? Убирается только внешняя провайдерская метка, весть трафик так и выходит тегированный через UNTAGGED порт, но только с клиентскими метками. Клиентские метки убираются следующим свичем.   С сервисным тегом есть свои заморочки. К примеру свич Netonix имеет 4 значения на порту для каждого влана: U T Q и D

Будет, проверял лично и 4 будет. Только зачем? До вас наврятли это кому-то в голову приходило - можете сами придумать термин, я думаю никто возражать не станет ))

Есть возможность проверить на практике? Не думал, что все так плохо. Я из Канады

Прям все-все не обязательно, достаточно только ICMP по идее

8.8.4.4? тогда надо бежать за противогазом, и в бункер, ибо третья мировая началась ))

Лучше output   Какой?

А если интернет упал за шлюзом?

Ну и нормально, напишите пробавцу емайл, они отфутболят на МТ, и спокойно обращайтесь в ТП с копией письма от продавана. Правда ждать прийдется, но ответят

Основной канал может загнуться по двум причинам - обрыв до шлюза, или проблема после шлюза. В первом случае шлюз будет Unreachable, маршрут до 8.8.4.4 не активен. Во втором случае Reachable - и маршрут до 8.8.4.4 будет активен. Я такое резервирование никогда не делал, но по логике я бы пинг через основной канал до 8.8.4.4 прибил гвоздями. Попробуйте заблочить фаерволом пинг до гугла от роутера через резервный канал, должно сработать

2011 - для дома еще куда ни шло, и то с большой натяжкой. Если нужны вланы на нем - то только на свич-чипе. Для шифрования все таки лучше поменять на что-то с аппаратной поддержкой

@kiragun Смогёт. Но до приемлемого все равно будет далеко. Мы тестировали 2011 чисто из спортивного интереса с виланами и без, RFC2544 тест. Без вланов и с хардовыми вланами тест провалил, с софтовыми вланами - вообще убил желание использовать эту железку где бы то ни было.

@kiragun 750Gr3 умеют аппаратное шифрование. А что у вас?

@poisons Мне нравится их слоган на главной странице сайта - "Чем мы лучше других?" ))) Я бы предложил им еще один в том же духе - " Нам что, больше всех надо?" :-)

Тупо запихать одну метку в другую это не QnQ а DoubleTagging. Для QnQ верхний тег должен быть особый, сервисный, с правильным Ethertype. DoubleTagging тоже будет работать, если MTU позволяет. Я просто придираюсь к терминологии. :-)

@alibek что вы имеете ввиду?

прилетают, их и в логах видно, не видно только ответы сервера Есть, но туда все что нужно - добавлено   Были подозрения на железо, или косяк с софтом после обновлений. Начали собирать копию сервера, и после каждого шага проверяли работоспособность. Те же глюки появились после фаервола. Оказалось, что открыть трафик для TCP UDP DST PORT 53 и явного accept всего с вышестоящих DNS серверов и локалки недостаточно. Блочился INCOMING трафик с SRC PORT 53. Каким боком оно там вообще сдалось - я пока не понимаю, но как только это открыли - всё заработало. Щас буду вникать, что и кому мы открыли )))

@ipaddr.ru из перечисленных вами логов только general и security содержит инфу

Включил все логи. резолвер лог пустой

Включил query.log. logging { channel query.log { file "/var/lib/bind/query.log"; // Set the severity to dynamic to see all the debug messages. severity debug 3; }; category queries { query.log; }; }; Вижу запросы от клиента. Но не вижу ответы сервера в этом логе

Пример NSLOOUP C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 *** UnKnown can't find nag.ru: Server failed C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 *** UnKnown can't find nag.ru: Server failed C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 *** UnKnown can't find nag.ru: Server failed C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 *** UnKnown can't find nag.ru: Server failed C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 *** UnKnown can't find nag.ru: Server failed C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 *** UnKnown can't find nag.ru: Server failed C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 *** UnKnown can't find nag.ru: Server failed C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 Non-authoritative answer: Name: nag.ru Address: 85.112.113.93 C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 Non-authoritative answer: Name: nag.ru Address: 85.112.113.93 C:\Users\User>nslookup nag.ru 10.0.10.148 Server: UnKnown Address: 10.0.10.148 Non-authoritative answer: Name: nag.ru Address: 85.112.113.93

На серваке с UBUNTU и DNS BIND заглючил NSLOOKUP у клиента, не на самом сервере. NSLOOKUP выдает ошибку: Server failed на любом клиенте несколько раз подряд, а потом начинает резолвить имя в IP нормально. При этом Reverse lookup работает отлично всегда. NSLOOKUP с самого сервера не глючит ни ИМЯ в IP, ни IP в ИМЯ. Куда копать?

Если у вас несколько админских сетей, то маршрутизацию там сделать та еще попоболь. На нем нету GW адреса, только IP и маска )))

Та же беда

Получил офиц. ответ от MT - не лечится. Возврат. The particular problem you have experienced on your CRS328-4C-20S-4S+ unit is not fixable by software updates. Please return this device to the distributor for warranty repair