[weedman]

Делаю тест ping packet size 1500, пакет проходит без фрагментации, пакет=1501 уже не проходит без фрагментации, хотя везде на линии мту=1550. Честно говоря не совсем понял методику тестирования пингом. точнее принцип понял, но не понял, почему не проходит больше 1500 при большем мту на интерфейсах. Если разрешить фрагментацию, то проходит. wireshark показывает фрагментацию 

В любом случае, при запуске теста, wireshark показал размер пакета=1514. поставил такое значение на VPLS интерфесе, на сколько понял, работает с таким значением. 

Правильно сделал поставив 1514?

[SUrov_IBM]

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

 

Ой…, я попробую включить свои сетевые мозги, вместо канцелярского хомячка и постараюсь объяснить как сам это представляю, постараюсь Вас случайно не запутать. У меня просто с педагогикой на самом деле очень, не очень...

 

В 29.01.2022 в 17:59, weedman сказал:

В любом случае, при запуске теста, wireshark показал размер пакета=1514.

 

В обычной Ethernet сети, MTU фрейма (кадра) = 1514 байт:

Layer-3 (IP) MTU - 20 байт заголовок IP и 1480 байт полезные данные (Layer-4) = 1500 байт.

Layer-2 (MAC) MTU - 14 байт заголовок Ethernet.

На самом деле, MTU фрейма = 1518 байт, потому что в нём присутствует FCS (Frame Check Sequence) - 4 байт, но FCS обрабатываются сетевым интерфейсом и напрямую в операционную систему не передаётся. Поэтому Wireshark показывает, что IPv4 = 1514 байт.
Если добавляется VLAN (тег 802.1Q - 4 байт), то MTU фрейма переданного в систему становиться = 1518 (без FCS), а MTU самого Ethernet фрейма c тегом 802.1Q будет = 1522 байт.

Для того, чтобы через радио-мост пролез L3 IP пакет = 1500 байт, с запретом фрагментации (DF Bit), запакованный в VLAN 802.1Q, интерфейсы радио-моста должны иметь L2 MTU = 1522 байт.

 

Как следствие, каждая технология инкапсуляции (VPLS, VLAN, PPPoE и т.д.) увеличивает значение L2/L3 MTU своим заголовком. Соответственно для того, чтобы пропустить через Ethernet порт всю инкапсулированную матрёшку без фрагментации IP пакетов на L3, необходимо суммировать заголовок каждого типа инкапсуляции для получения необходимого L2 MTU.

 

См. дополнительно:

https://mum.mikrotik.com/presentations/RU18M/presentation_5659_1538438877.pdf

https://habr.com/ru/post/226807/

 

[weedman]

В 30.01.2022 в 16:23, SUrov_IBM сказал:

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

 

Ой…, я попробую включить свои сетевые мозги, вместо канцелярского хомячка и постараюсь объяснить как сам это представляю, постараюсь Вас случайно не запутать. У меня просто с педагогикой на самом деле очень, не очень...

 

 

В обычной Ethernet сети, MTU фрейма (кадра) = 1514 байт:

Layer-3 (IP) MTU - 20 байт заголовок IP и 1480 байт полезные данные (Layer-4) = 1500 байт.

Layer-2 (MAC) MTU - 14 байт заголовок Ethernet.

На самом деле, MTU фрейма = 1518 байт, потому что в нём присутствует FCS (Frame Check Sequence) - 4 байт, но FCS обрабатываются сетевым интерфейсом и напрямую в операционную систему не передаётся. Поэтому Wireshark показывает, что IPv4 = 1514 байт.
Если добавляется VLAN (тег 802.1Q - 4 байт), то MTU фрейма переданного в систему становиться = 1518 (без FCS), а MTU самого Ethernet фрейма c тегом 802.1Q будет = 1522 байт.

Для того, чтобы через радио-мост пролез L3 IP пакет = 1500 байт, с запретом фрагментации (DF Bit), запакованный в VLAN 802.1Q, интерфейсы радио-моста должны иметь L2 MTU = 1522 байт.

 

Как следствие, каждая технология инкапсуляции (VPLS, VLAN, PPPoE и т.д.) увеличивает значение L2/L3 MTU своим заголовком. Соответственно для того, чтобы пропустить через Ethernet порт всю инкапсулированную матрёшку без фрагментации IP пакетов на L3, необходимо суммировать заголовок каждого типа инкапсуляции для получения необходимого L2 MTU.

 

См. дополнительно:

https://mum.mikrotik.com/presentations/RU18M/presentation_5659_1538438877.pdf

https://habr.com/ru/post/226807/

 

Здравствуйте, Suvorov_IBM.

Спасибо что помогаете разобраться, прочитал информацию, жаль она еще не стала знанием. 

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

Еще раз - Спасибо за очередную помощь.

[weedman]

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

В прошлых эпизодах:

Была совсем плоская сеть \24, местами на радио, местами по проводам, со временем сеть перешла на PPPoE, 

