Перейти до

Ubilling + NAS на FreeBSD бортжурнал починаючого адміна


Рекомендованные сообщения

вілан теж має рішити проблему бо мак до вілану не прибивається, а прибивається DHCP на вілан з конкретною адресою

+ ще вагон позитиву у вигляді ОНУшка кінцеве обладнання абонента.

Як варіант.
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 1,8k
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Вітаю Татко!   

Не так вже й багато   Ход коньом:   # cat /bin/clear_dhcpdlog #!/bin/sh /bin/echo > /var/log/dhcpd.log /usr/local/etc/rc.d/isc-dhcpd restart # chmod a+x /bin/clear_dhcpdlog # crontab -e

http://wiki.ubilling.net.ua/doku.php?id=userstats       Расист? http://wiki.ubilling.net.ua/doku.php?id=userstats

Posted Images

ага поки хто попривичці ресет не жмакне юзеру

мамі дорого дежурний обійдеться щоб  арп чистив постійно

дешевше  ціска  ;)

Ссылка на сообщение
Поделиться на других сайтах

ага поки хто попривичці ресет не жмакне юзеру

мамі дорого дежурний обійдеться щоб  арп чистив постійно

дешевше  ціска  ;)

а ну переложить терминацию тоже хороший вариант))))

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

так шо проси у мамы 100 баксов на 3550-12G и вперед))))

Ссылка на сообщение
Поделиться на других сайтах

 

 

так шо проси у мамы 100 баксов на 3550-12G и вперед))))

чот я невїду як має цей  3550-12G своїми здвоїними оптичними портами вписатися в мережу

у мене тільки звичайні шахти під sfp на свічі і на ОЛТ головах

 

чи там до нього якісь спец медіки чи що ще в нагрузку тре :huh:

гуглю 

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

tcpdump став слухати , що куда літає

після вчорашного ковбашення з білими айпішками

 

цікава штука спостерігається

генериться трафік від білінга до віддаленого НАС на 2-5 сек  мегабіт етак 50-80 буває :blink:

 

і так до різних адрес з того НАСу

чо так?, хто таке бачив?

клієнти тут в основному wi-fi в основному убікутік декуди sxt лайт

є нормальні відповіді туда, але більшість отакого  (там дві підмережі)

в логах DHCP нічо підозрілого нема для цих адрес і в момент скачка.

в цей момент  tcpdump

21:52:26.225362 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225369 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225375 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225383 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225389 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225402 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225410 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225423 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225428 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225437 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225442 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225450 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225455 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225465 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225470 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225478 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300
21:52:26.225483 IP 172.16.0.1.67 > 172.16.23.35.68: BOOTP/DHCP, Reply, length 300

3yZUiPk.png

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
tcpdump -i bridge0 -w dump.log port 67 and port 68

15:10:55.955221 IP 172.16.24.53.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 30:b5:c2:42:55:8d (oui Unknown), length 548
15:10:55.955365 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:55.965251 IP 172.16.24.18.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 14:cc:20:6b:cd:43 (oui Unknown), length 548
15:10:55.965413 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:56.114055 IP 172.16.24.175.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 10:60:4b:47:fc:9c (oui Unknown), length 548
15:10:56.114213 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:56.128855 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:30:67:d5:99:60 (oui Unknown), length 304
15:10:56.129054 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:58.335935 IP 172.16.24.206.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from b8:a3:86:1e:cd:d2 (oui Unknown), length 532
15:10:58.336157 IP 172.16.24.1.bootps > 172.16.24.206.bootpc: BOOTP/DHCP, Reply, length 300
15:10:58.472088 IP 172.16.23.33.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 14:58:d0:c8:48:37 (oui Unknown), length 548
15:10:58.472265 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:10:59.452059 IP 172.16.24.181.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:30:67:d5:99:60 (oui Unknown), length 300
15:10:59.452215 IP 172.16.24.1.bootps > 172.16.24.181.bootpc: BOOTP/DHCP, Reply, length 300
15:10:59.571015 IP 195.95.147.117.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 70:9e:29:cd:7b:72 (oui Unknown), length 548
15:10:59.571176 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:11:00.716523 IP 172.16.23.36.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 00:1a:4d:55:f4:1d (oui Unknown), length 548

