[Wingman]

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

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

Только ограничение по числу вланов svi, в остальном идеальная железяка

 

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

Ну вот, а когда дорастут до 1-1.5к юзеров, тогда и узнают все прелести длинка...

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

[kf72]

если с BRAS что-то случается, то абон не понимает, что все, кранты, нужно еще раз инициировать DHCP транзакцию. И ничего не не работает.

...

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

у меня сетка маленькая, ядро=что ваша агрегация, dhcp прям на цисках. если циска (агрегатор L3) работает, то абон адрес получит.

не модно, зато железно. доступ дешевый.

ip unnumbered не прижился.

 

в поисках проблем приходится лазить на оборудование смотреть арп таблицы и сверять с доступом.

в основном ошибки при настройке и прописывании пачек вланов через L2 агрегацию.

видел вариант отправлять "все вланы во все порты, а доступ разберется",

но считаю идеологически неправильным.

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

[nnm]

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

Cisco 3550/3650/3750, ME3400. D-Link 36xx. Что вам еще надо?)

Берем в руку любую из перечисленных Cisco и начинаем строить терминатора на 'влан на пользователя'. Упираемся в ограничение 1000 VLAN (и 1000 абонентов). Курим. Сносим конфиг и перестраиваем на Q-in-Q с L2 пробросом до BRAS-а. Во что упремся? По-моему в число MAC (12000 в VLAN template для 3550). Закладываем по два MAC на абонента. Получаем 6K абонентов. В шесть раз больше. Пример конечно грубый т.к. портов мало. Там такие L2 цепочки нужно будет строить, что никакие нервы не выдержат :) Более реалистичная оценка - 2K. Но закономерность очевидна - поменяли схему, и ограничение снялось. По моему неплохо. :)

Определитесь с тем, что вы хотите резервировать - BRAS или терминатор?

Резервируем услугу. Т.е. пытаемся минимизировать количество сценариев отказа при которых абон потеряет сервис. В PPPoE вообще ничего не нужно делать - все само. Хотим сравнимую функциональность в IPoE L2-доступ? Отлично, нужно синхронизировать состояние между BRAS. Добавили терминаторы и превратили доступ в L3? Теперь придется еще и терминаторы синхронизировать.

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

Есть терминаторы T1 и T2 и BRASы B1 и B2. Абонент получил адрес через T1. В этот момент default у T1 смотрел на B1. Через 30 минут B1 исчез с экранов радаров. Default у T1 теперь смотрит на B2. Что в этот момент B2 знает про абонента?

BRAS в таком случае может подтягивать нужные атрибуты хоть в real-time.

Я уже кажется спрашивал: по какому протоколу, и что будет являться триггером?

Если уж на то пошло, а BRAS у вас что делает? NAT, шейпер?

У меня нет никакого BRAS, но то, что обычно делает BRAS, ближе всего можно охарактеризовать словом 'шейпер'.

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

[Skylaer]

Какие вы сложные, блин...

 

Схема IPoE через 3750-12S + (раутер/шейпер/dhcp сервер) на микре + биллинг отлично работает.

Как показала практика, поднимается на 1 комплекте до 1000 юзерей с тарифом 10 или 100 мбит анлим.

 

Резервирование делается одним линуксовым сервером, у абонента нет интернета несколько секунд.

[Wingman]

Есть терминаторы T1 и T2 и BRASы B1 и B2. Абонент получил адрес через T1. В этот момент default у T1 смотрел на B1. Через 30 минут B1 исчез с экранов радаров. Default у T1 теперь смотрит на B2. Что в этот момент B2 знает про абонента?

Вот именно поэтому удобнее авторизация по unknown source ip; в этом случае у юзеров пропадут 1-3 пинга, и львиная доля ничего не заметит

 

Какие вы сложные, блин...

 

Схема IPoE через 3750-12S + (раутер/шейпер/dhcp сервер) на микре + биллинг отлично работает.

Как показала практика, поднимается на 1 комплекте до 1000 юзерей с тарифом 10 или 100 мбит анлим.

А на 20к абонентов ставить стопку из 20 3750? =) А если за одним физическим линком, приходящим в 3750, больше 1к юзеров, скажем, 1.5-2к - прокидывать вланы сквозь неё на следующую и терминить их там? А если 3к? А при сдыхании одной быстро-быстро прокидывать все эти вланы заново?)

[Night_Snake]

Берем в руку любую из перечисленных Cisco и начинаем строить терминатора на 'влан на пользователя'. Упираемся в ограничение 1000 VLAN (и 1000 абонентов). Курим. Сносим конфиг и перестраиваем на Q-in-Q с L2 пробросом до BRAS-а. Во что упремся? По-моему в число MAC (12000 в VLAN template для 3550). Закладываем по два MAC на абонента. Получаем 6K абонентов. В шесть раз больше. Пример конечно грубый т.к. портов мало. Там такие L2 цепочки нужно будет строить, что никакие нервы не выдержат :) Более реалистичная оценка - 2K. Но закономерность очевидна - поменяли схему, и ограничение снялось. По моему неплохо. :)

