Заодно можно будет снимать регистрацию с конкурентов. И продавать их домены на аукционе. Господам из домейнера видимо, уже мало перехватов с собственного whois.
это региональная а не федеральная расценка, если я правильно помню. Кроме того очередь может быть действительно большой, дней так на насколько. А укорачивание очереди стоит денег, это широкоизвестный бизнес, с которого взяточничество, собственно, и начиналось.
Может быть господа просто готовят кормушку? Слухи о регулировании «этих ваших интернетов» уже ходят. Но кажется мне, что с такими идеями домейнер пойдет гулять, просто найдут другого регистратора.
Гешвинде, Шенинг — «PHP и PostgreSQL Разработка WEB-приложений». Книжка достаточно древняя (postgreSQL 7.3, PHP4) — но очень подробна и тем исключительно хороша. Найти ее на бумаге достаточно сложно, но в электронном виде вполне возможно.
Давайте по частям :)
1. Про Option82 можно почитать на nag.ru и cisco.com. Сам я ее никогда не использовал, но народ очень хвалит. Она позволяет фильтровать DHCP-server трафик, поскольку в ней указывается, каким путем пришел DHCPREQ, и каким ушел DHCPREP. Особенно хорошо это работает в сочетании PerUserVLAN и Unnumbered Interface. К сожалению прямо сейчас я в провайдере не работаю, и экспериментирую на лабстенде. Как только пойду в провайдер — буду агитировать руководство на переход на такую схему
2. Нет, не исключает. Но обмен будет идти через PPPoE-концентратор/гейт, и его производительности может элементарно не хватить. Решается путем создания нескольких гейтов или использования в качестве гейтов железок с очень большой производительностью и очень большим количеством ENET портов, типа 6504 хотя бы :)
3. Реально вполне, DHCP ходит как Broadcast и слушается любим снифером с фильтрацией по маске
Видел и учавствовал. Вообще, через крупные дороги стараются не кидаться, это очень рискованная операция — могут монтажника в блин раздавить. Обычно делают так — с двух концов скидывают веревки, перекидывают их через провода линий освещения, в центре проезжей части связывают и натягивают. Потом с одной стороны к веревке привыязывают трос, и веревкой его вытаскивают на противоположную крышу. После чего по тросу специальной тележкой-кабелепроходчиком (этакий робот с моторчиком) тянут сам кабель. Если трасса очень оживленная — прокид делают глубокой ночью — в р-не 4 утра. В это время количество машин минимально.
Что конкретно вам про нее рассказать? Привязка к маку в станадртной реализации — это старое, страшное, жуткое и примитивное чудище. Не любит его никто, но пользуются многие — из-за простоты понимания и развертывания оно считается решением для быстрого развертывания сети. Решения без привязки есть, их достаточно немало, но они требуют настройки и определенных усилий от специалистов. Кроме того, не всякое решение возможно на том оборудовании, которое есть у провайдера. А оборудование — это живые деньги, и не у всех провайдеров они есть.
Насчет что случилось — вероятнее всего недостаточно внимательно оттестировали сеть. Судя по описаным симптомам, либо сеть «сломали», либо не учли производительности ядра и оно умерло под нагрузкой.
Способов решения этого — четыре:
1. Не использовать IP вообще, клиент цепляется по PPPoE
2. Не использовать DHCP, выдавать статический IP с привязкой. Клиент, взявший левый адрес — не получит сети.
3. Фильтровать DHCP как протокол на агрегаторе. То есть фальш-дхцп «закроет» только один дом в сети. При появлении жалоб в этом сегменте — прослушиваем сегмент сниффером и через это находим клиента-экспериментатора.
4. Использовать Option82.
На моем последнем месте работы использовался 2 метод, на предыдущем — 1.
Опять, же — всегда по-разному. И марка и волокна. Обычно закладывают от 2 до 50% волокн в резерв, чаще всего кабель идет четырех или 8 волоконный. Производители самые различные, китай, россия, США… Волокнные кабели, должен заметить, бывают разные — например есть специальные самонесущие кабели для провеса в воздухе или бронированые кабели для прокладки под землей.
Лучше снизить скорость. На старой линии помехи можно искать бесконечно, причем источником помех может быть что угодно, включая воду в магистральном кабеле (изоляция от старости трескается). WiFi помех в телефонной линии не вызывает, там слишком большие частоты, они с DSL не пересекаются.
1. Про Option82 можно почитать на nag.ru и cisco.com. Сам я ее никогда не использовал, но народ очень хвалит. Она позволяет фильтровать DHCP-server трафик, поскольку в ней указывается, каким путем пришел DHCPREQ, и каким ушел DHCPREP. Особенно хорошо это работает в сочетании PerUserVLAN и Unnumbered Interface. К сожалению прямо сейчас я в провайдере не работаю, и экспериментирую на лабстенде. Как только пойду в провайдер — буду агитировать руководство на переход на такую схему
2. Нет, не исключает. Но обмен будет идти через PPPoE-концентратор/гейт, и его производительности может элементарно не хватить. Решается путем создания нескольких гейтов или использования в качестве гейтов железок с очень большой производительностью и очень большим количеством ENET портов, типа 6504 хотя бы :)
3. Реально вполне, DHCP ходит как Broadcast и слушается любим снифером с фильтрацией по маске
Насчет что случилось — вероятнее всего недостаточно внимательно оттестировали сеть. Судя по описаным симптомам, либо сеть «сломали», либо не учли производительности ядра и оно умерло под нагрузкой.
1. Не использовать IP вообще, клиент цепляется по PPPoE
2. Не использовать DHCP, выдавать статический IP с привязкой. Клиент, взявший левый адрес — не получит сети.
3. Фильтровать DHCP как протокол на агрегаторе. То есть фальш-дхцп «закроет» только один дом в сети. При появлении жалоб в этом сегменте — прослушиваем сегмент сниффером и через это находим клиента-экспериментатора.
4. Использовать Option82.
На моем последнем месте работы использовался 2 метод, на предыдущем — 1.