hillers

эта точка давно включена

067-3002200

LanBilling.ru на FreeBSD

Знаю, что некоторые провайдеры отправляют свои абонентам сообщения в браузере. Как это реализовать?

легко - шлет пакеты на мак-адрес которого нет в FDB, и свич пакет ессно рассылает по всем портам. смотрите фильтры unknown unicast. Спасибо, очень похоже на это - UNKNOWN DESTINATION UNICAST Пока что нашел команду на свитче, которая ограничивает полосу: 3.1.12 rate-suppression Command: rate-suppression {dlf | broadcast | multicast} <Kbits> no rate-suppression {dlf | broadcast | multicast} Function: Sets the traffic limit for broadcasts, multicasts and unknown destination unicasts on all ports in the switch; the no command disables this traffic suppression function on all ports in the switch, i.e., enables broadcasts, multicasts and unknown destination unicasts to pass through the switch at line speed. Еще бы отрубать порт абоненту, у которого идет паразитный трафик

Очень на это похоже. Но как бороться - пока не определились. Пока что вычисляем флудящий роутер, отключаем абонента, потом разбираемся. Т.е действуем по факту выявления гадящего абонента.

Можно, делаете vlan на юзера и забываете вообще о понятии шторм. Пока нет такой возможности - слишком много надо менять. Может есть другой способ. Не совсем понятно как ТЕНДА может гадить юникастом на все порты во ВЛАНе. Это же свитчи, не хабы - не должны принимать пакеты адресованные не на тот порт. Есть такой тип атаки - сбросить АРП -таблицу и потом свитч не знает на какой порт слать пакеты. Может это оно? Как Тенда может сбросить АРП таблицу на нескольких свитчах?

Можно, делаете vlan на юзера и забываете вообще о понятии шторм. Пока нет такой возможности - слишком много надо менять. Может есть другой способ. Не совсем понятно как ТЕНДА может гадить юникастом на все порты во ВЛАНе. Это же свитчи, не хабы - не должны принимать пакеты адресованные не на тот порт. Есть такой тип атаки - сбросить АРП -таблицу и потом свитч не знает на какой порт слать пакеты. Может это оно? Как Тенда может сбросить АРП таблицу на нескольких свитчах?

обычно помогает перепрошивка роутера на самую свежую прошивку и установка пароля на веб-морду. Однако, проблема в том, что Тенд много - абоненты напокупали, т.к. роутер один из самых дешевых. Работает, вроде бы, нормально, потом начинает колбасить сеть. Может можно на свичах как-то гасить этот шторм юникастовый?

У нас в сети около 150 Тенд у абонентов - смотрели по МАКам, реально, наверное - больше, часть абонентов сменили МАКи у Тенд. Можно как-то бороться другими методами? З якими моделями Тенди проблеми ? w316r и F3

У нас в сети около 150 Тенд у абонентов - смотрели по МАКам, реально, наверное - больше, часть абонентов сменили МАКи у Тенд. Можно как-то бороться другими методами?

Периодически появляется проблема - начинается в сети жуткий флуд, штормит юникастом до 100Мбит/с. Начинаем разбираться - определяем что с одного или нескольких роутеров одновременно начинает идти передача паразитного трафика Вот пример одного абонента - трафик на порту у абонента вот как это отображается на других домах, которые находятся в этом же ВЛАНе. В правом верхнем углу картинка с домом абонента Спицкий. Идет передача и прием юникаст трафика. В остальных домах по всем портам идет паразитный юникаст трафик Начинаем разбираться, обычно у такого абонента роутер TENDA. Обычно со старой прошивкой 2011г (но были случаи и с новой прошивкой). Часто бывает не установлен пароль на веб морду роутера или установлен стандартный пароль ADMIN ADMIN. Как можно с этим бороться? Почему Юникаст валит по всем портам во ВЛАНе? Почему именно Тенда?

root@MX80> show route instance Instance Type Primary RIB Active/holddown/hidden master forwarding inet.0 604080/0/1718 inet.1 2/0/0 inet6.0 1/0/0 inet6.1 2/0/0 NAT-RI virtual-router NAT-RI.inet.0 17/0/0 juniper_private1 forwarding __juniper_private1__.inet.0 5/0/0 __juniper_private1__.inet6.0 3/0/0 juniper_private2 forwarding __juniper_private2__.inet.0 2/0/1 juniper_private4 forwarding master.anon forwarding http-redirect forwarding root@MX80>

