Comments 51
Городить колхоз из нескольких клиентов в одном влане — нарываться на проблемы.
vlan per user всё решает.
vlan per user всё решает.
Тоже не понял, почему нельзя вилан на юзера с /64 подсетью сделать. И рекомендации — кидать юзеров в один вилан как то совсем непрофессионально, особенно, когда речь о юр. лицах.
На что выдавать vlan в рамках ipv4 — всегда было холиваром на тематических форумах, тут многое зависит от уровня доступа и политики построения сети. Я бы хотел от вас обоих услышать что колхозного, в рамках IPv6 в vlan-per-aggr.
А я бы хотел услышать почему мы вообще обсуждаем вопрос VLAN'ов в разрезе ip адресации?
1) бесконтрольный трафик между абонентами.
абонент взял себе жирный тариф, соседи взяли дешёвые тарифы, хозяин жирного тарифа поднял прокси и устроил коммунизм.
если же резать скорость на порту — исчезает стандартная «быстрая локалка», да и свичи режут скорости неаккуратно, в отличие от роутеров.
2) абоненты могут гадить друг другу.
ставить себе адрес шлюза, поднимать dhcp/ra, ставить себе ip-адреса соседей, запускать снифферы.
причём, зачастую это делается не со зла, а просто по глупости.
3) при использовании SLAAC, ipv6 клиенты сами назначают себе адреса.
и даже не гадя друг другу, абоненты (как их компы автоматически, так и сами абоненты вручную) могут себе установить любой ipv6 адрес из /64 блока, никому не помешав.
в итоге — непонятно, кто где, как их шейпить, как разбираться, кто спамил…
и самое весёлое будет с внедрением СОРМ-2, когда нужно предоставить вполне конкретное соответствие адреса/блока абоненту.
Можно, конечно, отказаться от SLAAC, прибить намертво mac-адреса, v4/v6 адреса назначать статически и т.д., но это уже начинается какой-то геморрой для абонента.
Можно поставить Особо Умный Свич Доступа, который что-то там как-то сам контролирует, но это уже стройная система костылей, подпорок, палок и верёвок.
Для сравнения — в случае vlan per user — абонент включает патчкорд в компьютер и у него всё работает.
В дуалстеке. Само. Без каких-либо настроек.
Возможности помешать соседям нет даже теоретически — разные вланы двум абонентам по сути идентичны двум разным провайдерам.
абонент взял себе жирный тариф, соседи взяли дешёвые тарифы, хозяин жирного тарифа поднял прокси и устроил коммунизм.
если же резать скорость на порту — исчезает стандартная «быстрая локалка», да и свичи режут скорости неаккуратно, в отличие от роутеров.
2) абоненты могут гадить друг другу.
ставить себе адрес шлюза, поднимать dhcp/ra, ставить себе ip-адреса соседей, запускать снифферы.
причём, зачастую это делается не со зла, а просто по глупости.
3) при использовании SLAAC, ipv6 клиенты сами назначают себе адреса.
и даже не гадя друг другу, абоненты (как их компы автоматически, так и сами абоненты вручную) могут себе установить любой ipv6 адрес из /64 блока, никому не помешав.
в итоге — непонятно, кто где, как их шейпить, как разбираться, кто спамил…
и самое весёлое будет с внедрением СОРМ-2, когда нужно предоставить вполне конкретное соответствие адреса/блока абоненту.
Можно, конечно, отказаться от SLAAC, прибить намертво mac-адреса, v4/v6 адреса назначать статически и т.д., но это уже начинается какой-то геморрой для абонента.
Можно поставить Особо Умный Свич Доступа, который что-то там как-то сам контролирует, но это уже стройная система костылей, подпорок, палок и верёвок.
Для сравнения — в случае vlan per user — абонент включает патчкорд в компьютер и у него всё работает.
В дуалстеке. Само. Без каких-либо настроек.
Возможности помешать соседям нет даже теоретически — разные вланы двум абонентам по сути идентичны двум разным провайдерам.
А почему «Все loopback-и должны быть в одной /64 подсети»? Неочевидненько.
Плюс, года полтора назад, на ENOG'е представители провайдеров с грустью рассказывали, что не знают как считать IPv6 трафик.
Плюс, года полтора назад, на ENOG'е представители провайдеров с грустью рассказывали, что не знают как считать IPv6 трафик.
Такое у меня ощущение, что на самом деле они имели ввиду "… не знают, как считать IPv6 трафик, не приобретая новые версии OS маршрутизаторов и систем аккаунтинга". Конечно, никто из них не хочет тратиться.
А давайте от обратного: почему нет?
Если так не получится, то попробую выложить своё видиние.
Если так не получится, то попробую выложить своё видиние.
Нет, давайте от прямого, а то что это за такидатая дуэль?
Это удобнее и практичнее: не нужно на каждое устройство выделять по сети для лупбеков, либо брать из других сетей.
Тогда ознакомьтесь, пожалуйста.
А зачем считать трафик? Разве уже не уходят от трафиковых тарифов?
Если на провайдера выдается /32, то непонятен смысл экономии. Даже если на каждого хомяка (пардон — домашнего пользователя) давать /64, адресов хватит надолго. Ну и vlan-per-site оправдан только в случае с теми же домашними клиентами при условии «умного» доступа, умеющего фильтрацию на портах. В случае с юр. лицами vlan-per-user это почти обязательно.
Если на доступе что-то не совсем умное, то лучше будет vlan-per-user, но в таком случае в ядре сети должна быть достаточно производительная железка, которая будет фильтровать, красить, роутить, шейпить и т.д.
Забыл: еще вопрос в хардварных ограничениях. Н-р в дуал-стэке ресурсы Catalyst 3560G становятся совсем не впечатляющими, посему использовать vlan-per-user будет дорого как по железу, так и по трудозатратам н-р на перекоммутацию, смену текущих конфигураций и т.п.
Ну дык может просто надо апгрейдить железо? Серьезно, пока ipv6 станет обязательным и незаменимым, пройдет еще пару лет, а за это время можно поставить что-то более приличное.
Давать /64 на пользователя — мало, я считаю. Все-таки, некоторые захотят маршрутизировать IPv6, а это (правильно) не выйдет с одним /64. Либо давать 2-3 /64, либо /60.
Зачем хомячку маршутизировать IPV6?
Ну, насколько я знаю, SoHo роутеры пока не позволяют сделать бридж для IPv6, и NAT для IPv4. А иначе не раздать один /64. Ну, раздать-то можно, но это будет геморрой, т.к. RA поддерживает минимум /64.
Я что-то не понимаю, если роутер не может делать бридж для IPv6, то значит только натить ipv6? А если речь про NAT, то зачем раздавать ту же /64 машинам за NAT? Тогда уже можно приватные IPV6 префиксы там использовать.
Ну, например, у меня было сделано так: провайдер выдает один адрес IPv4, его пускаем в локалку через NAT, а IPv6 через туннель-брокера, тот же HE выдает две /64 — одна для связи с сервером, ее присваиваем sit-интерфейсу, а другая /64 для раздачу в локалку, ее присваиваем проводному интерфейсу. И я считаю, этот подход правильный.
И, думается мне, провайдеру будет так сделать проще всего: выдавать 1 IPv4 и два /64, ну, либо один /60, т.к. я не видел роутеров-коробок, которые могут бриджем пустить IPv6, а IPv4 натить, а NAT для IPv6 вообще недавно появился в ядре линукса, и это все-таки костыль, очень не хотелось бы задействовать его для IPv6, когда для провайдера никаких проблем в выдаче двух /64 нет.
www.bircd.org/annoyances/prefix64/ вот тут пишут:
«a home does not need more than one subnet»
You will need atleast 2 if you want both a wired lan, and wireless, and want control over how you set it up with routing, firewalling, public/private subnets, etc, or for experimentation/research.
И, думается мне, провайдеру будет так сделать проще всего: выдавать 1 IPv4 и два /64, ну, либо один /60, т.к. я не видел роутеров-коробок, которые могут бриджем пустить IPv6, а IPv4 натить, а NAT для IPv6 вообще недавно появился в ядре линукса, и это все-таки костыль, очень не хотелось бы задействовать его для IPv6, когда для провайдера никаких проблем в выдаче двух /64 нет.
www.bircd.org/annoyances/prefix64/ вот тут пишут:
«a home does not need more than one subnet»
You will need atleast 2 if you want both a wired lan, and wireless, and want control over how you set it up with routing, firewalling, public/private subnets, etc, or for experimentation/research.
Т.е. ваш роутер не умеет бриджить ipv6, но при этом умеет поднимать туннель до ipv6 брокера?
Вообще мы здесь обсуждаем не то как у вас было сделано, а как проще и лучше сделать хомячку. Мое имхо — бриждить ipv6, когда роутеры научатся. А на сегодняшний день нормального решения я не вижу.
Вообще мы здесь обсуждаем не то как у вас было сделано, а как проще и лучше сделать хомячку. Мое имхо — бриждить ipv6, когда роутеры научатся. А на сегодняшний день нормального решения я не вижу.
Мой роутер вообще не умеет IPv6, но я ни в одной прошивке не видел возможность бриджа IPv6. Вполне возможно, что она где-то есть, но мне не попадалось.
Есть еще вариант: бриджить все, как предлагал кто-то в похожей теме, т.е. делать NAT уже на стороне провайдера и выдавать, например, /29 IPv4 клиенту в серой подсети, но я считаю, это хуже.
Разве хомячку, как вы говорите, не проще выдать два /64? Раздачу с двух /64 уже все роутеры поддерживают.
Есть еще вариант: бриджить все, как предлагал кто-то в похожей теме, т.е. делать NAT уже на стороне провайдера и выдавать, например, /29 IPv4 клиенту в серой подсети, но я считаю, это хуже.
Разве хомячку, как вы говорите, не проще выдать два /64? Раздачу с двух /64 уже все роутеры поддерживают.
Я про soho роутеры и поддержку ими ipv6 совсем не в курсе. Т.е. на сегодняшний день есть модели, которые могут получить две /64 от провайдера? По какому протоколу выдается вторая /64? DHCPv6?
И затем роутер использует одну /64 на стыке роутер — провайдер, а вторую роутер — устройства клиента?
Маршрутизаторы провайдера автоматически прописывают у себя статический(?) маршрут на клиентскую сеть через айпишник роутера?
Не слишком ли муторная схема?
И затем роутер использует одну /64 на стыке роутер — провайдер, а вторую роутер — устройства клиента?
Маршрутизаторы провайдера автоматически прописывают у себя статический(?) маршрут на клиентскую сеть через айпишник роутера?
Не слишком ли муторная схема?
К сожалению, насчет автоматической настроки в таком случае не уверен, в случае двух /64 нужно их прописывать вручную. Точно не помню где, но, вроде, на прошивке tomato так и указано — /64 для роутера и /64 для раздачи в локалку. Вероятно, в случае автоконфигурирования, провайдер выдает одну /64 через DHCPv6, а вторую нужно вручную вводить.
Насколько я знаю, только один провайдер выдает /56 клиентам — ТИС-Диалог. У остальных либо одна /64, либо одна /64 для локалки + point-to-point для роутера.
Насколько я знаю, только один провайдер выдает /56 клиентам — ТИС-Диалог. У остальных либо одна /64, либо одна /64 для локалки + point-to-point для роутера.
т.к. я не видел роутеров-коробок, которые могут бриджем пустить IPv6, а IPv4 натить
Яблочные AirPort Extreme — умеют, правда с некоторыми нюансами.
что такое «бридж для ipv6»?
IPv6 Pass-Through. Когда у роутера нет IPv6 адреса, а весь IPv6-трафик идет от клиента к провайдеру, таким образом клиенты получают IPv6-адреса от провайдера «минуя» роутер, и можно обойтись одной /64.
Туннелирование что ли?
Нет, нет инкапсуляции. Это как обычный бридж двух интерфейсов, но только для IPv6. Т.е. весь IPv6 трафик идет напрямую к провайдеру, роутер его никак не изменяет, но, в то же время, остается возможность ната IPv4, в отличие от обычного бриджа.
Это не есть ли Proxy-NDP?
Второй вопрос: что мешает использовать unnumbered-интерфейсы (на стороне клиента это будет интерфейс, смотрящий в сторону провайдера)?
Второй вопрос: что мешает использовать unnumbered-интерфейсы (на стороне клиента это будет интерфейс, смотрящий в сторону провайдера)?
Proxy-NDP ведь проксирует только NDP? Здесь речь идет про L2 форвардинг всех пакетов с ethertype 0x86DD без какого либо изменения содержимого.
Наверное то, что SOHO роутеры этого не умеют.
что мешает использовать unnumbered-интерфейсы
Наверное то, что SOHO роутеры этого не умеют.
ProxyNDP для IPv6 — это то же самое, что и ProxyARP для IPv4. Полный аналог. Позволяет иметь одну и ту же сеть с двух сторон. Нюансы в настройке есть, но в данном случае несущественные (proxy ndp настраивается тоньше и поэтому в общем-то лучше).
А насчёт «не умеют» — ну бред же, почему-то ipv4 на древнем P660RT можно настроить без nat, при этом на wan и enet будут вполне могут быть одинаковые адреса, различающиеся только маской. Практически это и есть unnumbered. И работает всё.
А насчёт «не умеют» — ну бред же, почему-то ipv4 на древнем P660RT можно настроить без nat, при этом на wan и enet будут вполне могут быть одинаковые адреса, различающиеся только маской. Практически это и есть unnumbered. И работает всё.
Скорее форвардинг. Всё пролетает на L2.
Автор ошибочно пытается детать аллокацию в стиле IPv4 *считая* узлы. Так делать не стоит, причин тому множество и они перечислены скажем тут www.arin.net/participate/meetings/reports/ARIN_XV/PDF/mon/mei-wang.pdf
Искать по теме «Allocation by Bisection».
Искать по теме «Allocation by Bisection».
я вот одного не пойму — как в разрезе IPv6 можно говорить НЕ о PI-адресации?! Нахрена мне привязываться к прову адресами?! Это какое-то адресное-рабство.
Я понимаю что с ipv4 PI-сети были ценным ресурсом. Но сейчас-то?!..
Я понимаю что с ipv4 PI-сети были ценным ресурсом. Но сейчас-то?!..
Ну многим конторам PI не нужен, ИМХО. Надо будет съехать к другому провайдеру, возьмут PA у него и переедут к нему. Зато не надо заниматься настройкой всяких BGP роутеров и т.п.
Надо будет съехать к другому провайдеру, возьмут PA у него и переедут к нему.
Гемор даже при задействовании NAT (если есть требование непрерывности бизнеса). А если всем внутренним хостам назначать глобально маршрутизируемый адрес, как это предполагается в случае IPv6? Это будет эталонное анальное рабство…
Зато не надо заниматься настройкой всяких BGP роутеров
О да, поднять EBGP соседство и выдать наружу один-два префикса, приняв 0/0 — адски сложно :)
А когда провайдер ляжет? При PA внешние ресурсы компании отвалятся от глобального интернета (да, DNS балансировка существует, вот только отработает она очень нескоро, если вообще отработает). При PI тот же префикс через пару минут снова станет доступен.
В общем, вопрос требований со стороны бизнеса.
Большая часть компаний на земле не являются айти компаниями. У них есть офис в котором сидят люди с 9 до 17 и роутер/фаервол который им поставил провайдер. Какая непрерывность бизнеса? Какой eBGP?
А причем тут айти компании?
Бывает такое, что провайдерский канал ложится всерьез и надолго. Это — большая проблема для любого бизнеса. Надо как-то резервировать.
Бывает такое, что провайдерский канал ложится всерьез и надолго. Это — большая проблема для любого бизнеса. Надо как-то резервировать.
Так это не проблема есть же резервный канал от другого провайдера. Если основной канал упал переключаемся на резервный канал, а то что айпи адреса могут при этом поменяться — не так и страшно для большинства не айти компаний.
s/не айти/очень маленьких/g
Вот тогда это будет правдой.
Абсолютно неважно, относится ли основная сфера деятельности компании к IT. Просто начиная с определенного уровня, стабильная круглосуточная работа сети становится критически важной. Ну а мелкая фирма на 10 человек запросто может назначить всем устройствам глобально маршрутизируемые PA адреса, и это не поставит ее раком через год-два, при пересмотре тарифов.
Вот тогда это будет правдой.
Абсолютно неважно, относится ли основная сфера деятельности компании к IT. Просто начиная с определенного уровня, стабильная круглосуточная работа сети становится критически важной. Ну а мелкая фирма на 10 человек запросто может назначить всем устройствам глобально маршрутизируемые PA адреса, и это не поставит ее раком через год-два, при пересмотре тарифов.
Sign up to leave a comment.
Распределение адресного пространства IPv6 для ISP