Romka_Kharkov

В общем заработала схема 7204+7201.... Пошло поехало.. Появилась пока не совсем понятная мне проблемма, в виде MULTIPATH на 4000.. т.е бывает ситуация когда радиус по какой-то причине выдает например клиенту на NAS2 ип адрес который уже выдан на NAS1, но это уже как бы вторичная проблема, таких префиксов заежжает совсем мало и скорее всего я уже понял что к чему, но все еще в тестах, уже более 500 человек вломилось на NAS2... все пошло по правильной и накатанной схеме. Хотел бы выразить и выражаю огромную благодарность всем кто так или иначе принял участие в беседе, поддержал, подсказал, помог советом. Отличное комьюнити не смотря на излишний PR Ericson :D :D :D

Откопал и уже настроил 7201, ваши показатели просто прекрасны, потому что у меня сейчас выглядит где-то так: L2TP Tunnel Information Total tunnels 337 sessions 2009 И при этом CPU у 7204 ... 90-100%... Трафика проходит около гигабита. Сегодня отправим в место размещение вместо МТ, о результатах настройки доложу чуть позже. :D

Если в той же ценовой категории, можно и другое что-то лишь бы оно функции нужные выполняло, мне как бы все равно.... Что посоветуете? Я разве говорю, что был не предупрежден? ;) Я просто не открывал все карты которые не касаются моего вопроса, куда всунуть этот Mikrotik уже пара мест есть, где как минимум он выиграет по кол-ву юнитов :D :D :D А касательно продакшона - судя по моменту настроек и тому что я начитался, понимаю... именно это и было целью ... проверить его под нагрузкой, но блин даже до этого не дошли :D :D :D Я читал уже много разных тем (возможно и эту в том числе)... Но перед покупателем обычно стоит остро вопрос цены, по этому была бы куча денег , было бы нанято 100500 человек для оценки и выбора и куплено 100500 нужных тазиков или роутеров, но пока таких возможностей нет, приходится работать с тем что есть , не смотря на супер старость 7204 (только я с ней работаю 7й год) она полностью делает то, что нам надо, единственный её минус на сегодня - количество юнитов, ну и слабый проц по текущему кол-ву клиентов (но это уже как бы не проблема Cisco, просто она больше не может). ;)

В общем ситуация сводится к тому, что я наверное этот Микротик заюзаю где-то в другом месте, например как Border.. или что-то в этом роде, портов много BGP умеет, памяти и процессоров достаточно, а сюда все таки поставлю одноюнитовую Cisco подороже... Обидно конечно заткнуться в таком близком от решения моменте, но все же это опыт.... Сейчас рассматриваю 7201. Вроде не дорого. :) Что скажете? Я еще изучал схему например поставить еще 1 U между ISP И MT ... что бы он l2tp тунель обеспечивал, а тут уже как-то конвертировать его в то, что понимает MT. В этом направелнии какие-то мысли есть? А то я так и не нашел решения, при условии что я даже пока не понял почему именно l2tp.... ну это уже риторика :)

Как понимать "просто по IP" ? У нас есть /29 мы в конекте, пингую вторую сторону, стало быть и они меня видят, из мира моя сторона MT тоже видна, они могут без каких либо протоколов просто повернуть мне клиентов на IP? Не забывайте о том, что у меня балансировка и получается с их стороны уже настроен l2tp или что там у них в содружестве с моим Cisco... Видимо в одном месте двумя вариантами раздавать таки может не получится?

Я уже рассматривал этот варинт но ISP "отморозился" сказали что только l2tp, вы не могли бы привести примеры технологий по которым они могут мне доставлять клиентов минуя L2TP тунель который таки не понимает MT.... А я тогда уже буду обсуждать возможность их внедрения со своим ISP.

