[feeman]

Без шуток, да, это так...

[mightyscv]

У вас реально более 1023 зданий в обслуживании ?

VTPv2 - старое зло.

 

feeman

Вы оператор связи? Используйте QinQ и VLAN-per-port архитектуру. Очень много проблем сразу решите.

Ну или просто QinQ и влан на здание если на порт не подходит.

[feeman]

feeman

Вы оператор связи?

Да.

Но по мне так это громкое слово, т.к. стереотипер оператора, это сотовая четверка и говнотелеком, ну еще может с натягом ТТК.

Которые были, есть и будут.

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

 

Вы оператор связи? Используйте QinQ и VLAN-per-port архитектуру. Очень много проблем сразу решите.

Ну или просто QinQ и влан на здание если на порт не подходит.

А можно на пальцах объяснить? Ну или если повезет схемку...

[mightyscv]

А можно на пальцах объяснить? Ну или если повезет схемку...

Схемки красивой не нашёл, поэтому вкратце объясню суть.

На доступ ставятся коммутаторы с минимальным мозгом. Порты к абонентам получают свой inner-VLAN, например с 101 по 124(для 24х портового коммутатора конечно). Порт наверх - транк. Это типовая конфигурация для всех коммутаторов доступа.

Коммутаторы агрегации чуть поумнее, умеют QinQ, считают нижестоящих братьев QinQ клиентами, и вешают второй тег(outer VLAN) поверх первого, уникальный для каждого коммутатора. В итоге на BRAS к вам абонентский трафик прилетает с уникальным сочетанием 802.1q тегов, типа [100,110]. По этому уникальному сочетанию делается аутентификация и авторизация.

В такой схеме можно иметь по грубой прикидке >4000 коммутаторов доступа, и ~96 тысяч абонентов(портов). Это уже не каждый BRAS осилит, да и коммутаторы с такой здоровой MAC-таблицей стоят негуманно(они кстати вообще есть? как-то подзабыл уже), но если надо больше, то вводите второе "поколение" коммутаторов доступа, порты которым метите уже другим набором вланов, например 201-224. Сочетание тегов опять уникально, хотя теперь в сети есть два коммутатора доступа, которым назначен один outer VLAN. В этом ничего страшного, но иногда можно запутаться. С другой стороны у вас уже под 200000 абонентов, и в этом случае у вас должно хватать выручки чтобы нанять пару CCIE, чтобы у них об этом голова теперь болела. Дальше можно сделать третье "поколение", четвёртое, и так пока пространство под inner VLAN на закончится. Теоретически - 4096*4096=16777216(больше 16.5 миллионов) портов, на практике столько в один BRAS никогда не терминируются, потому что BRAS таких мощных не бывает, и коммутаторов с такой MAC-таблицей уж точно нет, да и централизация безумная слишком.

Эта архитектура решает, как минимум, следующие проблемы:

- полная изоляция абонентов на L2. Никакие левые DHCP серверы проблем не создают, соответственно не нужен никакой DHCP-snooping, L2 фильтры, и прочее. Да, абоненты друг с другом общаются через BRAS(через proxy-ARP), но если вы будете СОРМ делать то вам это даже понравится;

- упрощенная авторизация. Никаких DHCP opt-82 и прочих костылей - outer-VLAN,inner-VLAN, всё просто;

- возможность продавать triple-play без особой головной боли. Интернет как интернет, телефонию как телефонию, телевизор с использованием STB и MVR;

- при наличии свободных VLAN(я не знаю каким монстром нужно быть чтобы их не было) можно на той же сети продавать какие-то другие сервисы другим клиентам, например какой нибудь fixed IP юридическому лицу, или L2VPN;

- упрощённая процедура замены коммутаторов доступа. Конфигурация типовая, отличается только hostname да IP. Если один сдох - можно тут же достать из зипа другой и заменить вообще без вмешательства поддержки. При наличии нескольких "поколений" коммутаторов достаточно иметь отдельный зип на каждое поколение, ну или привлечь поддержку для минимального тюнинга конфигурации;

- минимизация вероятности хэш коллизий, что для простеньких коммутаторов иногда бывает критично. В такой схеме у вас каждый коммутатор доступа видит в влане только 2 MAC-адреса - BRAS и CPE. Агрегация видит побольше маков, но всё равно они хорошо размешаны по VLAN. Сюда же можно добавить приятным бонусом защиту от совпадения MAC(хотя я такого ни разу в своей практике не встречал) - теоретически вообще у всех абонентов может быть одинаковый MAC, форвардинг в сети идёт фактически по outer/inner VLAN тегам.

