[sirmax]

2 часа назад, jffulcrum сказал:

VXLAN на самом деле не совсем для туннелей, это, как и NVGRE, техника для датацентров, когда надо протащить пачку VLAN, не анонсируя её на всём пути от А до Б, ну или когда у тебя уже и QinQ не справляется с потребным количеством VLAN. Все это выхлопы из не полетевшего SDN. Что касается другой задачи, тащить кучу L2 с мест к некоему BRAS, то тут как был MPLS, так он и остался, L2TPv3 и EoIP от микротика для тех, кому что-то попроще, а EVPN - это изначально джуниперовская хрень, как у Cisco OTV, для крававаго гыр-тыр-прайса, покупайте наших слонов. 

Как это sdn не полетел?

 

я б рассказал подробнее но NDA:( участвовал в построении сети. 

Кой у кого полетел и летит но да не без проблем 

 

опенфлоу даже force10 4810 умеет, у меня дома одно время стояла парочка для сексуальных игр 

[jffulcrum]

Это все прекрасно в лабе, но в жизни возникают всякие вопросы, что, например, не очень хорошо, что одна human error может всю сеть окирпчить, причем от access до core. А уж безопасность софта для этого хозяйства... Если Cisco не в состоянии в 22 году границы и переменные проверять, то писатели имплементаций OpenFlow - тем более. А риски, опять же, куда поболее - сдается вся сеть разом.

[sirmax]

1 час назад, jffulcrum сказал:

Это все прекрасно в лабе, но в жизни возникают всякие вопросы, что, например, не очень хорошо, что одна human error может всю сеть окирпчить, причем от access до core. А уж безопасность софта для этого хозяйства... Если Cisco не в состоянии в 22 году границы и переменные проверять, то писатели имплементаций OpenFlow - тем более. А риски, опять же, куда поболее - сдается вся сеть разом.

Я не согласен :) но мы очень далеки от микротика и оспф

 

Sdn это не про доступ это да

 

можем создать отдельную тему :) 

[jffulcrum]

Дык, была, ваша же: 

 

Давайте туда

[Saab95]

Напомню еще раз.

 

Сегментируется вся сеть где только возможно и переводится транспорт на L3.

От дальних сегментов по EoIP весь абонентский трафик идет в центр, где терминируется на CCR1036 или иной железке. Тут плюс в том, что если где-то в сегменте что-то зафлудит, пропадет связь только с ним, все остальное продолжит работу.

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

 

По сути схема с EoIP единственно рабочая на переделках сетей вида большая помойка. На каждый туннель в центре вешается свой PPPoE сервер.

[weedman]

В 25.08.2022 в 03:35, Saab95 сказал:

 

По сути схема с EoIP единственно рабочая на переделках сетей вида большая помойка. На каждый туннель в центре вешается свой PPPoE сервер.

В угоду современным тенденциям, все же выбор пал на VxLAN (на БС)

Делал замеры производительности различных БС, все отрабатывают нагрузку.

Большая помойка это верный термин.

Изменено 28 августа, 2022 пользователем weedman

[Saab95]

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

[sirmax]

В 28.08.2022 в 23:36, Saab95 сказал:

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

Vlan!=VxLan

:)

[Saab95]

Поподробнее? То есть его можно через интернет пробросить?

[SUrov_IBM]

Saab95, здравствуйте.

 

В 31.08.2022 в 23:11, Saab95 сказал:

То есть его можно через интернет пробросить?

Имеете в виду VxLan? Если да, то да, можно пробросить через публичный Интернет. VxLan, это Ethernet кадры упакованные в UDP, главное чтобы была маршрутизируемая IP связность. ;)

[Saab95]

В 31.08.2022 в 23:36, SUrov_IBM сказал:

Интернет. VxLan, это Ethernet кадры упакованные в UDP, главное чтобы была маршрутизируемая IP связность. ;)