ТС сказал, что сетка у него небольшая. А когда у вас больше тысячи юзеров на сегмент, и терминатор уже не вывозит, таки да, можно собрать q-in-q и гнать весь трафик радостно до BRAS.

 

Резервируем услугу. Т.е. пытаемся минимизировать количество сценариев отказа при которых абон потеряет сервис. В PPPoE вообще ничего не нужно делать - все само. Хотим сравнимую функциональность в IPoE L2-доступ? Отлично, нужно синхронизировать состояние между BRAS. Добавили терминаторы и превратили доступ в L3? Теперь придется еще и терминаторы синхронизировать.

Терминаторы можно синхронизировать, объединив их в стек, допустим. Можно прописывать клиентов статически - тогда это делается внешним скриптом. Соответственно, в сторону клиента смотрит либо VRRP, либо стек.

 

Есть терминаторы T1 и T2 и BRASы B1 и B2. Абонент получил адрес через T1. В этот момент default у T1 смотрел на B1. Через 30 минут B1 исчез с экранов радаров. Default у T1 теперь смотрит на B2. Что в этот момент B2 знает про абонента?

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

 

Я уже кажется спрашивал: по какому протоколу, и что будет являться триггером?

Если брас у нас - железный, то проще всего организовать какие-то внешние скрипты, которые на BRAS будут заливать нужные политики. Если брас на тазике, то он и сам все сделает хоть по rsync. Хотя вполне возможно, сейчас брасы и сами могут дергать тот же радиус на предмет политик для клиентов, тут банально не сталкивался.

[Skylaer]

А на 20к абонентов ставить стопку из 20 3750? =) А если за одним физическим линком, приходящим в 3750, больше 1к юзеров, скажем, 1.5-2к - прокидывать вланы сквозь неё на следующую и терминить их там? А если 3к? А при сдыхании одной быстро-быстро прокидывать все эти вланы заново?)

На 20К абонентов потребуется 4-5 штук 3750, если делать по уму.

3760 стоят за агрегацией, вланы можно тупо добавить в соседний порт агрегатора :)

Тут больше интересен вопрос резерва, но так далеко пока не думал. Но думаю +1 сервер и резерв будет работать как надо :)

[Дятел]

Берем сап32 и получаем 4К вланов......

[kf72]

Берем сап32 и получаем 4К вланов......

для терминации 4К L2 сгодитcя сап2 (кулеры и бп дешевле) но места много ест.

 

Сносим конфиг и перестраиваем на Q-in-Q с L2 пробросом до BRAS-а.

с этого момента можно подробнее? что должен уметь BRAS ? в каком виде будут выглядеть вланы с одинаковыми id от разных доступов?

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

[ichthyandr]

Сносим конфиг и перестраиваем на Q-in-Q с L2 пробросом до BRAS-а.

с этого момента можно подробнее? что должен уметь BRAS ? в каком виде будут выглядеть вланы с одинаковыми id от разных доступов?

да тут какбы (имхо) нет проблем, например

901-1001, 901-1002, 901-1003 ...

902-1001, 902-1002, 902-1003 ...

где первое число id супервлана на сегмент, а 1001- ... id абонентских вланов в этих сегментах,

главное чтоб брас смог съесть в конфиге эту пачку sub-sub интерфейсов, если терминировать на нем.

Насчет терминации q-in-q до браса - придется ядро расширять, денюх скорее всего не дадут ... :)

[ichthyandr]

Берем в руку любую из перечисленных Cisco и начинаем строить терминатора на 'влан на пользователя'. Упираемся в ограничение 1000 VLAN (и 1000 абонентов).

если не ошибаюсь, например для c3750, нужно выключить vtp и вланы с id>1000 можно прописать:

 

Configuring Extended-Range VLANs

When the switch is in VTP transparent mode (VTP disabled), you can create extended-range VLANs (in the range 1006 to 4094). Extended-range VLANs enable service providers to extend their infrastructure to a greater number of customers. The extended-range VLAN IDs are allowed for any switchport commands that allow VLAN IDs. You always use config-vlan mode (accessed by entering the vlan vlan-id global configuration command) to configure extended-range VLANs. The extended range is not supported in VLAN database configuration mode (accessed by entering the vlan database privileged EXEC command).

Extended-range VLAN configurations are not stored in the VLAN database, but because VTP mode is transparent, they are stored in the switch running configuration file, and you can save the configuration in the startup configuration file by using the copy running-config startup-config privileged EXEC command.

[Дятел]

не путайте номера больше 1000 с количеством SVI