set routing-instances http-redirect routing-options static route 0.0.0.0/0 next-hop xxx.xxx.xxx.xxx на IP "ххх.ххх.ххх.ххх" находится веб сервер

Juniper MX80 не получатся реализовать схему Http-redirect для пользователей заблокированных по балансу. Для подключения пользователей с положительным балансом используем фильтры: set firewall family inet filter fltr-100Mb-NAT interface-specific set firewall family inet filter fltr-100Mb-NAT term 1 from source-prefix-list NAT-PREFIX-LIST set firewall family inet filter fltr-100Mb-NAT term 1 then service-accounting set firewall family inet filter fltr-100Mb-NAT term 1 then routing-instance NAT-RI set firewall family inet filter fltr-100Mb-NAT term 2 then service-accounting set firewall family inet filter fltr-50Mb-NAT interface-specific set firewall family inet filter fltr-50Mb-NAT term 1 from source-prefix-list NAT-PREFIX-LIST set firewall family inet filter fltr-50Mb-NAT term 1 then policer plcr-100Mb set firewall family inet filter fltr-50Mb-NAT term 1 then service-accounting set firewall family inet filter fltr-50Mb-NAT term 2 then policer plcr-100Mb set firewall family inet filter fltr-50Mb-NAT term 2 then service-accounting set firewall policer plcr-100Mb logical-interface-policer set firewall policer plcr-100Mb if-exceeding bandwidth-limit 1g set firewall policer plcr-100Mb if-exceeding burst-size-limit 38400000 set firewall policer plcr-100Mb then discard Для заблокированных по балансу пытались сделать через фильтр такого плана: set firewall family inet filter fltr-http-redirect term 1 from source-prefix-list NAT-PREFIX-LIST set firewall family inet filter fltr-http-redirect term 1 from protocol icmp set firewall family inet filter fltr-http-redirect term 1 from port bootpc set firewall family inet filter fltr-http-redirect term 1 from port dhcp set firewall family inet filter fltr-http-redirect term 1 from port domain set firewall family inet filter fltr-http-redirect term 1 from port netbios-ns set firewall family inet filter fltr-http-redirect term 1 then policer plcr-8Mb set firewall family inet filter fltr-http-redirect term 1 then count service_accept set firewall family inet filter fltr-http-redirect term 1 then accept set firewall family inet filter fltr-http-redirect term 2 from port http set firewall family inet filter fltr-http-redirect term 2 then policer plcr-8Mb set firewall family inet filter fltr-http-redirect term 2 then count redirected set firewall family inet filter fltr-http-redirect term 2 then routing-instance http-redirect set firewall family inet filter fltr-http-redirect term 3 then count else_discard set firewall policer plcr-8Mb logical-interface-policer set firewall policer plcr-8Mb if-exceeding bandwidth-limit 8m set firewall policer plcr-8Mb if-exceeding burst-size-limit 1920000 set firewall policer plcr-8Mb then discard set routing-instances http-redirect instance-type forwarding set routing-instances http-redirect routing-options static route 0.0.0.0/0 next-hop xxx.xxx.xxx.xxx Но данная схема не заработала.

Как сделать копирование всех файлов с резервной флешки на основную для Juniper МХ80 ? request system snapshot - копирование всех файлов с текущей nand флешки на резервную а какой командой сделать обратное действие ?

