dr.Livci

iBGP и сейчас есть Широкая маска на интерфейсе апстрима и сейчас есть. Прочитайте тему сначала. Сейчас с каждого моего бордера есть бгп сессия с аплинком. Новый аплинк может не захотеть делать много бгп сессий с моей одной AS (IP адреса при этом не проблема) - просто кто-то меня напугал - что никто не станит мне прописывать много сессий (хотя текущий апстрим без проблем прописал) Вот я спросил - как сделать - чтобы осталась одна сессия, куча моих бордеров и трафик не шел через один бордер - который только и будет держать сессию с апстримом - далее пошло множество версий с участием мультихоп/рефлекшн/некст хоп/ свичей с бгп и что-то еще. А оно вона как )))) "Само" сразу просто и работает.

Ну так если делать дешевле, а IP хватает и упираемся только в сессии - анонсит всё один бордер, указывая разные бордеры некст-хопами, а эти бордеры тупо наливают на аплинк - свич так и будет прозрачным - не взлетит? это вы у меня спрашиваете? я хз ))) Мне кажется не взлетит) Ну я просто очень давно не брал в руки шашки :) Мне кажется, что должно - попробуйте на стенде. Пипец - взлетело. Без каких либо вообще доп. опций. Тупо peer1 AS100 (типа мой апстрим) <----> сессия с peer2 AS200 (Типа мой "главный бордер, который держит одну сессию за всех:) peer2 AS200 <----> сессия с peer3 AS200 (типа мой второй бордер - который держит сессию тока с моим главным) все три в одной сетке - что логично. Адреса фейсов пиров peer1 192.168.30.1 peer2 192.168.30.2 peer3 192.168.30.3 Только прописал network, которые пиры анонсят соответвенно peer1 111.111.1.0/24 peer2 111.111.2.0/24 peer3 111.111.3.0/24 Посмотрел на каждом из трех роутеров таблицу роутов - и там ЧУДО и красота без всяких "указывая разные бордеры некст-хопами" на peer1 111.111.2.0/24 via 192.168.30.2 111.111.3.0/24 via 192.168.30.3 на peer2 0.0.0.0/0 via 192.168.30.1 111.111.1.0/24 via 192.168.30.1 111.111.3.0/24 via 192.168.30.3 на peer3 0.0.0.0/0 via 192.168.30.1 111.111.1.0/24 via 192.168.30.1 111.111.2.0/24 via 192.168.30.2 И даже дефолт руками не прописывал ни на пир2 ни на пир3 - тоже через бгп прокатило правильно. Практика великая вещь - все действительно оказалось просто - надо было просто сразу попробовать методом тыка, а я сначала начал читать теорию и ушел в такие дебри, что до практики не дошел )))) ПИСЕЦ - просто вообще НИЧЕГО не прописывал - тока установил сесии и прописал нетворки.

Пожалуй проверю на стенде - реально интересно.

Хотя надо взять и на стенде попробовать... Так я вам уже рассказываю историю успеха - у моего пира стоит и работает СТАБИЛЬНО.

Ну так если делать дешевле, а IP хватает и упираемся только в сессии - анонсит всё один бордер, указывая разные бордеры некст-хопами, а эти бордеры тупо наливают на аплинк - свич так и будет прозрачным - не взлетит? это вы у меня спрашиваете? я хз ))) Мне кажется не взлетит)

Горя нет никакого. Работает годами без ребутов и дропов. Неточтобы я защищаю вендора - просто факт.

Спасибо всем за объяснения. Я понял только что проще всего надо ставить свич с бгп и 10г портами. И полезный совет про то, что в случае чего можно ведь и свои белые адреса заюзать. Про остальные схемы с мультихоп, рефлекшн и некстхоп я не понял. А жаль. Вдруг война и нет у меня свича с бгп, и нужно обойтись тока одной сессией )))

свич L2 уже стоит - собирает физику в кучу - гигабитные медяшки c моих бордеров - далее 10G порт - оптика - и 10G порт порт аплинка Просто он не умеет бгп ) Т.е. абсолюно прозрачен сейчас для L3 уровня и для логики. Чисто физика.

