nightfly

Ага, коли провайдери з пятизначними кількостями абонентів мігрують на якусь біллінгову систему, вони точно не "бігають по селі" а спочатку думають про конвертацію абонбази. Благо простих як дошка засобів для цього передбачено цілу купу - від прямої роботи з базою до зручної "консолі розробника". Якщо в провайдера нема відповідних фахівців здатних просто зробити з одної БД іншу - вони просто звертаються до розробника. Є підозра що останній точно знає як в фіналі має виглядати цілістна сконвертована БД. В нормі перехід в продакшні займає рівно стільки часу аби переткнути кабель з одного тазіка в

Свиню в селі "забивають" - а юзеру присвоюється відповідна основна IP адреса ассоційована до конкретного "nethost" З якого NMLEASES "його видно"? Козу під деревом "привязують" а конкретний nethost ассоціюється до мережі крізь політику сервісів Значить про нього не має бути згадок в dhcpd.log як мінімум поняття не маю що за "пули" - в Ubilling такого немає Також в сусідньому селі "забивається" котрась інша свиня, а в таблички 3 та 4 зі скриптів ініціалізації користувача потрапляє саме та адреса, яка присвоєна йому в Ubilling. А, це така опція про яку в трьох

1. не создан nethost для IP какого-то пользователя 2. нету NAS для подсети какого-то пользователя Подозреваю, что 192.168.1.1 это останки изначального тестового пользователя, который остается сразу после установки - удалите его нафиг.

Молодець, візьміть з полички печеньку

Для начала включаем net.inet.ip.fastforwarding=1 и вдумчиво смотрим не выжрано ли обработчиком прерывания карточки в потолок CPU. em карточки вполне себе при таких раскладах отстреливаться. Если рядом с timeout resetting вы наблюдаете throttling interrupt - это уже плохо и похоже на болезнь матери и интеррапт сторм. Также очень даже помогает для начала поменять шнурок / переткнуть порт. Искренне надеюсь что никаких dev.em.Х. вы не крутили, что очень любят пионеры - em карточки тюнить таким образом бесперспективно, их следует менять на igb коли хочется shape/nat гигабитами.

NAT подымается на внешней сетевой - мы ее вроде как не трогаем дык ifconfig -a - не нужно ощущений Oo В общем случае, для тестирования на ходу, вам следует менять только /etc/firewall.conf после чего: 1. останавливать stargazer (killall stargazer) 2. перезапускать ipfw (/etc/rc.d/ipfw restart) 3. запускать stargazer (stargazer) Все остальное можно поправить при уверености в рабочести и контрольно ребутнуться. Что за сетевые, такие волшебные то? А да, и покажите ipfw show.

А чего не работает?

Незачто. Орите если чего.

В таком случае интерфейс шейпа крутиться только в /etc/firewall.conf ${FwCMD} add 12001 pipe tablearg ip from any to table\(4\) via интерфейс out ${FwCMD} add 12000 pipe tablearg ip from table\(3\) to any via интерфейс in

Если шейпера старые без tablearg - то да, там тоже указывается на каком интерфейсе подымается шейп. В любом случае полностью имеет смысл посмотреть в сторону перехода на новые - прирост производительности в таком варианте около 45%. После 0.3.5 шейп подымается только двумя правилами в firewall.conf

ok напомните в личку последних 4 цифры-буквы серийника это было-бы наглядной демонстрацией влияния тяжелых наркотиков На вскидку допускаю, что если после замены сетевой смениться имя интерфейса, стоит его изменить в следующих конфигах: /etc/rc.conf /etc/firewall.conf /etc/rc.d/billing /usr/local/bandwidthd/etc/bandwidthd.conf /usr/local/www/apache22/data/billing/config/alter.ini Это в случае если у вас используется модель шейпинга из 0.3.5 и выше. Если шейп остался более ранний (хотя и не рекомендуется) - стоит заглянуть еще в /etc/stargazer/OnConnect

не возможно Ставили инсталлятором? Меняли смотрящую в интернет или на пользователей? Если моделька та же - то скорее всего ничего менять не придется. Если отличается - придется исправить от двух до "чуть больше" конфигов в зависимости от того куда смотрит сетевая.

Как минимум отсутствие понимания того, как работает tablearg. Сравните ipfw table 111 show с тем что у вас, например находиться в table 4.

Вчимось читати разом: DirectoryIndex ще ніхто не відміняв.

фігово прикрутили уміляюсь, обгрунтуйте фігово прикрутили точно фігово фігово прочитали доку хотів би побачити того мудлана, який підмережу "невідомих абонентів" мало того, що не зробить deny via ifaceout а щей своїми ж руками в табличку під NAT додасть. я ж казав шо фігово прикрутили "Фігово прикрутили" - залишається в силі. Звідки блін взявся index.html? Відки ці всі збочення? Чому замість того аби прочитати уважно пів екрана детального мануала, виходячи з якого це рішення працює вже в кількох сотень нормальних провайдерів вас тягне на якісь не зрозу

Ухты, как посмотрю регистрация без капчи с банальной активацией мылом. А сколько голосов нужно?

Так, все вірно. Худ думок в правильному напрямку. Хоча є ше така штука - досить спрощує життя.

Так і є. Тільки я не розумію яким місцем у вас співвідносяться блокування 172.16.0.0/24 і невідомих-відомих MAC фаєром(!).

пробігають інколи п-ф-ф-ф, головне цього більше ні при кому в голос не кажіть. Зирніть в arp -a краще.

а шо, фист видко? яке відношення фаєр має до виловлювання MACів? Хінт. В кінець /etc/syslog.conf вписуємо в кінець !dhcpd *.* /var/log/dhcpd.log після чого робимо # touch /var/log/dhcpd.log # /usr/local/etc/rc.d/isc-dhcpd restart # /etc/rc.d/syslogd restart і в alter.ini виставляємо NMLEASES так; NMLEASES=/var/log/dhcpd.log Зручна вибиралка і виловлювалка MAC для того і існує. А чому б і ні? Ну хіба б самі собі налаштували dhcp snooping.

Хецнер не?

mc? п-ф-ф-ф Там в депенденсах, чорт зна шо може підтягуватись - тому да, вже нечестива. Ви її осквернили. Зараз откровення Іоана Богослова почну цитувати. Підоймати NAT по імені інтерфейсу і масці з пулу аплінка - нє? Можу дати хорошу безкоштовну пораду - розглядати мікротіки просто як L2 транспорт рівня доступу, а не як NAS. Це ліквідує порядку 95% концептуальних проблем в подальшому.

nat не піднявся, викиньте то dhcp на rl0 нафіг, намалюйте руками це своє 192.168.1.253 по людськи, і так - дефолтгейтвей теж. ok значить нікому ходити в інтернети - в 3 та 4 табличках лежать активні користувачі. ok ok

Ні, до маку воно привязує зовсім іншим місцем (див arp -a). А це - психодел якийсь, такі конфіги в принципі генеруватись не можуть. Даремно. Фря на яку ви щось вже намагались ставити руками - вже нечистива, нічорта там нормально не взлетить. Убінсталлером в варіантах 8.3 Offline та 8.3 Offline KMOD ставиться клієнтам практично щотижня - все нормально. cat /etc/firewall.conf ipfw nat 1 show ipfw table 2 list ipfw table 4 list ipfw table 9 list покажіть