[ichthyandr]

Всем привет.

В исходнике L2 сегменты, агрегированы в L3 ядро, раздача через pptp. Кроме того куча вланов для юрлиц. Всё думаю в какую сторону мигрировать - pppoe или ipoe. C pppoe вроде бы всё понятно, с ipoe в моем случае возможна только схема влан на абонента с терминацией q-in-q на брасе. Хотелось бы услышать мнения о недостатках ipoe с точки зрения эксплуатации.

Спасибо.

[ingress]

Ставлю 20 песо что будет 20 страниц флуда про rocket scienceнастройку коммутаторов доступа, в итоге придёт какой нить JoeDoe и будет сраца до упора, какие все козлы, один я француз в белом пальто.

[flamaster]

сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"?

[Night_Snake]

ТС не понял сути IPoE?

[dmg]

сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"?

А если количество клиентов > 4095 ?

[Asco]

сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"?

А если количество клиентов > 4095 ?

На cisco - разные порты на ES/ES+ картах, 16к инстансов на карту

На juniper - разные порты + flexible-vlan-tagging

[nnm]

Хотелось бы услышать мнения о недостатках ipoe с точки зрения эксплуатации.

Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :)

[ichthyandr]

Хотелось бы услышать мнения о недостатках ipoe с точки зрения эксплуатации.

Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :)

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

 

сорри не догнал, а нафига в схеме IPoE "влан на абонента с терминацией q-in-q на брасе"?

А если количество клиентов > 4095 ?

На cisco - разные порты на ES/ES+ картах, 16к инстансов на карту

На juniper - разные порты + flexible-vlan-tagging

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

Изменено 4 октября, 2012 пользователем ichthyandr

[Night_Snake]

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

 

Ну это как раз просто - VRRP (HSRP) ваш спасет

 

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

А 4к клиентов на сегмент - не многовато? Может, спустить терминацию чуть ниже?

[ichthyandr]

А 4к клиентов на сегмент - не многовато? Может, спустить терминацию чуть ниже?

в сегментах макс ~2тыщ абонентов + диапазон влан id до 1000 как уже писал частично используется, в ядре горка с3750 в vtp домене, ломать не хочется, поэтому думаю абонентские вланы, начиная с id 1001 нужно запустить в супервлан для каждого сегмента свой с id < 1000

 

Ну это как раз просто - VRRP (HSRP) ваш спасет

насколько понимаю, если брас L3-connected? я то думаю про L2

[Wingman]

Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :)

А также бывают проблемы с сохо-роутерами с кривыми прошивками, криво работающими с дцхп, виндузВисты, ещё хуже с ним работающие...

 

У нас сейчас ипое сделано на linux_isg, где инициализация сессии происходит по первому ip-пакету без необходимости в dhcp, что снимает все эти проблемы. В своё время от редбека отказались как раз из-за отсутствия в нём этого функционала, но они обещали запилить его в течение года.

[ichthyandr]

Основной недостаток - отсутствие явно выраженной сессии между BRAS-ом и абоном. В классическом варианте (подключение инициируется по DHCP) если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает. Есть разного рода костыли для решения этой проблемы, но это именно костыли, т.е. решая одну проблему они привносят другие :)

А также бывают проблемы с сохо-роутерами с кривыми прошивками, криво работающими с дцхп, виндузВисты, ещё хуже с ним работающие...

 

У нас сейчас ипое сделано на linux_isg, где инициализация сессии происходит по первому ip-пакету без необходимости в dhcp, что снимает все эти проблемы. В своё время от редбека отказались как раз из-за отсутствия в нём этого функционала, но они обещали запилить его в течение года.

т.е. ip адрес абоненту указываете в договоре статический?

[dazgluk]

 

насколько понимаю, если брас L3-connected? я то думаю про L2

Если BRAS поддерживает VRRP то почему бы и нет?

Семейство протоколов FHRP как раз таки и разрабатывалось для резервирования first hop. На L3 connected и OSPF отлично отработает.

Другое дело что сессии тряхнет, это да. Но тут и PPPoE не поможет, всеравно тряхнет.

Изменено 4 октября, 2012 пользователем dazgluk

[nnm]

Если BRAS поддерживает VRRP то почему бы и нет?

Там 'влан на абонента'. А значит IP-unnumbered. А значит просто сохранить достижимость gateway, которую сказали абоненту, недостаточно для того, чтобы сервис сохранить.

Другое дело что сессии тряхнет, это да. Но тут и PPPoE не поможет, всеравно тряхнет.

Если сессии порождаются по DHCP, то не тряхнет. И это очень прискорбно т.к. оставшийся в живых BRAS про абонента ничего не знает, а абонент думает, что адрес он получил и ближайшие X часов о DHCP можно не беспокоиться.