15:11:00.716668 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.392114 IP 172.16.23.20.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from 44:87:fc:8d:f7:d2 (oui Unknown), length 548
15:11:01.392281 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398232 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398252 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398660 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398668 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398735 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398757 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398765 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.398773 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.400590 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.400598 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401178 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401186 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401198 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401211 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.401256 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
.........................................
15:11:01.414017 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.414027 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.414037 IP 172.16.0.1.bootps > 172.16.23.20.bootpc: BOOTP/DHCP, Reply, length 300
15:11:01.423563 IP 172.16.24.83.bootpc > 172.16.0.1.bootps: BOOTP/DHCP, Request from bc:5f:f4:7f:b2:a7 (oui Unknown), length 5
15:11:01.423755 IP 172.16.0.1.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

чо так?

відповідь іде для 172.16.23.20 ~ 100 000 раз

що і де ще подивитися?

лівих  DHCP серверів небачу.

все ніби працює, тільки оця бадяга і тільки на віддалений НАС так відповідає.

там жменя тих абонентів.

може десь в транспорті проблема.

дайте пару ідей що ще перевірити.

 

freeBSD10.2 недавно переїхав, до цього неспостерігалося.

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах

а є можливість деякому списку сайтів надавати максимальну швидкість на порту , в обхід тарифу ? типу отдельная скорость 

Ссылка на сообщение
Поделиться на других сайтах

а є можливість деякому списку сайтів надавати максимальну швидкість на порту , в обхід тарифу ? типу отдельная скорость 

спидтест?

Ссылка на сообщение
Поделиться на других сайтах

 

 

спидтест?

не ,з спид тест все добре  

 

как я понимаю, копать сюда:

http://wiki.ubilling.net.ua/doku.php?id=uaixshape

 

та має впринципі працювати , якщо в prefixes.txt , запіхну свої сайти 

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...

Доброї ночі! Підкажіть будьласка. Після видлення юзера або декількох, з'явилися якись "тіні" чи то дущі. Отже, ні в біллінгу  ні в пошуку юзерів по ІР їх нема.

При спробі змінити ІР адресу останього у списку ІР на ІР того хто покинув біллінг не вдається, то так для феншуя хотілося, щоб всі йшли у порядку, та не було пропуків у списку ІР. Ось шматок конфігу ethrnet.conf

host m172x16x0x105 {
hardware ethernet 00:27:22:e8:1f:a8;
fixed-address 172.16.0.105;
}

host m172x16x0x106 {
hardware ethernet 00:27:22:9a:ea:4f;
fixed-address 172.16.0.106;
}

host m172x16x0x107 {
hardware ethernet ;
fixed-address 172.16.0.107

Як видно, перщі два юзери "нормальні" з МАС-адресами, а останій без МАС-а тай займає ІР, його вже нема в біллінгу, тай на його місце неможна поставити нікого.

При редагуванні ethrnet.conf руцями та після перезапуску DHCP, він заново генерується з "душами" юзерів. Як би то одна душа, то мать її за ногу, є декілька таких.

Отож питання, як довго ті дущі будуть мене лякати, чи варті вони уваги, чи є яка молитва проти того?

Дякую, гарної ночі!  :)

 

ЗІ. Сервер перезавантжив, дхцп логі вичистив, і все таке інше, результату 0.

Відредаговано -VaSaK-
Ссылка на сообщение
Поделиться на других сайтах

То відразу запитаю, що воно таке і чі є ліки? 

Jun 22 01:02:30 eserverx bandwidthd: DNS timeout for 172.16.0.103: This problem reduces graphing performance
Jun 22 01:04:30 eserverx bandwidthd: DNS timeout for 172.16.0.103: This problem reduces graphing performance
Jun 22 01:05:51 eserverx bandwidthd: DNS timeout for 172.16.0.103: This problem reduces graphing performance
Jun 22 01:15:54 eserverx last message repeated 5 times
Jun 22 01:25:58 eserverx last message repeated 4 times
Ссылка на сообщение
Поделиться на других сайтах
Отож питання, як довго ті дущі будуть мене лякати, чи варті вони уваги, чи є яка молитва проти того?

