megahertz0

Привет! Поставил тут недавно циску 4900M вместо 3750G, перенес конфиг и заметил, что с SFP в на half card (включены через родной цисковский X2->SFP конвертер) не видно DDM. При этом с SFP+ воткнутых в бортовые десятки все исправно читается. SFP точно с DDM. Это у нас что-то не так работает или такая особенность конкретно 4900M?

И здесь микротики и убнт :) По поводу того чтобы растянуть оптику и питание я тоже уже думал. Изначально так и хотелось, но пришлось пересматривать решение. И вот почему. 220В питание в земле штука все-таки более серьезная чем PoE со своими 48 вольтами. Грубо говоря, гофру с витой парой можно закопать на штык, а питание уже надо закапывать посерьезнее. Чтобы линия не познакомилась с лопатой озеленителей. Электрический кабель тоже стоит денег. Даже если делать не сильно серьезно и брать простой ВВГнг 3х2.5 в гофре, то это рублей 45 за электрческий кабель и рублей 50 за нормальную гофру. Электрический кабель надо как-то соединять. Для того чтобы сделать отвод требуется вывести на опору кабель петлей и там уже ставить электрический шкаф. Шкаф не простой IEK, а что-то посерьезнее чтобы не заржавел через год. Оптику надо чем-то оконцевать на стороне опоры, т.е. поставить медик + организовать питание камеры. Это значит либо медик с PoE, либо отдельный блок питания. Медиков по количеству камер. Тоже затраты. Обеспечение бесперебойного питания + защиты линии. Тоже некоторые сложности. Короче, не то что бы оптика + питание это сильно дороже, но значительно сложнее в реализации чем один шкаф и от него медь в земле. Незаземленная оптика с тросом воздушкой между зданиями тоже неслабо собирает статику и потом бьется током. Поэтому ее надо либо заземлять (с одной стороны).

Ну не так уж она и дорого стоит, где-то 80 р за метр 50 мм гофры. Надо метров 300 на весь проект, так что удорожание не сильно большое.

Гофра нужна как минимум для того чтобы можно было из нее кабель выдернуть и проложить новый в случае чего. Денег это больших не стоит, а жизнь в будущем должно упростить как мне кажется. Да нам более 50, ну максимум 70 метров то и не требуется. Но идея по поводу кабеля 22AWG по-моему неплоха. Это, грубо говоря, на 0,15 мм2 больше 24AWG, явно хуже не будет.

Нет-нет, никакой укладки прямо в грунт! Я ничего не употреблял чтобы в голову такое могло прийти ))) Я бы вот такой кабель рассмотрел и его в гофру или в ПНД трубу.

Ну в принципе внутри здания PoE на нормальном медном кабеле 24AWG (0.5мм2) PoE вполне работает. Тут даже вопрос не в самом PoE, а в укладке витой пары в грунт.

Добрый день! А есть ли у кого-то опыт укладки медного кабеля (витая пара) в грунт? Требуется от атмосферного шкафа подключить около 20 IP-камер в радиусе 50 метров. Камеры предполагается разместить на нескольких опорах по 3-4 камеры на опору. Можно, конечно, подвести от атмосферного шкафа к каждой опоре питание и оптику, а затем повесить на нее уличный узел доступа типа такого, но размещение активки на опорах усложняет весть процесс. Поэтому есть мысль попробовать сэкономить и просто кинуть медный кабель от атмосферного шкафа прямо к опоре и оттуда сразу подключить IP-камеры. Т.е. отказаться от активки на опорах совсем. Понятно, что бросать обыкновенную UTP в ПВХ оболочке прямо в землю никто не собирается и кабель предполагается использовать в полиэтиленовой оболочке, возможно даже в броне и уложить его в нормальную гофру. Но использование меди в земле для меня выглядит странным решением. Все равно кабель рано или поздно замокнет и выйдет из строя. Хотелось бы услышать мнение общественности по этому поводу.

А у него только веб-интерфейс или CLI тоже есть?

Не факт. У меня был случай когда в одном отеле стояла пара десятков точек доступа WiFi, сведенных в одну и ту же циску 3750. Точки работали в режиме local forwarding без тоннеля до контроллера. В случае, если клиент, к примеру, ехал через все здание на лифте, то его устройство поочередно прыгало с точки на точку то в логах была такая же запись. У любого свитча есть aging time для таблицы маков и циска, видя что мак изучен с одного порта и внезапно появляется на другом, делает вывод о флапинге мака о чем и сообщает. Для того чтобы однозначно сделать вывод о петле нужно использовать либо Spanning tree, либо Loopback detection.

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

Вот так наверное и сделаю. Как оказалось bird и правда не умеет агрегировать префиксы.

Привет! А умеет ли Микротик группировать DHCP-клиентов в классы и основываясь на классах отдавать им различные опции? Например делать как dhcpd с вот таким конфигом: class "MyHosts" { match hardware; } subclass "MyHosts" 1:10:bf:48:xx:xx:xx; # host2 subclass "MyHosts" 1:10:bf:48:xx:xx:xx; # host3 subnet 192.168.1.0 netmask 255.255.255.0 { ... pool { range 192.168.1.101 192.168.1.250; ... deny members of "MyHosts"; ... } pool { range 192.168.1.1 192.168.1.20; ... allow members of "MyHosts"; ... } } Т.е. взять хосты по маку или маске мака, собрать их в класс и выделить им адреса из отдельного пула с отдельным набором опций.

Вечер добрый! Есть один bird, который анонсит bgp пирам примерно 1,5к /32 префиксов, которые укладываются в /22 сеть. Хочу их сумировать при анонсе пирам по аналогии с цисковским aggregate-address. Но что-то читание мануалов по бирду ничего по этому поводу не говорит. Может есть у кого пример?

Нет, включить просто. У нас тоже были спецэффекты вот как какие. В 6500 воткнуто несколько гипервизоров VMWare и на них крутятся виртуалки. 6500 не хотел пинговать ВМ на гипервизоре пока с нее не пошлешь какой-нибудь пакет чтобы он изучил ее мак. Ну или если протухала ARP запись ВМ и пропадал по таймауту ее мак. Долго ломал голову в чем дело, даже дошло до того что в крон ВМ добавил пинговалку шлюза на 6500. Вылечилось как раз включением синхронизации таблиц маков между карточками с DFC и супервизором как раз командой выше. У вас в 8 слоте как раз стоит карточка 6748 с DFC, так что попробуйте, возможно поможет.

https://www.cisco.com/c/en/us/td/docs/ios/lanswitch/command/reference/lsw_book/lsw_m1.html#pgfId-1143362 Не оно?