Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 120
Шикарнейшая статья, спасибо!
> Роутер не умеет делать IPv6 NAT
Что-что?! o_O
Что-что?! o_O
Благодарю. Прочитал взахлёб. Думал, что переход на IPv6 лишь дело времени, а оказалось всё значительно хуже.
Спасибо. Да, мы тоже думали, что IPv6 сети доступных ресурсов будет больше, а можно пробовать разворачивать «чистую» IPv6. Ну, и производители софта и железа тоже удивили. По факту, сейчас хорошо с IPv6 работает только магистральное оборудование, конечному пользователю в v6 сети особо нечего делать пока что.
На самом деле это объясняет отсутствие массового перехода на IPv6. Полагаю, что «пока петух не клюнет» этого не произойдёт.
Ещё я полагаю, что проблемы поддержки связанны с тем, что IPv4 обкатаны много-много лет. И все ошибки отлавливались ещё на этапе становления протокола. В данном случае мы видим становление и его неопробованность.
Ещё я полагаю, что проблемы поддержки связанны с тем, что IPv4 обкатаны много-много лет. И все ошибки отлавливались ещё на этапе становления протокола. В данном случае мы видим становление и его неопробованность.
понимаешь в чём штука… петух не клюнет. во всяком случае в не в ближайшие 10-15 лет.
1. можно юзать NAT. и будут. и со всё бОльшим использованием NAT будут появлятся всё более мощные железки — т.к. будет спрос.
2. ресурсы на ipv6 не будут появлятся потому что нет пользователей, а пользователей не будет потому что нет поддержки провайдеров.
эти вопрос не решить техническим способом / мирным путём. только слаженной атакой мирового сообщества возможно сменить одну технологию на другую.
вспомните — раньше SMTP-сервера релеили почту от всех подряд. пока просто некоторое количество важных серверов не перестало принимать от таких других серверов почту. почта не работала где-то с неделю, если не больше, но всё устаканилось. потому что сеть была маленькая. сейчас такое невозможно, т.к. курс на глобализацию был остановлен общемировым кризисом и сепаратистские настроения преобладают.
1. можно юзать NAT. и будут. и со всё бОльшим использованием NAT будут появлятся всё более мощные железки — т.к. будет спрос.
2. ресурсы на ipv6 не будут появлятся потому что нет пользователей, а пользователей не будет потому что нет поддержки провайдеров.
эти вопрос не решить техническим способом / мирным путём. только слаженной атакой мирового сообщества возможно сменить одну технологию на другую.
вспомните — раньше SMTP-сервера релеили почту от всех подряд. пока просто некоторое количество важных серверов не перестало принимать от таких других серверов почту. почта не работала где-то с неделю, если не больше, но всё устаканилось. потому что сеть была маленькая. сейчас такое невозможно, т.к. курс на глобализацию был остановлен общемировым кризисом и сепаратистские настроения преобладают.
NAT тоже ограничен количеством портов (65535) на IP. 10-15 лет? Вряд ли.
Ну хотя, если создать симметричный NAT, максимально упаковывающий юзеров, в том числе повторно использующий исходящие порты для разных юзеров и разных серверов, можно ещё продлить жизнь ненадолго. Уверен, пользовалели Teredo, TeamViewer, игроки, использовавшие ранее Hamachi, да просто p2p'шники, по достоинству оценят симметричный NAT, уходя к конкурентам.
Мне как выход нравится автоматическая настройка IPv6 поверх IPv4. Например, вот есть сейчас в инсталляторах Яндекс.Бары не очень нужные, а почему бы не делать таким же образом конфигурацию IPv6?
Модуль для InnoSetup и других инсталляторов оценит IPv4 и IPv6 connectivity, попробует разные варианты, в том числе 6to4 и Teredo, и оставит включенными те, которые работают.
Ну хотя, если создать симметричный NAT, максимально упаковывающий юзеров, в том числе повторно использующий исходящие порты для разных юзеров и разных серверов, можно ещё продлить жизнь ненадолго. Уверен, пользовалели Teredo, TeamViewer, игроки, использовавшие ранее Hamachi, да просто p2p'шники, по достоинству оценят симметричный NAT, уходя к конкурентам.
Мне как выход нравится автоматическая настройка IPv6 поверх IPv4. Например, вот есть сейчас в инсталляторах Яндекс.Бары не очень нужные, а почему бы не делать таким же образом конфигурацию IPv6?
Модуль для InnoSetup и других инсталляторов оценит IPv4 и IPv6 connectivity, попробует разные варианты, в том числе 6to4 и Teredo, и оставит включенными те, которые работают.
Ещё вызывает некоторое сомнение размах, с которым раздаются IPv6 адреса. Да, адресов очень много, но каждому пользователю выдавать /64+/48 — не факт, что надолго хватит. Плюс, зарезервированные, и служебные блоки. Поэтому, последние рекомендации RIPE выдавать /56 вместо /48 навевают вопрос: «А не окажется ли, что лет через три-пять-десять IPv6 будет объявлен неудачным и маленьким, и начнётся внедрение какого-нибудь IPv8?».
А так — да, вы совершенно правильно заметили, что присутствует замкнутый круг ресурсы <-> пользователи. Но IETF не пойдёт на резкие шаги по ограничению IPv4, так что перспективы IPv6, как мне кажется — это оставаться одним из удобных для магистралов протоколов.
А так — да, вы совершенно правильно заметили, что присутствует замкнутый круг ресурсы <-> пользователи. Но IETF не пойдёт на резкие шаги по ограничению IPv4, так что перспективы IPv6, как мне кажется — это оставаться одним из удобных для магистралов протоколов.
1. Использование NAT решает проблему провайдеров.
Провайдеры-то да — они могут преспокойно упаковывать абонентов за NAT всё плотнее и плотнее ещё десятки лет.
А вот для датацентров, нехватка IPv4-адресов — это полный абзац.
Сервер или виртуалочку абонента за NAT не засунешь, они должны быть высунуты в интернет.
Датацентры уже начали взвинчивать цены на IPv4-адреса, надеясь «отжать» их у тех, кто берёт более чем один адрес на сервер. Допустим, они преуспеют, и практически у всех серверов будет не более чем один адрес.
Потом они вычерпают весь «чёрный рынок» IPv4.
А дальше — всё, приехали.
Провайдеры-то да — они могут преспокойно упаковывать абонентов за NAT всё плотнее и плотнее ещё десятки лет.
А вот для датацентров, нехватка IPv4-адресов — это полный абзац.
Сервер или виртуалочку абонента за NAT не засунешь, они должны быть высунуты в интернет.
Датацентры уже начали взвинчивать цены на IPv4-адреса, надеясь «отжать» их у тех, кто берёт более чем один адрес на сервер. Допустим, они преуспеют, и практически у всех серверов будет не более чем один адрес.
Потом они вычерпают весь «чёрный рынок» IPv4.
А дальше — всё, приехали.
Подозреваю, что тут дело в другом — когда все абоненты сидят за одним огромным NAT, затруднительно определить по заявке из органов, кто выходил с конкретного IPv4 адреса «в ночь с пятницы на понедельник» ©.
Но вся эта лафа быстро закончится, когда закончатся IPv4 адреса.
Повторюсь — это гипотеза. Я не знаком с реалиями украинского телекома. Просто провожу параллели с нашими российскими реалиями.
Данный вопрос я решил просто: каждому абоненту-физлицу даётся блок IPv4 адресов, который NATится в некий реальный.
В силу нехватки IPv4 адресов, физлица группируются на этих NAT.
В данный момент они у меня группируются по двое. Далее будут по трое, четверо и т.д.
Органы это устраивает — найти конкретного из 2-3-4 человек всё равно весьма несложно.
Но вся эта лафа быстро закончится, когда закончатся IPv4 адреса.
Повторюсь — это гипотеза. Я не знаком с реалиями украинского телекома. Просто провожу параллели с нашими российскими реалиями.
Данный вопрос я решил просто: каждому абоненту-физлицу даётся блок IPv4 адресов, который NATится в некий реальный.
В силу нехватки IPv4 адресов, физлица группируются на этих NAT.
В данный момент они у меня группируются по двое. Далее будут по трое, четверо и т.д.
Органы это устраивает — найти конкретного из 2-3-4 человек всё равно весьма несложно.
> для датацентров, нехватка IPv4-адресов — это полный абзац.
в данной статье рассматривали только домашников. о них и говорим. ;)
в данной статье рассматривали только домашников. о них и говорим. ;)
Как же всё печально-то…
Можете пожалуйста кратко срезюмировать это видео? А то на работе смотреть 40 минут видео не получается.
Краткие тезисы есть в PDF в виде слайдов
Ну не знаю. У меня в дебиане через RA получает и адрес и шлюз и не теряет. dhcpv6 и rdnss не проверял.
проверил rdnss (прописал опцию в radvd.conf), NetworkManager его подхватил и прописал в resolv.conf
то же самое на этапе инсталяции — не проверял.
то же самое на этапе инсталяции — не проверял.
Аналогично. В течение 2 лет в домашней сети у меня был IPv6. На сервере (debian) был поднят 6to4 через 192.168.99.1, раздача шла через RA radvd + DHCPv6 dibbler. Как linux, так и Windows 7 в сети работали хорошо, все маршруты и default gatewayи поднимались без проблем, ничего не конфликтовало с teredo.
Я не знаю, как там в ряду серьезного сетевого оборудования, вроде Cisco и Juniper, но с решениями на базе linux все довольно неплохо, скажу я вам. Т.е. вот автор говорит, что ping google.com пытается пинговать IPv4-адрес и не находит его, это правильное поведение, т.к. для пинга ipv6-адресов есть ping6. Аналогично, traceroute6, tracepath6, ip6tables и т.д.
Насколько я знаю, сейчас те провайдеры, которые не могут по причинам, описанным в статье выдавать IPv6-адреса, ставят девайсы или linux-коробки с 6to4 серверами и раздают адреса через них, это называется 6rd. Это требует ручной настройки, но работает достаточно стабильно, хоть и инкапсулирует пакеты в IPv4, т.е. с практической точки зрения, удобство пользователю только в отсутствии NAT. Этим решаются проблемы со свичами, которые не поддерживают IPv6.
Не используйте NAT64/DNS64. Это глупо, это костыль. Скайп через такое работать точно не будет, т.к. в него забиты IPv4-адреса. И не используйте IPv6-only. Можно и нужно использовать dual-stack.
Для тех, кто не в курсе: NAT64 — возможность ходить на IPv4-адреса через IPv6, т.е. есть специальный шлюз, DNS64 резолвит ip этого шлюза и дописывает IPv4-адрес, и таким образом вы попадаете на IPv4-адрес через IPv6 через этот шлюз. Это гораздо хуже, чем предоставлять dual-stack с нормальным IPv4 и «кривым» (через 6rd или как-то еще) IPv6.
Если объяснить пользователям, как настроить ОС так, чтобы IPv4-трафик был приоритетней (если у домена есть A и AAAA, чтобы по умолчанию использовался A), то проблем особо не будет, а пользователь сможет еще и игры хостить через свой IPv6.
Я не знаю, как там в ряду серьезного сетевого оборудования, вроде Cisco и Juniper, но с решениями на базе linux все довольно неплохо, скажу я вам. Т.е. вот автор говорит, что ping google.com пытается пинговать IPv4-адрес и не находит его, это правильное поведение, т.к. для пинга ipv6-адресов есть ping6. Аналогично, traceroute6, tracepath6, ip6tables и т.д.
Насколько я знаю, сейчас те провайдеры, которые не могут по причинам, описанным в статье выдавать IPv6-адреса, ставят девайсы или linux-коробки с 6to4 серверами и раздают адреса через них, это называется 6rd. Это требует ручной настройки, но работает достаточно стабильно, хоть и инкапсулирует пакеты в IPv4, т.е. с практической точки зрения, удобство пользователю только в отсутствии NAT. Этим решаются проблемы со свичами, которые не поддерживают IPv6.
Не используйте NAT64/DNS64. Это глупо, это костыль. Скайп через такое работать точно не будет, т.к. в него забиты IPv4-адреса. И не используйте IPv6-only. Можно и нужно использовать dual-stack.
Для тех, кто не в курсе: NAT64 — возможность ходить на IPv4-адреса через IPv6, т.е. есть специальный шлюз, DNS64 резолвит ip этого шлюза и дописывает IPv4-адрес, и таким образом вы попадаете на IPv4-адрес через IPv6 через этот шлюз. Это гораздо хуже, чем предоставлять dual-stack с нормальным IPv4 и «кривым» (через 6rd или как-то еще) IPv6.
Если объяснить пользователям, как настроить ОС так, чтобы IPv4-трафик был приоритетней (если у домена есть A и AAAA, чтобы по умолчанию использовался A), то проблем особо не будет, а пользователь сможет еще и игры хостить через свой IPv6.
Я не знаю, как там в ряду серьезного сетевого оборудования, вроде Cisco и Juniper
Плохо. Очень.
Пока нельзя организовать полноценную провайдерскую сеть на IPv6. Однако, вполне можно транспортировать IPv6 пакеты по провайдерской сети, в которой все сигнальные протоколы работают поверх IPv4. Собственно, так сейчас везде и делают. До полного отказа от IPv4 пройдут еще десятилетия.
по IPv6 не работают: skype, icq, yandex, odnoklassniki, steam, ex.ua и почти все остальные, включая новостные, развлекательные и игровые ресурсы
Не совсем так, yandex.com работает по IPv6
Наверняка, но если в саппорт домашней сети позвонит 300 клиентов с вопросом: «А почему у меня ya.ru не открывается?», то рассказывать каждому о том, что нужно теперь yandex.com использовать — заметно ударит по репутации провайдера.
А много обычных среднестатистических пользователей знают про yandex.com? не флейма ради вопрос, мне действительно интересно… За все годы, что он (Я) работает, про yandex.com я впервые услышал сейчас. Большая часть моих знакомых, кто пользуется яндексом не знает даже про ya.ru.
И я предвижу очень много криков офисных сотрудников «аа… интернет не работает» и пинков от руководства, если такое провернуть почти в любом офисе, где я работал.
И я предвижу очень много криков офисных сотрудников «аа… интернет не работает» и пинков от руководства, если такое провернуть почти в любом офисе, где я работал.
Именно по этому на IPv6 в начале перевели не очень критичную часть. Они подробно на YaC рассказывали. Они проводили несколько экспериментов и выяснили, что наличие IPv6 у многих провайдеров не означает, что он работает. А вот к примеру windows, когда видит, что IPv6 есть, отдает предпочтение ему, а если он нормально не работает… Ну, в общем, вы поняли :)
Еще раз повторюсь. В Яндексе для IPv6 все готово, как только провайдеры будут готовы, Яндекс включит поддержку всех сервисов.
Еще раз повторюсь. В Яндексе для IPv6 все готово, как только провайдеры будут готовы, Яндекс включит поддержку всех сервисов.
И ещё vk.com (такой мелкий сайтик для юзеров из СНГ).
Мы в Питере, например, не платим дополнительно за IPv6 аплинка.
Менять оборудование на поддерживающее IPv6 не надо, поскольку магистральное довольно давно поддерживает. Пихать 3750G в центр маршрутизации и жаловаться на урезанное количество памяти под маршруты несколько странно.
Менять оборудование на поддерживающее IPv6 не надо, поскольку магистральное довольно давно поддерживает. Пихать 3750G в центр маршрутизации и жаловаться на урезанное количество памяти под маршруты несколько странно.
1. Я специально обратил внимание, что вопрос касается «средние» домосетки. Это замечательно, что у вас стоит хотя бы 7600 циска в ядре, и вы можете в dual-stack раздать IPv6 адреса абонентам, и NAT-ить им серые IPv4. Вопросов только два: какой объём трафика вы сможете прогнать с учётом NAT-a? И, основной: а зачем это делать, если в IPv6 сети у конечного пользователя только торренты работают, а основной трафик всё равно уходит в IPv4 через NAT?
2. IPv6 имеет смысл использовать магистралам, можно завернуть IPv4 в IPv6, и работать с одним протоколом в пределах своей сети.
3. Среди наших клиентов — провайдеров домосеток, циски 3560-3750 в ядре весьма и весьма распространённое явление. Да и они себя показали очень хорошо на сетях до 2500 абонентов.
2. IPv6 имеет смысл использовать магистралам, можно завернуть IPv4 в IPv6, и работать с одним протоколом в пределах своей сети.
3. Среди наших клиентов — провайдеров домосеток, циски 3560-3750 в ядре весьма и весьма распространённое явление. Да и они себя показали очень хорошо на сетях до 2500 абонентов.
Торренты и есть основной трафик ;)
1. Мы и есть средняя домосетка. Не нужна 3750 в центре, не-нуж-на. Какое-то время держит D-Link, затем целесообразно переходить уже на Extreme (x650, x670) или Juniper(EX4200, например). 3750 совершенно вылетает из общего ряда. А, из Цисок 650x серия хорошо идёт. 3750 вообще никуда.
Трафик с помощью NAT'a прекрасно прогоняется обьёмами (проверено на практике) до 10 Гбайт спокойно — его чрезвычайно удобно распараллеливать на относительно дешёвые PC-сервера.
Делать это надо уже сейчас, потому что спрос на это УЖЕ есть.
2. Не магистрал, но что-то ОЧЕНЬ сомневаюсь. Тем более что сами магистралы IPv6 вполне себе разворачивают.
3. Бессмысленна она в домосетях, вообще. Это я говорю как бывший админ десятитысячной домашней сетки и нынешний пятитысячной.
Трафик с помощью NAT'a прекрасно прогоняется обьёмами (проверено на практике) до 10 Гбайт спокойно — его чрезвычайно удобно распараллеливать на относительно дешёвые PC-сервера.
Делать это надо уже сейчас, потому что спрос на это УЖЕ есть.
2. Не магистрал, но что-то ОЧЕНЬ сомневаюсь. Тем более что сами магистралы IPv6 вполне себе разворачивают.
3. Бессмысленна она в домосетях, вообще. Это я говорю как бывший админ десятитысячной домашней сетки и нынешний пятитысячной.
Выходом остаётся всё тот же NAT, только уже в другом направлении, а единственным известным софтверным решением является TAYGA, NAT64 for Linux (http://www.litech.org/tayga), последние изменения в котором датированы 10.06.2011, и который не входит в состав ни одного распространённого дистрибутива.
Простите, но «ЩИТО»‽ Для кого, спрашивается, я пакеты делал?
И да, даже и не думайте о NAT в IPv6. Не начинайте этот кошмар заново.
Да, именно это и неприятно удивило, что вместо того, чтобы использовать философию IPv6 протокола, разработчики пытаются скопировать принципы организации работы роутрера из IPv4.
Не понял. Вы сами написали, что минусом является отсутствие NAT. Или это были не Вы? :)
Минусом является следующее. Если провайдер развернул чистую IPv6 сеть, то невозможно пойти в магазин, купить wi-fi роутер с поддержкой IPv6, включить его в розетку, и попасть в интернет.
Даже если абонент в wizard-е первого запуска выберет IPv6, что уже выходит за пределы способностей среднего пользователя, то он получит адрес из сети fc00::/7, с которым он может только зайти на роутер, но не дальше. И звонок в поддержку домосетки абоненту не поможет, потому что пройтись по десятку менюшек, и корректно прописать выданные провайдером IPv6 сети для раздачи в LAN, а уж тем более маршруты — 99,99% пользователей гарантированно не сумеют.
Даже если абонент в wizard-е первого запуска выберет IPv6, что уже выходит за пределы способностей среднего пользователя, то он получит адрес из сети fc00::/7, с которым он может только зайти на роутер, но не дальше. И звонок в поддержку домосетки абоненту не поможет, потому что пройтись по десятку менюшек, и корректно прописать выданные провайдером IPv6 сети для раздачи в LAN, а уж тем более маршруты — 99,99% пользователей гарантированно не сумеют.
Простите, это где Вы видели такие роутеры, которые выдают
fc00::/7? Я не то что таких роутеров, а вообще с такими адресами в дикой природе не сталкивался, как-то так.Да и даже у вас написано:
Это не «единственное решение». Просто именно так делать и надо. По-другому не бывает, да.
Единственное решение — это в настройках DHCPv6 на роутере прописать реальную IPv6 сеть для LAN и прописать соответствующие маршруты в разделе IPv6 роутинга.
Это не «единственное решение». Просто именно так делать и надо. По-другому не бывает, да.
Роутер должен через PPPoE, RA или DHCPv6 получить от провайдера настройки для себя, сделать на их основе настройки для LAN и начать анонсить их в LAN по DHCPv6 и RA.
И, по–хорошему, те же действия роутер должен делать для Teredo и 6to4 (если полученный IPv4 не серый). Предположительно, доступ к другим Teredo узлам будет быстрее через Teredo, чем через нативный IPv6, и аналогично с 6to4.
Далее, у роутеров могут быть какие–то свои базы автонастройки 6rd для провайдеров типа ТТК–ЗС. Получили IPv4, взглянули на него, узнали, что у этого провайдера есть 6rd, настроили 6rd.
Далее, у роутеров могут быть какие–то свои базы автонастройки 6rd для провайдеров типа ТТК–ЗС. Получили IPv4, взглянули на него, узнали, что у этого провайдера есть 6rd, настроили 6rd.
1. хватит считать пользователей идиотами
2. хватит пускать идиотов в сеть.
я кончел ©
2. хватит пускать идиотов в сеть.
я кончел ©
Вы видимо не совсем изучили IPv6.
SLAAC и/или DHCPv6 должны раздавать сверху поданную /64 далее (в идеале и /56 и /48, но пока нет единого решения как это делать, ведь это LAN сегменты, а не один LAN сегмент). Он получит fe80 адрес локальный автоматом из своего мака, с помощью него он сможет отловить ICMP6 для установки соединения с рутером и соответственно установки реального внешнего IP с рутингом по SLAAC или DHCPv6.
SLAAC и/или DHCPv6 должны раздавать сверху поданную /64 далее (в идеале и /56 и /48, но пока нет единого решения как это делать, ведь это LAN сегменты, а не один LAN сегмент). Он получит fe80 адрес локальный автоматом из своего мака, с помощью него он сможет отловить ICMP6 для установки соединения с рутером и соответственно установки реального внешнего IP с рутингом по SLAAC или DHCPv6.
приобретать оборудование уровня Cisco ASR1000 — нереально дорого.
Серьезно?
Одна коробка, способная вытянуть почти 40гбит/с, стоит навскидку что-то около ста долларов по GPL. Со всеми лицензиями. Это я под 1002-X посчитал. И эта пара коробок наверняка способна стоять в самом ядре сети средних масштабов провайдера (но я не работал в операторе, потому могу ошибаться с оценкой трафика как в большую, так и в меньшую сторону). И умеет она до черта и больше.
Прямо сегодня рассказывали, что топовая модификация на тестах успешно роут-рефлектила в сумме 28 миллионов маршрутов при около 60к BGP соседств, даже не собираясь от этого умирать.
Ну и по поводу странных претензий к 3750-м. Вы уверены, что на них стоит поднимать BGP в условиях IX? Я вот нет. Они вообще не для этого предназначаются. Но я не вижу проблем для мелкого оператора (который слов вроде MPLS не знает и довольствуется QinQ в качестве доминирующего средства туннелирования, причем через весь город) тотально суммаризировать префиксы на каждом хопе, в итоге умещаясь в сотню-другую маршрутов на ядре. Включая, само собой, 0/0 в сторону устройств, пирящихся с IX.
1. Ну, в сотню тысяч у.е., пожалуй, не получится уложиться.
2. То, что вы описываете, относится к магистралам, нагрузка на ядро домашних сетей иная, и выше.
3. Мы работаем с большим количеством провайдеров домашних сетей, вас бы очень неприятно удивили реальные схемы построения и организации сетей. Особенно по сравнению с «рекомендациями» от Cisco.
4. Да, понятно, что 3750-3560 не предназначены для подобных задач, но на сетях до 2500 абонентов они обычное явление. В качестве ядра, с BGP, несколькими пирами, UA-IX (8-9К префиксов), и PIM-ом. Да, и загрузка по процу при этом у них в районе 30%. Их апгрейдят обычно, только когда в TCAM упираются.
2. То, что вы описываете, относится к магистралам, нагрузка на ядро домашних сетей иная, и выше.
3. Мы работаем с большим количеством провайдеров домашних сетей, вас бы очень неприятно удивили реальные схемы построения и организации сетей. Особенно по сравнению с «рекомендациями» от Cisco.
4. Да, понятно, что 3750-3560 не предназначены для подобных задач, но на сетях до 2500 абонентов они обычное явление. В качестве ядра, с BGP, несколькими пирами, UA-IX (8-9К префиксов), и PIM-ом. Да, и загрузка по процу при этом у них в районе 30%. Их апгрейдят обычно, только когда в TCAM упираются.
1. Плюс-минус. Если забить на резервирование, то можно вообще обойтись одной железкой. Ну и о выкладках, сделанных более полугода назад, забудьте — 1002-Х только что появился. Очень вкусная железка. Более емкие устройства тоже непрерывно обновляются.
2. Вы говорите, что 3560-3750 обычно стоят в ядре. Через них точно проходит поболее чем 40G? Просто такого непросто добиться, учитывая, что там в основном гигабитные интерфейсы :) А ASR имеет смысл ставить только на периметр (которому технически ничто не мешает быть ядром), и вот там carrier-grade NAT пригодится.
3. Да знаю я. Мне уже доводилось анализировать топологию L2 кольца одного местного провайдера и давать рекомендации по выравниванию костов STP, чтобы увести абонентов с постоянно падающего линка. Мне эта топология потом неделю в кошмарах снилась. Тут проблема ведь даже не в топологии, а в квалификации тех, кто поддерживает сеть.
4. Кошмар.
2. Вы говорите, что 3560-3750 обычно стоят в ядре. Через них точно проходит поболее чем 40G? Просто такого непросто добиться, учитывая, что там в основном гигабитные интерфейсы :) А ASR имеет смысл ставить только на периметр (которому технически ничто не мешает быть ядром), и вот там carrier-grade NAT пригодится.
3. Да знаю я. Мне уже доводилось анализировать топологию L2 кольца одного местного провайдера и давать рекомендации по выравниванию костов STP, чтобы увести абонентов с постоянно падающего линка. Мне эта топология потом неделю в кошмарах снилась. Тут проблема ведь даже не в топологии, а в квалификации тех, кто поддерживает сеть.
4. Кошмар.
Вы часто видели в свободном доступе графики загрузки каналов провайдера домашней сети? А знаете, почему? :) 40G канала среднему провайдеру не нужно вообще, даже 10G не всегда востребованы.
Тогда как понимать фразу «нагрузка на ядро домашних сетей иная, и выше.»? Так нагрузка выше, или ниже?
Шасси 1002-X (суп, два БП, 6 SFP дырок) стоит 33к. Плюс, вероятно, лицензия на 5к. Все GPL, то есть по факту будет намного дешевле. Это даст 5гб/с со всеми сервисами.
1002-X — такая замечательная маленькая железка, которая может роутить от 5гб/с до 36гб/с с промежуточными шагами в 10G и 20G (и насколько я понимаю архитектуру ASR, наличие/отсутствие NAT, netflow и прочих сервисов никак не сказывается на производительности). Одним и тем же железом. Скорости разблокируются лицензией, железо остается тем же самым.
Шасси 1002-X (суп, два БП, 6 SFP дырок) стоит 33к. Плюс, вероятно, лицензия на 5к. Все GPL, то есть по факту будет намного дешевле. Это даст 5гб/с со всеми сервисами.
1002-X — такая замечательная маленькая железка, которая может роутить от 5гб/с до 36гб/с с промежуточными шагами в 10G и 20G (и насколько я понимаю архитектуру ASR, наличие/отсутствие NAT, netflow и прочих сервисов никак не сказывается на производительности). Одним и тем же железом. Скорости разблокируются лицензией, железо остается тем же самым.
К сожалению, рекламный поток, выливаемый на посетителей семинаров/встреч, проводимых Cisco, очень сильно отличается от реалий провайдерского телекома. Да и, как минимум, нужно 48 sfp модуль куда-то вставить, а то, что вы предлагаете — не подходит для этого.
Ага, тот рекламный поток неслабо, так сказать, вдохновляет :) Ничего, по опыту — к выходным оклемаюсь. Однако, мы уже давно подумываем купить себе ASRов — есть задачи, где софтовый 7206-й справляется плохо.
Да, портовые адаптеры под ASR стоят неадекватных денег. Но если нужно принять много гигабитных физик, по которым ходит мало гигабитов — что конкретно мешает затерминировать их на тот же каталист или любой другой коммутатор с SPFшками, а на ASR выдать выдать их уже транком?
Ну и под «реалиями провайдерского телекома» понимается «кольца-кольца-кольца дэлинков»?
Да, портовые адаптеры под ASR стоят неадекватных денег. Но если нужно принять много гигабитных физик, по которым ходит мало гигабитов — что конкретно мешает затерминировать их на тот же каталист или любой другой коммутатор с SPFшками, а на ASR выдать выдать их уже транком?
Ну и под «реалиями провайдерского телекома» понимается «кольца-кольца-кольца дэлинков»?
1. В настоящее время считаю оптимальным вариантом для среднего провайдера 7600/6500 серию. Оптимальное соотношение цена/качество. Можно закрыть все текущие задачи, и всё равно остаётся ресурс на будущее развитие.
2. Кольца, звёзды — какая разница? Только лишь в настройке STP. Один раз настроить. А вот то, что на доступе: dlink/edge-core/zyxel/tp-link и прочие китайские поделки, они могут разукрасить каждый ваш день неповторимыми глюками. Да и то, что стоит в центре — отдельная тема, фантазии некоторых «IT-специалистов», особенно в небольших городах, иногда выплёскиваются в чудовщные реализации, где местный админ не уходит в отпуск годами, «потому что иначе всё ляжет».
2. Кольца, звёзды — какая разница? Только лишь в настройке STP. Один раз настроить. А вот то, что на доступе: dlink/edge-core/zyxel/tp-link и прочие китайские поделки, они могут разукрасить каждый ваш день неповторимыми глюками. Да и то, что стоит в центре — отдельная тема, фантазии некоторых «IT-специалистов», особенно в небольших городах, иногда выплёскиваются в чудовщные реализации, где местный админ не уходит в отпуск годами, «потому что иначе всё ляжет».
А вы думаете, 6-тонник в роли роутера будет дешевле ASRа? 720-й суп уже EOL, sup32 тоже, остались 720-10G и 2T. Один 720-й 10G суп (без шасси, без всего) стоит дороже одного ASRа в полном сборе. При этом уступает тому по части связанного с роутингом функционала (и NAT/PAT, и человеческий иерархический QoS, и многое другое).
Про 7600 не слежу, но наверняка там не лучше с ценами.
Ну а STP сам по себе является огромной проблемой. Не должно быть территориально разнесенных L2 сегментов окромя EoMPLS, не должно быть неравномерного распределения трафика (или тем более блокирования линков). Но вот только постройка правильной MPLS сети с TE и прочими наворотами — задача для мелкого хомячкового провайдера куда более сложная, чем покупка пары ASRов. И с точки зрения денег, и с точки зрения мозгов.
Про 7600 не слежу, но наверняка там не лучше с ценами.
Ну а STP сам по себе является огромной проблемой. Не должно быть территориально разнесенных L2 сегментов окромя EoMPLS, не должно быть неравномерного распределения трафика (или тем более блокирования линков). Но вот только постройка правильной MPLS сети с TE и прочими наворотами — задача для мелкого хомячкового провайдера куда более сложная, чем покупка пары ASRов. И с точки зрения денег, и с точки зрения мозгов.
1. К сожалению, реальная практика показывает, что очень редкий провайдер покупает новые железки. Это сегмент для корпораций, в основном, не связанных с IT. Если вас так часто Cisco таскает по семинарам/конференциям, значит вы либо реселлер, либо интегратор, либо представитель подобной корпорации, чей основной бизнес никак не основан на IT, однако бюджетирование позволяет CIO строить корпоративную инфраструктуру по всем «рекомендациям» Cisco.
2. Зато вторичный рынок активно бурлит, поэтому sup720 будет на нём присутствовать в достаточном количестве ещё лет пять, не меньше. Как и 67хх модули. Поэтому, для провайдера, который чаще всего либо находится на самоокупаемости, либо потратил уже все инвестиции, и должен начинать возвращать инвестору вложения, оптимальным решением является собрать на вторичке 7600/6500 за $25-35K, которая закроет все задачи сегодняшнего и завтрашнего дней. Опять-таки, именно 7600/6500, т.к. это «настоящий» хардварный роутер, а не 7200/7300.
3. Предлагаемые Cisco лабораторные схемы типа «правильной MPLS сети с TE и прочими наворотами» упираются в простой вопрос: «А зачем?». С точки зрения провайдера домашней сети основной позицией является, и будет являться: «Необходимо с минимальными накладными расходами организовать схему более-менее стабильно работающей сети». И вопрос даже не в мозгах, тем более, что для Cisco/Juniper на офф.сайте имеется полная документация по всем вопросам и технологиям, а вопрос именно в целесообразности использования той, или иной технологии.
2. Зато вторичный рынок активно бурлит, поэтому sup720 будет на нём присутствовать в достаточном количестве ещё лет пять, не меньше. Как и 67хх модули. Поэтому, для провайдера, который чаще всего либо находится на самоокупаемости, либо потратил уже все инвестиции, и должен начинать возвращать инвестору вложения, оптимальным решением является собрать на вторичке 7600/6500 за $25-35K, которая закроет все задачи сегодняшнего и завтрашнего дней. Опять-таки, именно 7600/6500, т.к. это «настоящий» хардварный роутер, а не 7200/7300.
3. Предлагаемые Cisco лабораторные схемы типа «правильной MPLS сети с TE и прочими наворотами» упираются в простой вопрос: «А зачем?». С точки зрения провайдера домашней сети основной позицией является, и будет являться: «Необходимо с минимальными накладными расходами организовать схему более-менее стабильно работающей сети». И вопрос даже не в мозгах, тем более, что для Cisco/Juniper на офф.сайте имеется полная документация по всем вопросам и технологиям, а вопрос именно в целесообразности использования той, или иной технологии.
1. Ни реселлер, ни интегратор, а конечный пользователь, чей бизнес действительно не связан с IT, однако качественная инфраструктура нужна.
2. По связанным с роутингом возможностям обе эти железки сильно отстают от специализированного роутера :)
3. Это же очевидно — обеспечить более полную утилизацию имеющихся каналов связи, ибо STP неуправляем. А более полная утилизация — это возможность и сделать более вкусные тарифы, и подключить больше абонентов. А главное — стремительная сходимость при очередном перерубании оптики бульдозером.
2. По связанным с роутингом возможностям обе эти железки сильно отстают от специализированного роутера :)
3. Это же очевидно — обеспечить более полную утилизацию имеющихся каналов связи, ибо STP неуправляем. А более полная утилизация — это возможность и сделать более вкусные тарифы, и подключить больше абонентов. А главное — стремительная сходимость при очередном перерубании оптики бульдозером.
Выглядит странно… Во всех четырех случаях, описанных в статье, были проблемы с DNS по IPv6. У автора точно с внешней инфраструктурой всё в порядке? Что использовалось с качестве эталонного ipv6 клиента, подтвреждающего, что инфраструктура IPv6 настроена правильно?
В качестве клиента использовались:
1. Железки cisco с разными IOS.
2. Те же самые системы в условиях dual-stack корректно забирают оба DNS: и IPv6, и IPv6.
1. Железки cisco с разными IOS.
2. Те же самые системы в условиях dual-stack корректно забирают оба DNS: и IPv6, и IPv6.
Инфраструктура Сisco c клиентами от cisco? Честно признаться. такая конструкция от доминирующего производителя доверия не вызывает. Cisco уже на раз ловили на несовместимости с железом сторонних производителей. И памятуя 3Сom'овский ethernet… Да и цисковский smb wifi роутер тоже не заработал.
Попробуйте в качестве эталонных железок выбрать что-нибудь от другого производителя. Например от Juniper…
Попробуйте в качестве эталонных железок выбрать что-нибудь от другого производителя. Например от Juniper…
1. Вспомнил, OpenWRT абсолютно корректно работал как в dual-stack, так и в чистом IPv6. И DNS тоже корректно забирал. Но в данной статье OpenWRT не рассматривалась, т.к. обзор ориентирован на провайдеров домашних сетей.
2. К сожалению, как показывает практика, не получается считать Extreme/Juniper «эталонными» железками. Из ярких примеров — недавнее трёхдневное флопанье UA-IX.
2. К сожалению, как показывает практика, не получается считать Extreme/Juniper «эталонными» железками. Из ярких примеров — недавнее трёхдневное флопанье UA-IX.
Да стоило хотя бы тот же Mikrotik попробовать.
Тот же дешевый 751й SOHO-роутер со свежей прошивкой стабильно умеет принимать RA, запрашивать посредством DHCPv6 routed-префикс, и использовать его в качестве ip-pool для клиентов во внутренней сети. Причем как и по Ethernet-у, так и по PPP.
Тот же дешевый 751й SOHO-роутер со свежей прошивкой стабильно умеет принимать RA, запрашивать посредством DHCPv6 routed-префикс, и использовать его в качестве ip-pool для клиентов во внутренней сети. Причем как и по Ethernet-у, так и по PPP.
Микротик — это несколько спорный вопрос. К нам приходит в среднем два-три потенциальных клиента в месяц со словами: «Нам так надоел микротик, жить с ним больше не можем, пожалуйста, сделайте, чтобы его не было». При этом сам по себе Микротик, имхо, очень неплохая вещь для соответствующих задач. Задачи эти описаны на его офф.сайте, это: подключение branch office (сети филиалов) в корпоративную сеть, и wi-fi hotspot.
Как для домашних сетей, то при определённой нагрузке, зависящей от модели и версии, микротик начитает лагать, и автоматизация его управления сводится к тому, что у администратора сети образуется набор скриптов, отслеживающих, не залипло ли API микротика, и не надо ли его перегрузить.
Но, опять-таки, повторюсь: есть задачи, для которых микротик — хороший, а иногда, и лучший выбор.
Как для домашних сетей, то при определённой нагрузке, зависящей от модели и версии, микротик начитает лагать, и автоматизация его управления сводится к тому, что у администратора сети образуется набор скриптов, отслеживающих, не залипло ли API микротика, и не надо ли его перегрузить.
Но, опять-таки, повторюсь: есть задачи, для которых микротик — хороший, а иногда, и лучший выбор.
Да и заявленная работоспособность, например, youtube, тоже относительна: сам ресурс полностью поддерживает IPv6, однако для его использования нужен Adobe Flash Player, который скачать и установить невозможно, т.к. все ресурсы Adobe недоступны по IPv6.
При всём уважении, но это чушь… Android 4.2 на моём Nexus 7 официально не поддерживает Adobe Flash Player. Но не видел на YouTube ни одного ролика, который бы я не смог посмотреть из-за отсутствия AFP…
Вы можете очень просто убедиться в том, что вы заблуждаетесь: поставьте Windows 7, накатите на неё все обновления, пропишите чистый IPv6 адрес, и сходите на youtube.
Вы смотрите его не через Flash, а в html 5 mode
Бинго!
А что мешает при использовании ipv6 смотреть в html5 mode?
Это замечательно, что вы знаете где и как это включить на youtube. Возможно, вы и Gentoo собираете с 2002 года. Однако для домашней сети, практически всегда существующей в условиях жёсткой конкуренции, лояльность пользователей является приоритетной задачей. А лояльность эта обратно пропорциональна количеству звонков абонентов в саппорт. Даже с вопросом: «А как мне включить html5 mode для youtube?».
Я был убежден, что html5 на youtube по умолчанию, если у вас правильный веб-броузер, поддерживающий html5.
Нв выходных гляну в чем там проблема…
Нв выходных гляну в чем там проблема…
Пытался я жить без флеша несколько месяцев назад, не вышло. Через html5 они рекламу, кажется, показывать не умеют, от того и половина роликов недоступна оказывается. На том же андроиде клиент показывает и рекламу, и ролик, естественно, без всякого флеша (имею в виду клиент. Рекламы в роликах на сайтах как-то не встречал) Может, что-то и изменилось нынче.
А мне, пожалуйста, QuickTime mode или VLC mode :)
еще в ipv4 существовалс такая опция dhcp как prefix deligation. вот в ipv6 этот параметр и должен показать себя во всей красе.
алгоритм такой: абонент получает RA, в котором есть префикс global unicast и шлюз. также опционально может быть dns и обязательно managment flag, который указывает, проводить дальнейшую настройку по dhcpv6 или нет. если да, то отправляется multicast пакет, в который коммутатор доступа добавляет opt37 и шлюз релеит его на центральный сервер. в ответе будут все обычные параметры плюс опция PD, заглянув в которую шлюз должен нарисовать этот маршрут в сторону абонента, а абонетский роутер должен начать выдавать эту сеть на внутренних интерфейсах. все работает и все счастливы!..
алгоритм такой: абонент получает RA, в котором есть префикс global unicast и шлюз. также опционально может быть dns и обязательно managment flag, который указывает, проводить дальнейшую настройку по dhcpv6 или нет. если да, то отправляется multicast пакет, в который коммутатор доступа добавляет opt37 и шлюз релеит его на центральный сервер. в ответе будут все обычные параметры плюс опция PD, заглянув в которую шлюз должен нарисовать этот маршрут в сторону абонента, а абонетский роутер должен начать выдавать эту сеть на внутренних интерфейсах. все работает и все счастливы!..
У ТТК–ЗС IPv6 сделан как 6rd, то есть, периферия и биллинг видят IPv4, потом пакеты где–то разворачиваются в полноценный IPv6.
Я посмотрел профиль автора и у меня возникло странное предположение, что технарь из украинского пионертелекома (или около того), не осиливающего IPv6, говорит людям, что оно им на самом деле не нужно и работать не будет. Скажите, автор, насколько я прав в своём предположении? Доводы в статье надуманные на 146%
1. Мы осуществляем поддержку ядра сети многих домосеток, из которых, несомненно, несколько десятков можно отнести к «пионертелекому». География наших клиентов — СНГ.
2. Будьте любезны, приведите ваши доводы либо опровержения, с удовольствием их выслушаю.
2. Будьте любезны, приведите ваши доводы либо опровержения, с удовольствием их выслушаю.
Согласен.
Возможно, по поводу домашних роутеров инфа и весьма достоверная, но заметно явное недопонимание технологий, с которыми должен быть знаком любой провайдер, особенно домашних сетей ;)
Возможно, по поводу домашних роутеров инфа и весьма достоверная, но заметно явное недопонимание технологий, с которыми должен быть знаком любой провайдер, особенно домашних сетей ;)
Хорошая статья. Одно «но» — Edge-Core — это не DCN, это Accton.
Вышесказанное необходимо осознавать в первую очередь украинским провайдерам: никакого UA-IX в IPv6 сетях нет,
Обычно бывает наоборот — IPv6 в сетях.
В UA-IX-е 6я версия протокола официально поддерживается с июня 2011г, больше четверти участников точки обмена анонсируют v6 префиксы. По BGP кстати. А в процитированном посте создается впечатление, что протоколы маршрутизации уже не нужны, и вообще, всем должно быть достаточно default gateway.
Я вообще не увидил причинно-следственной связи в этом абзаце, просто набор неверных (с моей точки зрения) утверждений.
На UA-IX BGPv6 поднят и вполне работает.
Префиксов на момент пол-года назад в fullview было 6k кажись. На тему агрегации серьезно ломаются копья, потому как народ по привычке начал дробить префиксы (и на то есть по правде говоря основания) и уже виден тот момент, когда 76е fullview v4 и v6 одновременно не потянут.
Насчет 100М вообще не понятно — при чем к v6 полоса?
Да и вообще в статье много спорных утверждений (например насчет отдельных полос под v6 у аплинков).
никакого UA-IX в IPv6 сетях нет, протоколом заложены элементы маршрутизации уже в заголовке IPv6 пакета (http://tools.ietf.org/html/rfc3587), сети аггрегируются по умолчанию, IPv6 full-view не может превышать 8К префиксов. Соответственно, провайдерам прийдётся отвечать на волну вопросов абонентов: «А почему у меня нет 100М на UA-IX?».
На UA-IX BGPv6 поднят и вполне работает.
Префиксов на момент пол-года назад в fullview было 6k кажись. На тему агрегации серьезно ломаются копья, потому как народ по привычке начал дробить префиксы (и на то есть по правде говоря основания) и уже виден тот момент, когда 76е fullview v4 и v6 одновременно не потянут.
Насчет 100М вообще не понятно — при чем к v6 полоса?
Да и вообще в статье много спорных утверждений (например насчет отдельных полос под v6 у аплинков).
Вы еще припомните такие «мелочи», как «полная» поддержка IPv6 в SNMP у той же циски, или возможность зажимать скорость для клиентов согласно их тарифным планам на том ПО и железе, которое уже есть в сетях. Как биллингам работать, если по тарифу первый 10 Гб клиент получает на скорость 5 Мбит, а далее скорость падает вдвое, при этом скорость доступа к сети провайдера всегда должна быть, скажем, 30 Мбит? Вопросов больше, чем ответов.
Особенно радуют отдельные крупные хостинги с вопросами «ой, а зачем вам вообще этот Ipv6?», и, порой, норовящие продавать каждый Ipv6 адрес поштучно :)
Особенно радуют отдельные крупные хостинги с вопросами «ой, а зачем вам вообще этот Ipv6?», и, порой, норовящие продавать каждый Ipv6 адрес поштучно :)
как так получилось что интернет лишился ipv5? как то быстро мы проскочили с ipv4 на ipv6…
IPv5 — это секретный военный проект. К сожалению по дурацкой оплошности вся информация о нем была утеряна, поэтому пришлось придумывать 6ю версию с нуля :-)
Вы еще про IPv9 спросите. А между тем tools.ietf.org/html/rfc1606 :)
P.S. Очевидно, чтобы адресов хватило всех холодильникам каждой блохи каждой скотины у каждого китайца :)
P.S. Очевидно, чтобы адресов хватило всех холодильникам каждой блохи каждой скотины у каждого китайца :)
Всё не так печально. Для оператора связи есть простая схема — называется vlan per customer.
При этом на доступе можно использовать даже самые дряхлые управляемые коммутаторы, от которых не требуется вообще знать, что такое IPv6 — управлять ими можно и по IPv4.
На агрегации нужна железка посвежее, умеющая «влан во влане», но и это не проблема — они сейчас дешёвые. Например, DGS-3120-24SC.
Пока полоса не превышает 5-10 гигабит — в ядре вполне справятся обычные PC-роутеры, при нехватке одного роутера трафик можно разбросать по роутерам. При полосе более 10 гигабит становится оправданной покупка, например, младшего Juniper MX, который позволяет терминировать, если мне не изменяет память, до 32 тысяч вланов.
В итоге абонент получает автоконфигурацию по DHCP+RA и у него всё работает.
IPv6 — стандартная подсеть /64, IPv4 — например, серая подсеть /28.
Теперь про абонентское железо — опять же, есть одно очень простое решение: абонентский вайфай можно перевести в режим моста. Либо отключить на нём DHCP и воткнуть провайдерский кабель в LAN. И с этого момента уже неважно, что старая абонентская железка ничего не знает про IPv6 — всё будет работать и так.
Если абоненту не требуется вайфай — то роутер не нужен вообще, никакой, достаточно неуправляемого свича за 300руб.
При этом на доступе можно использовать даже самые дряхлые управляемые коммутаторы, от которых не требуется вообще знать, что такое IPv6 — управлять ими можно и по IPv4.
На агрегации нужна железка посвежее, умеющая «влан во влане», но и это не проблема — они сейчас дешёвые. Например, DGS-3120-24SC.
Пока полоса не превышает 5-10 гигабит — в ядре вполне справятся обычные PC-роутеры, при нехватке одного роутера трафик можно разбросать по роутерам. При полосе более 10 гигабит становится оправданной покупка, например, младшего Juniper MX, который позволяет терминировать, если мне не изменяет память, до 32 тысяч вланов.
В итоге абонент получает автоконфигурацию по DHCP+RA и у него всё работает.
IPv6 — стандартная подсеть /64, IPv4 — например, серая подсеть /28.
Теперь про абонентское железо — опять же, есть одно очень простое решение: абонентский вайфай можно перевести в режим моста. Либо отключить на нём DHCP и воткнуть провайдерский кабель в LAN. И с этого момента уже неважно, что старая абонентская железка ничего не знает про IPv6 — всё будет работать и так.
Если абоненту не требуется вайфай — то роутер не нужен вообще, никакой, достаточно неуправляемого свича за 300руб.
Прошу пояснить при чем тут q-in-q и как его использовать.
Ну и чем спасет vlan на пользователя…
Ну и чем спасет vlan на пользователя…
Можно и без QinQ, но тогда будет лимит в четыре тысячи абонентов. В случае QinQ, теоретический предел порядка 16 миллионов.
vlan на пользователя имеет массу преимуществ:
— во-первых, как я написал выше, можно вводить IPv6 даже на самых старых свичах. Например, у меня в сети в нескольких местах трудятся D-Link DES-3226, которые датируются чуть ли не 2001 годом. Несмотря на столь почтенный возраст, они прекрасно работают по сей день. Им без разницы, что пропускать — IPv4 ли, IPv6 ли…
Конечно, для них нет плат с поддержкой wdm sfp модулей, но «вторым» свичом на доступе, будучи присоединённым к «первому» свичу медным гигабитом, они работают прекрасно.
— при предоставлении IPv6, можно выделять независимую /64 подсеть каждому абоненту, вместо «общеколхозной».
Это резко упрощает идентификацию абонента по адресу, ведение базы и администрирование адресного пространства в целом.
— практически исчезает необходимость в пользовательском роутере.
Абонент может воткнуть неуправляемый свич и кучу устройств в него, все они автоматом получат адреса (что v6, что серые v4) по DHCP — благодаря тому, что отсутствует необходимость в идентификации адресов и защитной привязке адресов к порту, лимит на их количество практически исчезает.
А это не только экономия денег, но ещё и экономия на поддержке — не нужно разбираться, проблема с сетью или с абонентским роутером, не нужно гонять сотрудника к абоненту, чтобы настраивать роутер, или полчаса пытаться объяснять абоненту, как его настроить самостоятельно (в итоге плюнув и выслав сотрудника).
Да и абонент при проблемах с роутером склонен пенять на провайдера.
— полная изоляция абонентов друг от друга.
Абонент не имеет даже теоретической возможности «нагадить» соседу. Ни намеренно, ни сдуру.
Абоненты не связаны между собой — по сути, они всё равно что подключены к разным провайдерам. Могут достучаться до друг друга только «через интернет».
— нет проблем с совпадением mac-адресов абонентов в одном доме, что вытекает из предыдущего пункта.
Если бы они были в одном влане, это сделало бы абсолютно невозможной работу как минимум одного из них, а обычно обоих.
Один и тот же mac-адрес в двух разных вланах — штатная ситуация, проблем при этом не будет и не может быть.
А такое совпадение случается — зачастую из-за роутеров, в которые заливают альтернативные прошивки: прошивка может проигнорировать mac роутера и засветить какой-нибудь дефолтный.
— нет нужды в разного рода «привязках», которыми страдают некоторые провайдеры. Просто воткнул и работает, никаких звонков «у меня сменился mac-адрес».
— можно регулировать локалку.
Фильтровать вирусный трафик, разного рода попытки сканирования соседей.
Можно предотвратить ситуацию типа «добрый юзер купил 100-мегабитный тариф и открыл прокси на весь дом» — халявщикам с младшими тарифами локалку можно зашейпить, и у них не будет смысла сидеть на прокси.
В общем, по сути палочка-выручалочка. Одни плюсы.
Минус только один — нужны управляемые свичи с вланами.
vlan на пользователя имеет массу преимуществ:
— во-первых, как я написал выше, можно вводить IPv6 даже на самых старых свичах. Например, у меня в сети в нескольких местах трудятся D-Link DES-3226, которые датируются чуть ли не 2001 годом. Несмотря на столь почтенный возраст, они прекрасно работают по сей день. Им без разницы, что пропускать — IPv4 ли, IPv6 ли…
Конечно, для них нет плат с поддержкой wdm sfp модулей, но «вторым» свичом на доступе, будучи присоединённым к «первому» свичу медным гигабитом, они работают прекрасно.
— при предоставлении IPv6, можно выделять независимую /64 подсеть каждому абоненту, вместо «общеколхозной».
Это резко упрощает идентификацию абонента по адресу, ведение базы и администрирование адресного пространства в целом.
— практически исчезает необходимость в пользовательском роутере.
Абонент может воткнуть неуправляемый свич и кучу устройств в него, все они автоматом получат адреса (что v6, что серые v4) по DHCP — благодаря тому, что отсутствует необходимость в идентификации адресов и защитной привязке адресов к порту, лимит на их количество практически исчезает.
А это не только экономия денег, но ещё и экономия на поддержке — не нужно разбираться, проблема с сетью или с абонентским роутером, не нужно гонять сотрудника к абоненту, чтобы настраивать роутер, или полчаса пытаться объяснять абоненту, как его настроить самостоятельно (в итоге плюнув и выслав сотрудника).
Да и абонент при проблемах с роутером склонен пенять на провайдера.
— полная изоляция абонентов друг от друга.
Абонент не имеет даже теоретической возможности «нагадить» соседу. Ни намеренно, ни сдуру.
Абоненты не связаны между собой — по сути, они всё равно что подключены к разным провайдерам. Могут достучаться до друг друга только «через интернет».
— нет проблем с совпадением mac-адресов абонентов в одном доме, что вытекает из предыдущего пункта.
Если бы они были в одном влане, это сделало бы абсолютно невозможной работу как минимум одного из них, а обычно обоих.
Один и тот же mac-адрес в двух разных вланах — штатная ситуация, проблем при этом не будет и не может быть.
А такое совпадение случается — зачастую из-за роутеров, в которые заливают альтернативные прошивки: прошивка может проигнорировать mac роутера и засветить какой-нибудь дефолтный.
— нет нужды в разного рода «привязках», которыми страдают некоторые провайдеры. Просто воткнул и работает, никаких звонков «у меня сменился mac-адрес».
— можно регулировать локалку.
Фильтровать вирусный трафик, разного рода попытки сканирования соседей.
Можно предотвратить ситуацию типа «добрый юзер купил 100-мегабитный тариф и открыл прокси на весь дом» — халявщикам с младшими тарифами локалку можно зашейпить, и у них не будет смысла сидеть на прокси.
В общем, по сути палочка-выручалочка. Одни плюсы.
Минус только один — нужны управляемые свичи с вланами.
Я все равно не понял про q-in-q. Что с ним делать?
Вот есть допустим коммутатор доступа и 32 абоненскими vlan'ами, прилетели эти vlan'ы на агрегацию, дальше что происходит?
Вот есть допустим коммутатор доступа и 32 абоненскими vlan'ами, прилетели эти vlan'ы на агрегацию, дальше что происходит?
Порт QinQ коммутатора может работать в двух режимах — NNI и UNI.
NNI — это традиционный режим. Прилетели 32 влана и коммутатор их понимает как 32 разных влана.
UNI — это режим свёртки в QinQ. В этом режиме коммутатор перестаёт обращать внимания на vlan-теги в пакетах, а вместо этого на абсолютно все приходящие пакеты, без разбору, вешает указанный vlan-тег «поверх».
Соответственно, на порту агрегирующего коммутатора, который смотрит на наш коммутатор доступа, мы включаем UNI. 32 влана сворачиваются в один влан, который улетает в ядро.
В итоге, в ядре мы имеем один влан на весь указанный доступ, пакеты в котором имеют двойной тег: снаружи тег, которым их обернул агрегирующий коммутатор, а внутри тег какого-то из 32 вланов.
Всё это прилетает на роутер в ядре, в котором созданы интерфейсы — по интерфейсу на абонента.
У всех интерфейсов указаны оба vlan-тега — внешний и внутренний.
На Juniper это прямо так и пишется в явном виде в свойствах интерфейса — например,
vlan-tags outer 3 inner 121;
На PC-роутерах же, просто создаются вложенные vlan-интерфейсы — сначала «внешний», цепляемый к физическому интерфейсу, а потом 32 «внутренних», цепляемых к «внешнему» — например,
ifconfig vlan3 create vlan 3 vlandev em0 up
ifconfig vlan121 create vlan 121 vlandev vlan3 up
NNI — это традиционный режим. Прилетели 32 влана и коммутатор их понимает как 32 разных влана.
UNI — это режим свёртки в QinQ. В этом режиме коммутатор перестаёт обращать внимания на vlan-теги в пакетах, а вместо этого на абсолютно все приходящие пакеты, без разбору, вешает указанный vlan-тег «поверх».
Соответственно, на порту агрегирующего коммутатора, который смотрит на наш коммутатор доступа, мы включаем UNI. 32 влана сворачиваются в один влан, который улетает в ядро.
В итоге, в ядре мы имеем один влан на весь указанный доступ, пакеты в котором имеют двойной тег: снаружи тег, которым их обернул агрегирующий коммутатор, а внутри тег какого-то из 32 вланов.
Всё это прилетает на роутер в ядре, в котором созданы интерфейсы — по интерфейсу на абонента.
У всех интерфейсов указаны оба vlan-тега — внешний и внутренний.
На Juniper это прямо так и пишется в явном виде в свойствах интерфейса — например,
vlan-tags outer 3 inner 121;
На PC-роутерах же, просто создаются вложенные vlan-интерфейсы — сначала «внешний», цепляемый к физическому интерфейсу, а потом 32 «внутренних», цепляемых к «внешнему» — например,
ifconfig vlan3 create vlan 3 vlandev em0 up
ifconfig vlan121 create vlan 121 vlandev vlan3 up
Спасибо, стало понятно )
Сделайте милость, расскажите еще один момент: схема отличная, но ведь (обычно) юзеры хотят и используют в т.ч. и IPv4. Так вот по сколько IPv4-адресов на юзера Вы выделяете? Ресурс-то дефицитный :), а многим дома девайса по 3-4 точно надо подключить… Плюс, получается, Вы выделяете на юзера по подсетке, т.е. тратите адреса не только на девайсы, но и по 3 адреса для служебных целей — не сильно расточительно, в случае IPv4?
Поскольку это «серые» адреса — абсолютно не расточительно.
На юридических лиц — подсеть /24, 253 эффективных адреса.
На физических лиц — подсеть /28, 13 эффективных адресов.
Например, абонент получает по DHCP шлюз 10.1.0.1, а адреса выдаются в диапазоне 10.1.0.2 — 10.1.0.14 включительно.
Если же абонент просит выделить внешний IPv4 адрес — то он выдаётся уже штучно по запросу, по rfc3069.
В моём случае конфигурирования по DHCP при этом уже не происходит, т.к. будет неопределённой ситуация, какой адрес выдавать устройству, запросившему его по DHCP — единственный назначенный абоненту внешний, либо какой-либо из серых.
К примеру, провайдер располагает подсетью 4.0.0.0/16 и хочет ею распорядиться предельно экономно.
У всех абонентов, использующих внешние IPv4 адреса, прописывается один и тот же шлюз 4.0.0.1 и одна и та же маска 255.255.0.0, а адреса указываются уже индивидуально из диапазона 4.0.0.2 — 4.0.255.254 включительно. Таким образом, если выдавать по одному адресу, то этими 65536 адресами можно обеспечить 65533 абонента.
Разумеется, можно выдать и два, три и так далее IPv4 адресов одному и тому же абоненту, что иногда востребовано юридическими лицами.
В отличие от работы с подсетями, помимо отсутствия затрат адресов для служебных целей, эта технология хороша тем, что адреса можно выдавать и изымать штучно, обеспечивая абонента ровно таким количеством адресов, в котором он нуждается, без «захомячивания» адресов впрок.
Также бывают иные подходы по той же технологии.
Например, московский провайдер Онлайм вместо использования «серых» адресов выдаёт реальные по DHCP, обеспечивая абонента от 1 до 5 внешними адресами. Шестой адрес уже не будет выдан, ответа на DHCP запрос не будет, пока не освободятся какие-то из занятых пяти. Когда длительное время не возобновляется DHCP аренда, адрес у абонента изымается, и в следующий раз будет выдан уже другой.
За отдельную плату один из адресов становится фиксированным и выдаётся всегда один и тот же.
Однако, это слишком расточительный подход, и вполне вероятно, что суровые реалии дефицита IPv4 заставят их пересмотреть подход в ближайшие годы.
На юридических лиц — подсеть /24, 253 эффективных адреса.
На физических лиц — подсеть /28, 13 эффективных адресов.
Например, абонент получает по DHCP шлюз 10.1.0.1, а адреса выдаются в диапазоне 10.1.0.2 — 10.1.0.14 включительно.
Если же абонент просит выделить внешний IPv4 адрес — то он выдаётся уже штучно по запросу, по rfc3069.
В моём случае конфигурирования по DHCP при этом уже не происходит, т.к. будет неопределённой ситуация, какой адрес выдавать устройству, запросившему его по DHCP — единственный назначенный абоненту внешний, либо какой-либо из серых.
К примеру, провайдер располагает подсетью 4.0.0.0/16 и хочет ею распорядиться предельно экономно.
У всех абонентов, использующих внешние IPv4 адреса, прописывается один и тот же шлюз 4.0.0.1 и одна и та же маска 255.255.0.0, а адреса указываются уже индивидуально из диапазона 4.0.0.2 — 4.0.255.254 включительно. Таким образом, если выдавать по одному адресу, то этими 65536 адресами можно обеспечить 65533 абонента.
Разумеется, можно выдать и два, три и так далее IPv4 адресов одному и тому же абоненту, что иногда востребовано юридическими лицами.
В отличие от работы с подсетями, помимо отсутствия затрат адресов для служебных целей, эта технология хороша тем, что адреса можно выдавать и изымать штучно, обеспечивая абонента ровно таким количеством адресов, в котором он нуждается, без «захомячивания» адресов впрок.
Также бывают иные подходы по той же технологии.
Например, московский провайдер Онлайм вместо использования «серых» адресов выдаёт реальные по DHCP, обеспечивая абонента от 1 до 5 внешними адресами. Шестой адрес уже не будет выдан, ответа на DHCP запрос не будет, пока не освободятся какие-то из занятых пяти. Когда длительное время не возобновляется DHCP аренда, адрес у абонента изымается, и в следующий раз будет выдан уже другой.
За отдельную плату один из адресов становится фиксированным и выдаётся всегда один и тот же.
Однако, это слишком расточительный подход, и вполне вероятно, что суровые реалии дефицита IPv4 заставят их пересмотреть подход в ближайшие годы.
В gentoo есть tayga:
Согласен с автором, что «работа не для обычного пользователя»
Спасибо за интересный обзор.
$ eix tayga
* net-proxy/tayga
Available versions: 0.9.2
Homepage: http://www.litech.org/tayga/
Description: out-of-kernel stateless NAT64 implementation based on TUN
Согласен с автором, что «работа не для обычного пользователя»
Спасибо за интересный обзор.
Убрал тоннель с роутера, Гугол задолбал перекидывать на голландскую версию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IPv6 для домашних сетей