[DelSt]

' timestamp='1338974706' post='722287']DTAG - transit free оператор, значит еще не со всеми v6 собрали..

Верно. Притом много пиров не установлено, из крупняка например

3549 1239 701 174 13030 6453

Особенно удивило отсутствие пиров с первым тремя

 

 

p.s.

3549 9070

3356 8962

3320 8027

6762 8999

1273 8965

Изменено 6 июня, 2012 пользователем DelSt

[Alex/AT]

Я не настаиваю на разжевывании :), хотя и было бы интересно понять, что именно вас не устраивает в том же DHCPv6. И всё-таки, особенности протогкола, или недостатки? Если первое - зачем устранять?

Сама по себе необходимость юзать DHCPv6 и RADVD поверх PPP - вызывает недоумение. Зачем городить кофигураторы поверх протокола с поддержкой конфигурации?

Изменено 6 июня, 2012 пользователем Alex/AT

[s.lobanov]

Я не настаиваю на разжевывании :), хотя и было бы интересно понять, что именно вас не устраивает в том же DHCPv6. И всё-таки, особенности протогкола, или недостатки? Если первое - зачем устранять?

Сама по себе необходимость юзать DHCPv6 и RADVD поверх PPP - вызывает недоумение. Зачем городить кофигураторы поверх протокола с поддержкой конфигурации?

 

Скажу более, что само по себе использование ethernet в ISP вызывает недоумение. Зачем городить вланы поверх вланов или несколько раз инкапсулировать PDU друг в друга?

 

Но приходится жить с чем есть, вендоры гребут бабло за имплементацию очередных костылей, операторы считают оборудование по стоимости порта, ну а абонентам пофиг на внутреннюю кухню первых и вторых.

[none7]

Я не настаиваю на разжевывании :), хотя и было бы интересно понять, что именно вас не устраивает в том же DHCPv6. И всё-таки, особенности протогкола, или недостатки? Если первое - зачем устранять?

Сама по себе необходимость юзать DHCPv6 и RADVD поверх PPP - вызывает недоумение. Зачем городить кофигураторы поверх протокола с поддержкой конфигурации?

Потому, что это уже принятый стандарт. Конфигурация PPP настраивает только link-local адреса, хотя разработчики стандарта могли скопировать в него весь функционал ICMPv6 RS/RA и DHCPv6, но их никто не убедил в необходимости этого. К тому же эти стандарты изначально были рассчитаны на работу с таким L2, поэтому это не костыль, так и было задумано изначально. Даже если Вы сможете протолкнуть изменения в RFC, то будете ещё 15 лет ждать, пока все реализуют это обновление.

[Дятел]

а зачем вообще РРР?

[Alex/AT]

Масштабируемость и относительная независимость от оборудования. Реализация отказоустойчивости в ядре без необходимости завязываться на вендора. Отсутствие граблей с привязкой политик, контролем доступа и учётом. Это как минимум.

Когда сеть становится большой и разнородной - PPP позволяет скрыть эту разнородность от системы управления абонентами. Сегодня D-Link и Cisco, завтра Huawei и Juniper, Ericcson, SNR, Eltex, etc.

Вообще сама возможность на доступе использовать что угодно, не завязываясь на самые разные варианты биндинга аккаунта абонента к порту в IPoE - уже прелесть. Легкость использования VLAN на абонента - туда же.

Изменено 6 июня, 2012 пользователем Alex/AT

[Дятел]

Использование древнего протокола, придуманного для того, чтоб пакеты бегали по медленным асинхронным каналам - уже прелесть )

[Ivan_83]

Ну не хочет человек учится новому, а кактус (PPPoE) ему уже в радость.

То что остальные плюются от этой гадости - это ничего, жрут же и платят.

И не в домёк, что PPPoE это те же самые пакетики эзернета, такие же как и в IPv*.

[Alex/AT]

