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

Quagga (zebra) и производительность CPU Quagga (zebra) и производительность CPU

Доброго времени суток.

Подскажите, пожалуйста, касательно производительности квагги на пограничном маршрутизаторе.

Имеется пограничный маршрутизатор на HP + Debian Squeeze + Quagga. Абоненты подключаются к Интернету через ПППоЕ (4 NAS), в Интеренет пакеты рулятся статикой (статический маршрут на насах к бордеру и дефаулт на бордере к шлюзу нашего магистрального провайдера), а вот обратно по оспф, наружу магистральному провайдеру, сабнеты анонсируются по бгп. Проблема в том, что при достижении кол-ва маршрутов >= 3000 квагга практически "ложит" цпу, нагрузка обоих ядер стабильно держится в районе 100%. Как следствие теряются пакеты, начинаются проблемы со скоростью и даже на ssh рутер отвечает с трудом. Помогает рестар квагги и ip router flush cache. Сейчас по крону рестартую кваггу и сбрасываю кэш каждые 60 минут. Естественно проблемы начинаются под вечер, когда онлайн больше всего узеров. Пока кол-во маршрутов не достигнет 3000, все работает вполне не плохо. Демон из бэкпортов обновлял до версии 0.99.20.1. В ЧНН рутер переваривает около 2.5 Гбит/с трафика. Я понимаю, что сервер с квагой не самый подходящий вариант для такой схемы, но пока приходится работать с тем, что есть. Есть ли возможность как то улучшить ситуацию?

Конфиги квагги:

 

! Zebra configuration saved from vty
!   2012/12/06 21:52:25
!
hostname RetnGate
password mypassword
enable password mypassword
log file /var/log/quagga/zebra.log
!
interface eth0
no ipv6 nd suppress-ra
!
interface eth1
no ipv6 nd suppress-ra
!
interface eth2
no ipv6 nd suppress-ra
!
interface eth3
no ipv6 nd suppress-ra
!
interface eth3.40
no ipv6 nd suppress-ra
!
interface lo
!
ip forwarding
!
!
line vty

 

!
! Zebra configuration saved from vty
!   2013/07/26 15:22:19
!
hostname RetnGate
password mypassword
enable password mypassword
log file /var/log/quagga/ospfd.log
!
!
!
!interface eth0
!
!interface eth1
!
!interface eth2
!
interface eth3
!
interface lo
!
router ospf
ospf router-id 10.0.0.13
network 10.0.0.0/28 area 0.0.0.10
!
line vty
!

 

!

! Zebra configuration saved from vty

! 2012/12/02 08:24:30

!

hostname BorderRouter

password mypassword

enable password mypassword

log file /var/log/quagga/bgpd.log

!

router bgp NNNNN

bgp router-id AA.AAA.AAA.AAA

network XX.XXX.XX.0/20

network XX.XXX.XX.0/24

network XX.XXX.XX.0/24

network XX.XXX.XX.0/24

neighbor DD.DDD.DDD.DDD remote-as MMMMM

neighbor DD.DDD.DDD.DDD description RetnNet

neighbor DD.DDD.DDD.DDD soft-reconfiguration inbound

neighbor DD.DDD.DDD.DDD route-map RetnIn in

neighbor DD.DDD.DDD.DDD route-map RetnOut out

!

ip prefix-list TWSUBNET-RETN seq 10 permit XX.XXX.XX.0/20

ip prefix-list TWSUBNET-RETN seq 11 permit XX.XXX.XX.0/24

ip prefix-list TWSUBNET-RETN seq 12 permit XX.XXX.XX.0/24

ip prefix-list TWSUBNET-RETN seq 13 permit XX.XXX.XX.0/24

 

 

!

route-map RetnOut permit 10

match ip address prefix-list TWSUBNET-RETN

!

route-map RetnIn deny 100

!

line vty

!

 

CPU

root@RetnGate:/etc/quagga# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 58
model name	: Intel(R) Pentium(R) CPU G2120 @ 3.10GHz
stepping	: 9
cpu MHz		: 3092.986
cache size	: 3072 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt xsave lahf_lm arat tpr_shadow vnmi flexpriority ept vpid
bogomips	: 6185.97
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

X 4

Share this post


Link to post
Share on other sites

Рулите внутри по BGP либо RIP. OSPF плохо переносит частые смены маршрутов.

 

Лучше всего - перетащите временно на RIP (так проще), потом постепенно переезжайте на iBGP с кластером из двух router reflector-ов.

Share this post


Link to post
Share on other sites

Рулите внутри по BGP либо RIP. OSPF плохо переносит частые смены маршрутов.

 

Лучше всего - перетащите временно на RIP (так проще), потом постепенно переезжайте на iBGP с кластером из двух router reflector-ов.

 

