prohodimec
-
Публикации
54 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем prohodimec
-
-
Последняя фирмваря вызвала несколько критичных вопросов, над которыми Длинк пообещал поработать в ближайшее время, возможно раньше.
-
Опубликовано · Изменено пользователем prohodimec · Жалоба на ответ
Не всё так однозначно, оказывается.
Выяснилось так же, что ......уже более двух лет размещенное в целях транзита трафика оборудование использовалось "Инфолинком" незаконно, т.к. никаких договоров на размещение оборудование или аренду площадей между ООО «Инфолинк» и администрацией "Дома быта" так и не было заключено.
Еще в декабре 2008 года руководство "Дома Быта" письменно обратилось в компанию «Инфолинк» с требованием перенести незаконно находящееся оборудование со своей крыши. После 2-х месячных телефонных переговоров, в ходе которых постоянно переносились сроки демонтажа, представители "Инфолинка", прибывшие, наконец, в "Дом Быта", вместо того, чтобы решать вопрос конструктивно, стали угрожать администрации "Дома Быта" антимонопольным комитетом и прокуратурой. Неизвестно, сколько это безобразие могло бы продолжаться дальше, если бы не произошедший инцидент.
В настоящее время же, по словам руководства "Дома Быта", незаконно использующееся оборудование демонтировано с крыши здания.
Кто прав в таком контексте?
Оттуда же:
Судя по фотографии и приведённым документам, изгиб кабеля должен был быть никак не меньше 20см по радиусу.Теперь то, что касается технической стороны вопроса. Как видно на фотографии, любезно предоставленной "Инфолинком", имеются как минимум 2 грубейших нарушения технологии прокладки волоконно-оптического кабеля......В соответствии с пунктами ВСН 60-89 и ОСТН 600-93 имеем два нарушения:
1. Несоблюдение защиты кабелей от механических повреждений при их монтаже ниже 2,3м (по другому документу – 3м) от поверхности металлическими профилями (желобами, угловой сталью), пластмассовыми трубами или металлорукавами (что наблюдаем на фото);
2. Несоблюдение радиуса изгиба кабеля
Подсмотрено здесь:
-
...из натурального говна. Дёшево и сердито...
-
Виноват в чём?
В том, что кабель так безалаберно проложен? С наружней стороны угла, внатяг, без элементарной гофры?
Разумеется монтажники.
В том, что кабель повреждён?
Лицо, занимающееся обслуживанием данного участка. Владелец здания, например.
Почитал тему, на которую дана ссылка - совершенно непонятно, почему владельцы кабеля проводят своё "внутреннее" расследование, а не подключают к этому органы?
Кабель что, был проложен нелегально? А владельцы здания прозрачно намекнули, что так делать нельзя?
-
Ну, я просто имел в виду, что если провайдер уже раздаёт адреса подсетками до каждого - то проблем не будет.Согласен, не внимательно прочел :)Но предложенная Вами схема (каждого пользователя в свою подсеть), тоже требует изменений таблицы маршрутизации на "чужом" рутере. :(
Как выход, можно поставить между сетью и "чужим" рутером "свой", и делать на нем все что угодно - хоть айпи-сеть на юзера, хоть арп-прокси поднимай. Можно и тегировать пакеты на нем, и забыть про кривой порт-бейзед влан :)
А про свой маршрутизатор в разрыве - тоже мысль интересная :)
-
Опубликовано · Изменено пользователем prohodimec · Жалоба на ответ
А теперь научимся читать всю тему, а не только понравившиеся кусочки :)Если пользователи изолированны друг от друга вланами, то ни чего не мешает поднять на рутере "арп-прокси"Дело в том, что пользователи имеют белые адреса, и маршрутизатор через который они выходят, насколько я знаю (он чужой и внутрь не пускают), имеет один статичный роут "выплевывая" траффик на маршрутизатор вышестоящего провайдера. -
Через маршрутизатор они будут работать только в том случае, если их подсети не пересекаются.
То есть, например, если у пользователя на 1м порту:
IP - 217.100.100.2
маска 255.255.255.252
шлюз 217.100.100.1
на 2м:
IP - 217.100.100.6
маска 255.255.255.252
шлюз 217.100.100.5
и так далее - то они будут общаться друг с другом через маршрутизатор.
Если, например, так:
IP - 217.100.100.2
маска 255.255.255.0
шлюз 217.100.100.1
IP - 217.100.100.6
маска 255.255.255.0
шлюз 217.100.100.1
то маршрутизатор участвовать в процессе не будет.
-
Офисная железка, которая не предназначена для провайдерских сетей.
С очень урезанными возможностями.
Почитайте на форуме длинка, сколько глюков они до сих пор в ней не исправили.
-
Только если пользователи будут в разных подсетях, между которыми маршрутизатор будет маршрутизировать трафик.Скажу просто.Если порты 1 и 2 изолированы друг от друга и видят только 24й порт, то тупой неуправляемый свитч и даже умный управляемый свитч, висящий на 24м порту - пакет обратно не вернут.
То есть если за 24м портом где-нибудь не будет колечка в сети (что сразу же убьёт всю сеть), то 1 и 2 друг друга видеть не будут.
О! Спасибо!
Маршрутизатор будет таким кольцом?
Потому что если пользователи в одном сегменте (в одной подсети) - они должны обмениваться трафиком напрямую, а когда порты изолированы - они лишаются такой возможности.
-
То бишь до тех пор, пока на всех узлах не будут стоять управляемые железки с возможностью привязок IP-мас, DHCP-снупинга или даже фильтрацией трафика - сеть остаётся беззащитной.
DHCP-снупинг позволит защититься от левых DHCP, а не от левых мак-адресов и айпишников.
О чём и было сказано выше.
А когда везде стоит такое оборудование - DHCP уже абсолютно ни на что не влияет, только на удобство самих пользователей.
-
Скажу просто.
Если порты 1 и 2 изолированы друг от друга и видят только 24й порт, то тупой неуправляемый свитч и даже умный управляемый свитч, висящий на 24м порту - пакет обратно не вернут.
То есть если за 24м портом где-нибудь не будет колечка в сети (что сразу же убьёт всю сеть), то 1 и 2 друг друга видеть не будут.
-
DHCP не спасёт от желающих воровать чужие айпишники и мак-адреса.
-
угу... из новостей двухнедельной давности...
Компания IBResource объявляет о выходе русской версии Invision Power Board v2.3.4.
-
Полностью от таких проблем позволит защититься лишь ACL.
Если клиентов изолировать, если сегменты кольца разные - это всё, конечно здорово. Особенно красиво с пометкой "проблем особых не будет". Особых может и нет, а вот вполне обычных - вполне хватит.
Блокировка портов по статик-макам - тоже вариант. Но с деградацией качества у клиента. А если подключена домашняя сетка на 10 человек и все платят и лишь только один "умник" догадался накосячить?
Все будут страдать при блокировках портов.
Сеточников сразу проще в отдельных вилан выделять, чтобы не страдали остальные.
Так что, пионерские сетки строить уже хватит - пора начинать усложнять настройки, чтобы упрощать использование :)
-
Сгоревшие мыльницы лучше бы радиолюбителям за пиво раздали.
Детали там фуфло, а вот корпуса - вещь неплохая.
Был бы небольшой праздник и у тех и у других :)
-
+1
согласен , тоже зашел сюда чтоб написать это!Покажите мне где там на фотографиях 220V от клиентов?
Там очевидно подведен постоянный ток от адаптера порядка 9-20V
И то, при таком "аккуратном" выполнении подключений, это безопаснее, чем подводить 220V на деревянную крышу :)
-
Ну что на это можно сказать?Видать никто не сталкивался, или все ставят авто режим.Телнет вам в помощь.
Смотрите ошибки CRC на проблемном порту - и поймёте, куда у вас улетучивается скорость.
3сом не со всеми сетевыми устройствами корректно работает при зажатии порта на 10full.
Попробуйте 10half - и увидите, что скорость возрастёт в разы, хотя и пинги при этом увеличатся.
Лечится только подбором оборудования, которое корректно работает в таком режиме :(
-
Опубликовано · Изменено пользователем prohodimec · Жалоба на ответ
Причём, как утверждают, этой фичей нельзя управлять.
-
А в некоторых случаях и вовсе менять свитч полностью, так как без выпайки сгоревших микрух на порты он вообще целиком остаётся неработоспособным :)Пусть уж лучше тогда порты на свиче выгораютага, а юзерам байки вешать, что извините, зашита дороже порта, и поэтому мы не защищаем, а вы уж как нить потерпите, пока мы горелые порты периодически меняем :)
-
Насчёт PPTP - возможно, что и на самом деле так.В DI-604 отвратительный модуль PPP - виснет именно он, если на 604-м поднимать только NAT, работает месяцами без зависаний.Роутеры, у кого в настройках PPTP выставлен непрерывный коннект частенько висли или теряли внешний сервер.
Проблема решалась выставлением "подключения по запросу" с таймаутом минут 15.
-
Ни разу не возникало такой проблемы.Легко сказать, не легко сказать.... Просто примите как правило безопасности: порты, вам не подконтрольные, должны игнорировать любые поползновения в сторону (R-)STPОткрытый абоненту STP - это приглашение ему вырубить ваш STP-сегмент нахрен
А вот проблемы с флудящими абонентскими мыльницами или закольцевания через других провайдеров, которые отрубают нахрен с десяток сегментов - это реальность.
-
Оптика не настолько дороже меди.
Скорее, лишнюю стоимость добавит оборудование для её использования.
А медь срезают не только для того, чтобы напакостить или потом использовать для своей сети.
Но ещё и для того, чтобы расплести и сдать цветмет.
А грозы тоже очень любят выносить медные пионернеты...
-
Разбить можно только запихнув разные подсети в разные виланы и пробросив их магистралями до L3.
Пока не видел случая, чтобы не справились с нагрузкой.
-
Легко сказать.Моментик: никогда не принимайте STP со стороны абонента!Вывод: от флуда со стороны абонента STP не очень помошник
А если абонент - частная сетка, у которой собственная полудохлая мыльница?
подскажите по 3028
в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Опубликовано · Жалоба на ответ
Мак-адреса в таблице FDB очень часто появляются с задержкой минут в 10-15, да и то - случайным образом.
Пока по snmp эту таблицу не снимешь - через CLI можно и не увидеть ничего.
Полтора месяца они эту проблему решают и всё никак не дорешат.
Чует моё сердце, прошивку писали той же левой ногой, что и раньше для 3026, ибо глюки схожи.