Может что-то ещё, что я забыл.

[feeman]

mightyscv, Благодарствую за столь развернутый ответ!

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

Мало ли что пропустил...

[feeman]

Надеюсь правильно вас понял и схема верно нарисована.

Набросал её для собственной же наглядности.

 

Но на этапе прокидывания вланов от агрегации до BRAS'а, случился затык.

BRAS'у же нужно объявить Vlan'ы с 100 по 123, но с повторением аж 4-е раза согласно схеме?

Что будучи уверен не позволит BRAS.

 

И вот вопрос, как примерно должен выглядеть конфинг BRAS'а?

Изменено 16 мая, 2017 пользователем feeman

[myth]

100 по 123, но с повторением аж 4-е раза согласно схеме?

нет, не так.

[mightyscv]

feeman

Не очень понял вопроса.

Грубо говоря с обычным 802.1q вы пишете

encapsulation dot1q 500

а с QinQ как-то так(команда может отличаться, главное принцип)

encapsulation dot1q inner 500 outer 600

Надеюсь, логика понятна.

 

Далее, руками это никто не прописывает. Используется dynamic vlan, пример конфигурации http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/isg/configuration/xe-16/isg-xe-16-book/isg-dyn-vlan.html

 

Я лично на Cisco ASR этого не делал никогда, я это делал на Juniper MX. Но принципы везде одинаковые, и судя по тому что я нагуглил за 2 минуты, у Cisco всё это работает и поддерживается точно так же как и у Juniper, за исключением самих команд конечно.

[feeman]

Да, вопрос пожалуй был более обширный, чем требовалось по факту. А нужен был всего лишь пример конфигурации sub интефрейса с qinq.

mightyscv, но благодаря вашей подсказке, сразу же нашел пример конфигурации SUB интерфейса =)))

 

interface TenGigabitEthernet0/0/0.101

encapsulation dot1Q 101 second-dot1q 100-123

ip address 10.16.13.1 255.255.255.0

[NikAlexAn]

По схеме Vlan на здание.

 

У вас реально более 1023 зданий в обслуживании ?

Вроде на схеме 6509 а это 4096 VLAN и SVI.

Хоть SVI хоть сабы всё равно больше 4096 L3 в сумме не будет. L3 интерфейс, даже если и не SVI, всё равно откушает VLAN для своих нужд.

И не уверен что хватит таблицы ARP для сети даж на 1К зданий.

Да и таблица маков не безразмерная.

Изменено 17 мая, 2017 пользователем NikAlexAn

[Saab95]

На доступ ставятся коммутаторы с минимальным мозгом. Порты к абонентам получают свой inner-VLAN, например с 101 по 124(для 24х портового коммутатора конечно). Порт наверх - транк. Это типовая конфигурация для всех коммутаторов доступа.

Коммутаторы агрегации чуть поумнее, умеют QinQ, считают нижестоящих братьев QinQ клиентами, и вешают второй тег(outer VLAN) поверх первого, уникальный для каждого коммутатора. В итоге на BRAS к вам абонентский трафик прилетает с уникальным сочетанием 802.1q тегов, типа [100,110]. По этому уникальному сочетанию делается аутентификация и авторизация.

Может что-то ещё, что я забыл.

 

Вы забыли какой на дворе год. Такая схема была актуальна примерно в 2010, а сейчас модные схемы с использованием MPLS, тогда вопросы мак адресов полностью исключаются, в центр все идет поверх L3 в MPLS интерфейсах, которые можно заводить куда угодно и как угодно. Соответственно схема сети несколько меняется, первые коммутаторы так и остаются с минимальным мозгом, вторые коммутаторы либо L2 промежуточные, от них все идет до ближайшего мини узла, где установлен коммутатор или роутер с поддержкой MPLS, он уже упаковывает данные в туннели и передает дальше в центр. Если средства позволяют сразу абонентские коммутаторы включать в MPLS коммутаторы - это еще более простая схема. Все сети крупняков именно так и сделаны. Т.к. при большом количестве абонентов прокидывать мильон вланов в центр поверх чистого L2 как-то не серьезно и муторно.

 

Да и таблица маков не безразмерная.

 

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

[feeman]

Saab95, из вашего поста только понял, что MPLS рулит.

Но как и куда, это осталось за кадром.

Опишите по подробней предложенную вами схему.

Только без микротиков пожалуйста.

[mightyscv]

Saab95

Это не так. Все проблемы MAC-адресов(совпадения, хэш коллизии, лимиты размера таблиц коммутатора) остаются, просто они локализованы в L2 сегменте, который включен в PE. Собственно все те же самые проблемы будут если вместо PE у вас непосредственно BRAS.

