Сообщения без ответов | Активные темы Текущее время: 01 окт 2020, 06:08



Ответить на тему  [ Сообщений: 43 ]  На страницу 1, 2  След.
Фрагментация и реасеблинг VXLAN 
Автор Сообщение
Аватара пользователя

Зарегистрирован: 25 апр 2013, 12:36
Сообщения: 115
Откуда: Мск. обл.
Коллеги, добрый день!
Подскажите есть ли оборудование(вендор любой), которое умеет делать реасеблинг фрагментированных пакетов VXLAN.
Например мы пробовали тестировать на cisco NEXUS 9300. Они не умею делать реасеблинг. Это подтверждается cisco TAC.
Есть ли у других вендоров коммутаторы или роутеры, которые умеют делать реасемблирование непосредственно сами.


17 сен 2019, 12:28
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
Huawei CE6880EI умеет а собственно чего вы добиваетесь


17 сен 2019, 14:55
Профиль
Аватара пользователя

Зарегистрирован: 25 апр 2013, 12:36
Сообщения: 115
Откуда: Мск. обл.
:mrgreen: Хотим VXLAN трафик между сайтами через VPN гонять.
Пакеты проходящие транзитом через маршрутизатор, маршрутизатор фрагментирует.
Далее эти пакеты приходят на маршрутизатор на другой стороны, он их далее отправляет в сторону NEXUS.
NEXUS эти пакеты дропает.


17 сен 2019, 16:49
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
cosmonaft писал(а):
Пакеты проходящие транзитом через маршрутизатор, маршрутизатор фрагментирует.Далее эти пакеты приходят на маршрутизатор на другой стороны, он их далее отправляет в сторону NEXUS.

А почему удаленный роутер их не восстанавливает?

Можно попробовать завернуть их в GRE например.
Внутри GRE поставить MTU с запасом, фрагментироваться будут GRE пакеты,
но они по идее должны восстанавливаться на том конце,
и на выходе вы получите исходные пакеты VXLAN (они UDP, насколько я помню).

_________________
Knowledge is Power


17 сен 2019, 16:57
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
вы страдаете фигнёй для того чтобы VXLAN работал у вас на всём протяжении линии должно быть минимум 1550 МТУ а лучше 1600 - тем более вы хотите ещё внутри GRE то тогда наканьте ещё 24 байта, когда будут соблюдены физические величины МТУ то тогда вам не понадобится fragmentation and reassembly of VXLAN traffic - и всё будет работать из коробки на том же Nexus 93180YC-EX или FX


Последний раз редактировалось root99 17 сен 2019, 17:09, всего редактировалось 1 раз.



17 сен 2019, 17:04
Профиль
Аватара пользователя

Зарегистрирован: 25 апр 2013, 12:36
Сообщения: 115
Откуда: Мск. обл.
Silent_D писал(а):
cosmonaft писал(а):
Пакеты проходящие транзитом через маршрутизатор, маршрутизатор фрагментирует.Далее эти пакеты приходят на маршрутизатор на другой стороны, он их далее отправляет в сторону NEXUS.

А почему удаленный роутер их не восстанавливает?

Можно попробовать завернуть их в GRE например.
Внутри GRE поставить MTU с запасом, фрагментироваться будут GRE пакеты,
но они по идее должны восстанавливаться на том конце,
и на выходе вы получите исходные пакеты VXLAN (они UDP, насколько я помню).



А собственно почему он их должен на втором маршрутизаторе восстанавливать?

Мы используем mGRE.

К сожалению это так не работает. Проверенно.


17 сен 2019, 17:07
Профиль
Аватара пользователя

Зарегистрирован: 25 апр 2013, 12:36
Сообщения: 115
Откуда: Мск. обл.
root99 писал(а):
вы страдаете фигнёй для того чтобы VXLAN работал у вас на всём протяжении линии должно быть минимум 1550 МТУ а лучше 1600 - тем более вы хотите ещё внутри GRE то тогда наканьте ещё 24 байта

Я это знаю. Я с вами согласен.
Страдаем.
Просто было интересно знать мнение специалистов.

Тогда второй вопрос.
Даже несколько.

Зачем и почему Huawei делает такую фичу, как реассемблинг VXLAN на своих коммутаторах?
Вы мне написали, что huawei поддерживает и я параллельно сам смог нагуглить только про huawei.

Почему другие вендоры не делают этого?

Получается, что для использования VXLAN необходимы каналы на которых можно увеличить mtu до 1600.


17 сен 2019, 17:13
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
cosmonaft писал(а):
А собственно почему он их должен на втором маршрутизаторе восстанавливать?

Если мы про GRE, то потому, что он на удаленном роутере терминируется.

cosmonaft писал(а):
Мы используем mGRE.
К сожалению это так не работает. Проверенно

А какой MTU у вас стоит на GRE?

_________________
Knowledge is Power


17 сен 2019, 17:15
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
МТУ на канале в любом случ должен быть 1550-1600 - через обычный IP Transit вы не получите такой МТУ - только заказывать канал точка-точка но там уже можно получить 9000 байт

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


