aaaaa

благодарю

Добрый день, как в 2980 включить балансировку на lag в новых коммутаторах snr делаю: port-group 1 Interface Port-Channel1 load-balance dst-src-ip а здесь нет load-balance? SoftWare Version 7.0.3.5(B0207.0019)

)))

я у себя это тоже спрашивал.. просто плодит логи, решил узнать, есть ли решение.

Порой возникает такая ситуация, как я понимаю зависает роутер у абонентов и начинает отключать и включать линк. Со стороны коммутатора это выглядит так: порт переходит в down сначала показывает: Time since last status change:0w-0d-0h-0m-0s (0 seconds) потом: Time since last status change:118w-2d-12h-6m-28s (71582788 seconds) потом: Time since last status change:0w-0d-0h-0m-0s (0 seconds) и возвращается в состояние up и так происходит не реже раза в минуту, может и каждые 10 секунд. Можно ли избежать подобного состояния (частого отключения и включения порта) настройками со стороны коммутатора?

На одном из коммутаторов возникла такая картина:) nbo_8_1.1(config)#sh cpu ut Last 5 second CPU USAGE: 78% Last 30 second CPU USAGE: 77% Last 5 minute CPU USAGE: 68% From running CPU USAGE: -2168% На самом деле я так понимаю anti-arpscan помогает только от сканирования mac, но при желании можно сканировать с меньшим количеством пакетов. Фактически от дальнейший реализации подмены мака спасет: ip dhcp snooping binding user-control ip dhcp snooping binding user-control max-user 5 от чужого dhcp-server ip dhcp snooping action blackhole от штормов: storm-control unicast 63 rate-violation broadcast 200 rate-violation multicast 200 rate-violation control shutdown recovery 3600 от петель loopback-detection specified-vlan 101 loopback-detection control shutdown от лишних подключений switchport port-security switchport port-security violation protect как я предполагаю дополнительно включать anti-arpscan это ресурсы на ветер, плюс у некоторых пользователей все равно валится по 15-20 arp пакетов?

Правила действительно обрабатываются до dhcp, в отличии от snr 2960 и орионов. В данном случае проблема была в том, что разрешено с только с permit ip 172.16.0.0 0.0.3.255 any-destinationpermit ip 10.0.0.0 0.0.3.255 any-destination и нет разрешения для первого запроса без ip: как указано выше, проблема была решена permit udp any-source host-destination 255.255.255.255 d-port 67

После включения anti-arpscan на коммутаторах изменился cpu utilization c 35-40% до 70-80% это нормальное поведение?

