SergKz

Интересно конечно. То есть подавать заявку не на базовые станции отдельно, а на сеть целиком? И реально дешевле получается? Что-то не помню такой возможности в их формах.

Расширяем тут свою сеть базовых станций, отправили запрос на частоты. Главный Радиочастотный Центр выставил счёт за ЭКСПЕРТИЗУ по 31 тыр за каждую базовую станцию. Это они охренели или мы отстали от жизни? Лет 5 назад платили раз в несколько меньше. И может ли кто-то ещё выдать таковую экспертизу? Ведь конторка-то прилепленная сбоку к Роскомнадзору чисто для сбора бабла.

Сам себе отвечаю: "век живи - век учись, дураком помрёшь" (с) Всё решилось установкой в настройке порта ether2-vlan100 на bridge-lan параметра EDGE=YES. То есть вилановский порт блокировался STP протоколом. Также помогает отключить STP на бридже совсем.

Есть микротик 3011 (не суть важно, помнится с подобным мучился и на 2011, но там бросил и перестроил сетку без использования vlan). На нём есть стандартный bridge-lan, к которому подключен мастер-порт второго свитча ether6 (и slave-порты второго свитча). Сетка в локалке 192.168.0.0/24, на микротике адрес из этой локалки не поднят - внешний трафик идёт через отдельный прокси. Порт ether6 воткнут в центральный коммутатор офисной локалки. Порт ether2 отвязан от всех бриджей и свитчей (нет мастера), к нему подключен wifi (ubiquiti) на удалённую площадку. На порту ether2 созданы два вилана: vlan111 с адресом, привязанным к самому интерфейсу вилана 192.168.2.1, и vlan100. Эти же виланы созданы на обеих ubiquiti и на коммутах на той стороне. Сетка 192.168.2 по vlan111 бегает на ту сторону отлично. Встала задача: прокинуть по неиспользуемому до того vlan100 локальную сетку 192.168.0.0/24 на ту сторону, с целью дать одному-двум компам на той стороне полный доступ в локалку. Поднимаю на интерфейсе ether2-vlan100 адрес 192.168.0.254/24 - всё отлично ходит на ту сторону, через все радиобриджи, коммуты и т.д. Но! Как только подключаю интерфейс ether2-vlan100 к bridge-lan, как пакеты, в том числе ARP запросы, напрочь отказываются улетать в ether2-vlan и ходят только по bridge-lan и местной локалке, и соответственно подключение компов удалённой площадки накрывается медным тазом. Самое противное, что при попытке пинговать из локалки комп на той стороне (192.168.0.74) примерно один из 30-50 пакетов почему-то проходит, и получает ответ! От микротика тоже перестаёт ходить на ту сторону, и видятся только адреса в локалке, подключенной к ether6. Что сделано не так? все настройки ARP на бридже и интерфейсах стандартные. Отвязываю ether2-vlan100 от bridge-lan - моментально всё начинает на ту сторону ходить, но только от самого микротика, естественно.

Вопрос в следующем: тестируем CCR-1036-8G-2S+ в качестве пограничного роутера. Функции - BGP (два FullView и несколько пирингов), NAT, шейпер. Суммарный трафик по внешкам - пока что гигабита 2-2.5 максимум. Первое включение принесло глюк - один FullView грузится минуты за три, второй начинает загружаться и где-то на 400 тыщ префиксов отпадает в idle. Один раз загрузил целиком и отпал минут через пять. Сначала думал, что ограничение по количеству префиксов, вписал каждому пиру с запасом - не помогло. Если, как пишут на родине микротика, BGP у них работает на одном ядре - поможет ли делу, если не в один BGP instance все peer вписывать, а каждого "соседа" создавать в отдельном инстансе? И стоит ли вообще этим заниматься?

А они встанут на Centos? или надо ставить EL7 тогда? А он однако платный...

Где - в туннеле? он и так автоматом 1476 - 1500 минус заголовок GRE 24 байта.

