fenikssss Опубликовано 29 мая, 2018 · Жалоба Коллеги привет, имеем в ядре Juniper МХ5 в роли пограничного, и микроики сср1036 в роли BRAS IPoE PPPoE L3VPN. Джуня и микротики связаны оспф двумя ареями: одна для белых сетей другая для серых сетей. На агрегации стоит каталист 4507. Никакого qinq нет. Так вот есть идея разнести ядро по двум объектам, прикупить еще один мх5 (в будущем отказаться от микрота и докупить лицензии BRAS и терминировать на них же, благо трафик позволяет но пока не про это а про пограничный роутер) и разнести полноценно ядро, что бы в случае если на один адрес упадет бомба, я не просыпался среди ночи. Что посоветуете? iBGP? какую лучше всего логику построить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 29 мая, 2018 · Жалоба Надо юзать все и ibgp и ospf, в щависимости от того, какие маршруты распространяете и между чем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fenikssss Опубликовано 31 мая, 2018 · Жалоба В 29.05.2018 в 17:15, dignity сказал: Надо юзать все и ibgp и ospf, в щависимости от того, какие маршруты распространяете и между чем. а как на bras получается будет два дефолтных роута? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 31 мая, 2018 · Жалоба Да. И это вполне нормально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 31 мая, 2018 · Жалоба @fenikssss У меня нет своего bgp, могу ошибаться проанонсить одну подсеть, только с одной ас. Для этого держат вторую(но она не под нагрузкой) либо две можно с одним номером ас(но каждая анонсит только свои подсети) при аварии все перетекает на одну. Знатоки кому не трудно поправте. Дефолт можно, через оспф раздать и назначить приоритетный, но как это ты все закрутить, я не знаю на микротике(можешь показать примеры в лс если не жалко) Немного инфы про нетфлоу, на джуне он больше будет в 5-8 раз больше, чем с микротик по объему. Будут трудности с билингом т.к. Джун использует приприоритарное тегирование в пакетах радиуса из коробки не все билингом это могут делать, нужно будет собирать костыли через соа. С одной мик платы либо нат либо флоу, если нужно и то и другое, тогда нужно нагружать ре. Если использовать qnq влан на клиента, на каждого клиента будет тратится 1 сабскрайбер(лицензия) на сессию, 1 на создание влана в qnq, на 80 можно легально купить только 8к, но можно от 104 загнать лицензию(по мне это все обман от продавцов т.к. лицензии вводит он сам на железки, ключей у меня нет, если слетят они зайдут и введут их) З.ы. на этом форуме есть закрытый раздел по джуну, только для владельцев. Там не так активно, но есть, что почитать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LostSoul Опубликовано 31 мая, 2018 · Жалоба 1 час назад, pingz сказал: У меня нет своего bgp, могу ошибаться проанонсить одну подсеть, только с одной ас. раньше вроде было нельзя, теперь явно можно ( судя по списку multi route prefix ) и одну подсеть с разных AS , и разные подсети с разных бордеров в рамках одной AS а ещё там BFD поднять можно и переключение будет долю секунды занимать и без такого онанизма Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 1 июня, 2018 · Жалоба Нет никаких проблем сделать много точек выходя во внешние сети. Для этого достаточно с микротика анонсить дефолт в OSPF сеть, данные пойдут по ближайшему маршруту, в случае отключения одного выхода - по оставшемуся. Но тут есть проблема равных весов и ограничения скорости. Если представить что все точки выхода имеют полную копию всех ограничений абонентов, то трафик любого из абонентов должен идти только на одну точку выхода. Если у кого-то окажутся равные веса - то его трафик может пойти сразу через две точки выхода и абонент получит двойную скорость. А так схема 100% отработанная и надежная. Естественно, если все делать в одной зоне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 1 июня, 2018 · Жалоба В 31.05.2018 в 16:09, fenikssss сказал: а как на bras получается будет два дефолтных роута? Ibgp вполне рулит. У меня было 3 браса и два nat. Ничего - пережевывали. Брас аносировал свой /32 при подключении клиента, его маршруты вполне анонсировались и аппрувились. Ну и бгп пофиг на дефолтные маршруты., если есть маршрут до клиента, директконнектед. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 3 июня, 2018 · Жалоба В 29.05.2018 в 08:59, fenikssss сказал: Что посоветуете? iBGP? какую лучше всего логику построить? оба бордера - как route reflector. на каждом брасе - 2 ibgp сессии. интерконнект между бордерами -жирным линком (десятку к примеру кинуть) т.к. best cost маршрут может оказаться совсем не с того бордера куда прилетел пакет. были бы брасы нормальными - советовал бы и на брасах принимать фуллвью, но т.к. это микротики - то анонсить им дефолт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...