[surgeon]

Всем привет.

 

Имеется провайдерская сеть на PPPoE. Проходим стадию модернизации и необходимо избавляться от L2 трафика в ядре. Планируем кольца в ядре. На узлах Tier3/Tier2 топология.

Необходимо пробросить PPPoE по L2 туннелю до брасов. Какую технологию лучше рассмотреть MPLS L2VPN или VxLAN? Может литература какая есть чтоб посмотреть в сравнении. Так сказать плюсы и минусы каждого решения.

 

Основные задачи
1. Отсутсвие L2 в ядре
2. Резервирование магистралей путем кольцевой топологии без наличия L2 трафика в нем
3. Возможность балансировки нагрузки по каналам
4. Возможность объединять филилалы абонентов в сеть.
5. Возможность перераспределения нагрузки  в случае отвала каких либо резерных или основных линков


Спасибо заранее

Edited September 29, 2023 by surgeon

[alexmern]

Аналогичную задачу у себя выполнили на MPLS + MPLS TE.
 

В целом, практически всё тоже самое имеется и в VXLAN + EBGP. Тут скорее вопрос в том, какое у вас оборудование и что оно может. 

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

Edited September 29, 2023 by alexmern

[ne-vlezay80]

В 29.09.2023 в 15:00, alexmern сказал:

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

хм, в linux vxlan доступен в ядре из коробки. Разве что потребуется установить frrouting... И через него настроить evpn. Но, можно и мультикастом со скриптами обойтись... Кстати, делать туннели лучше на ipv4...
А что за обурудование?

[surgeon]

Спасибо всем
Оборудования пока стоит Cisco Nexus 3064. Нет ни MPLS ни VxLAN. Смотрим, что лучше брать.

VxLAN привлекает тем, что нет необходимости иметь поддержку VxLAN на P оборудовании, достаточно на PE концах. Таким образом внедрить туннели можно быстрее
MPLS привлекает ТЕ, все же провайдерский протокол а не датацетров. Но тут нужна поддержка MPLS на всем пути следования. Соответственно реализация выходит дороже, а значит зайемет больше времени.

Поэтому и дилема

[Умник]

@surgeon, интересно, что из MPLS-TE не потенциально, а на практике может быть нужно небольшому оператору? В голову приходит только fast reroute. И то, если действительно важны десятки миллисекунд при перестроении.

С BFD и оптимизированными таймерами OSPF, можно особо не напрягаясь достичь времени схождения в пределах 1 секунды [1].

 

1. https://wiki.apnictraining.net/_media/apnic42/8-fast_convergence_techniques.pdf

Edited October 6, 2023 by Умник

[surgeon]

@Умник Из критичных сервисов, которые требуют быстрого переключения разве только телефония и IPTV, также есть клиенты на L2 тунели, которые сейчас работают через QinQ.  Спасибо, почитаю

[Archville]

@Умник Вот FRR на практике как раз и не особо нужен. Основной плюс TE для "небольшого" оператора заключается в возможности балансировки. Например: допустим, есть на магистральном сегменте LAG  из четырех 10G между двумя P маршрутизаторами. Допустим есть услуга vpls с полосой 15G между некими  двумя точками, трафик которого должен проходить через этот LAG. Если сигналинг  будет LDP, и PE оборудование не поддерживает т.н. entropy label, то трафик этой услуги пойдет только по одному из портов этого LAG. RSVP-TE позволяет сделать несколько LSP (в нашем случае четыре), привязать эти LSP к этому VPLS и все транзитное оборудование будет балансировать этот трафик по транспортной метке.

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

[Saab95]

В 06.10.2023 в 21:07, surgeon сказал:

только телефония и IPTV

Это не требует быстрого переключения, по телефонии пауза в несколько секунд не проблема, это же не многократные отключения будут а разовое при перестроении маршрутов. IPTV же имеет буферизацию и ему отключение хоть секунд на 5-10 не критично.

 

В 08.10.2023 в 13:01, Archville сказал:

Основной плюс TE для "небольшого" оператора заключается в возможности балансировки.

Если передавать чистый IP и будут 4 канала, то, разве, маршрутизатор не будет разбивать трафик по этим 4-м каналам сам безо всяких вмешательств? Что бы равномерно их загрузить?

[Умник]

7 часов назад, Saab95 сказал:

разве, маршрутизатор не будет разбивать трафик по этим 4-м каналам сам безо всяких вмешательств?

Имелась ввиду балансировка трафика в каналах с разной пропускной способностью. Он далее описывает.

[surgeon]

@Saab95 ну, может абон часть и не требует, только вот у нас с тарелок до платфомы идет 2gbs мультикаста, который при всем желании в буфер на 10 секунд не отправишь.  Есть корпоративные L2 VPN тунели, причем SLA по некоторым из них довольное жесткий.
На сколько помню, mpls в свое время не очень дружил с мультикастом

Edited October 10, 2023 by surgeon

[Saab95]

5 часов назад, Умник сказал:

балансировка трафика в каналах с разной пропускной способностью.

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

 

4 часа назад, surgeon сказал:

только вот у нас с тарелок до платфомы идет 2gbs мультикаста, который при всем желании в буфер на 10 секунд не отправишь.

Тогда что мешает рядом с тарелками перекодировать его в юникаст и дело в шляпе? Мультикаст уже как 10 лет прошлый век. При наличии больших каналов до абонентов уже нет ограничения в пропускную способность транспортной сети.

 

Например у нас при 1000 активных ТВ абонентов трафик с серверов всего 5-6Г. И это учитывая то, что много смотрят HD каналов и сжатие стоит минимальное, для увеличения качества картинки. Далее эти 5-6Г равномерно размазываются по сети, и даже хватает 1Г каналов на самые дальние абонентские подключения. А уж в центре где куча десяток, там этой нагрузки и не видно.

 

4 часа назад, surgeon сказал:

Есть корпоративные L2 VPN тунели, причем SLA по некоторым из них довольное жесткий.

У нас, например, везде микротики на сети (коммутаторы, роутеры). На магистралях настроен OSPF с BFD, время переключения 1 секунда (можно сделать меньше, но не стали). Микротик класса CCR1036 легко прогоняет через туннель МПЛС 10Г трафика, больше просто порты не пропустят. И у важных абонентов как раз и устанавливается такой микротик, и аналогичные на остальных точках. И уже между ними поднимается туннель для передачи данных этого абонента.

 

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

 

Более того, даже БС сотовых операторов подключали просто через туннель EoIP поверх сети, трафика 500М. Да, задержка чуток плавает, порой 5-7 мс (дальняя точка), но на качество разговора, скорости интернета с этой БС (проверяли сами), не влияет. Т.к. все эти запросы по SLA порой простая перестраховка, для передающихся данных не так и важны. Вот обрывы конечно важны. Но даже когда обрывался этот туннель, разговоры по сотовым просто прерывались на время обрыва, например 2-5 секунд, и сразу восстанавливались. Конечно, если обрыв длинный регистрация БС прерывается и требуется больше времени на включение и от сотовых сразу абуза прилетает с жалобой.

[surgeon]

@Saab95 

Quote

Тогда что мешает рядом с тарелками перекодировать его в юникаст и дело в шляпе? 

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

[ne-vlezay80]

В 10.10.2023 в 18:02, surgeon сказал:

@Saab95 

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

можно по gretap или что там у вас...