Да и вообще, PWHT(я надеюсь мы про него говорим?) не для этого придуман. Он решает задачу "как бы нам завести все наши L2 сегменты в один BRAS в MPLS-сети, и при этом иметь все плюшки MPLS?", потому что без PWHT это решается через PW/VPLS, но с ограничениями. Необходимость строить L2 сеть доступа это не отменяет, про MPLS на доступе все только разговаривают, но на практике я о таких решениях не слышал, и вообще не уверен что кто-то control plane под это хотя бы написал(потому что никому не нужно).

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

[Saab95]

Опишите по подробней предложенную вами схему.

 

Тут все просто. Есть порт куда подключен клиент. Если предположить, что везде стоят крутые L3 циски, то можно прямо на порт навесить адреса абонента и не иметь никаких вланов и связанных с ними проблем. Но это дорого и никогда не окупится. Следовательно нужно вставить устройства попроще между крутой циской и абонентами - это L2 коммутаторы. И чем ближе к абонентам вы прекратите этот L2, тем лучше.

 

Кроме всего, в чистом L2 с вланами их можно передавать только по одному каналу, а резервирование через STP, который отключает резервный канал. А используя L3 можно утилизировать оба канала одновременно.

[feeman]

L3 на доступ? Ну это пожалуй выбор аристократов, которых среди нас нет.

L2 на доступ + L3 для MPLS + Агреция + Bras. Что-то как то сложно и дорого.

 

Вариант предложенный mightyscv, считаю самым приемлемым в соотношении цена/качество!

Вбухивать бабло ради призрачной перспективы улучшения качества услуг?

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

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

 

Такая схема под стать федеральной четверке и говнотелекому.

Остальным придется довольствоваться более бюджетными решениями, как например VLAN-per-port.

[VolanD666]

На доступ ставятся коммутаторы с минимальным мозгом. Порты к абонентам получают свой inner-VLAN, например с 101 по 124(для 24х портового коммутатора конечно). Порт наверх - транк. Это типовая конфигурация для всех коммутаторов доступа.

Коммутаторы агрегации чуть поумнее, умеют QinQ, считают нижестоящих братьев QinQ клиентами, и вешают второй тег(outer VLAN) поверх первого, уникальный для каждого коммутатора. В итоге на BRAS к вам абонентский трафик прилетает с уникальным сочетанием 802.1q тегов, типа [100,110]. По этому уникальному сочетанию делается аутентификация и авторизация.

Может что-то ещё, что я забыл.

 

Вы забыли какой на дворе год. Такая схема была актуальна примерно в 2010, а сейчас модные схемы с использованием MPLS, тогда вопросы мак адресов полностью исключаются, в центр все идет поверх L3 в MPLS интерфейсах, которые можно заводить куда угодно и как угодно. Соответственно схема сети несколько меняется, первые коммутаторы так и остаются с минимальным мозгом, вторые коммутаторы либо L2 промежуточные, от них все идет до ближайшего мини узла, где установлен коммутатор или роутер с поддержкой MPLS, он уже упаковывает данные в туннели и передает дальше в центр. Если средства позволяют сразу абонентские коммутаторы включать в MPLS коммутаторы - это еще более простая схема. Все сети крупняков именно так и сделаны. Т.к. при большом количестве абонентов прокидывать мильон вланов в центр поверх чистого L2 как-то не серьезно и муторно.

 

Да и таблица маков не безразмерная.

 

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

 

А чем ваша схема отличает от того, что сейчас у ТС? У ТС как раз проблема дотянуть клиентов до ближайшего агрегатора, как ему мплс то поможет?

[NikAlexAn]

 

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

 

А как это передача L2 через MPLS может снять ограничения на таблицу MAC на том устройстве куда это всё вольётся?

 

Хорош впаривать микротики где ни поподя.

[Saab95]

А чем ваша схема отличает от того, что сейчас у ТС? У ТС как раз проблема дотянуть клиентов до ближайшего агрегатора, как ему мплс то поможет?

 

У ТС, судя по схеме, понимание вопроса на уровне L2 только, это влан управления и влан от абонента, упакованный в QinQ. И используя эти инструменты есть желание сделать все красиво. От тех же агрегаторов трафик все равно во вланах идет в центр.

 

Какие проблемы?

 

1. Допустим конфигурация коммутаторов типовая и там ничего делать не надо, все вланы везде одинаковые.

2. На первых коммутаторах поумнее уже надо добавить вланы для QinQ, тут уже каждый уникальный.

