Распиновка такая

Это вообще от циски консольник походу может не подойти

Бля да это тупой консольник там протокол не тот

/summary@summarization_bot

/text@summarization_bot

/clear@summarization_bot

Евгений: Добрый Чаннел: config user Чаннел: Брат только по консоли и командами делать ресет Чаннел: Может скорей всего консольный кабель не тот есть разные с 4 жидами обжаты и 8 и всё по разному Чаннел: Это вообще от циски консольник походу может не подойти Чаннел: Бля да это тупой консольник там протокол не тот

Последние 6 сообщений суммаризованы так: Евгений не знает правил домашнего компьютера. Чаннел думает, что это тупой консольник. Если вы хотите ускорить работу бота или ваше имя обрабатывается неправильно - поддержите нас на Boosty! https://boosty.to/summarization_bot/about

Сообщения удалены

Пустой текст!

как быть если на 1210-28/me в блок попал адрес шлюза? весь сегмент сети перестает работать

или мак-адрес шлюза, ситуация схожая

и до кучи XS/ME на 61й прошивке кто-нибудь проверял?

в какой блок?

IPMPB

а как он туда попал? кадр с него прилетел а мак в таблице был прописан один?

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

статически записать

коммутатор блокированные мак-адреса видет и транслирует дальше

и вообще странно, при наличии IPMPB записи, показывать мак на порту, при отсутствии линка

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

он же показывает тип записи, нет?

он заблокировался на порту клиента т.к. нет такого ip в биллинге, но при этом виден на коммутаторе и не дает работать всей подсети

и вообще странно, при наличии IPMPB записи, показывать мак на порту, при отсутствии линка

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

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

петлей возвращает мак провайдерского свича?

петлей возвращает мак провайдерского свича?

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

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

Тогда надо петлю устранить, всё остальное — костыли.

Тогда надо петлю устранить, всё остальное — костыли.

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

петлей возвращает мак провайдерского свича?

У нас лично мак абонента оставался на порту

И интернет ток у абонента не пахал

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

Можно повысить лимит привязки на порту до 2.

на петле там много летит

А откуда это возникало,совсем с другой точки города,так что инженер долго и упорно искал кривого абонента

Можно повысить лимит привязки на порту до 2.

и чем это поможет? проблема в том что заблокированные маки видят другие клиенты, и даже если у клиента ip-mac стали правильные, блокированный мак висит на свиче, и не факт что это петля, из последнего, несколько раз в день на порту абонента выскакивает ip-mac шлюза, и это не кольцо, перестает работать вся подсеть, помогает del ad b a, но не надолго, в результате пришлось отключить порт и отправить туда человека, посмотреть что у абонента происходит

логика не правильная, не должны быть видны другим клиентам маки того что заблокировано, и еще до кучи 2 свича, абонент привязан на 1м свиче, его переключают во второй, и он не работает, т.к. на первом есть его старая привязка ipmpb и его мак там светится, даже линка нет, а из-за того что есть привязка мак светится

это про серию DGS-1210-28_ME и иже с ними, на 3526 и 3200 ничего подобного не было

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

это про серию DGS-1210-28_ME и иже с ними, на 3526 и 3200 ничего подобного не было

про эту серию на форуме длинка больше чем в большой советской энциклопедии писано :)

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

да

про эту серию на форуме длинка больше чем в большой советской энциклопедии писано :)

этой серии уже сколько лет? а допилить прошивку так и не смогли

стали шить 57ю, а на ней с qinq проблемы, попробовали 61ю, с qinq порядок, но свичи XS/ME по управлению стали отваливатся

1) коммутатор создает запись fdb по _любому_ _валидному_ фрейму. тоесть, если мак появился за портом абона, значит, с порта абона прилетел собранный фрейм правильного размера и с корректной crc и с маком отправителя, равным маку вашего шлюза. если LBD не срабатывает на этот порт, то весьма вероятно что имеет место атака по модели MitM. Дальше, А ЧТО МЕШАЕТ ВАМ РУЧКАМИ СОЗДАТЬ СВЯКУ МАК-ИП ШЛЮЗА ЗА СООТВЕТВУЮЩИМ АПЛИНКОМ? Господа, это управляемое оборудование, оно собственной воли не имеет. оно работает ровно так, как его настроили.. Самоуправляемого оборудования, извините, нет... Посему железом надо рулить.

ну вчера я предлагал статически создать запись на легальном порту наверное не получилось

и чем это поможет? проблема в том что заблокированные маки видят другие клиенты, и даже если у клиента ip-mac стали правильные, блокированный мак висит на свиче, и не факт что это петля, из последнего, несколько раз в день на порту абонента выскакивает ip-mac шлюза, и это не кольцо, перестает работать вся подсеть, помогает del ad b a, но не надолго, в результате пришлось отключить порт и отправить туда человека, посмотреть что у абонента происходит

объясните что значит "заблокированные маки видят другие клиенты"?

в логах висит 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: 19), это ip-mac шлюза на порту конечного абонента, это не кольцо

ну увидел он на чужом порту мак и откинул. или настроено гашение порта?

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

в логах висит 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: 19), это ip-mac шлюза на порту конечного абонента, это не кольцо

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

или в отдел к написать приложив сниф и логи, пусть таким клиентом занимаются компетентные люди

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

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

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

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

ну, для этого надо понять как работает свичь. в данном случае за портом клиента прописывает мак, на который все остальные клиенты шлют запросы. напомню, по стандартам, мак это УНИКАЛЬНЫЙ идентификатор физического интерфейса, и может существовать только в единственном экземпляре.