Спасибо за ответ. Вопрос: не будет ли проблем, если я временно переведу роутинг внутри АС на RIP? Все-таки на бордер "прилетает" более 3000 маршрутов от

НАСов... С BGP и iBGP знаком пока очень плохо, так что быстро перейти на iBGP не получится.

Share this post


Link to post
Share on other sites

Рулите внутри по BGP либо RIP. OSPF плохо переносит частые смены маршрутов.

 

Лучше всего - перетащите временно на RIP (так проще), потом постепенно переезжайте на iBGP с кластером из двух router reflector-ов.

 

Спасибо за ответ. Вопрос: не будет ли проблем, если я временно переведу роутинг внутри АС на RIP? Все-таки на бордер "прилетает" более 3000 маршрутов от

НАСов... С BGP и iBGP знаком пока очень плохо, так что быстро перейти на iBGP не получится.

3000 маршрутов для RIP - это еще куда ни шло, потянет явно лучше, чем OSPF.

Кроме того, вы можете в будущем сократить количество маршрутов: разбейте в биллинге ваш пул адресов на части, скажем, на 4 /24 (по кол-ву NAS-ов), остальное - в остаток. Выдавайте каждому NAS-у сначала свою /24 и пусть он её прямо как /24 и анонсирует. Остальное "поверху" уже будет по /32. Не обязательно так, но идея, я думаю, Вам понятна.

Share this post


Link to post
Share on other sites

С BGP и iBGP знаком пока очень плохо, так что быстро перейти на iBGP не получится.

Да там все предельно просто. У меня 3 nas (cisco,accel,mpd) и nat, и ничего - работают под кваггой, не напрягая процессор...

Share this post


Link to post
Share on other sites

У меня сейчас по RIP около 4к маршрутов с NASов на бордер улетает, работает как часы с нулевой загрузкой(та же quagga). OSPF сдох с похожими на ваши симптомами где-то на 1.5-2к

Edited by kayot

Share this post


Link to post
Share on other sites

Не знаю почему, но примерно похожая конфигурация и с оспф, проц не ложит. 7 Accel-ppp ~11к маршрутов. Комп: 8 ядер 3GHz, nat, часть в NOTRACK, 5 Gbit.

Share this post


Link to post
Share on other sites

Не знаю почему, но примерно похожая конфигурация и с оспф, проц не ложит. 7 Accel-ppp ~11к маршрутов. Комп: 8 ядер 3GHz, nat, часть в NOTRACK, 5 Gbit.

плюсую

тоже 10-11к маршрутов на оспф.... все работает

Share this post


Link to post
Share on other sites

плюсую

тоже 10-11к маршрутов на оспф.... все работает

Нифига себе. А часто меняются?

 

Здесь вот в чем дело: OSPF - это link-state протокол. Он не передает маршруты. Он передает состояния линков, на основе которых каждый хост строит свою таблицу маршрутизации. Каждое изменение вызывает перестройку всей базы, из-за чего, собственно, и случаются описанные здесь проблемы.

 

Какой вывод? А такой: OSPF хорош для организации большой разветвленной сети с филиалами, транзитами, блекджеком и пачками подсетей. Для передачи маршрутов BRAS <-> Border он не предназначен, здесь лучше подходит RIP либо BGP - по вкусу.

Share this post


Link to post
Share on other sites

плюсую

тоже 10-11к маршрутов на оспф.... все работает

Нифига себе. А часто меняются?

ну меняются при переподключении абонентов ...

Здесь вот в чем дело: OSPF - это link-state протокол. Он не передает маршруты. Он передает состояния линков, на основе которых каждый хост строит свою таблицу маршрутизации. Каждое изменение вызывает перестройку всей базы, из-за чего, собственно, и случаются описанные здесь проблемы.

ну как бы то тут америка не открыта и все кто в теме это знают я думаю ....

Какой вывод? А такой: OSPF хорош для организации большой разветвленной сети с филиалами, транзитами, блекджеком и пачками подсетей. Для передачи маршрутов BRAS <-> Border он не предназначен, здесь лучше подходит RIP либо BGP - по вкусу.

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

если буду менять то скорее всего на рип. больше всякого барахла недорого поддерживает его

Share this post


Link to post
Share on other sites

Думаю у автора другая проблема м.б.

Я с подобным сталкивался, когда на сервере добавляется или удаляется интерфейс (пусть даже виртуальный), сервер перестраивает всю таблицу маршрутизации. И если это FV (т.е. почти 500К маршрутов), то процу становится не очень хорошо при частом изменении интерфейсов, что и происходит на брасе. В свое время из-за этого просто разделил бордер и брас - проблема отпала.

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