Чесно говоря, не совсем уверен, это должно вытекать из написанного выше, со стороны ISP техник говорит, что по понятиям Cisco у них VPDN, по понятиям Juniper это l2tp, а как это называется в MT он вообще не знает, собственно как и я :) Если описанное мною выше (с Cisco) решается путем L2TP Server-а на стороне MT, то кроме как "включить\выключить" и настроить MTU там никаких параметров и нет, а мне выдали пароль для тунеля которым я должен воспользоваться, куда его в MT прикрутить понятия не имею, все клиенты требуют пару login\pass, сервера - как-то не поднимал, почему-то подумал что я буду являться клиентом... В случае VPDN На 7204 она разве выступает L2TP сервером?

Интересная <усбрано цензурой> штука получилась, в общем собрал описанную выше схему с 7204 + MT + 4000, уже подал линк между MT И 4000, подал линк от PPPoE ISP на MT, законектились по /29 Видно, и тут пришло время как бы L2TP тунель поднять, а выяснилось что MT почему-то на это не способен, с точки зрения настройки Cisco 7204 Тунель обладает только паролем, точно так же говорит и мой PPPoE ISP ;( С его стороны все готово, но вот у меня нет никакой возможности на MT поднять даже L2TP Client без указания явного >>> логина <<< и пароля... Получается, что я даже L2TP поднять не могу со своим провайдером? Кто сталкивался, возможно я на каком-то этапе круто ошибся и сейчас вообще не в ту сторону смотрю... но выглядит это как будто этот MT вообще не подходит ;( http://forum.mikrotik.com/viewtopic.php?f=2&t=16211 http://forum.mikrotik.com/viewtopic.php?f=2&t=26959 http://forum.mikrotik.com/viewtopic.php?f=2&t=63476 http://forum.mikrotik.com/viewtopic.php?f=1&t=26698 Плакать уже можно :D ?

Все вроде бы разобрался, prefix list работает чуток не так как я планировал, но так как он работает тоже вполне подходит... )))

Интересная штука, поменял на стороне MT ипшник 4000 , взял с другого интерфейса и все запирилось, странно но факт, хотя теперь появились новые интересные штуки, в Foundry / Cisco при указании prefix list есть такая штука как "le"/"ge", в моем случае есть сеть /24 но максимальный префикс для вещания в ней /32, Prefix-length как-то не сильно работает в MT... или не пойму как им крутить, при этом в документации допустимое значение 0-32, что еще хоть как-то поясняет CIDR , а вот в RouterOS 0-128, это для ipv6 что ли остальные ?

Не совсем понял на счет лупбеков и соурсов.... роут есть раз TCP Established, верно? Оба девайса пингуют друг друга вполне отлично и видимы друг для друга... // Если вы имеете ввиду Update Source в настройках пира где на выбор идут интерфейсы - то пофик, хоть с ним хоть без него - не работает, что вы имели ввиду на счет loopback ?

Пока для теста решил проверить пиринг между 4000 И RouterOS которая стоит в Датацентре на обычном ПК, получился какой-то факап, даже пиринг не поднялся.... Настроил все примитивно, хоть с паролем хоть без , TCP успешно, отправляется OPEN и все, Connection Closed.... На стороне Foundry ... Debug ваще слабый... там даже попытки не показаны, а показывается только когда Up/Down.... Небольшое введение, пиринг между двумя соседями в разных сетях ... т.е у RouterOS и 4000 нет общей сети, согласно Cisco документации это отключается путем опции disable-connected-check, но ни на foundry ни в MT ничего похожего не нашел, подскажите, может ли это влиять на пиринг и что делать в таком случае, аналог опции для MT есть?

Огромное спасибо, так вчера и сделал, только кроме connected еще понадобились static, так как кроме 1го ип на интерфейс клиенту еще могут выдаваться доп. адреса, путем роутинга на основной... а они поменчаются как "U - per-user static route" и относятся к static роутам, следом на отправляющей стороне покрутил route-map что бы не высылало лишних роутов и собственно пока все ОК... Жду теперь Микротик, буду там тоже самое настраивать, посмотрим что получится ;)

