yakuzzza

Ну что здесь сказать - грустно. Порядок - это процесс. И за ним надо просто следить. Все время.

, скиньте пожалуйста, хотелось бы увидить пример) Да легко. Несколько примеров. Ну и немножко описания. Думаю, будет интересно. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/DSCN5558.JPG - шкаф открыли для удобства работы. ИБП в серединке с фильтрами для удобства. В процессе набивки. В ходе монтажа многое придумывали. Переделывали. Все самостоятельно бригадой в 4 человека. Сразу все документировали. Делали для себя. Сами же потом все косяки и вылавливали. Центральный узел удаленной площадки. Здание в то время на 550-600 портов. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/img_2253.jpg - было. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/img_2254.jpg - в процессе. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/img_2260.jpg - в процессе, не сдаемся! https://dl.dropbox.com/u/15559697/Frunze/pics/nets/img_2268.jpg - первые результаты. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/img_2271.jpg - крупный план. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/img_2272.jpg - еще ближе. Да, каждый кабель еще и стяжечкой решили скрутить. Менять коммутатор удобно. Выткнул все порты. Залил с бекапа конфиг в новый коммутатор. Поменял коммутатор. Включил назад. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/IMG_2688.JPG - еще какой-то узел сети. Новое. https://dl.dropbox.com/u/15559697/Frunze/pics/nets/IMG_3444.JPG - настолько обнаглели, что брали 0.5м патч-корды и не снимая упаковочных скруток просто втыкали. Очень быстро и удобно. Выводы: Очень удобно в обслуживании и не требует подробной документации. Все однозначно и просто. Работы выполняет любой вменяемый работник. Если подписаны панели то вообще все быстро включается. Нет жмутов кабеля и легко идентифицировать порт. Из минусов - их 2. Горит порт - меняли коммутатор или перекоммутировали краснючим каблом. Меня аж выворачивало от этого, но деваться некуда. По секрету - мы могли себе позволить заменить коммутатор на новый без сгоревших портов. И второй минус - расходование портов коммутаторов в случае, когда порты патч-панелей не 100% используются. Мы могли себе позволить заполненность актива не на 100%. Также перед заходом в узел, когда наводились порядки мы просто переобжимали все порты узла и выстраивали все с нуля. Удачи!

Точно нельзя использовать 1 линию на VDSL2 или SHDSL? Просто я представляю эту пачку модемов, коммутатор с вланами, софтроутер/cisco с мегаправилами. Не стОит оно того, ох не стОит...

А мы в свое время выработали простые правила: На доступе используются панели в 24 порта. На доступе используются 24- и 48-портовые коммутаторы. Кросс при использовании 24-портового коммутатора: первый порт панели подключается в первый порт коммутатора. И так все 24 порта. Кросс при использовании 48 портового коммутатора: одному 48-портовому коммутатору соответствует 2 24-портовые патч-панели. Далее делаем гамбургер. Используется 5U пространства. Первый и пятый юнит на патч-панели. Третий на коммутатор. Четные порты вниз, нечетные вверх. Выходит строгое соответствие между портами коммутатора и патч-панелями. В нагруженных коммутационных узлах в шкаф 42U помещается 6-7 коммутаторов доступа, ИБП, магистральный коммутатор, оптический кросс. Так работает сеть на крупном заводе в 2000-2500 уже и не знаю сколько там портов. Монтажники никогда не путаются. Админы довольны. Везде порядок. Будет интересно - скину пару фоток. Удачи!

IES1000 позволяет привязку фильтрацию маков, 802.1х, вланы... По сути он и называется DSL-коммутатор. Другое дело, что плотность портов в нем низкая по сравнению с тем же 1248 и 2 эзернет порта надо на 2 линейных карты... Но это совсем другая история. Кстати, зачем привязывать мак к порту в ADSL - для меня осталось загадкой. На кроссе конкретная пара идет к конкретному абоненту и все.

где?ну вот смотрите, пришли у вас вланы 100-200 на интерфейс сиськи к стороне офиса офис со всеми приблудами у вас работает с интерфейсов вланов 300-400; что мешает ограничить взаимодействие между 100-200 и 300-400 ? вариантов ограничений полный вагон - acl/nat/policy ну даже если вас смущает то что все к одному порту идет, - возьмем циску с поболее портов - 7301 для начала. g0/0 - аплинк к ядру, g0/1 - собираем управлялки, g0/2 - офис. Вы еще 65 поставьте туда. Вам никто не даст туда 7301, а если даст - то в голове пусто. Мы сейчас просто рассуждаем. Завалить 2800 кошку думаю можно будет. Чисто задосить. У меня предложение продолжать дискуссию не в деструктивной струе, как я и Иван, а наоборот - как правильно все-таки сделать. Вот на сегодняшний день я не вижу как все правильно можно сделать - давайте выстраивать решение вместе!

А электричество никогда не пропадает?Линии 100% надёжны? Уверен 99% ложных срабатываний подорвут доверие к оной. И что мешает по старинке подсмотреть и поставить себе такие как надо? Тут говорили и положить вроде можно, а может и инет чейто поюзать или абонентов поломать.Или ложить всё доступное оборудование по очереди, кроме того куда врезались, чтобы ТП побегала. см выше, менять не обязательно или менять в точке вреза. Ну вот под каждым словом Ивана я могу подписаться. Именно так. Это в разрезе, когда начинают рассказывать про безопасности итд итп.

Если у вас все то, что написано работает - респект и уважуха. Если только...

