[kostil]

Вечер добрый.

 

Пользую Mikrotik для терминации PPPoE. У каждого пользователя статический адрес. Для части пользователей, имеющих реальные ip-адреса использую OSPF NSSA как описывает cisco. Сталкнулся с большой загрузкой сервера при относительно не большом трафике. ТП mikrotik'а сказала что нужно изменить схему маршрутизации, избавиться от роутов /32, т.к. OSPF создает большую нагрузку на NAS. Сейчас имею два NAS mikrotik до 1000 коннектов на каждый и циску в роли ABR. Соответственно в LSDB в среднем 1000-1300 записей.

 

Поделитесь опытом как можно оптимизировать данную схему? Может подскажете менее ресурсоемкую схему?

 

[martin74]

а почему не RIP для впн роутов?

[darkagent]

у вас раздача идет по какой то шаманской схеме, или на каждый нас свой пул адресов, представляющий из себя сетку с определенной маской? ежели второе - поковыряйте на возможность суммаризации адресов. при изначально хорошем проектировании все сводится к максимум 2-3 роутам с какими нибудь масками /21,/22,/23,/24 и т.п.

 

а почему не RIP для впн роутов?

а смысл? ospf хотя бы не раз в 30 секунд штурмует таблицу маршрутов, а если их там под 1000х/32, rip изрядно даст прикурить.

Edited March 4, 2010 by darkagent

[martin74]

ну у меня 5к на 14 насов. и? наоборот, после отказа от ospf в сети впн серверов нагрузка на них упала. RIP по моему самый легкий протокол маршрутизации

[darkagent]

видимо что то делаете не так. после перехода с ripv2 на ospf - очень хорошо разгрузились маршрутизаторы. правда у нас и маршрутов в разы поболее будет, rip с ними помирал...

[martin74]

я во всей сети использую ospf. rip крутится только на сети впн серверов. Все живет на DGS-3627G

[mousus]

            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

 

выводы...

[darkagent]

фулвью вниз на брасы? или фулвью только на бордере, а дальше уже дефолт?

имхо первый вариант бесмысленен..

[mousus]

да вот за всей бессмысленностью и тяжестью как раз в своё время этот первый вариант и применялся, посмотреть как вырастет нагрузка ---- брасы как были холодные так и остались не сильно нагревшись

[Jugernault]

Вечер добрый.

Пользую Mikrotik для терминации PPPoE. У каждого пользователя статический адрес. Для части пользователей, имеющих реальные ip-адреса использую OSPF NSSA как описывает cisco. Сталкнулся с большой загрузкой сервера при относительно не большом трафике. ТП mikrotik'а сказала что нужно изменить схему маршрутизации, избавиться от роутов /32, т.к. OSPF создает большую нагрузку на NAS. Сейчас имею два NAS mikrotik до 1000 коннектов на каждый и циску в роли ABR. Соответственно в LSDB в среднем 1000-1300 записей.

Т.е. грузятся именно микротики? - не агрегатор?

Сдается мне что протокол маршрутизации тут не очень при делах. При наличии 500 рррое сессий по любому в таблице маршрутизации будет 500 маршрутов /32. А уж при помощи какого протокола маршрутная информация попадет на агрегатор это уже другая песня.

Edited March 4, 2010 by Jugernault

[kostil]

у вас раздача идет по какой то шаманской схеме, или на каждый нас свой пул адресов, представляющий из себя сетку с определенной маской? ежели второе - поковыряйте на возможность суммаризации адресов. при изначально хорошем проектировании все сводится к максимум 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.

 

[martini]

а откуда взялась мысль что загрузка из за ОSPF ??? Ты ТП микротика больше слушай ))

На НАСе правила фаервола, шейпинга есть ??

Edited March 4, 2010 by martini

[Jugernault]

В кратце: сеть разделена на несколько зон. В каждой зоне 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 ??? Ты ТП микротика больше слушай ))

На НАСе правила фаервола, шейпинга есть ??

Вооот... а я о чем говорю... :) - не похоже что нагрузка от маршрутизации. Если бы было все действительно плохо, то первым делом агрегатор офигел бы.

Edited March 4, 2010 by Jugernault

[martini]

да не трогайте вы агрегацию )) а может у него ИП глобально разбросаны по НАСам.. и нельзя ничё сагрегировать )

И еще пару вопросов по НАСу - каличество абонентов и трафик на интерфейсе к агрегатору какие (во время большрй загрузки сервера)?? И что за железо то хоть ?? да и версию софта не мешало бы узать

[kostil]

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:)

[martini]

ООО ))) а вот и проблемка решилась )))

NAT + conntrack + mangle + queue tree + filter + вот тебе и все составляющие твоих тормозов, так что сказочникам привет ))

Там небось еще и queue tree неправильно режет трафик в такие моменты ?? )))

А OSPF ставь в покое, он тут не при чем.

Edited March 4, 2010 by martini

[Jugernault]

1. Теряется отаказоустойчивость и прекрасное свойство PPPoE балансировать нагрузку между NAS.

2. пункт 1.

Разрешите поинтересоваться - а с какого перепугу первое. Ну и второе несколько не связано с первым.

3. Сейчас хочу попробовать отдать агрегатору еще и серые адреса, что бы пиринговый трафик ходил мимо шейперов и NAT.

Имеется ввиду в обход NASа? Илии пропустить сквозь NAS серые без ната для пиринга?

P.S. агрегатор не дохнет от ospf потому что cisco:)

У нас агрегатор dlink, посему мы боролись за то что бы на него не сильно много маршрутов выплескивалось

 

 

