nocproject.org

http://forum.nocproject.org/index.php?topic=248.0

хорошая идея

только понятие "граница сети" надобы как-то конкретизировать

предел, за который NOC не лезет ;)

нок и не лезет за предел

в ноке нет железок за пределои, он и не сможет туда залезть

а если железка есть, значит это не предел

выдыхай

подумал насчет скоростей портов, трансиверов, консолей и прочего

причеш к выводу, что в connection type должна быть все-таки физика

то есть RJ45 и в африке RJ45

а вот в модели на connection можно сделать поле protocols

список строк с поддерживаемыми протоколами

а там может быть rs232, eth10, eth100, eth1g, eth10g

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

а еще самое время вспомнить 8P8C vs rj45

?

Термин «RJ45» ошибочно употребляется для именования разъёма 8P8C, используемого в компьютерных сетях. На самом деле настоящий RJ45 физически несовместим с 8P8C, так как использует схему 8P2C с ключом. Ошибочное употребление термина «RJ45» вызвано,

вероятно, тем, что настоящий RJ45 не получил широкого применения, а также их внешним сходством.

не читайте на ночь википедию

:)

хочешь сказать там гон

давай погуглим

дело то нехитрое

*не хитрое

есть устоявшийся термин

и во всех datasheet'ах именно он и указывается

по протоколам я думаю, что между sfp и шасси будет что-то вроде протоколов sfp_100m, sfp_1g, sfp_10g

на выходе из sfp - 10GBase-LR, 1000Base-LX и так далее

на медных портах - 1000Base-TX

и дополнительные ограничения ввести

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

тогда у нас получится 2 уровня фильтрации

физический -- влезет или не влезет

и логический

правда, придется изгаляться с кабелями

а есть официальный стандарт, или как это правильно назвать

это я так

вот что я думаю, на железках иногда выводят контакты и подписывают это как Alarms

что с ними делать

на патч-кордах протоколы явно не нужны

zi_home: я знаю

у mx на craft'е 2 выхода под alarm'ы

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

да

там 3 болта

вроде M4

у кого как

на длинке разъем под клеммник

на моих цисках, угадайте...rj45

возможно

алармы мы следующим шагом добъем

с протоколами додумать надо

патч корд соединяет два порта, протоколы надо сравнивать на концах патча

да

они как-то пересекаются с кроссировкой

в той части, если direction - s

вот тебе и ответ, не надо подавать 220В на DC PSU

с одной стороны протоколы есть, на патче нет

zi_home: да, я думал, 220vac, 110vac, 48vdc

так вот

с патчом надо следующее

если с одной стороны connection c протоколами и с типом s

то по группе смотреть, на какой выход скоммутируется этот connection у патча

если с другой стороны ничего нет, то соединиение возможно

если есть -- возможно только при совместимых протоколах, или если дальше еще один патч -- тогда рекурсивно

c DC сложнее, как как правило range

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

патч панели и кроссы нужны

ну да

смотри

они могут быть обычными объектами

с галочкой

если галочка включена, то проверяется connection group'ы

что в них один или 2 connection'а, не более

при этом они типа s

хотя так тоже плохо

это статическая кроссировка

задается в модели

нужно иметь еще возможность менять кроссировку у объекта

я потерял нить

так

тажется додумался

с другой стороны пойдем

в модели у нас есть connections

а мы еще можем добавить поле кроссировок

скажем, у патч-торда 2 connection'а

например, 0 и 1

с обоих концов

в таблице кроссировки у него будет соответсвенно 0-1

предположим у тебя есть 1000рублей, или для круглого счета, 1024рубля :)

это я про 0-1

:)

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

чего хочешь-то?

хочу две вещи

1. разделить параметры портов по rj45 может быть rs232, rs485, 10M, 100M, 1G

при этом могут быть порты, которые поддерживают 10/100 и 10/100/1000

то же и с sfp

куда-то можно совать 100-ку

куда-то нельзя

или в sfp+ где-то можно лепить гиговые sfp, а где-то нельзя

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

то же с питанием

где-то 110, где-то 220, а где-то 110/220

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

•For telecom applications (-36 to -72 VDC), set the DC-voltage selector to -48 VDC.

•For industrial applications (+18 to +36 VDC), set the DC-voltage selector to +24 VDC.

это про цисковские БП

с дополнительным требованием на наличие со второй стороны хоть одного совместимого протокола

а оно надо?

да, спасает от ошибок

для питания твои случаи -- два протокола -48vdc, +24vdc

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

