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

Ошибки в quagga

Работала quagga более года. Нареканий никаких не было.

В связи с появлением в мире АС длиной 6 цифр начались чудеса :(

Пришлось обновить версию кваги с 0.99.6 на 0.99.12.

 

Сейчас Платформа :

FreeBSD 7.0-RELEASE #0

bgpd version 0.99.12

 

После обновлений появились следующие ошибки:

BGPD

 

1. Самопроизвольное завершение работы bgpd

BGP: Received signal 11 at 1247090512 (si_addr 0x304d181c); aborting...

 

2. Я так понимаю, эту надпись выдает, когда этот нейбор не отдает анонсов ?

2009/07/07 09:43:54 BGP: x.x.x.x [Error] bgp_read_packet error: Operation timed out

Примечание: Этот нейбор резервный

 

3. Еще набор непонятных логов:

2009/07/01 13:22:11 BGP: buffer_flush_available: write error on fd 16: Connection reset by peer
2009/07/01 13:22:51 BGP: buffer_flush_available: write error on fd 16: Connection reset by peer
2009/07/01 13:23:25 BGP: buffer_flush_available: write error on fd 16: Broken pipe

 

ZEBRA

 

4. Вот такие маты пишет уже зебра. Что это ??

2009/06/04 22:25:36 ZEBRA: kernel_rtm_ipv4: 222.44.192.0/18: rtm_write() unexpectedly returned -4 for command RTM_DELETE
2009/06/04 22:25:36 ZEBRA: kernel_rtm_ipv4: 222.44.192.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
2009/06/04 22:25:36 ZEBRA: kernel_rtm_ipv4: 222.44.224.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
2009/06/04 22:25:36 ZEBRA: kernel_rtm_ipv4: 222.73.126.0/23: rtm_write() unexpectedly returned -4 for command RTM_DELETE
2009/06/04 22:25:36 ZEBRA: kernel_rtm_ipv4: 222.164.104.0/21: rtm_write() unexpectedly returned -4 for command RTM_DELETE
2009/06/04 22:25:36 ZEBRA: kernel_rtm_ipv4: 222.164.120.0/21: rtm_write() unexpectedly returned -4 for command RTM_DELETE
2009/06/04 22:30:47 ZEBRA: if_ioctl(SIOCGIFFLAGS) failed: Device not configured
2009/06/04 22:30:47 ZEBRA: Can't lookup mtu by ioctl(SIOCGIFMTU)

 

Кто сталкивался с такими ошибками, подскажите, из-за чего они возникают :(

Edited by HEDG

Share this post


Link to post
Share on other sites

1. Обновите операционку, 7.0-RELEASE датируется, 26 Февраля 2008 года. (хотя бы до 7.2)

2. Очень похоже, что в целом проблема не в quagga, а в целом в файловой системе или настройках сетевых или опять же системных.

Share this post


Link to post
Share on other sites

аски 6-тициферные долбанули по рунету 3го мая.

пострадали многие, вплоть до MSK(SPB?)-IX роут серверов.

и проблема именно в квагге. либо пачтить либо обновлять.

http://www.google.ru/search?hl=ru&clie...mp;aq=f&oq=

Edited by Мартен

Share this post


Link to post
Share on other sites
аски 6-тициферные долбанули по рунету 3го мая.

пострадали многие, вплоть до MSX(SPB?)-IX роут серверов.

и проблема именно в квагге. либо пачтить либо обновлять.

http://www.google.ru/search?hl=ru&clie...mp;aq=f&oq=

У него как раз та версия, которая уже это умеет.

Share this post


Link to post
Share on other sites
1. Обновите операционку, 7.0-RELEASE датируется, 26 Февраля 2008 года. (хотя бы до 7.2)

2. Очень похоже, что в целом проблема не в quagga, а в целом в файловой системе или настройках сетевых или опять же системных.

1. боюсь операционка тут не причём.

2. полностью согласен. автор, уберите "тюнинг" усли есть, установите GENERIC ядро. (если заработает нормально - тогда конфиг ядра и "тюнинг" - на обозрение)

Share this post


Link to post
Share on other sites

К сожалению перегружать сервер нельзя :( .

Что делал по оптимизации, могу расписать.

 

sysctl.conf

###################
######   Формат записей " параметр=значение # значение по умолчанию "
# Запрет ответа при обращении на закрытые порты
net.inet.tcp.blackhole=2 # 0
net.inet.udp.blackhole=1 # 0

# Защита очереди от SYN атак
kern.ipc.somaxconn=1024 # 128

# запрет ридеректов
net.inet.icmp.drop_redirect=1 # 1
net.inet.icmp.log_redirect=1 # 1
net.inet.ip.redirect=0 # 1
#net.inet6.ip6.redirect=0 ipv6 disable in kernel

# Очистка таблицы ARP через .... секунд
net.link.ether.inet.max_age=1200 # 1200

# Запрет на "прощупывание" внутренней сети
net.inet.ip.sourceroute=0 # 0
net.inet.ip.accept_sourceroute=0 # 0

# Запрет ответа на широковещательный ECHO
net.inet.icmp.bmcastecho=0 # 0

# Запрет запроса маски адреса, запрет широковещательного запроса временного штампа (timestamp)
net.inet.icmp.maskrepl=0 # 0

# максимальное количество пакетов ICMP <<Недостижимо>>, а также количество отсылок TCP RST пакетов в секунду.
net.inet.icmp.icmplim=100 # 200

# определяет максимальное время жизни сегмента (Maximum Segment Life - MSL)
# Это максимальное количество времени ожидания ACK в ответ на SYN-ACK или FIN-ACK в миллисекундах
net.inet.tcp.msl=7500 # 30000

###################

# Увеличение размера буфера, для оптимизации при большом потоке данных HTTP FTP
net.inet.tcp.sendspace=32768 # 32768
net.inet.tcp.recvspace=65536 # 65536


# Не менять ttl при транзите пакетов
net.inet.ip.stealth=1 # 0

# Включение пуллинга
kern.polling.enable=1 # 0

# Установка значения ttl под Windows
net.inet.ip.ttl=128 # 64

 

Ядро - подрезаный Generic (убиты неиспользуемые устройства, а также INET6 и SCTP )

Добавлено:

## Pooling
options         HZ=2000
options         DEVICE_POLLING
## IPFW
options         DUMMYNET

options         IPFIREWALL
#options         IPDIVERT
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_FORWARD
options         IPFIREWALL_VERBOSE_LIMIT=200
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPSTEALTH
options         TCPDEBUG

 

P.S. А вообще проблемы появились после обновления кваги. До введения 6-тизначных АС и обновления кваги все было нормально.

Share this post


Link to post
Share on other sites

HEDG

Собери 0.99.13 из исходников, в новой версии эти ошибки уже исправлены.

 

Share this post


Link to post
Share on other sites
2arthurn Спасибо, попробую. напишу

Share this post


Link to post
Share on other sites

Можно поинтересоваться чем все закончилось?

у меня подобная проблема

[root@gate /usr/home/chip]# uname -a
FreeBSD gate.****** 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Wed May 12 18:44:34 EEST 2010     root@******:/usr/src/sys/i386/compile/GATE  i386
[root@gate /usr/home/chip]# zebra -v
zebra version 0.99.15

на нем Quagga BGP два провайдра, оба присылают мне полную таблицу машрутов, при отключении онтерфейса одно из провайдеров, в /var/log/messages валится куча сообщений типа

May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.252.0.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.64.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.96.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.128.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.160.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.192.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.224.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.254.128.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.254.160.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.254.192.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.254.224.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE

После двух - трех АпДаунов линка сервак уходит панику.

kernel_panic.jpg

в Гугле на эту тему не много информации.

Подскажите хоть куда копать. спасибо.

Share this post


Link to post
Share on other sites

наверное увеличить vm.kmem_size и vm.kmem_size_max

Share this post


Link to post
Share on other sites
наверное увеличить vm.kmem_size и vm.kmem_size_max

Сервак теперь не вылетает,

[root@gate /usr/home/chip]# sysctl -a | grep kmem
vm.kmem_size_scale: 3
vm.kmem_size_max: 419430400
vm.kmem_size_min: 0
vm.kmem_size: 419430400

хотя я не сильно увеличил vm.kmem_size_max, до этого он был что то типа ~335000000

 

А мессаги в лог по прежнему валятся с той же интенсивностью. может это дебаг режим зебры (хотя я его не включал), и его достаточно отключить? а то за одно отключение интерфейса 25 метров лог набегает.

 

Share this post


Link to post
Share on other sites

ищите ошибки в конфиге либо в системе

 

в исходниках вот чего написано:

 

/* Given that our NEXTHOP_FLAG_FIB matches real kernel FIB, it isn't

* normal to get any other messages in ANY case.

*/

case ZEBRA_ERR_RTNOEXIST:

case ZEBRA_ERR_RTUNREACH:

default:

 

 

т.е. либо маршрута нет уже (руками удалён либо ещё как)

либо ... маршрут недостижим чтоли, не понимаю чего это значит.

 

включите полный дебаг зебры и смотрите внимательно логи.

 

Share this post


Link to post
Share on other sites
на нем Quagga BGP два провайдра, оба присылают мне полную таблицу машрутов, при отключении онтерфейса одно из провайдеров, в /var/log/messages валится куча сообщений типа

May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.252.0.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.64.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE

простите, проглядел

 

отключается интерфейс как? и вообще зачем?

небось система маршруты херит и зебра понять не может чего произошло.

 

Share this post


Link to post
Share on other sites

>небось система маршруты херит и зебра понять не может чего произошло.

 

В этом случае возможно, поможет команда

link-detect

в настройках интерфейса(ов) в zebra

Share this post


Link to post
Share on other sites

Снефи фрю, поставь стабильный Debian - и quagga 16-ю из сырцов.

Share this post


Link to post
Share on other sites
на нем Quagga BGP два провайдра, оба присылают мне полную таблицу машрутов, при отключении онтерфейса одно из провайдеров, в /var/log/messages валится куча сообщений типа

May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.252.0.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 14 14:18:20 gate zebra[788]: kernel_rtm_ipv4: 222.253.64.0/19: rtm_write() unexpectedly returned -4 for command RTM_DELETE

простите, проглядел

 

отключается интерфейс как? и вообще зачем?

небось система маршруты херит и зебра понять не может чего произошло.

отключаю через ifconfig em0 down

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

не думаю что это система херит маршруты. проверял тем, что разрвал связь за свичем, все равно пишется. такое впечатление что нет прав на удаление маршлута...

 

>небось система маршруты херит и зебра понять не может чего произошло.

 

В этом случае возможно, поможет команда

link-detect

в настройках интерфейса(ов) в zebra

прописал, результата нет.
Снефи фрю, поставь стабильный Debian - и quagga 16-ю из сырцов.
но на фре тоже должно работать! я так понимаю ты утверждаешь что дебиан стабильнее чем фря?
Edited by inver

Share this post


Link to post
Share on other sites
Снефи фрю, поставь стабильный Debian - и quagga 16-ю из сырцов.
но на фре тоже должно работать! я так понимаю ты утверждаешь что дебиан стабильнее чем фря?

это полный бред, не слушайте его.

Share this post


Link to post
Share on other sites

отключается интерфейс как? и вообще зачем?

отключаю через ifconfig em0 down

простите, зачем? у всех годами работает и никто не пишет про такую проблему.

 

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

не думаю что это система херит маршруты. проверял тем, что разрвал связь за свичем, все равно пишется. такое впечатление что нет прав на удаление маршлута...

если честно - ничего не понял.

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

 

 

пы.сы. на счет линк-детект, небыло необходимости, не проверял.

Share this post


Link to post
Share on other sites
простите, зачем? у всех годами работает и никто не пишет про такую проблему.
Я сейчас настраиваю сервак с БГП, нужно смоделировать ситуацию, когда пропадает связь с провайдером, ломается модем или еще что то.

 

 

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

не думаю что это система херит маршруты. проверял тем, что разрвал связь за свичем, все равно пишется. такое впечатление что нет прав на удаление маршлута...

если честно - ничего не понял.

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

Насколько я понимаю, удаляет маршрут либо Зебра, либо бгпд, удаляют из-за того что изменился где то маршрут, провадер присылает апдейт и что то происходит, в результатечего пишутся сообщения:

 

tail /var/log/messages
May 18 08:35:44 gate zebra[783]: kernel_rtm_ipv4: 195.211.163.0/24: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 08:39:20 gate zebra[783]: kernel_rtm_ipv4: 193.41.239.0/24: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 08:41:52 gate zebra[783]: kernel_rtm_ipv4: 195.160.232.0/24: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 08:42:22 gate zebra[783]: kernel_rtm_ipv4: 193.43.222.0/23: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 08:42:52 gate zebra[783]: kernel_rtm_ipv4: 195.211.84.0/22: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 08:52:39 gate zebra[783]: kernel_rtm_ipv4: 195.189.16.0/22: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 08:52:39 gate zebra[783]: kernel_rtm_ipv4: 195.114.6.0/23: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 08:58:15 gate zebra[783]: kernel_rtm_ipv4: 202.80.233.0/24: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 09:32:28 gate zebra[783]: kernel_rtm_ipv4: 183.91.2.0/23: rtm_write() unexpectedly returned -4 for command RTM_DELETE
May 18 09:32:28 gate zebra[783]: kernel_rtm_ipv4: 183.91.8.0/23: rtm_write() unexpectedly returned -4 for command RTM_DELETE

 

ПыСы, а что дает Линкдетект?

Share this post


Link to post
Share on other sites
когда случается что ей надо удалить один маршрут, и прописать дургой, это тоже пишется в лог. и не важно какая причина изменения маршрута.

не думаю что это система херит маршруты. проверял тем, что разрвал связь за свичем, все равно пишется. такое впечатление что нет прав на удаление маршлута...

если честно - ничего не понял.

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

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

бгпд не удаляет ничего. занимается сменой маршрутов zebra,

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

(не является directly-connected - удалён алиас с интерфейса например),

на счет опускания интерфейса - не знаю, никогда не отключал интерфейсы ибо это нештатная ситуация, и обрабатывает её резервный роутер,

и в логах может быть куча мата, ибо это нештатная ситуация.

 

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

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