Интригаторы наши продают DCN. И кстати вроде наш аплинк как раз и собирает мои бордеры в свой DCN. Кто работал с ними - какую именно модель посоветуете для моих целей?

Вендор? (или имеется ввиду какйо-то дефолт вендор? ))) Типа сиско или SNR ?

Ясно одно - проще всего выделить свою подсетку белую для организации стыка - установить снова по одной сессии с каждого бордюра. Если вдруг рогом упрутся - что не хотят много сессий - тогда тупо свич. Кстати - какой свич, если нужно поддержка 32 битной AS, и не нужен фулвью, но все таки там будет еще в перспективе не только дефолт роут, но и пиринговые сетки - сколько-то тысяч префиксов. Сколько там роутов в таблице умеют свичи с бгп держать () и да - нужен свич с 10G - ибо трафика 3 гига т.е. от каждого бордера будет по отдельному линку к аплинку? между собой то они хоть останутся связаны? да конечно Каждый роутер подключен в мой свич (который не умеет бгп) - гигабитные порты. А уже далее 10G идет к аплинкку - оптика. Т.е. физически один линк, L2 - один сегмент - т.е. трафик ходит напрямую между каждым моим роутером и роутером аплинка. Просто вспомните первоначальный прикол - ЕСЛИ просто по каким-то причинам нельзя больше одной сессии. (с адресами разобрались - не проблема - выделю свои)

Про мультихоп не понял. Такто мои бордеры все таки буду напрямую подключены к аплинку - мультихоп нипричем - просто допустим не захочит к-во сессий делать много (с адресамм для бордеров решили - не проблема). Вот если бы не были подключены и адрес всего один и один мой бордер - а другие мои черз этот мой единственный и через мультихоп - то тогда вроде тут понятно для чего он нужен, но и траф пойдет тогда через этот бордюр. разве нет? Для экономии адресов на стыке, почему бы и нет. если домен представляет из себя простейшую звезду - там да, оно нафиг не нужно, а если хочется чтоб между сегментами была связь не через центральный узел, вполне сгодится и рефлектор, тем более что ожидаемый масштаб явно по силам тем же 3550/3750. стоп, стоп - рефлектор же только для IBGP - чтобы не мутить fullmesh между всеми моими бордюрами внутри, но траф наружу то пойдет тогда по любому через единственный бордюр, который будет единственную сессию держать с пиром... что-то снова начинаю запутываться ))))

Кстати да - если речь зайдет тока об адресах, но не к-ве сессий - то можно из своих же и выделить для этого дела.

Если аплинк выдаст /30, но не будет упираться что нужно 1 сессию, то через ebgp multihop заведет сколько потребуется. Ну а если упрется в 1 сессию, то поднимаем route reflector, и строим свою ibgp как душе угодно. Тем болей если аплинк только один, и акромя дефолта ничего не потребуется. да, акромя дефолта ничего не требуется и траф с бордеров к аплинку пойдет норм, а обратно разве не пойдет через единственный бордер, который будет анонситьвсе сети - ведь рефлектор тут нипричем для аплинка - ведь рефлект функция тока для iBGP. Или я что-то не так понимаю? Кстати да - самый оптимальный вариант - свич с бгп - ведь фул вью не нужно ему даже уметь, а стоить он будет не особо - т.е. не нужна дорогая мегавундервафля. а всего лишь свич ) Просто уже чисто за ради спортивного интерса интересно как реализовать без такого свича. И кстати тока ща понял - что дело может быть тупо не в к-ве сессий, а в к-ве ипов, которые согласится дать новый аплинк - т.е. всего один ип мне выдаст и все - чтобы не транжирить белые ипы на меня )