17 сен 2019, 17:19
Профиль
Аватара пользователя

Зарегистрирован: 25 апр 2013, 12:36
Сообщения: 115
Откуда: Мск. обл.
Silent_D писал(а):
cosmonaft писал(а):
А собственно почему он их должен на втором маршрутизаторе восстанавливать?

Если мы про GRE, то потому, что он на удаленном роутере терминируется.

cosmonaft писал(а):
Мы используем mGRE.
К сожалению это так не работает. Проверенно

А какой MTU у вас стоит на GRE?

1400


17 сен 2019, 17:22
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
для того чтобы VXLAN заработал на тех же Нексус 93180YC-EX or FX в любом случ нужно заказывать канал точка-точка с нужными характеристиками..., через обычный интернет Вам ничего не светит.


17 сен 2019, 17:25
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
Silent_D писал(а):
Внутри GRE поставить MTU с запасом, фрагментироваться будут GRE пакеты,

cosmonaft писал(а):
К сожалению это так не работает. Проверенно.

cosmonaft писал(а):
1400

Вы не видите противоречий?

root99 писал(а):
МТУ на канале в любом случ должен быть 1550-1600

MTU на канале может быть любой, ибо Pre-Fragmentation for IPsec VPNs

https://www.cisco.com/c/en/us/td/docs/i ... -vpns.html

Попытаюсь таки донести мысль. :-)
1. На GRE ставим MTU 1600, с запасом, так чтобы VXLAN пакеты туда пролезали БЕЗ фрагментации.
2. Сам GRE пакет потом фрагментируется при отправке в IPSec (см. выше)
3. GRE на том конце восстанавливается из IPSec и собирается, т.к. это его destination.
4. Из восстановленного GRE достается исходный пакет VXLAN.

Где здесь ошибка в логике? (Разве что GRE пакет не может быть больше, чем ...)

Да, frag/defrag будет грузить роутер, да оверхед, но это лучше, чем ничего.

_________________
Knowledge is Power


17 сен 2019, 17:37
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
как вы можете на GRE выставить 1600 если ETH интерфейс вашего рутера и вашего аплинка имеет 1500 а максимум в лучшем случ 1518

На GRE максимум что можно выставить 1500 - 24 = 1476 это в стандарте...


17 сен 2019, 17:47
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
root99 писал(а):
как вы можете на GRE выставить 1600 если ETH интерфейс вашего рутера и вашего аплинка имеет 1500 а максимум в лучшем случ 1518

1. Ограничение может быть только принудительным, т.к. GRE это логический интерфейс,
какое отношение он имеет к Eth?

2. VXLAN энкапсулируется в UDP, т.е. предполагается, что он потом штатно достается обратно.

3. UDP должен нормально передаваться через MTU 1500. Он энкапсулируется в GRE.

4. Прежде, чем попасть в Ethernet, GRE - Pre-Fragmentation for IPsec VPNs (см. выше еще раз).

_________________
Knowledge is Power


17 сен 2019, 18:07
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
Туннельный интерфейс имеет прямое отношение к физическому интерфейсу поверх которого он собирается ходить и соот. если стандартным МТУ является 1500 - то более 1476 ( или 1480 байт в режиме IP-IP ) на туннельном интерфейсе для туннельного транспорта не может быть...

для VXLAN есть системные требования к МТУ - значение МТУ 1550 ( 1500 + VXLAN 50 байт ) не взято с потолка..., для того чтобы проходили такие фреймы нужно включать jumbo frame - а это платные услуги ( и работают в рамках ДЦ или каналах точка-точка )


17 сен 2019, 18:23
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
root99 писал(а):
Туннельный интерфейс имеет прямое отношение к физическому интерфейсу поверх которого он собирается ходить и соот. если стандартным МТУ является 1500 - то более 1476 ( или 1480 байт в режиме IP-IP ) на туннельном интерфейсе для туннельного транспорта не может быть...

Туннельный интерфейс - это IP over IP в разных вариантах.
Нижний IP может ходить поверх чего угодно.

Про GRE, в частности:

When the DF bit on an IPv4 delivery header is set to 0, the GRE
delivery packet can be fragmented by any router between the GRE
ingress and egress nodes.

If the GRE egress node is configured to support reassembly, it will
reassemble fragmented delivery packets. Otherwise, the GRE egress
node will discard delivery packet fragments.

https://tools.ietf.org/html/rfc7588#section-3.2

IP MTU 1476 выбирается по умолчанию, чтобы избежать фрагментации.
Но если нам нужно, (а в этом случае нам нужно), то мы можем поставить любое.
Т.е. тут мы сознательно жертвуем производительностью, чтобы вообще работало.

Код:
c2821-VPN#sh int tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  Description: Test
  Internet address is 10.1.1.1/30
  MTU 17878 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set

c2821-VPN(config)#interface Tunnel1
c2821-VPN(config-if)#ip mtu ?
  <68-17878>  MTU (bytes)

