спасибо за наводку, посмотрю в эту сторону, но у меня в голове до сих пор не укладывается почему блокированный мак как-то влияет на работу остальных

То у одного клиента пропадает инет теперь у остальных..

Ну источник блокировки impb на сколько я понимаю из лога. Если кадр прилетел и был отброшен как не авторизованный для данного порта то значит есть статическая запись где он должен быть. От impb или от портсека например. Мне кажется что в таком случае запись в таблице не должна меняться не смотря на то что кадр валидный. Или я ошибаюсь? Если бы мак залочился например политикой то источником события был бы не impb кмк.

или ипмб ранее прописал правильную связку и все другое отбрасывает. еще, кстати, большой вопрос как ипмб настроен, ARP или ip режим

Если только он отбросил по несоответствию не мак а IP тогда по идее перезапишет fdb. Вы это имеете в виду?

Если только он отбросил по несоответствию не мак а IP тогда по идее перезапишет fdb. Вы это имеете в виду?

ага

сюда можно скидывать все настройки порта? это не наказуемо?

ненаказуемо, но есть чатик свичеводов, а тут больше по роутерам, лучше там https://t.me/dlinkru

show ports 19 configuration all Command: show ports 19 configuration all port:19 -------------------------- Port Status: Link Down Vlan Information: PVID: 2543 Static: Tagged: Untagged: 2543 Dynamic: GVRP State: Disabled Vlan trunk: Disabled ACL: Profile ID: 25 Access ID: 1 2 128 Loopdetect Status: State: Enabled Address Binding: Protocol State: Enabled for IPv4 ARP Inspection: Strict IP Inspection: Enabled ND Inspection Disabled Allow Zero IP: Enabled DHCPv4 Snooping: Disabled DHCPv6 Snooping: Disabled Port Security: Disabled Limited Multicast Address: None Bandwidth control: Tx Rate: No limit Rx Rate: No limit DHCP Local Relay: DHCP/BOOTP Local Relay Status : Disabled Traffic Control: Broadcast: Enabled Multicast: Enabled Unicast: Disabled Unicast Action: Shutdown Multicast Action: Shutdown Broadcast Action: Shutdown DHCP Relay: DHCP/BOOTP Relay Status : Disabled Link Aggregation: None PPPoE Circuit ID Insertion: None Traffic Segmentation: 23-28 STP: State: Disabled BPDU Forwarding: Disabled Port Status: Disabled Port Role: Disabled BPDU Protection: State: Enable Mode: Drop Status: Normal 802.1x Status: None

ненаказуемо, но есть чатик свичеводов, а тут больше по роутерам, лучше там https://t.me/dlinkru

то что здесь больше по роутерам понял, у меня оба чата, просто этот первый под руку попался)

были у абонента, заменили кабель, порт, у абонента меш система Deco, результат 0, IMPB-4: Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 10.108.205.1, MAC: F8-F0-82-76-1D-02, Port: 10), толи с роутером что-то не так, толи самому к абоненту ехать, треш

были у абонента, заменили кабель, порт, у абонента меш система Deco, результат 0, IMPB-4: Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 10.108.205.1, MAC: F8-F0-82-76-1D-02, Port: 10), толи с роутером что-то не так, толи самому к абоненту ехать, треш

и на каком порту мак роутера по fdb?

кстати там лупбек не настроен у абона?

конечно настроен

включил ему порт, и вот что в логах, сначала заблокировался ip-mac шлюза, потом появился мак клиента 2024 Feb 4 11:53:03 10.12.31.119 IMPB-4: Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 10.108.205.1, MAC: F8-F0-82-76-1D-02, Port: 10) 2024 Feb 4 12:10:28 10.12.31.119 IMPB-4: Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 10.108.205.1, MAC: 18-C0-4D-01-31-76, Port: 10)

конечно настроен

я имел в виду loopback интерфейс с его стороны.

Можно было тестовый роутер поставить,чтобы понять он чпокает мозги или нет

Можно было тестовый роутер поставить,чтобы понять он чпокает мозги или нет

это если в венде поставить адаптер замыкания на себя и сделать на него бридж - вот то же самое и будет.

конечно настроен

Вам же предложили МАК шлюза явно прописать за аплинком

и что в FDB?

sh ad b a Command: show address_binding blocked all VID IP Address MAC Address Port ---- --------------------------------------- ----------------- ---- 2543 10.108.205.1 18-C0-4D-01-31-76 10

2543 2543 F8-F0-82-76-1D-02 24 Dynamic

мак шлюза где сейчас

Вам же сказали что сделать и что посмотреть

были у абонента, заменили кабель, порт, у абонента меш система Deco, результат 0, IMPB-4: Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 10.108.205.1, MAC: F8-F0-82-76-1D-02, Port: 10), толи с роутером что-то не так, толи самому к абоненту ехать, треш

это шлюз, 2995 наговский, 2543 10.108.205.1 18-C0-4D-01-31-76 10 а это клиент

это шлюз, 2995 наговский, 2543 10.108.205.1 18-C0-4D-01-31-76 10 а это клиент

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

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

как наговский мак на порту клиента оказвыается? и с ip шлюза, да выше, l3-snr далее несколько /me

может схему нарисуете? :)

мне кажется что проблема в клиентском роутере, но почему это влияет на всю подсеть?

как наговский мак на порту клиента оказвыается? и с ip шлюза, да выше, l3-snr далее несколько /me

а какой там должен оказаться? в моем понимании, мак ван порта девайса, стоящего первым