Отпадают все интерфейсы на Ericsson Redback Smartedge SE100. После того, как появилась данная проблема - открыли устройство пропылесосили, посмотрели вздутых конденсаторов нет на плате и т.п. На вид выглядит нормально, в лог пишет: May 17 20:38:53: %PM-1-ALERT: Process IPPA IPC SLOT 2, pid 0x80020023, is not responding. May 17 20:38:56: %SYSMON-5-GEN_FTP: Core file /ata0/p01/ppa/crashSlot02Ippa.gz FTPed to /md/ successfully May 17 20:39:00: %CSM-6-PORT: ethernet 2/1 link state DOWN service state DOWN, overall admin is UP May 17 20:39:00: %CSM-6-PORT: ethernet 2/1 link state down, trigger source: Hardware removed May 17 20:39:00: %CSM-6-PORT: ethernet 2/2 link state DOWN service state DOWN, overall admin is UP May 17 20:39:00: %CSM-6-PORT: ethernet 2/2 link state down, trigger source: Hardware removed May 17 20:39:00: %CSM-6-PORT: ethernet 2/3 link state DOWN service state DOWN, overall admin is UP May 17 20:39:00: %CSM-6-PORT: ethernet 2/3 link state down, trigger source: Hardware removed May 17 20:39:00: %CSM-6-PORT: ethernet 2/4 link state DOWN service state DOWN, overall admin is UP May 17 20:39:00: %CSM-6-PORT: ethernet 2/4 link state down, trigger source: Hardware removed May 17 20:39:00: %CSM-6-PORT: ethernet 2/15 link state DOWN service state DOWN, overall admin is UP May 17 20:39:00: %CSM-6-PORT: ethernet 2/15 link state down, trigger source: Hardware removed May 17 20:39:00: %CSM-6-PORT: ethernet 2/16 link state DOWN service state DOWN, overall admin is UP May 17 20:39:00: %CSM-6-PORT: ethernet 2/16 link state down, trigger source: Hardware removed May 17 20:39:00: %CSM-6-CARD: card carrier REMOVED from slot 2 May 17 20:39:02: %PM-1-ALERT: Process EPPA IPC SLOT 2, pid 0x81020021, is not responding. May 17 20:39:02: [0002]: %DHCP-5-MRKG_SV_DEAD: Marking server: 192.168.11.1 in context: inet dead May 17 20:39:02: %LG-3-GRP_LOG: link-group LACP_SE100 state: DOWN May 17 20:39:02: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:300 state: DOWN May 17 20:39:02: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:301 state: DOWN May 17 20:39:02: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:302 state: DOWN May 17 20:39:02: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:333 state: DOWN May 17 20:39:02: %LG-3-GRP_LOG: link-group LACP_local2 state: DOWN May 17 20:39:10: %CSM-6-CARD: card carrier INSERTED in slot 2 May 17 20:39:15: %PUBSUB-3-ERR: SNMPD [rbn_pubsub_cache_attr_read]: Instance(20) out of range(0..18) for data id(128) May 17 20:39:15: %PUBSUB-3-ERR: SNMPD [rbos_pubsub_data_get]: rbn_pubsub_cache_attr_read failed (-1), instance (20), id (128) May 17 20:39:15: %PUBSUB-3-ERR: SNMPD [rbn_pubsub_cache_attr_read]: Instance(21) out of range(0..18) for data id(128) May 17 20:39:15: %PUBSUB-3-ERR: SNMPD [rbos_pubsub_data_get]: rbn_pubsub_cache_attr_read failed (-1), instance (21), id (128) May 17 20:39:17: %CSM-6-CARD: MIC number 1 ge-2-port REMOVED from slot 2 May 17 20:39:17: %SNMP-6-INFO: The last entity configuration change notification was sent out2.00 (less than 5.00) seconds before. Suppressing this one. May 17 20:39:19: %CSM-6-CARD: MIC number 2 ge-2-port REMOVED from slot 2 May 17 20:39:19: %SNMP-6-INFO: The last entity configuration change notification was sent out4.00 (less than 5.00) seconds before. Suppressing this one. May 17 20:39:19: %CSM-6-CARD: MIC number 1 ge-2-port INSERTED in slot 2 May 17 20:39:19: %PUBSUB-3-ERR: SNMPD [rbn_pubsub_cache_attr_read]: Instance(20) out of range(0..18) for data id(128) May 17 20:39:19: %PUBSUB-3-ERR: SNMPD [rbos_pubsub_data_get]: rbn_pubsub_cache_attr_read failed (-1), instance (20), id (128) May 17 20:39:19: %PUBSUB-3-ERR: SNMPD [rbn_pubsub_cache_attr_read]: Instance(21) out of range(0..18) for data id(128) May 17 20:39:19: %PUBSUB-3-ERR: SNMPD [rbos_pubsub_data_get]: rbn_pubsub_cache_attr_read failed (-1), instance (21), id (128) May 17 20:39:19: %SNMP-6-INFO: The last entity configuration change notification was sent out4.00 (less than 5.00) seconds before. Suppressing this one. May 17 20:39:20: %CSM-6-CARD: MIC number 2 ge-2-port INSERTED in slot 2 May 17 20:39:20: %PUBSUB-3-ERR: SNMPD [rbn_pubsub_cache_attr_read]: Instance(32) out of range(0..18) for data id(128) May 17 20:39:20: %PUBSUB-3-ERR: SNMPD [rbos_pubsub_data_get]: rbn_pubsub_cache_attr_read failed (-1), instance (32), id (128) May 17 20:39:20: %PUBSUB-3-ERR: SNMPD [rbn_pubsub_cache_attr_read]: Instance(33) out of range(0..18) for data id(128) May 17 20:39:20: %PUBSUB-3-ERR: SNMPD [rbos_pubsub_data_get]: rbn_pubsub_cache_attr_read failed (-1), instance (33), id (128) May 17 20:39:25: %QOS-6-INFO: qos info: PPA just reborn 0 May 17 20:39:25: %PPAINFRA-6-ISTART_INFO: 42e04e7e/0000000002/925500000:02/IPPA/EU00:Ready to receive packets May 17 20:39:25: %QOS-6-INFO: qos info: iPPA reg on slot 2 May 17 20:39:25: %CSM-6-CARD: card carrier INSERTED in slot 2 READY May 17 20:39:26: %PPAINFRA-6-ISTART_INFO: 4d2375be/0000000003/390800000:02/EPPA/EU00:Ready to receive packets May 17 20:39:26: %CSM-6-PORT: ethernet 2/4 link state UP service state UP, overall admin is UP May 17 20:39:26: %CSM-6-CARD: Card in slot 2 entering In Service state. May 17 20:39:26: %CSM-6-PORT: ethernet 2/3 link state UP service state UP, overall admin is UP May 17 20:39:26: %CSM-6-PORT: ethernet 2/15 link state UP service state UP, overall admin is UP May 17 20:39:26: %CSM-6-PORT: ethernet 2/16 link state UP service state UP, overall admin is UP May 17 20:39:26: %PPAINFRA-6-IFACE_INFO: 588d172e/0000000003/908300000:02/IPPA/EU00:ROUTING_READY sent to CSM May 17 20:39:26: %QOS-6-INFO: qos info: PPA just reborn 0 May 17 20:39:26: %QOS-6-INFO: qos info: ePPA reg on slot 2 May 17 20:39:28: %CSM-6-PORT: ethernet 2/1 link state UP service state UP, overall admin is UP May 17 20:39:28: %CSM-6-PORT: ethernet 2/2 link state UP service state UP, overall admin is UP May 17 20:39:30: %LG-3-GRP_LOG: link-group LACP_SE100 state: UP May 17 20:39:30: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:300 state: UP May 17 20:39:30: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:301 state: UP May 17 20:39:30: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:302 state: UP May 17 20:39:30: %LG-3-GRP_LOG: link-group LACP_SE100 PVC:333 state: UP May 17 20:39:37: %PM-1-ALERT: Process IPPA IPC SLOT 2, pid 0x80020025, is not responding. May 17 20:39:37: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLICY to EPPA, pol_grid 1 May 17 20:39:38: %NAT-3-INT_ERR: work thread: failed to send UNBIND POLIC.. Из-за чего может быть проблема?