Чем же тогда он отличается от EoIP? Тот же оверхед, те же 2 пакета при передаче исходных 1500 байт и т.п. Разве что не по GRE работает.

[weedman]

В 01.09.2022 в 04:09, Saab95 сказал:

Чем же тогда он отличается от EoIP? Тот же оверхед, те же 2 пакета при передаче исходных 1500 байт и т.п. Разве что не по GRE работает.

Ткнул пальцем в небо. Были варианты EoIP\MPLS-VPLS\VxLAN. Последний вроде как последний писк L2 по L3. 

[Saab95]

EoIP сам определяет максимальный MTU и передает данные в туннеле пакетами 1500 и более байт без проблем. Его используют везде.

VPLS работает с тем МТУ, которое есть на порту, не перепаковывает данные. Его обычно используют на своем транспорте.

VxLAN как себя ведет?

[weedman]

В 02.09.2022 в 01:17, Saab95 сказал:

EoIP сам определяет максимальный MTU и передает данные в туннеле пакетами 1500 и более байт без проблем. Его используют везде.

VPLS работает с тем МТУ, которое есть на порту, не перепаковывает данные. Его обычно используют на своем транспорте.

VxLAN как себя ведет?

Не заметил чтобы EoIP определял максимальный MTU, так же нужно править по пути

VxLAN как и все наверное в этом плане

[Saab95]

EoIP сам определяет максимальный МТУ на пути, и выставляет его себе в свойствах. Можно перенастроить, но если МТУ будет больше максимально возможного, оно все равно обрежется до меньшего.

[weedman]

В 03.09.2022 в 02:46, Saab95 сказал:

EoIP сам определяет максимальный МТУ на пути, и выставляет его себе в свойствах. Можно перенастроить, но если МТУ будет больше максимально возможного, оно все равно обрежется до меньшего.

Как тогда объяснить непрохождение некоторой части информации? не открываются сайты, пока руками не поправишь.

[Saab95]

В 03.09.2022 в 05:49, weedman сказал:

Как тогда объяснить непрохождение некоторой части информации? не открываются сайты, пока руками не поправишь.

Если добавляете EoIP туннель в бридж, то на этом бридже уменьшается мту, т.к. мту туннеля меньше 1500.

 

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

 

Так же не нужно забывать корректировать МТУ туннеля с другой стороны. Часто бывает, что с одной стороны работает мту 1500, а с другой меньше, вот и появляются странности, которые и требуют корректировки правилом. Но можно обойтись и без него.

[Turbid]

On 9/10/2022 at 11:15 PM, Saab95 said:

Если добавляете EoIP туннель в бридж, то на этом бридже уменьшается мту, т.к. мту туннеля меньше 1500.

А если EoIP добавлен в Bonding?

[Saab95]

В 13.10.2022 в 13:40, Turbid сказал:

А если EoIP добавлен в Bonding?

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

[Turbid]

On 10/13/2022 at 8:39 PM, Saab95 said:

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

Ничего не понел. 

 

Такая схема резервирования+агрегации каналов, например на филиалы, очень популярная: через несколько каналов  разных операторов собираются  L2TP/IPSec-туннели, поверх низ EoIP, которые уже собираются в Bonding. 

 

С 41 страницы: https://mum.mikrotik.com/presentations/RU17N/presentation_4141_1490078529.pdf

Изменено 14 октября, 2022 пользователем Turbid

[Saab95]

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

 

Я такие схемы видел и на микротике, и на других решениях - всегда это проблемная технология.

 

Другой вариант схемы - в центре на нескольких разных белых IP доступны L2TP сервера, к ним подключаются удаленные филиалы. По OSPF маршруты разделяются автоматически по 2-м и более туннелям и идут в центр. То есть запрос одного клиента филиала пойдет по каналу 1, запрос второго клиента филиала пойдет по каналу 2 и т.п. Если какой-то канал отключится то это не создаст проблем, просто скорость работы или доступность резерва ухудшится.