терморектальный анализ... только так. если хакеры нашли уязвимость - значит ее кто то допустил на этапах проектирования/интеграции. если злые хакеры попали в управляющий влан из общей сети - значит кому то надо оторвать руки, и вставить в то место, откуда они должны расти, а так же отказаться от использования того оборудования, которому gvrp ingress checking/802.1q ingress filter не удается правильно отработать. Попытка номер 2. Физический доступ получили к ящику - подключились в влану ч-з врезку итд. В схеме, предложенной с пробросом вланов в офисную сеть есть косяк. И не более того. А руки всем отрывать - сил не хватит. Лучше предложите действительно правильное решение.

Перечитал трижды. Не въехал. Читать дальше? На ночь. До просветления? :) хм, нарисовал примерную схемку (извините за кошмарность, рисовать не умею), может с ней как то понятнее выйдет. В случае если на доступ попадут злые хакеры и получат ваш контрол влан, что тогда? Все равно он прибежал к вам в офисный свитч.То есть в итоге есть дырка.

А что будет, если при реализации схемы влан на свич отдавать свичу IP например 10.10.10.1 адрес из подсети пользователей без всяких вланов управлений итд? пинг на свич от абонента - проверка доступности свича. Пинг на свич от оператора - проверка доступности свича. Остальные пинги зарезать (для параноиков). У кого-то такое есть? То есть строить старый добрый сеть с маршрутизируемыми интерфейсами. Ваше мнение, господа.

Заведут опять ч-з нат кучу народу. Что ж еще.

Та троллит жеж, сабака! Шо вы в самом деле. Про "а вообще круто"... А что не так? 20 волокон по гигабиту в Л3 коммутатор и витухой в сервак. Замечательно все будет работать.

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

Некто отправил письмо на мейл.ру... Вообще у меня логика железная - отправил письмо=использовать SMTP.Использовал веб-интерфейс? Смотреть в заголовках от кого отправлено - того и пинать. Нет аккаунта? Простите. Не используется SMTP - см выше совет по Netflow. Не надо передергивать. PS: давайте только не будем сейчас еще вспоминать об анонимных прокси итд. Смотрим на вопрос ТС.

Правильный биллинг (читай допиленный или самописный) Кесарю кесарево.В биллинге по логике не должно быть техучета. Спасибо, Капитан Очевидность! :) У нас бухгалтерия и фин.служба - разные вещи. Система техучета - какая система (пример)? Вторая попытка. Какая-то система техучета - хоть на 1С + какая-то система контрактно-договорного учета - хоть на 1С. Все зависит от количества точек и частоты переезда. А теперь от "капитана следующие вопросы": У вас есть какая-то информационная система, которая уже работает? Финслужба что у вас считает? Она оплатит ваши счета и оформит платежи по контракту или договору. А в бухгалтерию это все сваливается и остаются все акты работ и налоговые накладные.

IPoE+Netflow+помегабайтный пакет - ну очень плохая идея. Уж простите. Вроде как есть возможность продолжать вести RADIUS-аккаунтинг на IPoE, или вы принципиально не используете RADIUS?

Э. Проблему вашу понял.Скажите, а вы не используете RADIUS-аккаунтинг? Ведь учет трафика должен идти до той поры, пока у вас поднят туннель. Старт=стоп ну и при необходимости алайв-пакеты. Туннель уничтожился и трафика нет - что там может досчитываться? Роутинга на этот реальный IP тоже нет - он должен уходить в Null0 в терминах Cisco. В принципе есть и второй вариант - IPoE. Но как по мне, то использование помегабайтных тарифов вкупе с IPoE - не Даовэй. А если нет, то скажите, как считаете трафик? Нетфловом? Счетчиком в правилах пакетного фильтра? Заранее благодарен за комментарии.

Некто отправил письмо с майлвру, что и где можно увидеть в заголовках ? Правильно, - только Ip вашего ната. Если конкретно письмо и наш нат, то письмо отправят от нас только через наш релей - это раз, логи покажут кто отправлял - это два.Ну и не путайте уже письма-аськи с натом и netflowом.

Думаю здесь Wi-Fi в CPE. Об этом речь.

Так вроде как спецслужбы у топикстартера 1. Не дали ни портов ни IP другой стороны. А только IP его. ВСЕ. 2. И ответ > 1 абонента их, вроде как тоже не устроил. У него технических вариантов ровно 2. или нат 1:1 или реальники. Нужно чтобы в каждый момент времени внешний IP был только у одного абонента. Если же есть другая сторона и порты, то тогда да, или снятие трафика до ната или сама таблица ната спасет положение. Но это нужно договариваться со спец службами, чтобы дали доп. информацию и не полоскали моск. Что значит не устраивает? Есть запрос от спецслужб - вот ответ. Уточнить хотите - давайте дополнительные данные. Не настолько там тупые ребята, как все думают. Это даже из личного опыта общения с тем же СБУ (Украина). Нат 1 в 1, реальники и проч - это не спецслужбам решать как проектировать сеть, еще раз повторяю.

Так и делают, в сотовых сетях например. А в ШПД слишком много игроков, не договориться. А пока слияния/поглощения пройдут уже IPv6 будет, идея станет мало привлекательной. Каких игроков? Не понял.В байки про IPv6 не верю. Ну не смогут все перейти сразу на IPv6, затратное это дело, ребята + будет вылазить такое, чего никто не ожидает.

Тем, кто обслуживает кабельное хозяйство, очевидно.

Что в итоге? Только наплевательское отношение к документации. Делались бы хотя бы ежеквартальные обходы - таких вопросов бы не было.

Это система техучета + бухгалтерия.