При отправке CoA-запроса на смену значений mpd-limit у клиента кратковременно происходит затык трафика на 1-2сек. Подскажите можно ли решить данную проблему? FreeBSD 8.0 MPD5.5 PPTP, PPPOE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
При обработке CoA mpd фактически кладет интерфейс и поднимает его заново с новыми параметрами. Потому совсем безразрывно оно быть не может. Но две секунды все-же сильно перебор. Смотри что именно у тебя там происходит. Может у тебя какой-то up/down скрипт висит медленный или еще что-то. Может ты devd не отломал.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Отключил devd в rc.local. Всеравно при CoA запросе стабильно пропадает ICMP пакет, иногда 2, если слушать потоковое радио, то появляется небольшой разрыв, в онлайн играх так-же замечаются прерывания. Все настройки по дефолту, никаких дополнитеьлных скриптов нет. Есть желание применять CoA несколько раз в час, остается исправить проблему с перерывом в момент запроса. Неужели никак нельзя сделать?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
devd в конфигурации по умолчанию имеет привычку запускать кучу скриптов при событиях на интерфейсах. Для достижения нормальной производительности его нужно или отключить или подправить конфигурацию оторвав лишее.
Я подробно это не тестировал. Учитывая что mpd может авторизовать по сотне пользователей в секунду - я не вижу почему CoA может рвать связь на две секунды. Попробуй накрутить логи и посмотреть что происходит в момент CoA и как долго это происходит.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Немного разобрался… Действительно при CoA запросе задержка минимальная. У меня проблема в том что настроена динамическая маршрутизация quagga ospf. Видимо когда mpd фактически кладет интерфейс и поднимает его заново с новыми параметрами теряется маршрут до сервера и потом создается заного. При статической маршрутизации такой проблемы нет. Пытаюсь решить ее. Если кто знает как помочь, буду благодарен…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Настроена quagga zebra ospfd.
Вот мой конфиг ospf
router ospf
ospf router-id 91.204.184.8
redistribute connected
passive-interface default
no passive-interface bge0
network 91.204.184.0/27 area 0.0.0.0
area 0 authentication message-digest
!
В конфиге zebra только ip forwarding.
Еще zebra при подключении и отключении пользователей выдает в лог такое:
2010/04/22 00:14:05 ZEBRA: if_ioctl(SIOCGIFFLAGS) failed: Device not configured
2010/04/22 00:14:05 ZEBRA: if_ioctl(SIOCGIFFLAGS) failed: Device not configured
2010/04/22 00:14:05 ZEBRA: Can't lookup mtu by ioctl(SIOCGIFMTU)
В логах ospf все нормально.
Прошу показать рабочий конфиг?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Все перепробовал, неполучается никак обмануть zebra. Пропадает маршрут и все. Может проблема в Up down скриптах? Я никаких скриптов неделал. Если у кого есть покажите пример… Или может кто знает как можно настроить zebra, что бы при кратковременном пропадании интерфейса ничего она не отрабатывала?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Получилось только так, если перед COA запросом убивать демон zabra и после снова запускать, тогда никакого перерыва и потери маршрута непроисходит. Но это не совсем правильное решение. Кто может помочь?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Если совсем не в моготу - думаю проще будет подхачить radsrv.c и еще пару файликов, чтобы вместо опускания/поднимания всего перестраивать только netgraph дерево. Теперешняя реализация не претендует на идеал - она была лишь самой простой и универсальной.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Я бы с удовольствием подхачил radsrv.c и еще пару файликов, если бы знал как… Пока придеться обходить сторонними методами. Возможно в последующих релизах исправить проблему? Или написать какой-нибудь патч?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Добрый день всем еще раз. Обращаюсь к разработчикам: Может кто-нить исправить проблему с COA запросом или написать патч для MPD? К кому можно обратиться? Пробовал обойти стороннымим путями, убивая демон zebra перед CoA запросом, но тогда со временем получаются дублирующие маршруты (в момент когда zebra неработает пользователи переключаются между серверами).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
При отправке CoA-запроса на смену значений mpd-limit у клиента кратковременно происходит затык трафика на 1-2сек. Подскажите можно ли решить данную проблему? FreeBSD 8.0 MPD5.5 PPTP, PPPOE.
При обработке CoA mpd фактически кладет интерфейс и поднимает его заново с новыми параметрами. Потому совсем безразрывно оно быть не может. Но две секунды все-же сильно перебор. Смотри что именно у тебя там происходит. Может у тебя какой-то up/down скрипт висит медленный или еще что-то. Может ты devd не отломал.
Все настроено по дефолту…. Можно подробнее про devd?
Отключил devd в rc.local. Всеравно при CoA запросе стабильно пропадает ICMP пакет, иногда 2, если слушать потоковое радио, то появляется небольшой разрыв, в онлайн играх так-же замечаются прерывания. Все настройки по дефолту, никаких дополнитеьлных скриптов нет. Есть желание применять CoA несколько раз в час, остается исправить проблему с перерывом в момент запроса. Неужели никак нельзя сделать?
devd в конфигурации по умолчанию имеет привычку запускать кучу скриптов при событиях на интерфейсах. Для достижения нормальной производительности его нужно или отключить или подправить конфигурацию оторвав лишее.
Я подробно это не тестировал. Учитывая что mpd может авторизовать по сотне пользователей в секунду - я не вижу почему CoA может рвать связь на две секунды. Попробуй накрутить логи и посмотреть что происходит в момент CoA и как долго это происходит.
Лог покажи.
log +iface +iface2 +phys +radius
У меня при ping -i 0.01 терялось 1-2 пакета. И то не всегда.
Немного разобрался… Действительно при CoA запросе задержка минимальная. У меня проблема в том что настроена динамическая маршрутизация quagga ospf. Видимо когда mpd фактически кладет интерфейс и поднимает его заново с новыми параметрами теряется маршрут до сервера и потом создается заного. При статической маршрутизации такой проблемы нет. Пытаюсь решить ее. Если кто знает как помочь, буду благодарен…
У меня quagga. Такой проблемы нет.
to pronini:
quagga - настроена на ospf или что еще?
Настроена quagga zebra ospfd.
Вот мой конфиг ospf
router ospf
ospf router-id 91.204.184.8
redistribute connected
passive-interface default
no passive-interface bge0
network 91.204.184.0/27 area 0.0.0.0
area 0 authentication message-digest
!
В конфиге zebra только ip forwarding.
Еще zebra при подключении и отключении пользователей выдает в лог такое:
2010/04/22 00:14:05 ZEBRA: if_ioctl(SIOCGIFFLAGS) failed: Device not configured
2010/04/22 00:14:05 ZEBRA: if_ioctl(SIOCGIFFLAGS) failed: Device not configured
2010/04/22 00:14:05 ZEBRA: Can't lookup mtu by ioctl(SIOCGIFMTU)
В логах ospf все нормально.
Прошу показать рабочий конфиг?
quagga 0.99.15
OSPFD + zebra
Конфиг такой же как у тебя.
Все перепробовал, неполучается никак обмануть zebra. Пропадает маршрут и все. Может проблема в Up down скриптах? Я никаких скриптов неделал. Если у кого есть покажите пример… Или может кто знает как можно настроить zebra, что бы при кратковременном пропадании интерфейса ничего она не отрабатывала?
Получилось только так, если перед COA запросом убивать демон zabra и после снова запускать, тогда никакого перерыва и потери маршрута непроисходит. Но это не совсем правильное решение. Кто может помочь?
Хм. Как вариант перед CoA запросом заходит по телнету на демон и прописывать ему этот маршрут статически?
Если совсем не в моготу - думаю проще будет подхачить radsrv.c и еще пару файликов, чтобы вместо опускания/поднимания всего перестраивать только netgraph дерево. Теперешняя реализация не претендует на идеал - она была лишь самой простой и универсальной.
Я бы с удовольствием подхачил radsrv.c и еще пару файликов, если бы знал как… Пока придеться обходить сторонними методами. Возможно в последующих релизах исправить проблему? Или написать какой-нибудь патч?
Добрый день всем еще раз. Обращаюсь к разработчикам: Может кто-нить исправить проблему с COA запросом или написать патч для MPD? К кому можно обратиться? Пробовал обойти стороннымим путями, убивая демон zebra перед CoA запросом, но тогда со временем получаются дублирующие маршруты (в момент когда zebra неработает пользователи переключаются между серверами).
Про zebra я вроде бы писал выше.
Прописываь маршрут пробовал - непомогает.