Jump to content

ospfd грузит сервера


Recommended Posts

Запостил такую тему на НАГе, продублирую и тут.

 

Схема сети - бордер на c3750G, в него включены 3 linux NAS'a терминирующих pppoe. Всем клиентам даются белые адреса, между NAS'aми и каталистом поднят ospf.

Собственно после перевода сети с серых IP на белые начал замечать аномально высокую загрузку серверов, раньше грешили на NAT, но он исчез а загрузка нет :lol:

 

В час пик на каждом сервере ~700 ppp сессий, и 400-500мбит дуплексного трафика. Простой фаервол + шейпинг с хешами для небольшой части клиентов + ospf, больше ничего тяжелого нет.

В обычной ситуации загрузка ядер 5% днем, и 10-15% в час пик - для quad Q9450 и трафика до 500мбит нормальные цифры. А вот в момент когда начинаются чудеса загрузка рывком подскакивает до 50-60%, держится так минуту-другую и возвращается к норме на минуту, и опять скачек-норма. Никаких аномалий в эти моменты не нашел, трафик бежит тот же, pps тот же, все без изменений кроме загрузки.

Пробовал косить фаервол, отключал шейперы - загрузка немного уменьшается, но сама картина не меняется, раз в минуту загрузка прыгает с 10 до 50%.

 

А вот если сделать zebra stop - все приходит в норму и скачки исчезают. Сервер получается в замороженном состоянии относительно маршрутов, но подключенные клиенты работают, бегает тот же трафик, а загрузки нет. Куда копать? Время везде выставлено точно, кваггу обновил до 0.99.17 - фиолетово, конфиги везде простейшие в 3 строчки..

Link to post
Share on other sites

Пока не опубликуете текст конфига со стороны бордера и со стороны аксесс сервера, никто не двинется.

Также покажите sh ip rou osp, sh ip osp nei

Желательтельно получить листинг в момент "лага"

Link to post
Share on other sites

xx.xx.xx.21,22,23 - NAS'ы, xx.xx.xx.30 - бордер.

C серверов доступа:

 

zebra.conf:

hostname nas1.xxx

log file /var/log/quagga/zebra.log

!

interface eth0.2

multicast

!

line vty

exec-timeout 30 0

!

ospfd.conf:

hostname nas1-ospf.xxx

log file /var/log/quagga/ospfd.log

!

interface eth0.2

!

router ospf

ospf router-id xx.xx.xx.21

redistribute connected route-map ospf

passive-interface default

no passive-interface eth0.2

network xx.xx.xx.21/28 area 0.0.0.1

!

access-list 10 permit xx.xx.xx.0 0.0.0.255

access-list 10 permit yy.yy.yy.0 0.0.1.255

access-list 10 permit zz.zz.zz.0 0.0.31.255

access-list 10 deny any

!

route-map ospf permit 1

match ip address 10

!

line vty

exec-timeout 30 0

!

 

 

sh ip ospf route:

============ OSPF network routing table ============

N xx.xx.xx.16/28 [10] area: 0.0.0.1

directly attached to eth0.2

 

============ OSPF router routing table =============

R xx.xx.xx.22 [10] area: 0.0.0.1, ASBR

via xx.xx.xx.22, eth0.2

R xx.xx.xx.23 [10] area: 0.0.0.1, ASBR

via xx.xx.xx.23, eth0.2

 

============ OSPF external routing table ===========

.. тут куча маршрутов, все верные

 

sh ip osp nei:

Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL

xx.xx.xx.22 1 2-Way/DROther 33.393s xx.xx.xx.22 eth0.2:xx.xx.xx.21 0 0 0

xx.xx.xx.23 1 Full/Backup 30.939s xx.xx.xx.23 eth0.2:xx.xx.xx.21 0 0 0

xx.xx.xx.30 1 Full/DR 36.213s xx.xx.xx.30 eth0.2:xx.xx.xx.21 0 0 0

 

А вот с бордера:

 

config:

router ospf 100

router-id xx.xx.xx.30

log-adjacency-changes

passive-interface default

no passive-interface Vlan2

network xx.xx.xx.16 0.0.0.15 area 1

distribute-list 1 in

!

access-list 1 permit xx.xx.xx.0 0.0.0.255