Есть граничный роутер на базе неплохого (когда-то :-) интеловского серверного системника с установленной на нём Centos 7. Прокачивает в сумме до 1.5 гигабит, там же маршрутизация и шейпинг в сторону внутренней сети. Загрузка процессора умеренная, вполне себе шевелится. Недавно встал ребром вопрос: одному абоненту понадобился GRE туннель. И он по непонятным причинам тормозит безбожно - больше 1.5 мегабита не разгоняется никак (смотрим iperf'ом). Между теми же точками поднимаем туннель ipip - получаем мегабит эдак 80, то есть на всю сотку абонентскую. Заменяем в командах создания туннеля ipip на gre - 1.5 мегабита максимум, а в среднем 800 кбит. Гасим весь шейпинг - обнуляем все правила tc - не влияет никак. Проапдейтили центос до последнего выложенного ядра - ноль эффекта. Провели эксперимент на отдельной сетке - поставили старый центос 6.8 с ядром 2.6 - всё летает! в той же сетке на той же железке запускаем центос 7 - те же тормоза. Найти параметров ядра, привязанных как-то к протоколу именно GRE, пока не удалось. Кто-нибудь нарывался? что можно покрутить или только downgrade на ядро 2.6?

Именно это я и пробовал в п.1 - после объединения портов в агрегированный канал теряется доступ к самим радиомостам - по "половинке транка" не хочет достукиваться до устройства.

Есть два радиолинка примерно одной пропускной способности, построенные на Ubiquiti - один на мостах 2.4 Ггц, второй на мостах 5 Ггц. Установлены по одним и тем же конечным точкам, даже на одной мачте с каждой стороны. Задача: собрать их в агрегированный канал связи так, чтобы: 1) Канал связи продолжал работать при выходе из строя любого из двух радиоканалов. Хорошо бы, чтобы в исправном состоянии пропускная складывалась (баланс трафика?) 2) Внутри агрегированного канала должны работать виланы. 3) Должен быть доступ к управлению самими радиомостами. На столе пока стенд не собирал, решил спросить - вдруг есть готовое типовое решение. Как я пока это себе представляю: Вариант 1 - ставим с двух сторон железки, умеющие VLAN и LACP/Etherchannel (cisco, d-link, mirkotik... их есть... да линукс в конце концов); - собираем порты, подключенные к радиомостам, в failover trunk; - внутри транка прокидываем виланы в этом варианте остаётся открытым вопрос: как управлять мостами? ведь они будут подключены каждый только к части транка, предварительный эксперимент на "живом" микротике, включенном в эту схему, показал, что доступ к устройствам (мостам) теряется, чтобы их настраивать - надо разбирать транк. Может есть какие-то варианты не включать определенные виланы в транк? что будет, если на портах будет разный набор виланов? Вариант 2 - ставим с двух сторон железки, умеющие VLAN и LACP/Etherchannel; - прокидываем по каждому порту радиоканалов одинаковый набор виланов (один вилан на управление радиобриджами, можно native, два-три рабочих), возможно все с разными номерами; - собираем в failover trunk ВИЛАНЫ. при таком подходе управление устройствами должно остаться, но многие ли железки сумеют такой транк? Вариант 3 - ставим с двух сторон железки, умеющие VLAN; - прокидываем по каждому порту радиоканалов одинаковый набор виланов (один вилан на управление радиобриджами, можно native, два-три рабочих), возможно все с разными номерами; - за железкой п.1 с каждой стороны ставим вторую, умеющую LACP/Etherchannel - либо роутер (ciso, mikrotik), либо шлюз на линуксе, к которым прокидываем на физпорты развиланенные на первой железке виланы и собираем их в транк. Тут вроде всё совсем железно должно работать, но наблюдается некоторая избыточность :-) Может есть соображения? (или это надо было в форум "технические вопросы локальных сетей"?)

У нас прошедшую неделю сбрасывает NanoStation, и почему-то только их, с прошивкой 5.6.6 ! Кто-нибудь нарывался?

На Cisco, если на одном и том же роутере запущены и BGP и Netflow, можно получить поток netflow с номерами AS. Дико удобно для анализа трафика по нескольким внешним линкам. Будет ли так работать Mikrotik?

У меня микротик только с одной стороны, с другой Linux.

А он справится, если ширина каналов разная? 24 мегабита и 40 мегабит. ospf и равные веса на линках lacp + source-dest ip balancing Второй вариант с LACP, как уже упоминал, отключает хождение IP по индивидуальным каналам. А оно нужно.

Есть два каналы между двумя точками. Частично через кабели/оптику/коммутаторы, частично по воздуху (Ubiquiti). Оборудование Ubiquiti разных серий причём. Приходят в итоге на два интерфейса линуксового шлюза с одной стороны и два интерфейса микротика с другой. Вопрос: как грамотно их объединить, чтобы для "прикладного" трафика у них был общий IP адрес с каждой стороны? Требования: 1. Отказоустойчивость: выход из строя любого канала из двух не должен приводить к потере связи. 2. Объединение полосы пропускания каналов в нормальном режиме. 3. Сохранение хождения IP по каждому из "субканалов" (ВАЖНО!!!) - необходимо для мониторинга и управления активным оборудованием по каждой ветке. Что было испробовано: 1. Первое приходящее в голову - Bonding (Link Aggregation). Испытано в разных режимах (active-backup, balanmce-tlb, balance-alb, 802.3 ad). Работает, но только в режиме ARP мониторинга -раз, и при этом в каждом отдельном канале хождение IP прекращается - два. К тому же в половине режимов какие-то необъяснимые потери до 60% (??!!) 2. Статическая маршрутизация с равными весами. Испытано, работать работает, но отказоустойчивость никакая, поскольку удалить маршрут из таблицы при потере связи не получается - линк ведь на интерфейсе роутера/шлюза не теряется! Не подходит. 3. Динамическая маршрутизация. После курения мануалов по микротику и quagga выяснилось, что единственный реально подходящий под задачу протокол динамической маршрутизации - цисковский EIGRP, которого ни на том ни на другом устройстве нет. У остальных с распределением нагрузки большие заморочки. 4. PPP(oE) Multilink Не пробовалось. Напрягает неизбежное уменьшение MTU, хотя в итоге возможно так и придётся сделать. 5. Самописанный скрипт а-ля Cisco SLA, тестирующий доступность второго конца каждого канала и корректирующий маршруты. Возможно и это попробую. Что подскажет "всезнающий All"? Есть готовые рецепты? ну кроме "купить циску на каждую сторону и запустить EIGRP"?