Для отказоустойчивости одного из участков, линк на AF60LR был дополнен линком на Mikrokotik 5Ghz, поверх этого OSPF\MPLS\VPLS, поверх чего в свою очередь ходит PPPoE. Во время обсуждения этих потуг, мне поступил совет перестроить сеть на L3. поставить на дальнем конце Mikrotik для терминации PPPoE и забить на все эти слои лишних технологий*.

* - Самописный биллинг будет работать с маленькой вундервафлей через белый IP

Сейчас я готов это попробовать, для начала конечно собрать на столе, потом перевести на рабочую сеть, но пока поверх тех же OSPF\MPLS\VPLS, если все хорошо, убрать все кроме OSPF потом не сложно.

Вопрос номер 1 - Куда вешать белый адрес на будущий PPPoE-Server-mikrotik? предположу - на пустой бридж.

Изменено 20 июня, 2022 пользователем weedman

[sirmax]

В 20.06.2022 в 08:24, weedman сказал:

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

В прошлых эпизодах:

Была совсем плоская сеть \24, местами на радио, местами по проводам, со временем сеть перешла на PPPoE, 

Для отказоустойчивости одного из участков, линк на AF60LR был дополнен линком на Mikrokotik 5Ghz, поверх этого OSPF\MPLS\VPLS, поверх чего в свою очередь ходит PPPoE. Во время обсуждения этих потуг, мне поступил совет перестроить сеть на L3. поставить на дальнем конце Mikrotik для терминации PPPoE и забить на все эти слои лишних технологий*.

* - Самописный биллинг будет работать с маленькой вундервафлей через белый IP

Сейчас я готов это попробовать, для начала конечно собрать на столе, потом перевести на рабочую сеть, но пока поверх тех же OSPF\MPLS\VPLS, если все хорошо, убрать все кроме OSPF потом не сложно.

Вопрос номер 1 - Куда вешать белый адрес на будущий PPPoE-Server-mikrotik? предположу - на пустой бридж.

А зачем ему вообще белый адрес?

 

[weedman]

В 07.07.2022 в 15:15, sirmax сказал:

А зачем ему вообще белый адрес?

 

Так устроен биллинг. 

в целом- разобрался 

пока вернул на L2 и RSTP

Что странно, на столе все работало нормально, на рабочем линке образовалась петля, стоят микроты,в бридже RSTP включен 

Изменено 7 июля, 2022 пользователем weedman

[sirmax]

Вопрос в том зачем платный и конечный ресурс нужен на VPN сервере если можно дать ему серый адрес а белый продать абоненту

Я вашу тему читал-читал в несколько подходов и все равно у меня не сложилось понимание что именно вы хотите получить

L2OverL3 - вроде в микроты завезли VxLAN и может даже EVPN - посмотрите в эту сторону? в FRR  EVPN точно был уже 
VxLAN в микротиках есть но есть ли там  MP-BGP я не знаю

 

[jffulcrum]

Заявлены и VxLAN, и MP-BGP. VxLAN в процессе опробования на стенде, пока полет нормальный.

[weedman]

В 08.07.2022 в 19:13, jffulcrum сказал:

Заявлены и VxLAN, и MP-BGP. VxLAN в процессе опробования на стенде, пока полет нормальный.

VxLAN на сколько знаю прожорлив, а так интересно

[sirmax]

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

Заявлены и VxLAN, и MP-BGP. VxLAN в процессе опробования на стенде, пока полет нормальный.

Да я ещё с первых беток гоняю vxlan    Работает и с линуксом и между микротиками но без MP-BGP он игрушка по большому счету

[jffulcrum]

В 08.07.2022 в 18:46, weedman сказал:

VxLAN на сколько знаю прожорлив

На CCR2116-12G-4S+ незаметно. Хотя, больше 10G еще через VxLAN не подавал, но тут с источниками проблема.

[weedman]

В 07.07.2022 в 21:06, sirmax сказал:

Вопрос в том зачем платный и конечный ресурс нужен на VPN сервере если можно дать ему серый адрес а белый продать абоненту

Я вашу тему читал-читал в несколько подходов и все равно у меня не сложилось понимание что именно вы хотите получить

L2OverL3 - вроде в микроты завезли VxLAN и может даже EVPN - посмотрите в эту сторону? в FRR  EVPN точно был уже 
VxLAN в микротиках есть но есть ли там  MP-BGP я не знаю

 

Здравствуйте.

Спасибо за участие в моей проблеме, дополню.

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

По VxLAN Смотрел информацию, когда анонсировали 7 версию и общие плюсы, нужно обновить информацию в голове, чем сейчас и займусь. Немного пугает необходимость перехода на v7, я не сторонник всего последнего.

Спасибо.

Изменено 12 июля, 2022 пользователем weedman

[weedman]

Суть всех проблем, как я ее вижу в том, что изначально все сделано из говна и палок, решения принимались не только мной, "кроилово привело к попадалову" (народная ммудрость). Ставились дешевые неуправляемые свитчи и чтобы как-то обуздать происходящий звиздец и стартануть с биллингом, в работу пошел PPPoE, для работы которого нужен тот самый L2, но в наличие есть не коммутаторы, а различные роутеры. Что-то купить сейчас не просто, денег как у любого мелкого в притык, реально доходит до маразма и мне криками приходится говорить о необходимости сегментации на что слышу...лучше не вспоминать что. Ситуацию спасает то, что клиенты сидят за натом свих микротиковских устройств, но местами в сеть смотрят устройства абонентов и это вызывает проблемы.

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