Ребята, вправьте мозг. Читал тысячу раз много доков по BGP, но запутался вхлам. А как сформулировать поисковый запрос в данном случае - не знаю. Хотя уверен что обсуждалось не раз. Итак: Имеем всего одного бгп пира (далее аплинк). Исторически сложилось, что сеть поделена на сегменты и каждый этот сегмент обслуживает отдельный бордер. Имеем свою автономку. Каждый наш бордер имеет бгп сессию с бордером аплинка и анонсит аплинку свою белую подсеть. Все наши бордеры и бордер аплинка внешними фейсами - в одной подсети, что ессно. Т.е. мы не собираем весь трафик со всех сегментов в одну точку на один бордер. И все хорошо и все работает. Аплинка ниграмма не напрягло поднять со своего бордера бгп сессию на каждый наш бордер. Но вот маячит перспектива смены аплинка. (не важно почему - политика) И новый аплинк может теоретически сказать - хер вам - делаем всего одну сессию и все. (хотя чего тут сложного - почти копипаста :) Ясно, что простое и логичное решение - купить вундервафлю - которая будет собирать весь траф в одну точку, и там мы уже анонсим пиру все свои подсетки (ну или даже одну - агрегировав более мелкие подсетки). Но интересно другое - можно ли как-то обойтись без покупки вундервафли. Создать всего одну бгп сессию с одного из моих бордеров, и анонсить как-то грамотно и за мои соседние бордеры. Но чтобы трафик не пошел через этот мой один бордер, а ходил, как и раньше, через "нужные" бордеры. Вроде простая задача, но чем больше раз я читаю доки по функционалу бгп - тем больше запутался. Хелп, плиз.

не NATь

просто возьмите самый дешевый RB и попробуйте. Он копейки стоит. В зависимости от топологии помещения может понадобится несколько таких дешевых точек поставить. Обратить внимание только на радиомодуль и антенны и тюнинг всего этого добра. Статей на эту тему много.

ну, Вы меня просто успокоили )

Почему я не прав? Я лишь сказал, что одну и туже задачу можно решить разными способами. Нет тут никакого "обычно". Нет единственно правильной схемы. У вас свое "обычно" - у других "свое" обычно. Главное правило - "решай задачу с помощью тех инструментов, которые хорошо знаешь". Заметьте - я не говорю, что Вы не правы, а я прав. Можно делать как вы привыкли, а можно и по другому. Я знаю хорошо определенные модели коммутаторов с десятками полезных фенечек, а не MikroTikOS и RB. И у меня все получилось реализовать. Я вообще могу при необходимости точки доступа заменить на любые другие - потому что не использую никаких специфических вещей - они протсо как радиодоступ и преобразование среды. А у меня тоже не в грязном эзернете идет управление ) Я просто говорю, что хорошей практикой является для управления железками выделть отдельный влан. Я вообще ничего не знаю про MPLS - зачем мне эту сущность сюда приплетать? Зачем мне PPP? Юзеры в гостинице не будут на смартфонах настраивать впн. Зачем мне вообще L3? Я верю, что есть такая схема. И верю - что она рабочая. Но есть и другая схема. Которую я знаю и умею - на L2. Идем далее. Что за ужасы. Как? Клиенты не смогут пользоваться нахаляву инетом. Клиент получает при въезде в гостиницу карточку с временным логином и паролем (напоминаю - я юзаю хотспот - веб авторизация - радиус - биллинг - временные учетки генерятся там с логинами/паролями). Только после авторизации - юзеру выдается через радиус-хотспот белый адрес, и добавляется разрешение форвардинга этого ип адреса сквозь RB1100. Все автоматизировано Все логируется. И еще нетфлоу собирается. Никакого общего sNAT адреса (маскарадинга) - только NAT 1:1 (серый адрес полученный до авторизации на хотспот на интерфейс юзера - натиться в белый адрес, полученный после авторизации на биллинге). Никакой анонимности). И полный контроль. Схема с управлениями на коммутаторах - для меня - самая простая, самая логичная, самая понятная, самая надежная и проверенная мною годами в различных конфигурациях. Я на свичах разрулил вланы, я настроил изоляцию точек, я настроил дхцп снупинг и арп инспекшн (юзеры не смогут руками себе ничего прописать, не смогут левый дхцп сервер включить), Я настроил loop детект и шторм контроль, я настроил арп и дхцп тротлинг (ограничение ппс этих протоколов). Я зарезал мультикаст, игмп, нетбиос, некоторые всем известные "плохие" UDP/TCP порты, типа 135-139, 445. Я делал это тысячу раз ) Почему придется ВСЁ перенастроить? Мне ничего не придется перенастраивать в уже рабочих сегментах. Всего лишь исходя из конкретных условий добавить новый сегменти пробросить новый линк. Не вижу проблем прокинуть нужный влан. Это тоже легко делается на свичах) - VLAN mapping, QnQ и т.д, а часто просто договариваемся на обычный тэгированный VLAN , который не пересекается у нас и у них. Все равно не правильно? ) я даже на RB751 делал. и еще на 433 и RB912UAG Нарезать скорости, навешать ограничений - все это можно прекрасно намутить на RouterOS

