kostil Опубликовано 4 марта, 2010 · Жалоба Вечер добрый. Пользую Mikrotik для терминации PPPoE. У каждого пользователя статический адрес. Для части пользователей, имеющих реальные ip-адреса использую OSPF NSSA как описывает cisco. Сталкнулся с большой загрузкой сервера при относительно не большом трафике. ТП mikrotik'а сказала что нужно изменить схему маршрутизации, избавиться от роутов /32, т.к. OSPF создает большую нагрузку на NAS. Сейчас имею два NAS mikrotik до 1000 коннектов на каждый и циску в роли ABR. Соответственно в LSDB в среднем 1000-1300 записей. Поделитесь опытом как можно оптимизировать данную схему? Может подскажете менее ресурсоемкую схему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 4 марта, 2010 · Жалоба а почему не RIP для впн роутов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 4 марта, 2010 (изменено) · Жалоба у вас раздача идет по какой то шаманской схеме, или на каждый нас свой пул адресов, представляющий из себя сетку с определенной маской? ежели второе - поковыряйте на возможность суммаризации адресов. при изначально хорошем проектировании все сводится к максимум 2-3 роутам с какими нибудь масками /21,/22,/23,/24 и т.п. а почему не RIP для впн роутов?а смысл? ospf хотя бы не раз в 30 секунд штурмует таблицу маршрутов, а если их там под 1000х/32, rip изрядно даст прикурить. Изменено 4 марта, 2010 пользователем darkagent Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 4 марта, 2010 · Жалоба ну у меня 5к на 14 насов. и? наоборот, после отказа от ospf в сети впн серверов нагрузка на них упала. RIP по моему самый легкий протокол маршрутизации Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 4 марта, 2010 · Жалоба видимо что то делаете не так. после перехода с ripv2 на ospf - очень хорошо разгрузились маршрутизаторы. правда у нас и маршрутов в разы поболее будет, rip с ними помирал... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 4 марта, 2010 · Жалоба я во всей сети использую ospf. rip крутится только на сети впн серверов. Все живет на DGS-3627G Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 4 марта, 2010 · Жалоба input (Total) output packets errs bytes packets errs bytes colls 51134 0 23564104 51953 0 30439200 0 46829 333 22238884 49036 0 27302355 0 52664 0 23903358 54117 0 30630459 0 51242 0 23532159 52155 0 29675516 0 52937 0 24484217 53616 0 30729188 0 500+ пользователей на пппое mpd5, квагга ospf делает плюс нат на сетку в 32 адреса load averages: 0.30, 0.31, 0.26 браса в сетке 2 ну и в ospf докучи из бгп фулвью залит, FreeBSD 7.2 i386 выводы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 4 марта, 2010 · Жалоба фулвью вниз на брасы? или фулвью только на бордере, а дальше уже дефолт? имхо первый вариант бесмысленен.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mousus Опубликовано 4 марта, 2010 · Жалоба да вот за всей бессмысленностью и тяжестью как раз в своё время этот первый вариант и применялся, посмотреть как вырастет нагрузка ---- брасы как были холодные так и остались не сильно нагревшись Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 4 марта, 2010 (изменено) · Жалоба Вечер добрый.Пользую Mikrotik для терминации PPPoE. У каждого пользователя статический адрес. Для части пользователей, имеющих реальные ip-адреса использую OSPF NSSA как описывает cisco. Сталкнулся с большой загрузкой сервера при относительно не большом трафике. ТП mikrotik'а сказала что нужно изменить схему маршрутизации, избавиться от роутов /32, т.к. OSPF создает большую нагрузку на NAS. Сейчас имею два NAS mikrotik до 1000 коннектов на каждый и циску в роли ABR. Соответственно в LSDB в среднем 1000-1300 записей. Т.е. грузятся именно микротики? - не агрегатор?Сдается мне что протокол маршрутизации тут не очень при делах. При наличии 500 рррое сессий по любому в таблице маршрутизации будет 500 маршрутов /32. А уж при помощи какого протокола маршрутная информация попадет на агрегатор это уже другая песня. Изменено 4 марта, 2010 пользователем Jugernault Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 4 марта, 2010 · Жалоба у вас раздача идет по какой то шаманской схеме, или на каждый нас свой пул адресов, представляющий из себя сетку с определенной маской? ежели второе - поковыряйте на возможность суммаризации адресов. при изначально хорошем проектировании все сводится к максимум 2-3 роутам с какими нибудь масками /21,/22,/23,/24 и т.п.Если вы внимательно прочтете пример по ссылке то поймете мою схему - для меня подошел самый последний пример "Dialup Design with the Dynamic IP Assignment from a Central Address Pool"В кратце: сеть разделена на несколько зон. В каждой зоне N NAS серверов. В голове зоны обычно cisco. Для каждой из зон выделен пул реальников /21-/24. На циске все суммаризируется и отправляется в backbone. На NAS с циски идет только дефолт и маршруты относящиеся к данной зоне которых N*800, где N - количество NAS в данной зоне. К чему тут суммаризацию прикручивать еще? Раз уж эта структура плохая - предложите свой вариант. а почему не RIP для впн роутов?Были мысли попробовать RIPv2 но руки пока не дошли, подумал сначало поковырять OSPF. Если есть на примете материал почитать по RIP с PPPoE буду признателен. Т.е. грузятся именно микротики? - не агрегатор?Сдается мне что протокол маршрутизации тут не очень при делах. При наличии 500 рррое сессий по любому в таблице маршрутизации будет 500 маршрутов /32. А уж при помощи какого протокола маршрутная информация попадет на агрегатор это уже другая песня. Агригатор переваривает все в лёт, нагрузки на нем никакой. Между агригатором и NAS собственно OSPF. На NAS - redistribute connected. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 4 марта, 2010 (изменено) · Жалоба а откуда взялась мысль что загрузка из за ОSPF ??? Ты ТП микротика больше слушай )) На НАСе правила фаервола, шейпинга есть ?? Изменено 4 марта, 2010 пользователем martini Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 4 марта, 2010 (изменено) · Жалоба В кратце: сеть разделена на несколько зон. В каждой зоне N NAS серверов. В голове зоны обычно cisco. Для каждой из зон выделен пул реальников /21-/24. На циске все суммаризируется и отправляется в backbone. На NAS с циски идет только дефолт и маршруты относящиеся к данной зоне которых N*800, где N - количество NAS в данной зоне.К чему тут суммаризацию прикручивать еще? Раз уж эта структура плохая - предложите свой вариант. Мне кажется что правильнее было бы исходить из следующих приниципов:1. 1 NSSA area = 1 NAS, т.е. что бы с NASа на NAS не было заброса /32 маршрутов - минимизируется количество маршрутов (кернел роуты ppp не в счет - они по любому есть). 2. Если на каждую area (NAS) выделено блок белых ip, то и маршрутизировать его надо одним агрегатом. 3. Разговор идет о белых адресах, а что с серыми? - их то уж точно надо агрегатами подавать. Агригатор переваривает все в лёт, нагрузки на нем никакой. Между агригатором и NAS собственно OSPF. На NAS - redistribute connected.Рабочая схема - мы с такой живем. а откуда взялась мысль что загрузка из за ОSPF ??? Ты ТП микротика больше слушай ))На НАСе правила фаервола, шейпинга есть ?? Вооот... а я о чем говорю... :) - не похоже что нагрузка от маршрутизации. Если бы было все действительно плохо, то первым делом агрегатор офигел бы. Изменено 4 марта, 2010 пользователем Jugernault Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 4 марта, 2010 · Жалоба да не трогайте вы агрегацию )) а может у него ИП глобально разбросаны по НАСам.. и нельзя ничё сагрегировать ) И еще пару вопросов по НАСу - каличество абонентов и трафик на интерфейсе к агрегатору какие (во время большрй загрузки сервера)?? И что за железо то хоть ?? да и версию софта не мешало бы узать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 4 марта, 2010 · Жалоба 1. 1 NSSA area = 1 NAS, т.е. что бы с NASа на NAS не было заброса /32 маршрутов - минимизируется количество маршрутов (кернел роуты ppp не в счет - они по любому есть).2. Если на каждую area (NAS) выделено блок белых ip, то и маршрутизировать его надо одним агрегатом. 3. Разговор идет о белых адресах, а что с серыми? - их то уж точно надо агрегатами подавать. 1. Теряется отаказоустойчивость и прекрасное свойство PPPoE балансировать нагрузку между NAS. 2. пункт 1. 3. Сейчас хочу попробовать отдать агрегатору еще и серые адреса, что бы пиринговый трафик ходил мимо шейперов и NAT. а откуда взялась мысль что загрузка из за ОSPF ??? Ты ТП микротика больше слушай ))На НАСе правила фаервола, шейпинга есть ?? Лично у меня мысль что NAT c conntrack + queue основную нагрузку создают. Про сказки из ТП микротика с друдом верится.firewall не большой, ~40 правил + парядка 50 в mangle для разметки трафика и дальнейшего ограничения скорости в queue tree. P.S. агрегатор не дохнет от ospf потому что cisco:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 4 марта, 2010 (изменено) · Жалоба ООО ))) а вот и проблемка решилась ))) NAT + conntrack + mangle + queue tree + filter + вот тебе и все составляющие твоих тормозов, так что сказочникам привет )) Там небось еще и queue tree неправильно режет трафик в такие моменты ?? ))) А OSPF ставь в покое, он тут не при чем. Изменено 4 марта, 2010 пользователем martini Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 4 марта, 2010 · Жалоба 1. Теряется отаказоустойчивость и прекрасное свойство PPPoE балансировать нагрузку между NAS.2. пункт 1. Разрешите поинтересоваться - а с какого перепугу первое. Ну и второе несколько не связано с первым.3. Сейчас хочу попробовать отдать агрегатору еще и серые адреса, что бы пиринговый трафик ходил мимо шейперов и NAT.Имеется ввиду в обход NASа? Илии пропустить сквозь NAS серые без ната для пиринга?P.S. агрегатор не дохнет от ospf потому что cisco:)У нас агрегатор dlink, посему мы боролись за то что бы на него не сильно много маршрутов выплескивалось ООО ))) а вот и проблемка решилась )))NAT + conntrack + mangle + queue tree + filter + вот тебе и все составляющие твоих тормозов, так что сказочникам привет )) Там небось еще и queue tree неправильно режет трафик в такие моменты ?? ))) А OSPF ставь в покое, он тут не при чем. Ну тут для пущей ясности надо бы конфигурацию железа узнать + вводные по софту, а так же каково загрузка проца во время пиковых нагрузок... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 4 марта, 2010 · Жалоба да не трогайте вы агрегацию )) а может у него ИП глобально разбросаны по НАСам.. и нельзя ничё сагрегировать )И еще пару вопросов по НАСу - каличество абонентов и трафик на интерфейсе к агрегатору какие (во время большрй загрузки сервера)?? И что за железо то хоть ?? да и версию софта не мешало бы узать Intel S3210SHLC + Intel Core2Duo 3Ghz + 1G RAMM + USB flash Использую две интегрированные серевые: одна к агрегатору, вторая к пользователям. В пиках сейчас 800-850 коннектов, 250Mbit в обе стороны, пакетов 45-50kpps, ошибок до 200/с на аплинке, проц до 70 процентов (но скорее всего опять проц на половину используется, т.к. mikrotik напроч не умеет многоядерность/многопроцессорность). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 4 марта, 2010 (изменено) · Жалоба да не трогайте вы агрегацию )) а может у него ИП глобально разбросаны по НАСам.. и нельзя ничё сагрегировать )Даже если не агрегируется, то что? - 700 клиентов = 700 маршрутов /32 в таблице маршрутизации NASа... Т.е. OSPF там или RIP - пох... 700 маршрутов есть 700 маршрутов...А вот если NAS стоит вместе с соседом в одной арии, то соседских 700 маршрутов тоже приедут на первых NAS. - А нах они там нужны? Насколько я понимаю на агрегации L3-я кошка, можно было бы через дефолт между NASами инфой обмениваться, а не по прямой. Изменено 4 марта, 2010 пользователем Jugernault Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 4 марта, 2010 · Жалоба у тебя потолок уже, дальше дропов еще больше будет. Отгружай половину юзеров на другую тачку, и желательно хотябы НАТ убрать с НАСа, кстати, TCP mss на каждого свое ? ) 2 Jugernault - правильно говоришь, через дефолт лучше НАСам связываться, чем обрабатывать еще и соседские маршруты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 4 марта, 2010 · Жалоба 1. Теряется отаказоустойчивость и прекрасное свойство PPPoE балансировать нагрузку между NAS.2. пункт 1. Разрешите поинтересоваться - а с какого перепугу первое. Ну и второе несколько не связано с первым.3. Сейчас хочу попробовать отдать агрегатору еще и серые адреса, что бы пиринговый трафик ходил мимо шейперов и NAT.Имеется ввиду в обход NASа? Илии пропустить сквозь NAS серые без ната для пиринга?P.S. агрегатор не дохнет от ospf потому что cisco:)У нас агрегатор dlink, посему мы боролись за то что бы на него не сильно много маршрутов выплескивалось делим на две зоны, на каждую своя подсеть /24. падает один NAS - куда денутся пользователи из этой зоны со своими статическими реальниками? на NAS соседней зоны? так у него же другая подсеть. собственно таже история и при балансировке - пользователь жестко привязан к NAS за который зароучен. не вариант. В обход NAT и queue tree. ООО ))) а вот и проблемка решилась )))NAT + conntrack + mangle + queue tree + filter + вот тебе и все составляющие твоих тормозов, так что сказочникам привет )) Там небось еще и queue tree неправильно режет трафик в такие моменты ?? ))) А OSPF ставь в покое, он тут не при чем. Да, queue tree переодически подводят при пиковой нагрузке. Виной тому mangle или сами queue tree? P.S. RouterOS 4.6 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 4 марта, 2010 · Жалоба Использую две интегрированные серевые: одна к агрегатору, вторая к пользователям.А вот с этого места подробней - что за сетевки?В пиках сейчас 800-850 коннектов, 250Mbit в обе стороны, пакетов 45-50kpps, ошибок до 200/с на аплинке, проц до 70 процентов (но скорее всего опять проц на половину используется, т.к. mikrotik напроч не умеет многоядерность/многопроцессорность).Intel® Core2 CPU 6300 @ 1.86GHz больше пережевывает, правда под Центосом... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 4 марта, 2010 (изменено) · Жалоба у тебя потолок уже, дальше дропов еще больше будет. Отгружай половину юзеров на другую тачку, и желательно хотябы НАТ убрать с НАСа, кстати, TCP mss на каждого свое ? ) 2 Jugernault - правильно говоришь, через дефолт лучше НАСам связываться, чем обрабатывать еще и соседские маршруты. tcpmss - одной строчкой.относить NAT на отдельный такой же сервак - смысла не вижу. Поискал на форуме, народ пишет что с подобной железки под NAT можно выжать порядка 150kpps - получается 3 NAS конфигурации как сейчас. Добавим к NAT серверу два NAS с pppoe и queue и получаем шило на мыло. Те же три сервака + хуже отказоустойчивость при выходе из строя NAT т.к. он не резервируется. а есть возможность принимать только дефолт и отдавать свои роуты только агрегатору? Изменено 4 марта, 2010 пользователем kostil Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 4 марта, 2010 · Жалоба делим на две зоны, на каждую своя подсеть /24. падает один NAS - куда денутся пользователи из этой зоны со своими статическими реальниками? на NAS соседней зоны? так у него же другая подсеть. собственно таже история и при балансировке - пользователь жестко привязан к NAS за который зароучен. не вариант.Вы первое со вторым спутали. В первом я говорил о том, что в рамках одной NSSA арии надо оставлять один NAS. При этом Вы можете продолжать анонсировать клиентскую белую коннектед статику в OSPF по /32. Но если у Вас два NASа в двух NSSA ариях, то они не будут ничего знать о клиентских маршрутах друг друга.Т.е. в идеале у Вас на NASе будет N+3 маршрута, где N-число онлайн клиентов pppoe. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostil Опубликовано 4 марта, 2010 · Жалоба А вот с этого места подробней - что за сетевки?Intel® Core2 CPU 6300 @ 1.86GHz больше пережевывает, правда под Центосом... Сетевки 82566DM-2 и 82541GI, причем первая похоже PCI 32Bit. Пробовал все пускать через одну сетевую, которая на PCIe - хуже, дропов больше. Смотря под какие задачи. Вы первое со вторым спутали. В первом я говорил о том, что в рамках одной NSSA арии надо оставлять один NAS. При этом Вы можете продолжать анонсировать клиентскую белую коннектед статику в OSPF по /32. Но если у Вас два NASа в двух NSSA ариях, то они не будут ничего знать о клиентских маршрутах друг друга.Т.е. в идеале у Вас на NASе будет N+3 маршрута, где N-число онлайн клиентов pppoe. Циска еще в статье своей предупреждает что нельзя много area делать на один агрегатор. Сколько много правда не указано. К примеру на одном из узлов у меня 10 NAS. Агрегатору не поплохеет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...