interface Tunnel1
 description Test
 ip address 10.1.1.1 255.255.255.252
 ip mtu 1500

c2821-VPN#sh ip int tunnel 1
Tunnel1 is up, line protocol is up
  Internet address is 10.1.1.1/30
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1500 bytes


Это IPSec VTI, но идея везде одна.

_________________
Knowledge is Power


17 сен 2019, 19:00
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
root99 писал(а):
для VXLAN есть системные требования к МТУ - значение МТУ 1550 ( 1500 + VXLAN 50 байт ) не взято с потолка..., для того чтобы проходили такие фреймы нужно включать jumbo frame - а это платные услуги ( и работают в рамках ДЦ или каналах точка-точка )

То, что вы говорите, возможно так и есть, на L2 уровне внутри свитчей.
Но для доставки VXLAN фреймов между сайтами, они инкапсулируются в UDP.
Все.
Вот эти самые UDP нам нужно доставить на ту сторону через VPN, не испортив (не фрагментировав).
С учетом оверхеда это как бы невозможно, но мы эту фрагментацию переносим на уровень обертки.
GRE, IPSec VTI etc.
Да, это будет жрать проц. ресурсы роутера на больших пакетах, но зато будет работать.
Нужно это или нет такой ценой - решать каждому на месте.

Введение в VXLAN
https://habr.com/ru/post/344326/

_________________
Knowledge is Power


17 сен 2019, 19:32
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
т.е. вы предлагайте строить туннель в туннеле, причём более новый протокол пропускать через более старый...

не проще просто иметь канал связи с jumbo frame и нативно использовать VxLAN без сторонних обвёрток....


17 сен 2019, 19:46
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
root99 писал(а):
т.е. вы предлагайте строить туннель в туннеле, причём более новый протокол пропускать через более старый...

Не обязательно. GRE/IPSec это просто наиболее общий случай.

Выше я приводил пример IPSec VTI.
Там лишнего оверхеда нет и тоже делается IP MTU 1500.

Код:
interface Tunnel1
 description Test
 ip address 10.1.1.1 255.255.255.252
 ip mtu 1500
 ip tcp adjust-mss 1300
 qos pre-classify
 tunnel source GigabitEthernet0/1
 tunnel mode ipsec ipv4
 tunnel destination x.x.x.x
 tunnel protection ipsec profile S2S-VPN

_________________
Knowledge is Power


17 сен 2019, 19:50
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
как это нет для IPSec overhead - минимум 50-57 байт


17 сен 2019, 20:08
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
root99 писал(а):
как это нет для IPSec overhead - минимум 50-57 байт

Там ключевое слово было - "лишнего", т.е. GRE-шного.
Совсем без оверхеда VPN естественно не бывает.

root99 писал(а):
не проще просто иметь канал связи с jumbo frame и нативно использовать VxLAN без сторонних обвёрток....

Кто же спорит?!
Но это если он есть, или есть на него средства. :-)
А так можно хоть через паблик Инет гонять.

_________________
Knowledge is Power


17 сен 2019, 20:11
Профиль

Зарегистрирован: 08 июл 2019, 11:31
Сообщения: 6
Можете попробовать сбросить DF бит с помощью QoS или PBR (если поддерживаются аппаратно).


17 сен 2019, 20:47
Профиль

Зарегистрирован: 07 сен 2014, 02:54
Сообщения: 407
Откуда: Moscow
Еще можно попробовать включить

ip virtual-reassembly in

с обеих сторон туннеля.
Хотя это может и не работать, если сборка действительно только "виртуальная",
т.е. чисто для сбора информации о пакете (для NAT/FW).

Код:
interface Tunnel1
 description Test
 ip address 10.1.1.1 255.255.255.252
 ip mtu 1500
 ip virtual-reassembly in
 ip tcp adjust-mss 1300
 qos pre-classify
 tunnel source GigabitEthernet0/1
 tunnel mode ipsec ipv4
 tunnel destination x.x.x.x
 tunnel protection ipsec profile S2S-VPN

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

_________________
Knowledge is Power


18 сен 2019, 07:30
Профиль
Аватара пользователя

Зарегистрирован: 25 апр 2013, 12:36
Сообщения: 115
Откуда: Мск. обл.
Коллеги,
Снимать df бит - это не помогает. Мы это и так делаем, чтобы маршрутизатор фрагментировал.
ip virtual-reassembly in - это мы тоже пробовали делать, не помогает.

Silent_D спасибо за идею, попробуем проверить.


18 сен 2019, 11:01
Профиль

Зарегистрирован: 29 май 2017, 21:19
Сообщения: 1145
маловероятно что туннель эмулирующий работу L2 и которому нужен цельный фрейм размером 1550 байт пробросите через по сути такой же туннель ( иначе было бы куча примеров в инете по этому вопросу )


18 сен 2019, 11:25
Профиль
Показать сообщения за:  Поле сортировки  
Ответить на тему   [ Сообщений: 43 ]  На страницу 1, 2  След.

Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 24


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF.
Русская поддержка phpBB