Считаю наезд необоснованным. На самом деле в данный момент как раз таки разрабатываю вменяемое по стоимости решение, которое даст в рамках IPoE практически всю гибкость PPPoE - привязку сервисов, посервисный обжим и учёт, CoA, etc. без необходимости дёргать железки на доступе. Очень вероятно, что в рамках этого же решения будет разрулена раздача IPv6 на большую сеть, во всяком случае, задел сделан.

 

Просто когда под контролем достаточно разнородная сеть, где есть всё, в принципе - от стандартного FTTB по звезде и VLAN на дом, FTTB по кольцам + VLAN на абонента, WiFi и прочих радостей, до FTTH на GPON - управлять всем зоопарком "скриптами по SNMP" уже именно что "не в радость". А внедрять бездумно на отлаженной сети IPoE в контексте разнородности оборудования и скорости роста == ободрать весь зад об пресловутый кактус в процессе.

Изменено 6 июня, 2012 пользователем Alex/AT

[Картуччо]

С точки зрения абонента PPPoE,PPTP,L2TP это очень неудобно и непрактично, а если откровенно, то просто говно. Провайдер, у которого всё заработает простым подключением патчкорда, будет иметь очевидное психологическое преимущество.

[Alex/AT]

С точки зрения абонента PPPoE,PPTP,L2TP это очень неудобно и непрактично, а если откровенно, то просто говно. Провайдер, у которого всё заработает простым подключением патчкорда, будет иметь очевидное психологическое преимущество.

С точки зрения абонента, очень неудобно и непрактично, когда при смене оборудования всё перестаёт работать, и надо звонить в саппорт. У большинства при построении сети на IPoE это бич. А еще неудобно и непрактично, когда "локальщики" (будем честными, IPoE часто строится для того, чтобы попроще дать локалку) забивают междомовые линки в полку. И еще более неудобно и непрактично, когда по пути затыкается под нагрузкой или числом записей в ARP-таблице "квартальный" L3'шный агрегатор. Есть в практике домашнего доступа одна домовая сеть-переросток, которая всем этим болеет очень сильно.

 

Но не суть - я с Вами согласен, PPPoE несёт определённые неудобства. И даже не только сама необходимость авторизации, есть ещё нюансы с MTU на некоторых железках. Особенно жжОт продукция Apple.

 

Просто у доступа по IPoE свои грабли тоже есть, хоть и в меньшей мере, и даже коллеги по работе регулярно с ними сталкиваются у своих домашних операторов.

 

В целом факт, что у доступа по IPoE есть абсолютно неоспоримые преимущества. Поэтому и делается сейчас решение, которое бы позволило без лишних костылей взять лучшее сразу с двух полок. А с учетом IPv6 - может и с трёх.

Изменено 6 июня, 2012 пользователем Alex/AT

[karpa13a]

непрактично, когда при смене оборудования всё перестаёт работать, и надо звонить в саппорт.

у белых людей, изначальный лимит на 4-5 девайсовмаков)

[martin74]

Народ, а где почитать, как мне, провайдеру, это IPv6 правильно запустить? ;)