Не знаю как правильно поступить, попробовать разбить все на вланы на том имеющимся оборудовании, или по крайней мере там где уже работает оставить как есть. Пускать по вланам PPPoE звучит странно, может начнут вылазить проблемы с MTU, или еще что.

Сейчас планируется новый участок работ (PON), который хочется сделать максимально правильно, ибо с нуля.

Хотя согласен, надо рассмотреть VxLan

 

[sirmax]

тут надо понять что у вас есть а то по всей теме я все еще не понимаю какая часть сети ваша и полностью контролируется а какая - чужого провайдера

насчет VxLAN я малость погорячился - тут в ROS7 даже пока sh ip bgp  не завезли какой там MP-BGP/EVPN
Cыро в семерке пока что все ( а так хочется

 

[VolanD666]

В 12.07.2022 в 07:09, weedman сказал:

Не знаю как правильно поступить,

Правильно сделать аудит сети, потом сделать нормальный проект на основе аудита, потом привести сеть к тому что напроектировали.

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

[gard]

На прошлой работе у нас заходили разговоры о BRAS PPPoE. Может вам подойдет этот вариант? Ну.. чтобы как-то сегментировать сеть. Вариант с VLAN тоже.. типа VLAN на многоэтажку (свитч)... Но насколько это загрузит шлюз/ы... непонятно, ибо ничего не тестировалось.

[weedman]

В 12.07.2022 в 20:55, sirmax сказал:

тут надо понять что у вас есть а то по всей теме я все еще не понимаю какая часть сети ваша и полностью контролируется а какая - чужого провайдера

насчет VxLAN я малость погорячился - тут в ROS7 даже пока sh ip bgp  не завезли какой там MP-BGP/EVPN
Cыро в семерке пока что все ( а так хочется

Ну вот, а я пока взялся пробовать делать Vxlan от БС до центра (вариант на столе)

 и смотреть на сколько проца БС хватит на эти потуги. В любом случае попробую. Выглядит то все красиво.

 

В 12.07.2022 в 22:05, VolanD666 сказал:

Правильно сделать аудит сети, потом сделать нормальный проект на основе аудита, потом привести сеть к тому что напроектировали.

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

Согласен со всем, тут только добавлю не только рабочие часы а качество услуг и недовольство людей.

[weedman]

Погонял тесты на VxLAN, жрет ресурсы на самом деле прилично, но кажется работает. Если взять за идею- VxLAN от центра ( CCR1036 ), до базовой станции например mAntBOX15S, или omnitik Pro, проходит около 80 TCP, упираясь в проц базы, Если в качестве БС взять Wap60, то тут все Быстрее в силу более быстрого проца, но скорость сильно плавает, на столе получил порядка 350-500. При чем процессор полностью не нагружен ни на 1036, ни на wap60

 

Upd тесты делались на железку, на которой vxlan и поднимался, в дальнейшем сделал тест на устройство за этой железкой и скорость на 15s и omnitik поднялась до 100-130мб\с

Точных замеров с фиксацией не делал, но в целом дает представление.

[jffulcrum]

Нет, на старом добре с VxLAN лучше и не пытаться. Только новые шелезяки на ARM64

[weedman]

Почему нет? мне больше 100 на базе не нужно, я конечно не все знаю, может ответите подробнее? на столе все удовлетворительно работает, падение скорости - 2-2.5 раза

 

Изменено 14 июля, 2022 пользователем weedman

[VolanD666]

А чем принципиально VXLAN на микроте (насколько я понимаю EVPNа там не привезли пока) отличается от EoIP?

[weedman]

В 14.07.2022 в 15:34, VolanD666 сказал:

А чем принципиально VXLAN на микроте (насколько я понимаю EVPNа там не привезли пока) отличается от EoIP?

Хороший вопрос, присоединяюсь. 

Также мои замеры прошу не учитывать, так как скорее всего были ошибки

Пробовал на днях смотреть по EVPN, но не совсем понял. Поверхностно понял, что это технология другого бренда с аналогичными целями

Изменено 14 июля, 2022 пользователем weedman

[sirmax]

3 часа назад, VolanD666 сказал:

А чем принципиально VXLAN на микроте (насколько я понимаю EVPNа там не привезли пока) отличается от EoIP?

Я не знаю как работает EoIP и есть ли где то еще

VxLan это нечто более стандартное 

 

 

 

Все придумано до нас похоже 
ядрокот позаботился но я не тестил (мне как раз нужен был простой тунель на линукс а там есть и vxlan и он же в openvswitch

[jffulcrum]

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

[weedman]

В 14.07.2022 в 21:47, jffulcrum сказал:

Что касается другой задачи, тащить кучу L2 с мест к некоему BRAS, то тут как был MPLS, так он и остался

В моем опыте Это mpls\vpls и потом тот же бридж, но мои знания поверхностны, можно гонять l2 с помощью только mpls, без прочих слоев?

Сублективно vxlan проще