Интересная загвоздка вышла, я сделал BGP пиринг между 7204 и 4000. Со стороны 4000 in - x.x.x.x/32 out - ничего, пока так. Со стороны 7204 in - ничего out - x.x.x.x/32 x.x.x.x/32 - это реальный ИП одной pppoe сесси.. После пиринга получилось следующее: Со стороны 4000: Ко мне пытаются попасть естестственно только те сети которые прописаны в networks в настройках BGP роутера...., причем четко по /24й маске, они ессесно фильтруются, а вот указанный permit x.x.x.x/32 почему-то даже не приходит.... и естественно со стороны 7204 не отправляется. А на стороне 7204 он вполне себе есть, но он же блин не в BGP networks.... В роут таблице он есть, но как его дожно iBGP подхватить и должно ли вообще? Каким образом передавать ip от "directly connected" сессий.... Может именно по этому OSPF ?

Я с OSPF не работал, понимаю его как аналог BGP.... только для передачи внутри одной AS. И тут формулировка не совсем понятна, "разрешить ему анонсировать маршрут по умолчанию". Кому он будет себя анонсировать? или это вы имеете ввиду что бы "остальной OSPF (гипотетический)" туда не поехал? (prefix-list?) Или это default gw для cisco и MT ? Вот тут пока плаваю, не совсем понимаю каким образом разрешить именно pppoe маршруты, описанное выше про "redistribute" еще не пробовал, как раз сейчас занимаюсь пирингом 7204 и 4000, только по iBGP... Кстати, не решает ли оно эти задачи? или в чем причина выбора OSPF? При условии что описанное ранее сработает так как сказано, вопросов тут не имею :D суть понимаю, просто никогда не делал еще, хочется не факапнуться :D или хотя бы понять где и починиться :D Одна подсеть уже есть, все три девайса стоят в одной /27. network - это вы имеете ввиду анонсируемые сети?

Такую методику я тоже предполагал, но я почему-то не считаю её нормальной, во первых как вы понимаете на такое количество pppoe идет далеко не одна /24 сеть и даже далеко не одна /20 ;) По этому делить это на маршрутизаторы и пулы - как-то вяло , потому что во первых и пулы есть разные, например банально статика и динамика , их тоже делить ?? А как угадывать куда статический клиент подключится? :)))) А если например завтра еще 1 или 2 микротика.... еще пул резать ? на /27 ???:) В общем эту тему я забыл )))) Сейчас изучаю методы OSPF и плавно подхожу к тому, что то же самое я могу реализовать путем iBGP ?? Сегодня почитал справочник свой настольный в OSPF есть некая штука "redistribute connected", пока еще не осознал, но почему-то полагаю, что это именно оно, там разговор идет про Direct Connection.... похоже на правду???? Предполагаю схему следующим образом, при включенном "redistribute connected" будут таки от 7204 и от MT в сторону 4000 заежжать маршруты по /32й маске, но все таки.... пусть их будет даже 10тысяч.... хотя их реально не может быть > чем количество моих ИП, я не думаю что для BGP это какие-то цифры.... далее при подключении клиента и авторизации его будет цеплять на какой-то Virtual Interface и как я полагаю "redistribute connected" даст именно тот эфект, когда /32 будет анонсироваться после появления интерфейса.... настройка с двух сторон такой штуки вроде как и должна решить мою задачу.... ? Я в верном направлении копаю? Сегодня попробую в штатном режиме запирить 7204 и 4000 по iBGP и посмотреть как эти /32 будут в анонсы попадать....

Первый пункт выполнен, теперь второй пункт остался впарить кучу микротиков из правильного магазина :) Никогда не полнимал аналогичных постов, троль? Или просто обидно что вы с Ериксоном своим пункт 1 не выполнили? Да вы к тому же и не внимательно читаете тему, Микротик я уже купил, там, где посчитал нужным... А вот от дельных советов Saab95 по его настройке отказываться глупо. Если вам есть что добавить в тему по ключу беседы - милости прошу, если вы все еще про Ериксон - не забивайте эфир.. Эриксон я не продаю да и в последнее время писал про комп. микротик максимум для среднего офиса. Спасибо за информацию, попробуем набить своих шишек как написали постом выше.... :) P.S: Знаю я один офис небольшой, человек 400-500 не больше, так там стоят Микротики... Конечно они наверное 50 GB/s сквозь себя не гоняют, но такое количество работающих и смотрящих ВК и прочую муть - должно давать больше 5 Mb/s :))))))