Т.е. вы предполагаете, что ether1 у меня не в бридже? И на точке роутинг работает? Нет - у меня юзеры сквозь точку прозрачно проходят по L2. Т.е. на точке доступа - сбриджованы ether1 и wlan1. Когдя я вешаю влан на этот бридж - к клиенту идет тэгированный траф. Вообщем - все это винигред - вланы мутить на точках доступа. Мне на коммутаторах проще настроить и разрулить вланы -ведь они именно и предназначены для этого. Все равно все точки я собираю в управляемый свич. Все равно свичи нужно настраивать (и это весьма просто и быстро) - ведь мне нужно по городу до аппаратной догнать этот траф в отдельном влане до отдельного типа браса RB1100 - на котором у меня поднят хотспот + радиус. И все работает. Просто я притупил с этим отключением арп полностью. И кстати - мне проще на том оконечном свиче , к которому точки подключаются - тупо снять тэги на юзерском влане, и не заморачиваться с настройкой вланов на точках доступа. Это нормальная практика для access портов. А это и есть по сути access порт - порт доступа - к которому прозрачно (L2) сквозь точку подключаются непосредственно клиенты. А для управления точками можно завести отдельный управляющий влан. В итоге на точках я имею до ужаса простейший конфиг - тупо преобразователь среды - практически только радио настроено. Дале все четко рулится на управляемых свичах и на брасе в центре. Ессно - юзеры и точки изолированы друг от друга. Вывод - можно сделать сто разных способов. Но я выбираю - который мне более по душе (рулить вланы на свичах)

Reply-Only попробую завтра. Что касается свича - то он особо то никак не влияет на суть процессов - просто делает свою работу - пересылает пакеты на порты согласно вланам и макам. А если завести влан на точке тогда юзерам тоже летит тегированный траф. Юзеры его, конечно - не понимают. Поэтому я просто не заводил влан на точки - а слал со свича нетегированный траф.

Все настроил - все работает. В кратце схема юзеры (вафля) ---- AP RB912UAG-2HPnD ----- switch_Zyxel_MES3500-24 --- RB1100AH2 В точках доступа RB912UAG-2HPnD - беспроводный и езернет фейсы в бридже. Далее свич _Zyxel собирает в кучу несколько точек RB912UAG-2HPnD, тэгирует трафик и далее подает на (VLAN56 интерфейс) RB1100AH2 (Типа WiFi controller) (на нем HOTSPOT, DHCP, DNS, RADIUS, BGP, шейпер, фаер и т.д и т.п.) Далее хочу защитить адрес шлюза - в дхцп ставлю галку: add ARP for leases - привязки добавляются нормально. Но как только выключаю арп на соответвующем интерфейсе - трафик перестает ходить. И статически я пробовал для теста прописывать ARP записи. Нифига. При этом arp ping работает, icmp пинг и любой другой трафик уже не проходит ни на роутер ни через роутер. Как только вкл арп на фейсе - лыжи сразу едут. В чем может быть прикол? Может быть из-за особенностей VLAN интерфейса - именно на нем шлюз и там и выкл арп ? Если никто не подскажет - разрулю защиту на коммутаторе...

все понял, спс.

Парни, такой простой вопрос: Есть вайфай хотспоты на микротиках в гостинице. Как можно защититься от ситуации, когда юзер пропишет руками себе IP адрес роутера?

в трассировке мы видим только прямой путь значит узлы "В" "Г" "Д" "Ж" "Л" ? Т.е. никак не узнать - на каком узле потери/задержки? или что?