Пока удалось решить данную проблему включением БДКОМ-ов через дополнительный свитч Конфигурация данного коммутатора отличается от С704 (в который раньше были включены BDCOMы) включенным DHCP-snooping binding. Конфигурация портов: Interface Ethernet1/25 description BDCOM_1x8 ip multicast destination-control access-group 6000 switchport mode trunk switchport trunk allowed vlan 303;331;400 ip access-group 100 in loopback-detection specified-vlan 303;331;400 loopback-detection control shutdown arp-guard ip 192.168.7.1 arp-guard ip 192.168.6.1 arp-guard ip 192.168.5.1 arp-guard ip 192.168.4.1 arp-guard ip 192.168.3.1 arp-guard ip 192.168.11.1 arp-guard ip 192.168.10.1 arp-guard ip 10.100.0.10 arp-guard ip 192.168.2.1 arp-guard ip 192.168.1.1 arp-guard ip 192.168.0.1 arp-guard ip 10.100.2.9 arp-guard ip 10.0.0.1 arp-guard ip 10.120.0.1 arp-guard ip 10.100.2.7 arp-guard ip 10.100.2.1 ip dhcp snooping action shutdown recovery 180 на С704: (в который раньше были включены BDCOMы) Interface Ethernet4/11 description BDCOM_1x8 ip multicast destination-control access-group 6011 switchport mode trunk switchport trunk allowed vlan 303;331;400 ipv6 access-group 600 in loopback-detection specified-vlan 300;303;331-332;400 loopback-detection control shutdown ipv6 security-ra enable arp-guard ip 10.100.0.10 arp-guard ip 192.168.2.1 arp-guard ip 192.168.1.1 arp-guard ip 192.168.0.1 arp-guard ip 10.120.0.1 arp-guard ip 10.0.0.1 arp-guard ip 10.100.2.1 anti-arpscan trust supertrust-port Уже более 5 дней наблюдаем нормальную работу БДКОМ-ов. До этого каждый день, по несколько раз возникал некий штром со 100% загрузкой процессоров всех БДКОМов одновременно. Похоже что есть ошибка в прошивке БДКОМ-ов относительно DHCP-snooping. Какие может будут Ваши идеи по данному оборудованию?

