VGA

точно, в статусе написано "5180/20/а" с корость 54мбит, что же ждать то еще кроме 25Mбит по tcp

для бондинга придется EoIP тунели поднимать, а на них, помоему тут говорили, бондинг не очень работает. вообще можно попробовать и маршрутизацией побалансировать, ставим еще один маршрутизатор к которому будут подключены обе антены и на нём пишим в одном маршруте два шлюза (шлюзами будут ip одной и второй антены) собственно этим и производим стандартную микротиковскую балансировку. Каналы собственно строим как два маршрутизатора с wifi линком между собой (не WDS). P.S. Я знаю что можно обойтись для данной схемы и без дополнительного маршрутизатора, просто описать схему без дополнительного было бы сложнее.

вот это не правильно, как писали выше этот адрес должен быть на бридже, в общем должно быть как то так : для " Антенна передатчик бридж " /ip address add address=192.168.80.91/24 interface=bridge1 network=192.168.80.0 /ip route add distance=1 gateway=192.168.80.93 для " Антенна приемник бридж " /ip address add address=192.168.80.92/24 interface=bridge1 network=192.168.80.0 /ip route add distance=1 gateway=192.168.80.93 для "роутер с ИП адресами провайдера" /ip address add address=192.168.80.93/24 interface=WAN network=192.168.80.0 /ip firewall nat add action=dst-nat chain=dstnat dst-port=8292 protocol=tcp to-addresses=192.168.80.91 to-ports=8291 add action=dst-nat chain=dstnat dst-port=8293 protocol=tcp to-addresses=192.168.80.92 to-ports=8291 После этого обе точки будут доступны по внешнему ip адресу ( в принципе по любому ip весящему на любом интерфейсе роутера) одна по порту 8292 вторая по порту 8293

Криво конечно описана проблема, но как я понял у вас нету доступа (не пингуются) микротики подключенные по L2TP к основному микротику с белым IP когда сами к нему подключены по L2TP, как мне кажется это из за того что вы забыли на этих удаленных микротиках прописать маршрут до IP адреса который вы получаете на своё L2TP соединение, попробуйте трассернуть этот адрес с того микротика на который нету доступа, вероятнее всего трасер будет уходить не в тунель на основной микротик а в маршрут по умолчанию.

Хотелось бы на микротиках увидеть какую нибудь технологию типа STACK или MLAG для обеспечения высокой доступности или избыточности.

loopback у меня конечно же есть, я по его ip на железки захожу, в том что вы написали возможно есть здравый смысл, но сходу я чего-то не разобрал как вы предлогаете сделать. У меня на центре два канала, и на выносах тоже два канала, соответственно основной канал на выносе по gre (иногда по L2tp) цепляется к основному каналу на центре, резевный на выносе к резервному на центре. соответственно у меня образуется два независимых тунеля (а иногда четыре тунеля, когда с выноса поднимаю два тунеля с основного и два с резервного канала). То что вы предлагаете нужно делать, как я понимаю, через scope и target scope в общем можно подумать на досуге.

Вообще-то замечаю. Схема следующая удаленный офис два интернет канала, основной и резервный, через которые подняты на центр ГРЕ тунели и ОСПФ, так вот когда основной канал отваливается и идет переключение на резервный, винбокс отваливается. Правда конечно быстро связь восстанавливается. Возможно правда это связано с keepalive самого тунеля, не разбирался с этим т.к. для нас это не критично и происходит очень редко. В любом случае это скорее не балансировка, я представляю себе балансировку как возможность отправлять пакеты в разные каналы, то есть в теории скорость каналов складывается при балансировке.

По идее OSPFом балансировать нагрузку не получиться т.к. даже если менять каким то образом цену маршрута (например каким нибудь скриптом) то перестроение маршрутов довольно длительная процедура во время которой вообще никуда трафик не идёт, а если маршрутизатор еще и постоянно маршруты перестраивать будет то это вообще никуда не годится. А вообще задача интересная, не думал над такой и быстро что-то сообразить не могу как решить её, посмотрим кто чего тут посоветует.

Я сейчас посмотрел и понял о чем вы говорите, вы похоже имеете ввиду Tag Protocol Identifier (TPID) — Идентификатор протокола тегирования. Размер поля — 16 бит. Указывает, какой протокол используется для тегирования. Для 802.1q используется значение 0x8100 " Это не совсем эзертип т.к. это часть вилан тега точно такая-же как и ID . Хотя многие и называют это эзертипом, но в таком случае получается в пакете два эзертипа, ну в принципе конечно можно его и так обозвать.

вот http://xgu.ru/wiki/802.1Q

по моему вы что то путаете или подзабыли, метка ID vlan ставится сразу после мак адреса получателя и отправителя как раз перед изертипом, метится сам ethernet кадр не смотря вообще на то, что там внутри него идёт (ну в чистом виде конечно без разных там технологий типа войс влан и т.п. где пакет может направляться в вилан в зависимости от того что там внутри) Скажем не плюсы и минусы а разные задачи, ато сейчас тут быстро напридумывают разного такого о чем ни кто не говорил, типа виланы устарели и т.п. Нужно понимать всю схему и на чем она сделана. А именно что связывают эти два моста, в каком месте абонент, где и на чем живет абонентская сеть, в общем нужно понимать всю схему целиком.

Это точно. Иной раз такие проблемы вырисовываются на ровном месте, что охренееш. И я их встречал. Например не пинговался линк между маршрутизатором alcatel и коммутатором huawei при этом если в разрыв поставить какой нибудь простецкий хаб то всё работало, но самое интересное что если в этот huawei воткнуть кабель в другой порт то тоже работает где-то от недели до месяца, а потом теже проблемы возникают, но главное что если переткнуть в старый типа не рабочий порт он опять начинает работать. В общем так и пришлось провайдеру этот коммутатор поменять на другой и все проблемы пропали. А при чем здесь это каким образом езер тип и мту с виланами связан, ну ладно мту может быть короче требуемого и не регулироваться ни на той ни на другой железке в связке, а езер тип как вообще может на виланы может повлиять?

ни разу не видал проблем с OSPF на разных вендорах. Работал с OSPF на Cisco Juniper Alcate и конечно-же Mikrotik. Не все вместе конечно их соединял но как правило два три вендора было. Да собственно и с чего там должны быть проблемы если это стандартный протокол. А чему там не работать,? Вы бы еще сказали что Fast Ethernet на разных вендорах хорошо работает.

Ну мутнеет, меняется затухание, меняется рефлектограмма и что с того? работает же, может у кого передатчики на приделе мощности и сдохнет линк, но таких я думаю нету. Я знаю целый район в Москве где оптика работает уже больше 20 лет, а точнее 22 года, это микрорайон Дорогомилово. Наша контора его сдала в эксплуатацию в 98 году, делали его года два, вот и считайте сколько оптика работает, а она до сих пор работает я точно знаю т.к. знакомый её (в смысле сеть) там обслуживает по сей день.

нет. джуниперы, алкатели, экстримы, авая плюс триплайт. Во, верно рассуждаешь. Плюс сетевые сервисы обычно не так уж сильно критичны и при хорошем оборудовании всё работает годами. Начальство вообще вспоминают о сети когда что-то жестко выходит из строя и долго не восстанавливается, что начинает мешать работе, вот тогда они готовы на многое, но как правило когда всё снова начинает работать все обещания и желание что то улучшить у них пропадает, причём это даже не зависит от уровня компании, везде одно и тоже.