то что с кли ентского порта прилетел IP и мак шлюза говорит скорее всего об атаке. ну или о лопбеке

то что с кли ентского порта прилетел IP и мак шлюза говорит скорее всего об атаке. ну или о лопбеке

лупбек исключен, там сегодня были и все что можно поменяли-проверили

может схему нарисуете? :)

jun - SNR-S2995G-24FX - D-Link DGS-1210-28/ME - D-Link DGS-1210-28/ME (с проблемой) - D-Link DGS-1210-28/ME

да, стало понятнее :)) jun это абонент?

Коммутатор Juniper EX8216

роутер абонента подключен на клиентский порт проблемного а инет отваливается у юзеров последнего 1210?

роутер абонента подключен на клиентский порт проблемного а инет отваливается у юзеров последнего 1210?

да, но точной статистики нет, это умозаключение сделано из предыдущих подобных случаях

тут собственно и суть вопроса, почему левые-заблокированные маки влияют на работу сети, ответ я получил, попробую что-то сделать

роутер абонента подключен на клиентский порт проблемного а инет отваливается у юзеров последнего 1210?

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

он не в блоке висит он в FDB таблице висит.

да, заблокированный попадает в fdb

потому и просили посмотреть за каким портом он мак шлюза в таблице. если за клиентским то так и будет. он же все запросы к шлюзу шлет клиенту. а уж намеренно или нет так сделано....

и если есть привязка ipmpb она тoже в fdb, даже если линка нет

заблокированные тоже fdb, и в этом проблема

не заблокированые а отброшенные

но это по мак-соурсу. а мак-дестинейшн никто не блокировал и свич думает что он за 19 портом. и трафик остальных туда перенаправляет

как отброшенные могут влиять на остальных?

они и не влияют

очень как влияют, у клиента вылез ip-mac шлюза и весь дом начинает звонить что интернет не работает

на аплинке же нет привязки верно?

не влияют они. не в этом проблема

нет, привязка только на абонетских портах

привязка статическая или динамически 1 адрес изучается и привязывается?

статическая

У вас коллизии маков исключены ?

Я же правильно понял, что коммутатор 1210me ?

У вас коллизии маков исключены ?

не понимаю как это может повлиять

Я же правильно понял, что коммутатор 1210me ?

да

с порта прилетает мак. Он запрещен потому как за портом числится другой. Но при этом он попадает в таблицу. Для всех остальных клиентов шлюз по умолчанию (снр) становится за 19 портом. Куда они и шлют свои запросы. А шлюза там нет. Вот и не работает.

enable flood Подождать несколько секунд show flood

с порта прилетает мак. Он запрещен потому как за портом числится другой. Но при этом он попадает в таблицу. Для всех остальных клиентов шлюз по умолчанию (снр) становится за 19 портом. Куда они и шлют свои запросы. А шлюза там нет. Вот и не работает.

да

нет, привязка только на абонетских портах

Заметил, что у вас IMPB без DHCP Snooping. Не пробовали его в связку добавить?

с порта прилетает мак. Он запрещен потому как за портом числится другой. Но при этом он попадает в таблицу. Для всех остальных клиентов шлюз по умолчанию (снр) становится за 19 портом. Куда они и шлют свои запросы. А шлюза там нет. Вот и не работает.

А такое может происходить если какой-то мак клиента и шлюза словили коллизию

Заметил, что у вас IMPB без DHCP Snooping. Не пробовали его в связку добавить?

нет, не пробовали

А такое может происходить если какой-то мак клиента и шлюза словили коллизию

да может

А такое может происходить если какой-то мак клиента и шлюза словили коллизию

вариантов много, но почему он в fdb попадает

только шлюз snr там маки специфические. Хотя в последниз битах может быть

вариантов много, но почему он в fdb попадает

потому что он с порта прилетел.

потому что он с порта прилетел.

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

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

он отбрасывает мак потому что с данного порта такой максаурс прилетать не может. Но это не мешает ему быть в fdb.

он не мешает свич просто согласно таблице редиректит на этот порт весь трафик и все.

ipmpb разве не для того чтобы неверных блокировать? почему верные перестают работать когда свич заблокировал неверного?

Хм, пожалуй, тут могло бы частично помочь включение port_security с правильно подобранным периодом deleteontimeout. Кое-где у меня это используется. Если я правильно понял логику работы этой функции, конечно.

Хм, пожалуй, тут могло бы частично помочь включение port_security с правильно подобранным периодом deleteontimeout. Кое-где у меня это используется. Если я правильно понял логику работы этой функции, конечно.

спасибо, тоже поизучаю, а то проблема не единичная, и чем больше /me, тем чаще встречается

ipmpb разве не для того чтобы неверных блокировать? почему верные перестают работать когда свич заблокировал неверного?

в fdb неверная запись порта за которым находится мак который arp резолвит на запрос адреса шлюза

при наличии привязки ipmpb и отсутствии линка на порту, должен быть виден мак?

при наличии привязки ipmpb и отсутствии линка на порту, должен быть виден мак?

Клиентский — нет, шлюза — да.

а он виден в fdb и переключи клиента в нижестоящий свич, он не работает, т.к. его мак виден выше

а он виден в fdb и переключи клиента в нижестоящий свич, он не работает, т.к. его мак виден выше

clear fdb не приносит избавления?

Клиентский — нет, шлюза — да.

Вам наверное повезло обойти эту серию стороной