Блок адресов у меня есть.. В IPv4 мне как то понятнее было, как бгп поднять, как днс настроить... А тут как то плаваю и до конца не понимаю ;(

[zi_rus]

С точки зрения абонента, очень неудобно и непрактично

Конечно, каждому абоненту всегда проще настроить туннелирование, чем продиктовать техподдержке мак адрес с брюха нового роутера

[Картуччо]

А зачем диктовать мак адрес ?

[martin74]

причем еще надо понять, что там на самом деле написан мак адрес лан интерфейса, а провайдеру нужен ван интерфейс.....

[Sergey Gilfanov]

Ну сколько можно. У абонента должна висеть коробочка. Установленная лично провайдером. Вот в к ней-то абонент и цепляет свои патч-корды. И она же изолирует сеть абонента от сети оператора. Так что никаких переполнений ARP таблиц на квартальных L3 агрегаторов не будет. А всякое изменение на порту коммутатора, куда эта коробочка подключена, должно приводить к звонку абоненту с вопросом 'что происходит?'.

[zi_rus]

А зачем диктовать мак адрес ?

да в общем-то, как правило и этого не нужно, но иногда случаются и такие операторы, но даже в таком, самом худшем, случае, это проще чем настраивать "соединение"

[Дятел]

С точки зрения абонента PPPoE,PPTP,L2TP это очень неудобно и непрактично, а если откровенно, то просто говно. Провайдер, у которого всё заработает простым подключением патчкорда, будет иметь очевидное психологическое преимущество.

С точки зрения абонента, очень неудобно и непрактично, когда при смене оборудования всё перестаёт работать, и надо звонить в саппорт. У большинства при построении сети на IPoE это бич.

.

.

В целом факт, что у доступа по IPoE есть абсолютно неоспоримые преимущества. Поэтому и делается сейчас решение, которое бы позволило без лишних костылей взять лучшее сразу с двух полок. А с учетом IPv6 - может и с трёх.

 

А вот с учетом IPv6 у меня есть некоторые вопросы, на которые не вижу ответов....

Берём самую простую схему предоставления доступа по IPv6oE. Делаем влан на абонента, на интерфейс вешаем /64, DHCP терминящей циски выдает DNS, абонент дома ставит тупой свич, и любое количество устройств из его домашней сети спокойно выходит в мир.

Прямо идилия какая-то.

И тут, значит, сгорает коммутатор доступа. Прибегает на чердак техник, вытаскивает из свича 24 патч-корда, вставляет новый, запихивает патч-корды обратно и убегает. Но, гаденышь этакий, путает местами два порта.

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

 

Таким образом, на стороне абонента нужно иметь какой-нибудь идентификатор. PPP - это пароль доступа, IPoE - статический адрес или MAC. IPv6oE - тоже МАС? Фигово как-то....

[zi_rus]

абонента можно вполне прятать за роутер, как-то узнал, что по dhcp для ipv6 можно еще раздавать сети, если роутер их запросит, тоже себе вариант, конечно же не без своих нюансов

[-Ars-]

абонента можно вполне прятать за роутер

Т.е. опять же приходим к тому, что абоненту нужен роутер? Причём от провайдера? :)

 

У абонента должна висеть коробочка. Установленная лично провайдером

[Дятел]

что-то мне кажется - нет таких роутеров.

[Negator]

должно приводить к звонку абоненту с вопросом 'что происходит?'.

Вы уверены что абоненту нужен Ваш звонок?

 

И тут, значит, сгорает коммутатор доступа. Прибегает на чердак техник, вытаскивает из свича 24 патч-корда, вставляет новый, запихивает патч-корды обратно и убегает. Но, гаденышь этакий, путает местами два порта.

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

На самом деле -это решаемо.

1-На новом коммутаторе при замене включаем все порты. Всех юзов -на страничку ввода логина в личный кабинет. Далее смотрим кто с какого порта ввел и прописываем верные порты в биллинг.

2-Если не п.1 - то за 1 день маки абонентов вряд-ли изменятся, а значит можно посмотреть какой мак висел на каком порту вчера и что стало сегодня. И поправить это.

[Alex/AT]

В общем и целом да - быстрее всего один из абонентов начнёт жаловаться на то, что у него скорость ниже тарифной. Причём первый (а зачастую и второй) эшелоны техподдержки не всегда смогут понять, что случилось.

 

На новом коммутаторе при замене включаем все порты. Всех юзов -на страничку ввода логина в личный кабинет. Далее смотрим кто с какого порта ввел и прописываем верные порты в биллинг.

Ну ведь костыль же. Ручная работа. Второй бич прибивки абонента к порту, увы. Лишняя нагрузка на саппорт, инженеров, etc.

 

Интересна практика, правда будет оффтопично, а 802.1x кто-нибудь уже на доступе реально юзает? Как ощущения? Какие плюсы/грабли?

Изменено 7 июня, 2012 пользователем Alex/AT

[zi_rus]

RFC 3633 это не выдумки

А каким-нибудь длинком или хуавеем можно договорить о производстве соответствующих СРЕ, а потом может и на массовом рынке работа пойдет