Проблема с dhcp, после подключения данных правил к порту, все работает, но если выключить и включить порт deb ip dhcp sn pa на данном порту пустой. SoftWare Version 7.0.3.5(R0102.0138) nbo_2_1.2(config-if-ethernet1/0/42)#ip access-group users in nbo_2_1.2(config-if-ethernet1/0/42)#shu nbo_2_1.2(config-if-ethernet1/0/42)#%Jan 23 18:08:56 2018 %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/0/42, changed state to DOWN %Jan 23 18:08:56 2018 %LINK-5-CHANGED: Interface Ethernet1/0/42, changed state to administratively DOWN nbo_2_1.2(config-if-ethernet1/0/42)#no%Jan 23 18:09:02 2018 DHCPS: rcv packet from client e0-cb-4e-ed-f8-08, interface Ethernet1/0/48(portID 0x1000030), length 594, type DHCPREQUEST, opcode BOOTREQUEST, stacking 0 %Jan 23 18:09:02 2018 DHCPS: Sending port must be trust port for DHCP request unicast packet for dhcp server 00-21-5e-3f-3c-96 in vlan 101 shu nbo_2_1.2(config-if-ethernet1/0/42)#%Jan 23 18:09:04 2018 %LINK-5-CHANGED: Interface Ethernet1/0/42, changed state to UP %Jan 23 18:09:04 2018 %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/0/42, changed state to DOWN nbo_2_1.2(config-if-ethernet1/0/42)#%Jan 23 18:09:06 2018 %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/0/42, changed state to UP %Jan 23 18:09:25 2018 DHCPS: rcv packet from client e8-94-f6-af-0f-81, interface Ethernet1/0/48(portID 0x1000030), length 594, type DHCPREQUEST, opcode BOOTREQUEST, stacking 0 %Jan 23 18:09:25 2018 DHCPS: Sending port must be trust port for DHCP request unicast packet for dhcp server 00-21-5e-3f-3c-96 in vlan 101 %Jan 23 18:09:34 2018 DHCPS: rcv packet from client e0-cb-4e-ed-f8-08, interface Ethernet1/0/48(portID 0x1000030), length 594, type DHCPREQUEST, opcode BOOTREQUEST, stacking 0 %Jan 23 18:09:34 2018 DHCPS: Sending port must be trust port for DHCP request unicast packet for dhcp server 00-21-5e-3f-3c-96 in vlan 101 %Jan 23 18:09:50 2018 DHCPS: rcv packet from client e0-cb-4e-ed-f8-08, interface Ethernet1/0/48(portID 0x1000030), length 594, type DHCPREQUEST, opcode BOOTREQUEST, stacking 0 %Jan 23 18:09:50 2018 DHCPS: Sending port must be trust port for DHCP request unicast packet for dhcp server 00-21-5e-3f-3c-96 in vlan 101 nbo_2_1.2(config-if-ethernet1/0/42)#no ip access-group users in nbo_2_1.2(config-if-ethernet1/0/42)#%Jan 23 18:09:58 2018 DHCPS: rcv packet from client e0-cb-4e-ed-f8-08, interface Ethernet1/0/48(portID 0x1000030), length 594, type DHCPREQUEST, opcode BOOTREQUEST, stacking 0 %Jan 23 18:09:58 2018 DHCPS: Sending port must be trust port for DHCP request unicast packet for dhcp server 00-21-5e-3f-3c-96 in vlan 101 shu nbo_2_1.2(config-if-ethernet1/0/42)#%Jan 23 18:10:01 2018 %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/0/42, changed state to DOWN %Jan 23 18:10:01 2018 %LINK-5-CHANGED: Interface Ethernet1/0/42, changed state to administratively DOWN no shu nbo_2_1.2(config-if-ethernet1/0/42)#%Jan 23 18:10:06 2018 %LINK-5-CHANGED: Interface Ethernet1/0/42, changed state to UP %Jan 23 18:10:06 2018 %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/0/42, changed state to DOWN %Jan 23 18:10:08 2018 %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet1/0/42, changed state to UP %Jan 23 18:10:09 2018 DHCPS: parse packet from client c4-6e-1f-90-dd-ff, failed interface Ethernet1/0/42(portID 0x100002A), length 594, type DHCPRELEASE, opcode BOOTREQUEST, stacking 0 %Jan 23 18:10:09 2018 Port-security has reached the threshold on Interface Ethernet1/0/42, so packets with unknown source addresses are dropped! %Jan 23 18:10:11 2018 DHCPS: rcv packet from client c4-6e-1f-90-dd-ff, interface Ethernet1/0/42(portID 0x100002A), length 594, type DHCPDISCOVER, opcode BOOTREQUEST, stacking 0 %Jan 23 18:10:11 2018 DHCPR PACKET: build circuit id with vid <252>, portname <Ethernet1/0/42> %Jan 23 18:10:11 2018 DHCPR PACKET: rcvd request packet, length <548>, making our circuit-id <00:06:00:65:01:00:00:2A>, our remote-id <F8:F0:82:73:47:C1> DHCPR PACKET:receive relay request packet,and enter function fnDhcpRelayRequest(). %Jan 23 18:10:11 2018 DHCPR PACKET: rcvd BOOTPREQUEST from client 1 c4-6e-1f-90-dd-ff on interface Vlan252. %Jan 23 18:10:11 2018 DHCPR PACKET: inserted an option 82(subscriber-id 00:06:00:65:01:00:00:2A remote-id F8:F0:82:73:47:C1) into this request packet(type:1), new packet length 317 %Jan 23 18:10:11 2018 DHCPR PACKET: unicasting BOOTP-REQUEST from client c4-6e-1f-90-dd-ff to server/relay 10.0.100.253