Если сессии порождаются по IP, то тут теоретически шансы есть. Но логика авторизации очень сложная и 'из коробки' ее вроде и нету ни у кого. :(

[Wingman]

т.е. ip адрес абоненту указываете в договоре статический?

У нас - нет, у нас он выдаётся самописным dhcp из бд на основе option82

Авторизация при этом от dhcp никак не зависит

[Night_Snake]

Если сессии порождаются по DHCP, то не тряхнет. И это очень прискорбно т.к. оставшийся в живых BRAS про абонента ничего не знает

А чего он не знает? Роуты на клиентов можно взять хоть с dhcp-сервера, хоть с биллинга, arp-таблицу набить недолго, l3-связность есть

[Wingman]

Если сессии порождаются по 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 до браса, эх

[nnm]

Если сессии порождаются по DHCP, то не тряхнет. И это очень прискорбно т.к. оставшийся в живых BRAS про абонента ничего не знает

А чего он не знает?

Обычно IPoE BRAS про клиента знает его IP-адрес и к какому VLAN-у он подключен. Это знание он получает 'подслушав' DHCP-обмен. После этого он может поставить маршрут на этого клиента в VLAN. Еще он знает на какой скорости нужно доступ предоставлять потому что RADIUS-атрибут(ы) при авторизации прилетели. И поэтому он какой-то шейпер в сторону клиента воткнул. Еще он знает Acct-Session-ID, который надо в эккаунтинговых пакетах в сторону RADIUS слать. Но это только если трафик посчитать хочется. Тот BRAS, который резервирует нас по VRRP, в общем случае ничего этого не знает.

Роуты на клиентов можно взять хоть с dhcp-сервера, хоть с биллинга, arp-таблицу набить недолго, l3-связность есть

Кто будет брать например роуты, по какому протоколу он будет это делать и что будет выступать триггером для старта процесса забирания роутов?

Мне кажется, что 'из коробки' так не умеет никто. Это только скрипты которые что-то там непрерывно мониторят и если что - курочат конфиг. Т.е. те самые костыли о которых я писал.

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

[Night_Snake]

Что хочется: поставить "что-то" вместо 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/биллинга.

[nnm]

Все проще - разнести терминатор и собственно BRAS.

Терминатор знает только роуты до клиентов. Он же является DHCP-relay. И тут в случае резервирования нужно либо держать на обоих копии роутов, либо приделывать костыли. Все что выше знает только L3 роуты и информацию из RADIUS/биллинга.

 

Насколько я понимаю, в случае VLAN на абонента, это означает, что терминатор должен уметь ip-unnumbered. В альтернативной модели с L2 доступом от агрегирующего коммутатора нужно только q-in-q. Мне кажется, что ip-unnumberd пореже встречается и стоит подороже.

Далее, если хотим резервироваться, то нужно изобретать свой индивидуальный комплект костылей для BRAS и для терминатора (в терминатор маршруты, в BRAS политики).

L3-connected сессии умеет далеко не каждый BRAS. Например рекомендованный Вами Juniper кажется умеет, но за неадекватные деньги. RedBack кажется не умеет.

Какое-же это упрощение?

Единственная плюшка такого решения - локальный трафик мимо BRAS без учета и ограничений. Но нет единого мнения относительно того, полезна-ли эта плюшка для здоровья :)

[ingress]

L3-connected сессии умеет далеко не каждый BRAS. Например рекомендованный Вами Juniper кажется умеет, но за неадекватные деньги. RedBack кажется не умеет.

 

наоборот.

[Wingman]

Что хочется: поставить "что-то" вместо 3750g для аналогичных функций, только терминить должно будет vlan per user (на более чем 4096 юзеров), а не vlan per house

Juniper MX, если позволяет бюджет. Если не позволяет - DGS-3610-26G

- Juniper MX сопоставим по цене с нормальным брасом, нет смысла

- Длинков на L3 в своё время наелись, спасибо, не надо =)

 

Все проще - разнести терминатор и собственно BRAS.

Вот не выходит =)

[Night_Snake]

Насколько я понимаю, в случае 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, двумя шейперами и одним бордером. И все это довольно сносно резервировалось

[Wingman]

Насколько я понимаю, в случае 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?

[Night_Snake]

Дык! Надо, чтобы "что-то" обслуживало на ip unnumbered столько же хомяков, сколько 3750 обслуживает без ip unnumbered ;)

Кроме ограничения по числу вланов, в чем принципиальная разница в использовании ip unnumbered или без него со стороны затраченных ресурсов?

 

И сколько юзеров на L3 обслуживает 3627, если не секрет? А тв по pim-sm крутит? А ospf, bgp?

Чуть позже точную инфу скажу. статика, iptv есть. Клиентов несколько сотен точно.