Jump to content
Калькуляторы

PPPoE NAS vs OSPF NSSA Оптимизация динамической маршрутизации для PPPoE

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

 

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

 

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

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

            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

 

выводы...

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Вечер добрый.

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

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

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

Edited by Jugernault

Share this post


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

 

Share this post


Link to post
Share on other sites

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

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

Edited by martini

Share this post


Link to post
Share on other sites
В кратце: сеть разделена на несколько зон. В каждой зоне 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 by Jugernault

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
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:)

Share this post


Link to post
Share on other sites

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

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

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

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

Edited by martini

Share this post


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

2. пункт 1.

Разрешите поинтересоваться - а с какого перепугу первое. Ну и второе несколько не связано с первым.
3. Сейчас хочу попробовать отдать агрегатору еще и серые адреса, что бы пиринговый трафик ходил мимо шейперов и NAT.
Имеется ввиду в обход NASа? Илии пропустить сквозь NAS серые без ната для пиринга?
P.S. агрегатор не дохнет от ospf потому что cisco:)
У нас агрегатор dlink, посему мы боролись за то что бы на него не сильно много маршрутов выплескивалось

 

 

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

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

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

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

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

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites
да не трогайте вы агрегацию )) а может у него ИП глобально разбросаны по НАСам.. и нельзя ничё сагрегировать )
Даже если не агрегируется, то что? - 700 клиентов = 700 маршрутов /32 в таблице маршрутизации NASа... Т.е. OSPF там или RIP - пох... 700 маршрутов есть 700 маршрутов...

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

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

Edited by Jugernault

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
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

 

 

Share this post


Link to post
Share on other sites
Использую две интегрированные серевые: одна к агрегатору, вторая к пользователям.
А вот с этого места подробней - что за сетевки?
В пиках сейчас 800-850 коннектов, 250Mbit в обе стороны, пакетов 45-50kpps, ошибок до 200/с на аплинке, проц до 70 процентов (но скорее всего опять проц на половину используется, т.к. mikrotik напроч не умеет многоядерность/многопроцессорность).
Intel® Core™2 CPU 6300 @ 1.86GHz больше пережевывает, правда под Центосом...

 

Share this post


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

 

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

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

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

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

Edited by kostil

Share this post


Link to post
Share on other sites
делим на две зоны, на каждую своя подсеть /24. падает один NAS - куда денутся пользователи из этой зоны со своими статическими реальниками? на NAS соседней зоны? так у него же другая подсеть. собственно таже история и при балансировке - пользователь жестко привязан к NAS за который зароучен. не вариант.
Вы первое со вторым спутали. В первом я говорил о том, что в рамках одной NSSA арии надо оставлять один NAS. При этом Вы можете продолжать анонсировать клиентскую белую коннектед статику в OSPF по /32. Но если у Вас два NASа в двух NSSA ариях, то они не будут ничего знать о клиентских маршрутах друг друга.

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

Share this post


Link to post
Share on other sites
А вот с этого места подробней - что за сетевки?

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. Агрегатору не поплохеет?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this