Коммутаторы D-Link, как найти MAC соседнего?

[LostSoul]

Есть некая большая сеть ( сотни коммутаторов )

 

построенная на управляемых L2 свитчах D-Link.

 

STP в сети выключено. Сеть - сложное дерево, местами L3.

 

Подскажите, как бы по хитрому понять связи между коммутаторами.

 

То есть рассматривая отдельно взятый коммутатор, по таблице форвардинга мы можем понять каким портом он связан с какими другими коммутаторами....

 

но вот с каким конкретно?

Висит на порту 6 к примеру MAC десятка коммутаторов.

Как понять какой из них ближайший?

 

В голову напрашиваются варианты:

1) включить STP ( не хотелось бы )

2) написать скрипт отключающий магистральные порты на каждом коммутаторе, и отлавливающие трапы, откуда "link-down" прилетел ( наверное может не сработать с конвекторами , и монтажники пугают что оптические линки могут потом плохо подниматся )

 

Есть ли ещё варианты?

Всякую математику из области графов не предлагать. По ряду причин тут нужно более простое решение.

[BuHast]

1. У ДЛинк есть их утилита, которая может помочь, SIM mangement по моему. Она может строить связи.

2. Метод логических пертурбаций... Как я его вижу - заходим на свич, очищаем FDB table, потом смотрим на каком порту какой MAC появился и так далее.

3. При наличии L3 коммутаторов это несколько удобнее, тк можно смотреть привязки к портам уже IP, а не MAC.

[LostSoul]

[qoute]

2. Метод логических пертурбаций... Как я его вижу - заходим на свич, очищаем FDB table, потом смотрим на каком порту какой MAC появился и так далее.

[/qoute]

 

Ну вот появился MAC. Как понять - мак ближайшего к нам свитча появился, или самого дальнего?

[desperado]

в случае с деревом всё просто. по мере удаления от центра, количество маков на даунлинках убывает, смотрим некий порт на центральном свитче, составляем список маков на порту, ищем свитч имеющий мак один из этих и имеющий остальные маки из составленного списка на портах отличных от порта где имеется мак центрального свитча (аплинк). вообще аплинк однозначно идентифицируется по маку центрального свитча/роутера.

[LostSoul]

в случае с деревом всё просто. по мере удаления от центра, количество маков на даунлинках убывает, смотрим некий порт на центральном свитче, составляем список маков на порту, ищем свитч имеющий мак один из этих и имеющий остальные маки из составленного списка на портах отличных от порта где имеется мак центрального свитча (аплинк). вообще аплинк однозначно идентифицируется по маку центрального свитча/роутера.

Никакого центрального свитча нету!

Схема сети сложная, древовидная . Я сразу написал что подобные методы ( оптимизации найденных маков ) непригодны.

 

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

 

То есть нужен метод определения, какой именно свитч стоит с другой стороны линка.

[desperado]

Никакого центрального свитча нету!

возьми любой, представь, что он центральный. :)

 

То есть нужен метод определения, какой именно свитч стоит с другой стороны линка.

ddp?

[Kirya]

Кроме анализа таблицы ip-mac, надежного средства нет.

(зачем спрашивается отключали STP ?)

http://www.dlink.ru/technical/faq_hub_switch_106.php

А дальше mac-и загоняются в табличку и просчитываются.

[ugluck]

вроде на нек-рых длинках есть lldp... сам не видел, но пишут

[LostSoul]

вроде на нек-рых длинках есть lldp... сам не видел, но пишут

Увы, в DES нету.

 

 

Кроме анализа таблицы ip-mac, надежного средства нет.

(зачем спрашивается отключали STP ?)

http://www.dlink.ru/technical/faq_hub_switch_106.php

А дальше mac-и загоняются в табличку и просчитываются.

Это как раз ненадёжный способ.

 

Допустим, есть некое число свитчей которые нам недоступны и выпали из картины мира.

 

( ну например на сканирование не откликнулись потому что у них default gateway в настройках не прописан, потому что был включен какой-то ACL на управление или просто тупо повис )

 

так вот мне нужно иметь возможность чётко выявить, что кабель коммутатора А уходит к непонятному соседу , который не отвечает ... а не к тому следующему коммутатору в цепочке кто ответит)

 

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

[desperado]

так вот мне нужно иметь возможность чётко выявить, что кабель коммутатора А уходит к непонятному соседу , который не отвечает ... а не к тому следующему коммутатору в цепочке кто ответит)

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

тогда обломись, чудес не бывает.

[LostSoul]

так вот мне нужно иметь возможность чётко выявить, что кабель коммутатора А уходит к непонятному соседу , который не отвечает ... а не к тому следующему коммутатору в цепочке кто ответит)

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

тогда обломись, чудес не бывает.

Да разумеется бывают. Тока чудеса это некрасивые.

например настраиваем на коммутаторе snmp-trap

дальше дёргаем произвольный порт down-up.

С другой стороны линка приходит trap с номером коммутатора-порта)

 

Тока вот монтажники пугают что оптические вставки после down-up бывают плохо заводятся.

[S_ergey]

Тока вот монтажники пугают что оптические вставки после down-up бывают плохо заводятся.

Наверно и плохо если LC коннекторы пальцами помацать и в пыли повалять. А если еще и двухглазые то местами поменять. Проще показать о бьяснить и научить монтажников что нужно делать и как. И то что они пугают явно выходит из за незнания как работать с оптикой.

[zoro]

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

[desperado]

так вот мне нужно иметь возможность чётко выявить, что кабель коммутатора А уходит к непонятному соседу , который не отвечает ... а не к тому следующему коммутатору в цепочке кто ответит)

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

тогда обломись, чудес не бывает.

Да разумеется бывают. Тока чудеса это некрасивые.

например настраиваем на коммутаторе snmp-trap

дальше дёргаем произвольный порт down-up.

С другой стороны линка приходит trap с номером коммутатора-порта)

 

Тока вот монтажники пугают что оптические вставки после down-up бывают плохо заводятся.

у вас в таком гадюшнике от таких трапов должен сислог валиться. :)

к тому же в даун-то его дернули, а вот ап - уже с вероятностью 50% :) а в другие 50% трап не прийдет.

 

и вообще, это монтажники должны бояться админов а не наоборот :)

 

ЗЫ

можно еще байтики и пакетики считать

Edited January 16, 2008 by desperado

[LostSoul]

у вас в таком гадюшнике от таких трапов должен сислог валиться. :)

к тому же в даун-то его дернули, а вот ап - уже с вероятностью 50% :) а в другие 50% трап не прийдет.

 

и вообще, это монтажники должны бояться админов а не наоборот :)

 

 

 

ЗЫ

можно еще байтики и пакетики считать

Монтажники свои, а "эксперт" наёмный, косячить не должен ;)

 

насчёт 50% портов которые не поднимутся- фигня.

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

Во вторых -- перед отключением порта можно на пробу фильтровать MAC trap-сервера на том порту, который собираемся отправить в DOWN. Если управление свитчем пропало -- значит накосячили, снимаем фильтрацию, порт не трогаем и ставим на него флаг обхода)))