Первый пункт выполнен, теперь второй пункт остался впарить кучу микротиков из правильного магазина :) Никогда не полнимал аналогичных постов, троль? Или просто обидно что вы с Ериксоном своим пункт 1 не выполнили? Да вы к тому же и не внимательно читаете тему, Микротик я уже купил, там, где посчитал нужным... А вот от дельных советов Saab95 по его настройке отказываться глупо. Если вам есть что добавить в тему по ключу беседы - милости прошу, если вы все еще про Ериксон - не забивайте эфир..

Решил еще раз удостоверится в том, что мы понимаем друг друга верно, прикрепляю файлик с полной схемой коммутации на сегодня. BigIron 4000 - BGP (Border) Между 4000 и 7204 сейчас статическая маршрутизация, т.е все сети статически роутятся на IP 7204, а оттуда default GW это 4000... 4000->7204 и 4000-MT будут объеденены одной сеткой /27, т.е у обоих девайсов будет одинковый шлюз. 1. Нужно ли мне организовывать прямой линк между 7204 и MT ? 2. В OSPF в данном случае долдны участвовать выдаваемые сети на всех трех устройствах или достаточно только 7204 + MT ? Мне не совсем понятно каким образом 4000 поймет в какой девайс кидать пришедший клиенту трафик... надеюсь именно это OSPF и решает???? Готов побеседовать с вами лично на счет платной помощи в виде советов \ инструкций и.т.п

А можно чуточку подробнее? Не совсем понимаю.... У меня сейчас вещаемые по BGP префиксы уходят статикой на 7204... Между чем и чем и по какой схеме нужно OSPF строить?

Приехал микротик, завтра буду бороться с ним :D По ходу возник еще один интересный вопрос, к примеру у меня сейчас на 7204 есть сетка /24 из которой выдаются ИП адреса клиентам..... Когда я активирую второй линк с L2TP от провайдера у меня получится ситуация в которой я буду вынужден эту сеть маршрутизировать сразу на две железки получается???? Пример: Приешл клиент, авторизовался через 7204, ему выдало IP 1.1.1.1 , после этого он реконектится и попадает случайным образом уже на MT, который тоже его авторизует и допустим выдает тот же IP 1.1.1.1 каким образом со стороны Border/Core мне надо будет указывать куда именно пришел клиент, мне ведь надо будет роутинг к нему проложить....

Действительно. У меня все работает без проблем, просто бывают не правильные конфигурации. С микротиком не годится цисковский подход. Что значит Цисковский подход ??? , т.е таки нормально работат не будет :D ?

Никакого сарказма, раньше (если мне не изменяет память) все это добро было в user-land, что означало достаточно скудную производительность. Как вы видите, из примеров, что 16 ядерный тянет еле-еле 650мбит + 800 сессий. Хотя писюк с mpd + 6-ядерный ксеон вполне легко тянет 1.5к с натом и трафиком в 2 гига. Вот и есть мнение, что PPPOE там все еще или в юзерленде, или сделано так что не ахти... Мдя уж.... PC - считаете надежным? Меня вот немного удивило (надеюсь это совпадение), что по указанным ссылкам скриншоты показывают аптйам не более двух суток при тестах... + аптайм автор почему-то обвел в красный круг :D Древняя Cisco 7204 дает (th-r3-cs7204vxr uptime is 20 weeks, 4 days, 21 hours, 7 minutes).

Спасибо, познавательно, принял к сведенью!!!! +1

Если можно, раскройте свой саркази для обычных людей :D