ichthyandr Опубликовано 4 октября, 2012 · Жалоба Всем привет. В исходнике L2 сегменты, агрегированы в L3 ядро, раздача через pptp. Кроме того куча вланов для юрлиц. Всё думаю в какую сторону мигрировать - pppoe или ipoe. C pppoe вроде бы всё понятно, с ipoe в моем случае возможна только схема влан на абонента с терминацией q-in-q на брасе. Хотелось бы услышать мнения о недостатках ipoe с точки зрения эксплуатации. Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 4 октября, 2012 · Жалоба Ставлю 20 песо что будет 20 страниц флуда про rocket scienceнастройку коммутаторов доступа, в итоге придёт какой нить JoeDoe и будет сраца до упора, какие все козлы, один я француз в белом пальто. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flamaster Опубликовано 4 октября, 2012 · Жалоба сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 4 октября, 2012 · Жалоба ТС не понял сути IPoE? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmg Опубликовано 4 октября, 2012 · Жалоба сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"? А если количество клиентов > 4095 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Asco Опубликовано 4 октября, 2012 · Жалоба сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"? А если количество клиентов > 4095 ? На cisco - разные порты на ES/ES+ картах, 16к инстансов на карту На juniper - разные порты + flexible-vlan-tagging Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 4 октября, 2012 · Жалоба Хотелось бы услышать мнения о недостатках ipoe с точки зрения эксплуатации. Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 4 октября, 2012 (изменено) · Жалоба Хотелось бы услышать мнения о недостатках ipoe с точки зрения эксплуатации. Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :) понятно, спасибо, еще как один недостаток насколько понимаю - вопрос резервирования с точки зрения браса сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"? А если количество клиентов > 4095 ? На cisco - разные порты на ES/ES+ картах, 16к инстансов на карту На juniper - разные порты + flexible-vlan-tagging дело не в цисках, проблема в том что присутствует много вланов в сегментах и они проброшены между ними, выход вижу один - абонентские вланы каждого сегмента заключать с супервлан Изменено 4 октября, 2012 пользователем ichthyandr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 4 октября, 2012 · Жалоба понятно, спасибо, еще как один недостаток насколько понимаю - вопрос резервирования с точки зрения браса Ну это как раз просто - VRRP (HSRP) ваш спасет дело не в цисках, проблема в том что присутствует много вланов в сегментах и они проброшены между ними, выход вижу один - абонентские вланы каждого сегмента заключать с супервлан А 4к клиентов на сегмент - не многовато? Может, спустить терминацию чуть ниже? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 4 октября, 2012 · Жалоба А 4к клиентов на сегмент - не многовато? Может, спустить терминацию чуть ниже? в сегментах макс ~2тыщ абонентов + диапазон влан id до 1000 как уже писал частично используется, в ядре горка с3750 в vtp домене, ломать не хочется, поэтому думаю абонентские вланы, начиная с id 1001 нужно запустить в супервлан для каждого сегмента свой с id < 1000 Ну это как раз просто - VRRP (HSRP) ваш спасет насколько понимаю, если брас L3-connected? я то думаю про L2 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 4 октября, 2012 · Жалоба Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :) А также бывают проблемы с сохо-роутерами с кривыми прошивками, криво работающими с дцхп, виндузВисты, ещё хуже с ним работающие... У нас сейчас ипое сделано на linux_isg, где инициализация сессии происходит по первому ip-пакету без необходимости в dhcp, что снимает все эти проблемы. В своё время от редбека отказались как раз из-за отсутствия в нём этого функционала, но они обещали запилить его в течение года. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 4 октября, 2012 · Жалоба Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :) А также бывают проблемы с сохо-роутерами с кривыми прошивками, криво работающими с дцхп, виндузВисты, ещё хуже с ним работающие... У нас сейчас ипое сделано на linux_isg, где инициализация сессии происходит по первому ip-пакету без необходимости в dhcp, что снимает все эти проблемы. В своё время от редбека отказались как раз из-за отсутствия в нём этого функционала, но они обещали запилить его в течение года. т.е. ip адрес абоненту указываете в договоре статический? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 4 октября, 2012 (изменено) · Жалоба насколько понимаю, если брас L3-connected? я то думаю про L2 Если BRAS поддерживает VRRP то почему бы и нет? Семейство протоколов FHRP как раз таки и разрабатывалось для резервирования first hop. На L3 connected и OSPF отлично отработает. Другое дело что сессии тряхнет, это да. Но тут и PPPoE не поможет, всеравно тряхнет. Изменено 4 октября, 2012 пользователем dazgluk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 4 октября, 2012 · Жалоба Если BRAS поддерживает VRRP то почему бы и нет? Там 'влан на абонента'. А значит IP-unnumbered. А значит просто сохранить достижимость gateway, которую сказали абоненту, недостаточно для того, чтобы сервис сохранить. Другое дело что сессии тряхнет, это да. Но тут и PPPoE не поможет, всеравно тряхнет. Если сессии порождаются по DHCP, то не тряхнет. И это очень прискорбно т.к. оставшийся в живых BRAS про абонента ничего не знает, а абонент думает, что адрес он получил и ближайшие X часов о DHCP можно не беспокоиться. Если сессии порождаются по IP, то тут теоретически шансы есть. Но логика авторизации очень сложная и 'из коробки' ее вроде и нету ни у кого. :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 4 октября, 2012 · Жалоба т.е. ip адрес абоненту указываете в договоре статический? У нас - нет, у нас он выдаётся самописным dhcp из бд на основе option82 Авторизация при этом от dhcp никак не зависит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 4 октября, 2012 · Жалоба Если сессии порождаются по DHCP, то не тряхнет. И это очень прискорбно т.к. оставшийся в живых BRAS про абонента ничего не знает А чего он не знает? Роуты на клиентов можно взять хоть с dhcp-сервера, хоть с биллинга, arp-таблицу набить недолго, l3-связность есть Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 4 октября, 2012 · Жалоба Если сессии порождаются по DHCP, то не тряхнет. И это очень прискорбно т.к. оставшийся в живых BRAS про абонента ничего не знает А чего он не знает? Роуты на клиентов можно взять хоть с dhcp-сервера, хоть с биллинга, arp-таблицу набить недолго, l3-связность есть А вот мб посоветует кто решение в железе? =) Дано: влан на дом, сходятся по 100-300 домов на 3750g, далее L3-связность до браса; брас знает только саггрегированный маршрут на клиентов; т.о. с пом. того же bgp резервирование брасов элементарное... Что хочется: поставить "что-то" вместо 3750g для аналогичных функций, только терминить должно будет vlan per user (на более чем 4096 юзеров), а не vlan per house. Хотелки: должно быть 1-2 юнита, а не монструозные шеститонники; не слишком сильно дороже 3627, уметь qinq, в перспективе уметь раздавать ipv6, желат-но хоть один 10g интерфейс Что-то сколько ни думаю, всё сводится только к протягиванию qinq до браса, эх Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 4 октября, 2012 · Жалоба Если сессии порождаются по DHCP, то не тряхнет. И это очень прискорбно т.к. оставшийся в живых BRAS про абонента ничего не знает А чего он не знает? Обычно IPoE BRAS про клиента знает его IP-адрес и к какому VLAN-у он подключен. Это знание он получает 'подслушав' DHCP-обмен. После этого он может поставить маршрут на этого клиента в VLAN. Еще он знает на какой скорости нужно доступ предоставлять потому что RADIUS-атрибут(ы) при авторизации прилетели. И поэтому он какой-то шейпер в сторону клиента воткнул. Еще он знает Acct-Session-ID, который надо в эккаунтинговых пакетах в сторону RADIUS слать. Но это только если трафик посчитать хочется. Тот BRAS, который резервирует нас по VRRP, в общем случае ничего этого не знает. Роуты на клиентов можно взять хоть с dhcp-сервера, хоть с биллинга, arp-таблицу набить недолго, l3-связность есть Кто будет брать например роуты, по какому протоколу он будет это делать и что будет выступать триггером для старта процесса забирания роутов? Мне кажется, что 'из коробки' так не умеет никто. Это только скрипты которые что-то там непрерывно мониторят и если что - курочат конфиг. Т.е. те самые костыли о которых я писал. Есть альтернативный путь - когда BRASы работающие в паре синхронизируют состояние (все то, что я написал в первом абзаце и кое-что еще), но это не все умеют и цена вроде не демократичная выходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 5 октября, 2012 · Жалоба Что хочется: поставить "что-то" вместо 3750g для аналогичных функций, только терминить должно будет vlan per user (на более чем 4096 юзеров), а не vlan per house Juniper MX, если позволяет бюджет. Если не позволяет - DGS-3610-26G Обычно IPoE BRAS про клиента знает его IP-адрес и к какому VLAN-у он подключен. Это знание он получает 'подслушав' DHCP-обмен. После этого он может поставить маршрут на этого клиента в VLAN. Еще он знает на какой скорости нужно доступ предоставлять потому что RADIUS-атрибут(ы) при авторизации прилетели. И поэтому он какой-то шейпер в сторону клиента воткнул. Еще он знает Acct-Session-ID, который надо в эккаунтинговых пакетах в сторону RADIUS слать. Но это только если трафик посчитать хочется. Тот BRAS, который резервирует нас по VRRP, в общем случае ничего этого не знает. Все проще - разнести терминатор и собственно BRAS. Терминатор знает только роуты до клиентов. Он же является DHCP-relay. И тут в случае резервирования нужно либо держать на обоих копии роутов, либо приделывать костыли. Все что выше знает только L3 роуты и информацию из RADIUS/биллинга. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 5 октября, 2012 · Жалоба Все проще - разнести терминатор и собственно BRAS. Терминатор знает только роуты до клиентов. Он же является DHCP-relay. И тут в случае резервирования нужно либо держать на обоих копии роутов, либо приделывать костыли. Все что выше знает только L3 роуты и информацию из RADIUS/биллинга. Насколько я понимаю, в случае VLAN на абонента, это означает, что терминатор должен уметь ip-unnumbered. В альтернативной модели с L2 доступом от агрегирующего коммутатора нужно только q-in-q. Мне кажется, что ip-unnumberd пореже встречается и стоит подороже. Далее, если хотим резервироваться, то нужно изобретать свой индивидуальный комплект костылей для BRAS и для терминатора (в терминатор маршруты, в BRAS политики). L3-connected сессии умеет далеко не каждый BRAS. Например рекомендованный Вами Juniper кажется умеет, но за неадекватные деньги. RedBack кажется не умеет. Какое-же это упрощение? Единственная плюшка такого решения - локальный трафик мимо BRAS без учета и ограничений. Но нет единого мнения относительно того, полезна-ли эта плюшка для здоровья :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 5 октября, 2012 · Жалоба L3-connected сессии умеет далеко не каждый BRAS. Например рекомендованный Вами Juniper кажется умеет, но за неадекватные деньги. RedBack кажется не умеет. наоборот. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 5 октября, 2012 · Жалоба Что хочется: поставить "что-то" вместо 3750g для аналогичных функций, только терминить должно будет vlan per user (на более чем 4096 юзеров), а не vlan per house Juniper MX, если позволяет бюджет. Если не позволяет - DGS-3610-26G - Juniper MX сопоставим по цене с нормальным брасом, нет смысла - Длинков на L3 в своё время наелись, спасибо, не надо =) Все проще - разнести терминатор и собственно BRAS. Вот не выходит =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 5 октября, 2012 · Жалоба Насколько я понимаю, в случае VLAN на абонента, это означает, что терминатор должен уметь ip-unnumbered. В альтернативной модели с L2 доступом от агрегирующего коммутатора нужно только q-in-q. Мне кажется, что ip-unnumberd пореже встречается и стоит подороже. Cisco 3550/3650/3750, ME3400. D-Link 36xx. Что вам еще надо?) Далее, если хотим резервироваться, то нужно изобретать свой индивидуальный комплект костылей для BRAS и для терминатора (в терминатор маршруты, в BRAS политики). Определитесь с тем, что вы хотите резервировать - BRAS или терминатор? Если терминатор, то да, сложно, потому что нужно будет выдумывать что-то с маршрутами (это при условии, что они статикой не прописываются при прописывании клиента). Если BRAS, то не вижу ничего сложного - BRAS знает только айпишник клиента и его атрибуты, а через какой терминатор к нему этот клиент придет - то дело десятое. BRAS в таком случае может подтягивать нужные атрибуты хоть в real-time. Единственная плюшка такого решения - локальный трафик мимо BRAS без учета и ограничений. Но нет единого мнения относительно того, полезна-ли эта плюшка для здоровья :) Если уж на то пошло, а BRAS у вас что делает? NAT, шейпер? Вот не выходит =) Знаю работающую схему с терминаторами в виде DGS-3610-26G, двумя шейперами и одним бордером. И все это довольно сносно резервировалось Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 5 октября, 2012 · Жалоба Насколько я понимаю, в случае VLAN на абонента, это означает, что терминатор должен уметь ip-unnumbered. В альтернативной модели с L2 доступом от агрегирующего коммутатора нужно только q-in-q. Мне кажется, что ip-unnumberd пореже встречается и стоит подороже. Cisco 3550/3650/3750, ME3400. D-Link 36xx. Что вам еще надо?) Дык! Надо, чтобы "что-то" обслуживало на ip unnumbered столько же хомяков, сколько 3750 обслуживает без ip unnumbered ;) Знаю работающую схему с терминаторами в виде DGS-3610-26G, двумя шейперами и одним бордером. И все это довольно сносно резервировалось И сколько юзеров на L3 обслуживает 3627, если не секрет? А тв по pim-sm крутит? А ospf, bgp? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 5 октября, 2012 · Жалоба Дык! Надо, чтобы "что-то" обслуживало на ip unnumbered столько же хомяков, сколько 3750 обслуживает без ip unnumbered ;) Кроме ограничения по числу вланов, в чем принципиальная разница в использовании ip unnumbered или без него со стороны затраченных ресурсов? И сколько юзеров на L3 обслуживает 3627, если не секрет? А тв по pim-sm крутит? А ospf, bgp? Чуть позже точную инфу скажу. статика, iptv есть. Клиентов несколько сотен точно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...