3. На маршрутизаторе каждого участка нужно завести эти вланы.

 

Далее на схеме нарисованы 3 маршрутизатора, и между ними зачем то указан влан управления VLAN 10, который так же идет и до коммутаторов доступа. Но зачем? Что мешает сделать влан управления между маршрутизаторами свой изолированный, там же проблем не бывает. А на каждый коммутатор доступа сделать уже свой влан, и вланы с коммутаторов двух маршрутизаторов вместе не пересекать. При этом в теме фигурировало желание подключить очень много домов с коммутаторами, то есть вероятность отказа возрастает.

 

Вот в одном месте покупали оператора, а когда покупают, сами знаете, сеть не подходит под свою схему, а работать надо. Тем более узел связи, биллинг и т.п. находится в другом городе. Перед существующими коммутаторами установлены роутеры, на которых заведены вланы, и после коммутатора доступа весь трафик идет поверх L3, каждый коммутатор изолирован от других, никаких вланов управления нет. Оптика от центральных коммутаторов втыкается уже в роутер. Далее после маршрутизатора трафик через центральные коммутаторы и существующее оборудование провайдера идет через канал интернета на центральный узел по туннелю, где уже терминируется и абоненты получают доступ в сеть.

 

 

Естественно, встает вопрос, а хватит ли RB3011 для пропуска трафика? Конечно хватит, ведь с домовых коммутаторов обычно более 300-400 мегабит трафика не бывает. И то это с локалкой, которая теперь перестала существовать.

 

Плюсы такой схемы:

1. Каждый коммутатор изолирован, любые поломки, флуды портов, глюки абонентских роутеров, могут создать проблемы только этому коммутатору. Других не затронет.

2. Удобство управления - никаких вланов управления, на транспортной сети ничего прокидывать, пробрасывать не нужно, все идет поверх L3 сети.

3. Масштабируемость и отказоустойчивость, можно подключать любое количество коммутаторов по такой схеме.

 

Конечно, тут все упирается в железку для перевода L2 в L3, у микротика есть такие, у других вендоров нет, поэтому установка некой циски за большую сумму не имеет смысла, как уже писали. Обычно в возможности микротика не верят, типа он глючит и виснет, но на практике все хорошо работает. И такая сеть практически не требует вмешательств в свою работу. Любители линукса могут использовать убнт роутеры, в которых линукс и они так же нужные объемы трафика пропустят, или различные там тп-линк роутеры, но у них со стабильностью самого железа могут быть вопросы.

 

А как это передача L2 через MPLS может снять ограничения на таблицу MAC на том устройстве куда это всё вольётся?

 

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

 

Хорош впаривать микротики где ни поподя.

 

Я тут микротики не впариваю, а лишь на примере их показываю, как можно сделать нормальную сеть. Там что по циске нарисовать перед домовым коммутатором?. Если знаете аналоги таких коробочек за маленькую стоимость, приведите их примеры и используйте вместо микротика.

[Serejka]

На каждый VLAN вешать один L3 интерфейс с нужным набором дополнительных IP адресов.

 

такое людям советуют делать в 2017году? заведомо плохой дизайн, хотя если это дело опереть ещё и на шаткий костыль статической маршрутизации, то на радость админу может и прокатит.

[VolanD666]

А чем ваша схема отличает от того, что сейчас у ТС? У ТС как раз проблема дотянуть клиентов до ближайшего агрегатора, как ему мплс то поможет?

 

У ТС, судя по схеме, понимание вопроса на уровне L2 только, это влан управления и влан от абонента, упакованный в QinQ. И используя эти инструменты есть желание сделать все красиво. От тех же агрегаторов трафик все равно во вланах идет в центр.

 

Какие проблемы?

 

1. Допустим конфигурация коммутаторов типовая и там ничего делать не надо, все вланы везде одинаковые.

2. На первых коммутаторах поумнее уже надо добавить вланы для QinQ, тут уже каждый уникальный.

3. На маршрутизаторе каждого участка нужно завести эти вланы.

 

Далее на схеме нарисованы 3 маршрутизатора, и между ними зачем то указан влан управления VLAN 10, который так же идет и до коммутаторов доступа. Но зачем? Что мешает сделать влан управления между маршрутизаторами свой изолированный, там же проблем не бывает. А на каждый коммутатор доступа сделать уже свой влан, и вланы с коммутаторов двух маршрутизаторов вместе не пересекать. При этом в теме фигурировало желание подключить очень много домов с коммутаторами, то есть вероятность отказа возрастает.

 