ООО ))) а вот и проблемка решилась )))

NAT + conntrack + mangle + queue tree + filter + вот тебе и все составляющие твоих тормозов, так что сказочникам привет ))

Там небось еще и queue tree неправильно режет трафик в такие моменты ?? )))

А OSPF ставь в покое, он тут не при чем.

Ну тут для пущей ясности надо бы конфигурацию железа узнать + вводные по софту, а так же каково загрузка проца во время пиковых нагрузок...

[kostil]

да не трогайте вы агрегацию )) а может у него ИП глобально разбросаны по НАСам.. и нельзя ничё сагрегировать )

И еще пару вопросов по НАСу - каличество абонентов и трафик на интерфейсе к агрегатору какие (во время большрй загрузки сервера)?? И что за железо то хоть ?? да и версию софта не мешало бы узать

Intel S3210SHLC + Intel Core2Duo 3Ghz + 1G RAMM + USB flash

Использую две интегрированные серевые: одна к агрегатору, вторая к пользователям. В пиках сейчас 800-850 коннектов, 250Mbit в обе стороны, пакетов 45-50kpps, ошибок до 200/с на аплинке, проц до 70 процентов (но скорее всего опять проц на половину используется, т.к. mikrotik напроч не умеет многоядерность/многопроцессорность).

[Jugernault]

да не трогайте вы агрегацию )) а может у него ИП глобально разбросаны по НАСам.. и нельзя ничё сагрегировать )

Даже если не агрегируется, то что? - 700 клиентов = 700 маршрутов /32 в таблице маршрутизации NASа... Т.е. OSPF там или RIP - пох... 700 маршрутов есть 700 маршрутов...

А вот если NAS стоит вместе с соседом в одной арии, то соседских 700 маршрутов тоже приедут на первых NAS. - А нах они там нужны?

Насколько я понимаю на агрегации L3-я кошка, можно было бы через дефолт между NASами инфой обмениваться, а не по прямой.

Edited March 4, 2010 by Jugernault

[martini]

у тебя потолок уже, дальше дропов еще больше будет. Отгружай половину юзеров на другую тачку, и желательно хотябы НАТ убрать с НАСа, кстати, TCP mss на каждого свое ? )

 

2 Jugernault - правильно говоришь, через дефолт лучше НАСам связываться, чем обрабатывать еще и соседские маршруты.

[kostil]

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

 

 

[Jugernault]

Использую две интегрированные серевые: одна к агрегатору, вторая к пользователям.

А вот с этого места подробней - что за сетевки?

В пиках сейчас 800-850 коннектов, 250Mbit в обе стороны, пакетов 45-50kpps, ошибок до 200/с на аплинке, проц до 70 процентов (но скорее всего опять проц на половину используется, т.к. mikrotik напроч не умеет многоядерность/многопроцессорность).

Intel® Core™2 CPU 6300 @ 1.86GHz больше пережевывает, правда под Центосом...

 

[kostil]

у тебя потолок уже, дальше дропов еще больше будет. Отгружай половину юзеров на другую тачку, и желательно хотябы НАТ убрать с НАСа, кстати, TCP mss на каждого свое ? )

 

2 Jugernault - правильно говоришь, через дефолт лучше НАСам связываться, чем обрабатывать еще и соседские маршруты.

tcpmss - одной строчкой.

относить NAT на отдельный такой же сервак - смысла не вижу. Поискал на форуме, народ пишет что с подобной железки под NAT можно выжать порядка 150kpps - получается 3 NAS конфигурации как сейчас. Добавим к NAT серверу два NAS с pppoe и queue и получаем шило на мыло. Те же три сервака + хуже отказоустойчивость при выходе из строя NAT т.к. он не резервируется.

а есть возможность принимать только дефолт и отдавать свои роуты только агрегатору?

Edited March 4, 2010 by kostil

[Jugernault]

делим на две зоны, на каждую своя подсеть /24. падает один NAS - куда денутся пользователи из этой зоны со своими статическими реальниками? на NAS соседней зоны? так у него же другая подсеть. собственно таже история и при балансировке - пользователь жестко привязан к NAS за который зароучен. не вариант.

Вы первое со вторым спутали. В первом я говорил о том, что в рамках одной NSSA арии надо оставлять один NAS. При этом Вы можете продолжать анонсировать клиентскую белую коннектед статику в OSPF по /32. Но если у Вас два NASа в двух NSSA ариях, то они не будут ничего знать о клиентских маршрутах друг друга.

Т.е. в идеале у Вас на NASе будет N+3 маршрута, где N-число онлайн клиентов pppoe.

[kostil]

А вот с этого места подробней - что за сетевки?

Intel® Core™2 CPU 6300 @ 1.86GHz больше пережевывает, правда под Центосом...

Сетевки 82566DM-2 и 82541GI, причем первая похоже PCI 32Bit. Пробовал все пускать через одну сетевую, которая на PCIe - хуже, дропов больше.

 

Смотря под какие задачи.

 

Вы первое со вторым спутали. В первом я говорил о том, что в рамках одной NSSA арии надо оставлять один NAS. При этом Вы можете продолжать анонсировать клиентскую белую коннектед статику в OSPF по /32. Но если у Вас два NASа в двух NSSA ариях, то они не будут ничего знать о клиентских маршрутах друг друга.

Т.е. в идеале у Вас на NASе будет N+3 маршрута, где N-число онлайн клиентов pppoe.

Циска еще в статье своей предупреждает что нельзя много area делать на один агрегатор. Сколько много правда не указано. К примеру на одном из узлов у меня 10 NAS. Агрегатору не поплохеет?