До кінця днів ваших.

 

Молитва:

DELETE FROM `nethosts` where `ip`='172.16.0.107'

Після чого просто потицяти в "мережі та послуги" і подивитись як перегенерувався ваш ethrnet.conf. Амінь.

 

То відразу запитаю, що воно таке і чі є ліки?

Всьо погібло, тепер тричі "отче наш".

Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах

гг  оновив свій старий добрий 4.0 до поточного релізу

ще стільки не копіпастив запитів зараз :blink:

аж пальці заболіли, так, що оновлюйтесь вчасно 

Ссылка на сообщение
Поделиться на других сайтах
Всьо погібло, тепер тричі "отче наш".

 

Тепер усе по феньшую!

Дякую! -_-  -_-

 

 

 

так, що оновлюйтесь вчасно 

 

 

Стараюсь оновити одразу після виходу релізу  :rolleyes:

 

І не спиться ото вночі  :D

Відредаговано -VaSaK-
Ссылка на сообщение
Поделиться на других сайтах
  • 3 weeks later...
Опубліковано: (відредаговано)

Прокляли конкуренти  ОЛТ після грози

до ОЛТ оптика, від тоже

і тут містика, пропадає олт рівно на 40-ві хвилині  по кілька разів на день

опитування 5 хв  swping поставив після появи, але всерівно в 40 хвилині.

залізяки з ребутом по таймеру нема, хіба медік взбісився.

абони звідти нежаліються, все ніби добре.

 

може хто стикався з таким бісом і підкаже чарівних заклинань а?

3A631jy.png

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
14:35:04.982337 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.4.1 tell 172.16.5.57, length 50
14:35:04.982341 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.16.4.1 is-at 02:c3:1b:af:d6:09 (oui Unknown), length 32
14:35:05.981736 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.4.1 tell 172.16.5.57, length 50
14:35:05.981742 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.16.4.1 is-at 02:c3:1b:af:d6:09 (oui Unknown), length 32

хто таке наблюдав і саме головне як лікувати?

сиплеться кожну секунду

172.16.4.1 НАС, 172.16.5.57 клієнт, мережа 172.16.4.0/22

 

клієнт непінгається, тицяєм роутер, ноут ситуація одинакова, висить на PON

Відредаговано mgo
Ссылка на сообщение
Поделиться на других сайтах
може хто стикався з таким бісом і підкаже чарівних заклинань а?

 

alter.ini

SWITCH_PING_CUSTOM_SCRIPT="/bin/arp_switch_test"

cat /bin/arp_switch_test

#!/usr/local/bin/php
<?php
if (isset($argv[1])) {
        if(filter_var($argv[1], FILTER_VALIDATE_IP)) {
        $ip=$argv[1];
        $command='/usr/local/bin/sudo /usr/local/sbin/arping -v -c2  -i igb0 '.$ip;
                $pingResult=shell_exec($command);
                if (strpos($pingResult, 'time')) {
                   print('1');
                 } else {
                   print('0');
                 }      

        } else {
                print('FAIL:WRONG_IP');
        }

} else {
print('FAIL:NO_IP');
}
?>
Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від Remez
      Ценник 5,500
       
      в наличии 3 шт
       
       





    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від Plastilin
      Вітаю. Маю наступний комплект. Ubilling на Debian + Mikrotik CHR як маршрутизатор. Наче все запустилось, але виникло питання яке не вдається розрулити. Читав Wiki, ковиряв, читав знову Wiki, знову ковиряв - не допомогло.
      Чи можливо якось визначити конкретну IP адресу з пулу який видає Mikrotik клієнту через Radius? Мені пропонує обрати наступну вільну адресу з пулу при спробі зміни адреси?
      З цього з'являється додаткове питання, чи можливо контролювати доступ користувачам у яких IP назначений статично, тобто прописаний вручну? Наприклад при зміні статусу не активний - пхати до Firewall Mikrotik правила заборони доступу з IP адреси визначеної вручну, навіть якщо вона не отримана по DHCP.
       
      UPD: з першою частиною знайшов: IP_CUSTOM=1 в alter.ini 
    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
    • Від sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.

×
×
  • Створити нове...