access-list 1 permit yy.yy.yy.0 0.0.1.255

access-list 1 permit zz.zz.zz.0 0.0.31.255

access-list 1 deny any

 

sh ip ospf neighbor:

Neighbor ID Pri State Dead Time Address Interface

xx.xx.xx.21 1 FULL/DROTHER 00:00:38 xx.xx.xx.21 Vlan2

xx.xx.xx.22 1 FULL/DROTHER 00:00:38 xx.xx.xx.22 Vlan2

xx.xx.xx.23 1 FULL/BDR 00:00:38 xx.xx.xx.23 Vlan2

 

sh ip route ospf и на бордере и на НАСах дает нормальный список маршрутов(>1k записей), список одинаков и верен.

 

Подобные тормоза происходят практически постоянно, 30 секунд лагает, минуту нет. Иногда 5 минут не лагает, какой-либо системы не заметил. Проверял в такие моменты - трафик/pps/число маршрутов без изменений, а загрузка в 5 раз выше.

Link to post
Share on other sites

1k для OSPF это уже достаточно дофига. или выбирайте другой протокол(EIGRP или IS-IS к примеру) или настраивайте правильное суммирование.

Link to post
Share on other sites

Вечером и >2к бывает, клиентов достаточно много.. Попробую как самое простое решение на RIP2 перейти.

Link to post
Share on other sites

Дык проблемы то начинаются не у циски, а как раз у 'бессмертных' серверов. Хочу разобраться, почему так..

Разве bgp не еще более тяжелый протокол?

Link to post
Share on other sites

Дык проблемы то начинаются не у циски, а как раз у 'бессмертных' серверов. Хочу разобраться, почему так..

Разве bgp не еще более тяжелый протокол?

BGP сейчас спокойно работает у всех и обслуживает весь интернет, это около 300k префиксов.

RIP не лучшее решение, смотрите в сторону IS IS или EIGRP или BGP, но BGP из них самый медленный с дефолтными таймерами.

RIP считайте уже умер

Link to post
Share on other sites

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

 

Ну так может дело как раз и в LSA? Ну а кроме того что вы зрительно видите увеличение загрузки, эта загрузка как то чувствуется? Что говорит лог зебры?

 

Вы сказали что после ухода с НАТ начались "чудеса", но раньше грешили на НАТ. Так всетаки была загрузка при НАТ или появилась при переходе на роутинг?

Link to post
Share on other sites

Ну так может дело как раз и в LSA? Ну а кроме того что вы зрительно видите увеличение загрузки, эта загрузка как то чувствуется? Что говорит лог зебры?

 

Вы сказали что после ухода с НАТ начались "чудеса", но раньше грешили на НАТ. Так всетаки была загрузка при НАТ или появилась при переходе на роутинг?

Сложный вопрос, аномальные скачки загрузки заметили как раз после избавления от НАТа, раньше думали что так и должно быть) Да и скачки с ним были менее заметны, с 50% до 70% можно списать на что угодно, а вот с 10 до 50 как сейчас уже нет.

 

Как-то можно теста ради запретить роутеру прием LSA-сообщений? По большому счету важно только что б маршруты были переданы на бордер, между собой пусть через ту же циску бегают. В циске нашел фильтрацию distribute-list in, а в квагге такого нет, роут-мапы фильтруют только рассылку маршрутов.

Link to post
Share on other sites

Как-то можно теста ради запретить роутеру прием LSA-сообщений? По большому счету важно только что б маршруты были переданы на бордер, между собой пусть через ту же циску бегают. В циске нашел фильтрацию distribute-list in, а в квагге такого нет, роут-мапы фильтруют только рассылку маршрутов.

Насколько я понимаю, Вы редистрибьютите в OSPF каждого кастомера по /32? - Зачем?

В идеале каждый сервер должен нести свой пул (пулы) адресов, которые бы редистрибьютился в OSPF одним(несколькими) префиксами.

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

 

p.s. у нас по похожей схеме работает - по 2500-3000 кастомеров на сервер несет без проблем.

Link to post
Share on other sites

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

Пробовал сделать 3 независимые зоны ospf, но слишком уж это получается нетривиально - не взлетело нормально.

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
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...