ну, для этого надо понять как работает свичь. в данном случае за портом клиента прописывает мак, на который все остальные клиенты шлют запросы. напомню, по стандартам, мак это УНИКАЛЬНЫЙ идентификатор физического интерфейса, и может существовать только в единственном экземпляре.

discarded кадры точнее маки с них в таблицу пишутся? при том что там есть статически запись impb?

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

discarded кадры точнее маки с них в таблицу пишутся? при том что там есть статически запись impb?

как думаешь, discarded входит в подмножество "любой валидный фрейм"?

как думаешь, discarded входит в подмножество "любой валидный фрейм"?

конечно нет

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

в последний раз спрашиваю, объясните что значит "заблокированные маки видят другие клиенты"? что значит "видят"? Они что, пингуются, с ними сессии устанвливаются?

за 19 портом что находится?

за 19 портом что находится?

роутер клиента, по sh ad b a блокировка висит, делаем del ad b a, блокировка уходит, пошли пинги до клиентов ил этой подсети

как думаешь, discarded входит в подмножество "любой валидный фрейм"?

или в данном случае входит? ну даже если бы входил - запись то есть мака и ИП за портом аплинка. раз impb работает.

роутер клиента, по sh ad b a блокировка висит, делаем del ad b a, блокировка уходит, пошли пинги до клиентов ил этой подсети

sh fdb при этом мак щлюза показывает за каким портом?

А если в разные виланы разнести то какая разница какой там мак будет в другом вилане? Например

sh fdb при этом мак щлюза показывает за каким портом?

при повторении проблемы посмотрю

при повторении проблемы посмотрю

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

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

если его отбрасывает impb то он прибит, нет?

при повторении проблемы посмотрю

последний раз было с 2024 Jan 28 19:54:31 по 2024 Feb 1 14:15:07, потушили порт т.к. это происходило несколько раз в день, и решили пожертвовать одним абонентом, ради других

последний раз было с 2024 Jan 28 19:54:31 по 2024 Feb 1 14:15:07, потушили порт т.к. это происходило несколько раз в день, и решили пожертвовать одним абонентом, ради других

Дык у тебя по дефолту должно быть "честный абоны не должны страдать от действий нечестного", не?

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

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

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

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

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

я уже ответил на этот вопрос, может косвенно, есть нное количество свичей, клиенты в одном влане, звонит абонент, говорит не работает интернет, запускаю пинг, пинга нет, делаю на свиче где висит блокировка del ad b a , пошел пинг до клиента и соответственно интернет завелся у клиента, блокировка и клиент связаны только тем что они в одном влане

ааа... имеется в виду что заблокированные на порту маки (шлюза в данном случае например) другим клиентам доступны. так что ли?

я уже ответил на этот вопрос, может косвенно, есть нное количество свичей, клиенты в одном влане, звонит абонент, говорит не работает интернет, запускаю пинг, пинга нет, делаю на свиче где висит блокировка del ad b a , пошел пинг до клиента и соответственно интернет завелся у клиента, блокировка и клиент связаны только тем что они в одном влане

traffic_segmentation используете?

я уже ответил на этот вопрос, может косвенно, есть нное количество свичей, клиенты в одном влане, звонит абонент, говорит не работает интернет, запускаю пинг, пинга нет, делаю на свиче где висит блокировка del ad b a , пошел пинг до клиента и соответственно интернет завелся у клиента, блокировка и клиент связаны только тем что они в одном влане

как только прилетает с 129 порта пакет, где маком отправителя прописан мак шлюза, в фдб свича этот мак прибивается на 19 порт (если не включен портсек) и все, дальше все пакеты от всех юзерей, который подключены ко всем свичам, подключенным ниже данного свича летят куда? в 19ый порт. атака по модели Man in the Middle удалась. вопрос, что ты сделал чтобы эта атака не удалась? прописал ограничение записей в портсеке? прибил вручную мак шлюза на аплинк в портсеке и порт-ип-мак биндинге?

traffic_segmentation используете?

да, но это помогает в рамках одного коммутатора, а если их 10?

traffic_segmentation используете?

по секрету, его практически никто не испотльзует. или просто влан или уже приват влан

по секрету, его практически никто не испотльзует. или просто влан или уже приват влан

😅 Каюсь, грешен. От легаси всегда сложно избавляться.

как только прилетает с 129 порта пакет, где маком отправителя прописан мак шлюза, в фдб свича этот мак прибивается на 19 порт (если не включен портсек) и все, дальше все пакеты от всех юзерей, который подключены ко всем свичам, подключенным ниже данного свича летят куда? в 19ый порт. атака по модели Man in the Middle удалась. вопрос, что ты сделал чтобы эта атака не удалась? прописал ограничение записей в портсеке? прибил вручную мак шлюза на аплинк в портсеке и порт-ип-мак биндинге?

вопрос почему тогда кадр дискардед?

вопрос почему тогда кадр дискардед?

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

как только прилетает с 129 порта пакет, где маком отправителя прописан мак шлюза, в фдб свича этот мак прибивается на 19 порт (если не включен портсек) и все, дальше все пакеты от всех юзерей, который подключены ко всем свичам, подключенным ниже данного свича летят куда? в 19ый порт. атака по модели Man in the Middle удалась. вопрос, что ты сделал чтобы эта атака не удалась? прописал ограничение записей в портсеке? прибил вручную мак шлюза на аплинк в портсеке и порт-ип-мак биндинге?

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

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

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