с этим разобрались

2. ???

из первого вылезает очень серьезная проблема

с одной стороны у нас 2 rj45

первый выдает rs232, второй 10base-t, 100base-tx

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

и обламываемся

так как патч не поддерживает ни одного протокола

а протокол поддерживает хрень с другого конца

прописывать все, что можно на патче -- не вариант явно

патч втыкается в дырку с типом S

всегда

всегда?

всегда только патч?

ну да, наверное

s это connection

то что соединяет с другим портом

не всегда

иначе это не S

у порта на rj45 тоже S

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

на I и O требования по протоколам жесткие

либо совпадает, либо нет

а на S нужно найти то, что стоит с другого конца

и проверить протоколы там

при этом другой конец может быть в воздухе

и вообще сам патч может быть составным

например, с аттенюатором

может, но воздух означает что ОК

воздух -- ok

проверка будет когда второй конец приземлять будешь

не проблема, взял и проверил

там нет проблемы

но это работает только если у всех S'ок этих по пути -- строго 2 connection'а

правильно?

из первого пришел, из второго вышел

так?

похоже на правду

более расширенный вариант -- если мы принимаем в расчет группы

то есть мы пришли на S с группой, скажем, 15

находим другой S в этой группе и выходим из него

вот тебе простейшая кроссировка

так?

эээ

что за группа 15

в модели в connections прописана group

любая

вот представь у меня в одном кабеле 4 патч-корда

и что она означает

8 разъемов

1 соединяется с 5, 2 c 6 и так далее

1 и 5 в одной группе, обзываем ее 1

далее 2

и так далее

брр

вот оно мне самому и не нравится

:)

группа это набор портов на кроссах и патч-панелях?

нет

набор соединенных

во

кажись понял

не надо нам мучить группы

все проще гораздо

http://kb.nocproject.org/display/DEV/ObjectModel

в connections добавляем поле cross

с именем

тогда не надо никакие группы мочить

просто этот вход закорочен на этот выход

cable map будет?

и это, да

при этом мы сделаем cross в модели

это то, что внутри раскроссировано

и еще там можно будет указать, скажем *

что означает -- что этот connection может быть скроссирован непосредственно на объекте

вот тебе и разварки всякие

не пойму как все это связываться будет

:) вспомнил про адсл

и телефонистов

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

ну смотри

нет, я про другое

какие-то объекты, connection и прочее

а где все эти узлы связи

стойки на них

прочее

узел и стойка -- это объекты

в которые засунуты другие объекты

тут пока не про них

да вот я как раз про то что вс еще не про них

*все еще

и до них дойдем

может было бы проще если бы другое решили

тот же cable map

вот есть у тебя канал по кроссам

и все

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

?

ты просто сравнивал бы протоколы на концах

на концах канала

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

моя мысль в том чтобы

иметь cable map как надстройку, пусть это будет таблица кроссировки, не важно, абстракстно, и обращаться к этой надстройке за информацией

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

или туда 23 порт свича воткнут

и ты по этой информации действуешь

не усложняя модель ненужными подробностями

приерно как у тебя сейчас ФМ выводит дескрипшен порта, запрашивая его у инвентори

http://kb.nocproject.org/display/DEV/ObjectConnection

на самом деле вот тебе кабельный журнал

только в нем не только кабель, но и внутренние соединения

а у кабеля есть еще категория :)

гиговый линк и кабель третьей категории не дружат

возможно

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

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

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

в inventory

id понятно

сплиттеры еще есть

скрутки?

вход один - выходов много

нет, скруток у нас там нет

или ты не знаешь о них :)

там сплиттеры есть, которые аналоговый TV сигнал по оптики расшепляют

для них трассировка пути зависит от направления

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

есть задача -- трассировка оптического пути

нужная задача задача

если будешь светить с одной стороны -- выйдешь на все разветвления

а если с другой -- только к источнику

а чего хочешь никто не знает?

Ж)

http://kb.nocproject.org/display/DEV/ObjectModel

поле cross

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

кстати и сплиттеры вполне можно положить на эту модель

стоп

по sfp -- только протокол

кроссировка -- это кабель

да-да, я помню

какие объекты описывает ObjectModel?

почему в кросс ты говоришь о connections объекта

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

остается пожелать удачно все это реализовать

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

http://kb.nocproject.org/display/DEV/ObjectModel

вот, смотри примеры

http://kb.nocproject.org/display/DEV/Protocols

подумаю пока