Особливості проходження трафіку по різних ОНУ від різних НАС

[mgo 20]

Ситуація наступна.

Користуюся Убілінгом і NAS freeBSD, і NAS MikroTik.  (Авторизація клієнта DHCP, IP+MAC)

Є кілька мереж PON.

Перша мережа побудована на freeBSD NAS -->Bdcom 3310B --> onu Extalink 

Нову мережу будували, кинули Мікротік -->Bdcom 3310C --> onu FORA NA-1001d

Все бігало, але виросла нагрузка і вирішили замінити Мікротік на тазік з freeBSD.

 

тут почалося наступне

Абон одержує ip по DHCP, пінг між абонентом і NAS небігає

 

NAS 172.16.20.1/24

абон 172.16.20.2/24

 

В цей момент tcpdump на NAS 

tcpdump -i bridge0 host 172.16.20.2

14:35:04.982337 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.16.20.1 tell 172.16.20.2, length 50
14:35:04.982341 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.16.20.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.20.1 tell 172.16.20.2, length 50
14:35:05.981742 ARP, Ethernet (len 6), IPv4 (len 4), Reply 172.16.20.1 is-at 02:c3:1b:af:d6:09 (oui Unknown), length 32

і так  по кругу

 

Очевидно обладнання абонента за ОНУ неодержує відповідь від НАС і шле запити по колу.

 

Зі 150 абонентів десь у  половини наблюдається така бадяга.

як тільки пінгую абонента arping 172.16.20.2

перший- другий  пінг десь під 1000, далі  1-2 мс

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

 

При установці ОНУ Fora в першу мережу яка вся на Extralink  такаж бадяга наблюдається.

 

На NAS MikroTik таких проблем немає.

 

ОЛТ налаштована по мінімому, один вілан, всі інтерфейси туда + навісив IP, все.

 

В тазіку з freeBSD мережеві Intel 82576, налаштування з коробки по документації.

 

 

Які думки є чому так?

Відредаговано 2016-08-22 11:38:51 mgo

[mamolog 14]

 freeBSD це не мікротік. Там потрібні знання щоб правильно все налаштувати і ніяка http://wiki.ubilling.net.ua/doku.php?id=freebsdremotenasне може бути керівництвом щоб один в один все працювало. скоріше проблема в драйверах мережевої карти і в компонентах сервера на чому збудовано сервер. як правило завше є потреба тюнінгу параметрів.

[mgo 20]

 

 

скоріше проблема в драйверах мережевої карти

дрова до цієї мережевої є в любі системі, мережева одна з кращих для цієї роботи, проблеми з драйверами люди мали десь на  freeBSD 7,0  але не сьогодні і з em картами, з igb все чудово.

 

 

 

як правило завше є потреба тюнінгу параметрів.

є ідеї? буду вельми вдячний.

 

Гуглиться по видачі tcpdump кольцо в мережі, але такого в принципі бути неможе, і мікротік включений апсолютно так само як і фря.

Відредаговано 2016-08-22 20:06:45 mgo

[mgo 20]

У мене підозра, дешева fora  має обмежений розмір таблиці  під мак адреси чи щось тіпа того.

[kissbohda 23]

 

 

У мене підозра, дешева fora

скажи монтажникам нехай поміняють ону , якщо в ній підозра
 ( хлопці монтажники на добло їздять і на синій 9-і)  ?

[mgo 20]

ага 150 шт і ще 100 зі складу))

 

гг я тоже на добло їздю і на ЗП як і ті монтажніки.

Відредаговано 2016-08-22 20:55:56 mgo

[KaYot 3 738]

Абоненту не доходит arp-reply от шлюза. Врядли в этом может быть ONU виновата, где-то у вас в сервере кривой фаервол или на OLT какие-то кривые фильтры.

[mgo 20]

Абоненту не доходит arp-reply от шлюза.

угу, і з якого дива воно починає бігати після arping?

треба загнати туда монтажніка з tcpdump аби послухав, що там прилітає.

 

онушка як свіч,  думаю запамятовує маки, кому що слати.

коли таблиця переповнина вона може ігнорувати arp-reply від шлюза.

 

Врядли в этом может быть ONU виновата,

 

на інші мережі заміна ону на дорожчу помогає,  але це ще нічого неозначає.

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

 

где-то у вас в сервере кривой фаервол

навряд, фаєр не перестає блокувати після arping. 

 

 

на OLT какие-то кривые фильтры.

або їх відсутність)

Відредаговано 2016-08-22 21:42:49 mgo