Вот в одном месте покупали оператора, а когда покупают, сами знаете, сеть не подходит под свою схему, а работать надо. Тем более узел связи, биллинг и т.п. находится в другом городе. Перед существующими коммутаторами установлены роутеры, на которых заведены вланы, и после коммутатора доступа весь трафик идет поверх L3, каждый коммутатор изолирован от других, никаких вланов управления нет. Оптика от центральных коммутаторов втыкается уже в роутер. Далее после маршрутизатора трафик через центральные коммутаторы и существующее оборудование провайдера идет через канал интернета на центральный узел по туннелю, где уже терминируется и абоненты получают доступ в сеть.

 

 

Естественно, встает вопрос, а хватит ли RB3011 для пропуска трафика? Конечно хватит, ведь с домовых коммутаторов обычно более 300-400 мегабит трафика не бывает. И то это с локалкой, которая теперь перестала существовать.

 

Плюсы такой схемы:

1. Каждый коммутатор изолирован, любые поломки, флуды портов, глюки абонентских роутеров, могут создать проблемы только этому коммутатору. Других не затронет.

2. Удобство управления - никаких вланов управления, на транспортной сети ничего прокидывать, пробрасывать не нужно, все идет поверх L3 сети.

3. Масштабируемость и отказоустойчивость, можно подключать любое количество коммутаторов по такой схеме.

 

Конечно, тут все упирается в железку для перевода L2 в L3, у микротика есть такие, у других вендоров нет, поэтому установка некой циски за большую сумму не имеет смысла, как уже писали. Обычно в возможности микротика не верят, типа он глючит и виснет, но на практике все хорошо работает. И такая сеть практически не требует вмешательств в свою работу. Любители линукса могут использовать убнт роутеры, в которых линукс и они так же нужные объемы трафика пропустят, или различные там тп-линк роутеры, но у них со стабильностью самого железа могут быть вопросы.

 

А как это передача L2 через MPLS может снять ограничения на таблицу MAC на том устройстве куда это всё вольётся?

 

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

 

Хорош впаривать микротики где ни поподя.

 

Я тут микротики не впариваю, а лишь на примере их показываю, как можно сделать нормальную сеть. Там что по циске нарисовать перед домовым коммутатором?. Если знаете аналоги таких коробочек за маленькую стоимость, приведите их примеры и используйте вместо микротика.

 

Вы путаете софт-роутер и L3 коммутатор. На место ТС я бы поставил несколько L3 коммутаторов, и терминировал бы вланы на них. Т.е. схема примерно как вы нарисовали, но только на L3 коммутаторах.

Изменено 18 мая, 2017 пользователем VolanD666

[feeman]

На место ТС я бы поставил несколько L3 коммутаторов, и терминировал бы вланы на них. Т.е. схема примерно как вы нарисовали, но только на L3 коммутаторах.

 

 

VolanD666, т.е. предложенный вами вариант должна выглядеть так:

 

L2 (доступ) => L3 (х.з. зачем?) => L3 (агрегация) => Bras

[VolanD666]

На место ТС я бы поставил несколько L3 коммутаторов, и терминировал бы вланы на них. Т.е. схема примерно как вы нарисовали, но только на L3 коммутаторах.

 

 

VolanD666, т.е. предложенный вами вариант должна выглядеть так:

 

L2 (доступ) => L3 (х.з. зачем?) => L3 (агрегация) => Bras

 

L2 (access) => L3 (distribution) => L3 (Core)

 

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

[feeman]

Я просто не знаю полной схемы сети.

Схема прикрепил.

 

Но ставить одну 6509 на агрегацию я бы не стал.

Два SUP'а, один в работе, другой на холодном старте, + два блока питания в резерве.

Что там еще может выйти из строя?

 

Т.к. имеем те проблемы, которые вы имеете сейчас+ единая точка отказа.

Уточните что за проблемы?

По поводу единой точки отказа, соглашусь. Но это спорный вопрос, если под рукой есть ЗИП.

[Saab95]

Так а масштаб сети какой все же? На приведенной схеме если только одна циска, то домовых коммутаторов может быть столько, сколько на ней имеется портов и не более того. Нужно еще смотреть на то, как волокна идут от домов в центр, можно ли там сделать резервирование, кольцо какое-то, или двойное L3 кольцо и т.п. Центральное оборудование настроить на совместную работу, что бы выход из строя одного устройства не требовал оперативного вмешательства администратора.

[DRiVen]

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

 

P.S>Так любимый Саабом95 MPLS у т.н. "крупняка" используется из-за необходимости в различных моделях пропуска трафика, а никак не из-за его "модности".

 

P.P.S>Cхему поправьте, qinq на аплинках с доступа нарисовали.