Добрый день, ниже написанные правила работают на snr s2960, orion alpha a26. для работы на SNR-S2965-24T работают, если разрешить ARP путем permit any-source-mac any-destination-mac tpid 806 ip any-source any-destination, что надо сделать на SNR-S2990G-48T для работы данных правил? ip access-list extended users deny ip any-source host-destination 255.255.255.255 deny ip any-source 10.0.0.0 0.255.255.255 deny ip any-source 172.16.0.0 0.15.255.255 deny ip any-source 192.168.0.0 0.0.255.255 deny ip any-source 224.0.0.0 15.255.255.255 permit ip 172.16.0.0 0.0.3.255 any-destination permit ip 10.0.0.0 0.0.3.255 any-destination deny ip any-source any-destination exit

Да, отключается именно процессом anti-arpscan, блокируются по ip, так как порт в up. Думал дело в оборудовании клиента/прошивке, но подключили роутер той же модели с той же прошивкой, что работал нормально на другом коммутаторе, к коммутатору, который отключает абонентов, после чего данный роутер минут через 15 был отключен процессом anti-arpscan.

Orion А26   У меня на нескольких коммутаторах а26 включен anti-arpscan, данные коммутаторы находятся в разных домах, в разных вланах управления. На магистральных настроен supertrustport, настройки коммутаторов идентичные. Все пользователи в одном влан и там и там. На одном коммутаторе часто отключаются абонентские порты на другом все спокойно. Что, кроме абонентского оборудования может влиять на срабатывания anti-arpscan?

Еще вопрос про разницу в блокировке, при обнаружение арп запросов с наличием src-ip блокируются пакеты с данным ip на порту, порт не переходит в состояние down, правильно? А при обнаружении превышения пакетов без src-ip порт переходит в состояние shutdown by anti-arpscan?

насколько помню вам нужны таблица с inetnum и таблица с route

Спасибо.

Подскажите пожалуйста, для включения anti-arpsсan на а28 (используется релей) достаточно: ip arp-inspection trust на магистральный порт, глобально: ip arpinspection dhcp-relay ip arprate-limit recover enable на пользовательские порты ip arp-rate-limit enable верно?

Спасибо.

Добрый день, чем отличается настройка порта в trust от supertrust?

Причина флуда, в абоненте. Юрлицо, имеет несколько своих услуг, в том числе раздачу трафика. Они реализовали авторизацию на своих вайфай сторонним решением, поставили у себя железку, которая обращалась в инет и т.д.. Итоговое решение по флуду было в замене железки. Далее теория и анализ пакетов, каким то боком часть тафика шла с src-mac одного из их устройств находящимся за их натом, а src-ip был белый ип их ната. Соответственно трафик обратно шел на их белый ип, но попадая в нашу сеть, где не было данного мака, трафик блуждал по всем портам.

Но попробую на будущее, выставить ограничение на всех портах для uncnown unicast

Трафик попадает из вне. Пакеты пока не изучал, но ip назначения из моей сети. Т.е. как-что предполагаю либо исходящий у абонента идет одним путем а входящий другим (раз пакет попадает в сеть, а на коммутаторах нет мака) или еще что-то. Я хотел получить информацию о том, сможет ли таблица маков заполняться без unicast трафика.

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

В заполнение мак таблицы коммутатора участвуют broadcast или uncnown unicast пакеты? _lynx

Добрый день, подскажите возможные последствия полного запрета в сети передачи uncnown unicat.

Добрый день, в сети используется dhcp opt.82 с релеем на каждом коммутаторе. Пользователь может получать ip из следующих сетей: 172.16.0.0/22, 10.0.0.0/22, 185.1.1.0/22 Цель: 1. пользователь без ip - может выполнить только dhcp запрос 2. пользователь с ip не должен никак взаимодействовать с остальными пользователями. Текущие Acl: deny ip any-source host-destination 255.255.255.255 deny ip any-source 192.168.0.0 0.0.255.255 deny ip any-source 172.16.0.0 0.15.255.255 deny ip any-source 10.0.0.0 0.255.255.255 deny ip any-source 185.1.1.0 0.0.3.255 permit ip 172.16.0.0 0.0.3.255 any-destination permit ip 10.0.0.0 0.0.3.255 any-destination permit ip 185.1.1.0 0.0.3.255 any-destination deny ip any-source any-destination Подскажите, что можно добавить в acl.