В общем, провели эксперимент - убрали ip arp inspection vlan 331 и ip dhcp-relay snooping log. Стало работать лучше, подключили роутер к ОНУшке неправильно, так чтобы DHCP роутера смотрело в сторону сети. Разогнать процессор БДКОМа до 100% не удалось, ОДНАКО, вечером, когда много пользователей онлайн ситуация повторилась - все 4 OLT BDCOM ушли в 100% загрузку. Помогает краткосрочное отключение одного из ОЛТ, тогда через пару минут спадает загрузка всех ОЛТ. Загрузка процессора одного из БДКОМов Конфиг прилагается. bdcom2_20151211.txt

благодарю за советы, проведем эксперименты, по результатам отпишусь

Работаем по технологии IPoE. Есть 4 головы BDCOM - на 16 и на 8 направлений. Все четыре BDCOM включены в один свитч. Столкнулись со следующей проблемой - одновременно начинает колбасить все BDCOM. Загрузка процессоров подскакивает до 100% на всех головах одновременно. По нашим наблюдениям такое происходит когда появляется левый DHCP за ОНУшкой, к примеру, абонент не правильно подключил роутер. Провели эксперимент - Схема включения: Router TP-Link wr941nd <---> ONU BDCOM P1501C1 <---> BDCOM P3310 <---> BRAS Ericsson SE-100 <----> NAS <----> Internet При подключении Router TP-Link wr941nd в порты с ДХЦП-сервером на BDCOM P3310 нет никакой реакции, но CPU самого BDCOM P3310 еще не растет. По истечении ~ 4 мин. приходят сообщения о попытках отбросить ДХЦП-пакеты: BDCOM_4#Dec 9 17:28:14 %FILTER-4-UNBLOCK: [dhcp]Source MAC Address b048.7abf.8aa0 vlan 331 600s on EPON0/4 Dec 9 17:28:14 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:14 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:14 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:16 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:17 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:17 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:17 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:18 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:21 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped Dec 9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped При этом пока БДКОМ еще работает - пингуется по 0,5мс. Проходит еще ~4-5 минут. CPU BDCOM P33100 взлетает до 100%, при этом наблюдаем почти 100% потери пакетов ICMP. При этом все остальные BDCOM-ы также начинают тормозить и CPU у них вырастает до 100%. На других BDCOM-ах в логах нет никаких сообщений. Такая ситуация длится до тех пор пока не отключаем Router TP-Link wr941nd от ONU BDCOM P1501C1. Как только это сделали отключение, буквально через ~30-40 сек. восстанавливаться нормальная работа всех BDCOM-ов. Вот настройки из конфига BDCOM_1x8#sh ip dhcp-relay snooping ip dhcp-relay snooping ip dhcp-relay snooping vlan 331 ip arp inspection vlan 331 ip verify source vlan 331 ip dhcp-relay snooping log DHCP Snooping trust interface: GigaEthernet0/1 ARP Inspect trust interface: GigaEthernet0/1 IP source guard trust interface: GigaEthernet0/1 DHCP Snooping deny interface: ip dhcp-relay snooping db-file /dhcpr-database Кто-то встречался с подобным явлением? Как бороться?

Спасибо, посмотрел, информация не полная, но хоть что-то... С чего начинать получение частот для хот-спота WiFi, какой алгоритм действий?

Присоединюсь к вопросу - интересует организация в городе нескольких Хотспот зон (центральный парк и т.п.). Как получить частоты? Вроде бы в нашем городе заняты все частоты под организацию WiFi. Где можно проверить есть свободные частоты в городе или нет? Есть ли информация о том кто занял частоты в городе в открытом доступе на сайте Укрчастотнагляда?

это понятно, но кому верить Мультитесту или показаниям на голове БДКОМа? Расхождение стабильно 3- 3,5 дБ

да