Anticisco http://www.anticisco.ru/forum/ |
|
Фрагментация и реасеблинг VXLAN http://www.anticisco.ru/forum/viewtopic.php?f=2&t=11103 |
Страница 1 из 2 |
Автор: | cosmonaft [ 17 сен 2019, 12:28 ] |
Заголовок сообщения: | Фрагментация и реасеблинг VXLAN |
Коллеги, добрый день! Подскажите есть ли оборудование(вендор любой), которое умеет делать реасеблинг фрагментированных пакетов VXLAN. Например мы пробовали тестировать на cisco NEXUS 9300. Они не умею делать реасеблинг. Это подтверждается cisco TAC. Есть ли у других вендоров коммутаторы или роутеры, которые умеют делать реасемблирование непосредственно сами. |
Автор: | root99 [ 17 сен 2019, 14:55 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Huawei CE6880EI умеет а собственно чего вы добиваетесь |
Автор: | cosmonaft [ 17 сен 2019, 16:49 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Хотим VXLAN трафик между сайтами через VPN гонять. Пакеты проходящие транзитом через маршрутизатор, маршрутизатор фрагментирует. Далее эти пакеты приходят на маршрутизатор на другой стороны, он их далее отправляет в сторону NEXUS. NEXUS эти пакеты дропает. |
Автор: | Silent_D [ 17 сен 2019, 16:57 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
cosmonaft писал(а): Пакеты проходящие транзитом через маршрутизатор, маршрутизатор фрагментирует.Далее эти пакеты приходят на маршрутизатор на другой стороны, он их далее отправляет в сторону NEXUS. А почему удаленный роутер их не восстанавливает? Можно попробовать завернуть их в GRE например. Внутри GRE поставить MTU с запасом, фрагментироваться будут GRE пакеты, но они по идее должны восстанавливаться на том конце, и на выходе вы получите исходные пакеты VXLAN (они UDP, насколько я помню). |
Автор: | root99 [ 17 сен 2019, 17:04 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
вы страдаете фигнёй для того чтобы VXLAN работал у вас на всём протяжении линии должно быть минимум 1550 МТУ а лучше 1600 - тем более вы хотите ещё внутри GRE то тогда наканьте ещё 24 байта, когда будут соблюдены физические величины МТУ то тогда вам не понадобится fragmentation and reassembly of VXLAN traffic - и всё будет работать из коробки на том же Nexus 93180YC-EX или FX |
Автор: | cosmonaft [ 17 сен 2019, 17:07 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Silent_D писал(а): cosmonaft писал(а): Пакеты проходящие транзитом через маршрутизатор, маршрутизатор фрагментирует.Далее эти пакеты приходят на маршрутизатор на другой стороны, он их далее отправляет в сторону NEXUS. А почему удаленный роутер их не восстанавливает? Можно попробовать завернуть их в GRE например. Внутри GRE поставить MTU с запасом, фрагментироваться будут GRE пакеты, но они по идее должны восстанавливаться на том конце, и на выходе вы получите исходные пакеты VXLAN (они UDP, насколько я помню). А собственно почему он их должен на втором маршрутизаторе восстанавливать? Мы используем mGRE. К сожалению это так не работает. Проверенно. |
Автор: | cosmonaft [ 17 сен 2019, 17:13 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
root99 писал(а): вы страдаете фигнёй для того чтобы VXLAN работал у вас на всём протяжении линии должно быть минимум 1550 МТУ а лучше 1600 - тем более вы хотите ещё внутри GRE то тогда наканьте ещё 24 байта Я это знаю. Я с вами согласен. Страдаем. Просто было интересно знать мнение специалистов. Тогда второй вопрос. Даже несколько. Зачем и почему Huawei делает такую фичу, как реассемблинг VXLAN на своих коммутаторах? Вы мне написали, что huawei поддерживает и я параллельно сам смог нагуглить только про huawei. Почему другие вендоры не делают этого? Получается, что для использования VXLAN необходимы каналы на которых можно увеличить mtu до 1600. |
Автор: | Silent_D [ 17 сен 2019, 17:15 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
cosmonaft писал(а): А собственно почему он их должен на втором маршрутизаторе восстанавливать? Если мы про GRE, то потому, что он на удаленном роутере терминируется. cosmonaft писал(а): Мы используем mGRE. К сожалению это так не работает. Проверенно А какой MTU у вас стоит на GRE? |
Автор: | root99 [ 17 сен 2019, 17:19 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
МТУ на канале в любом случ должен быть 1550-1600 - через обычный IP Transit вы не получите такой МТУ - только заказывать канал точка-точка но там уже можно получить 9000 байт другие вендоры не делают потому что это неоправданно нагружает дополнительно процессор, на Хуавей это работает на очень старших моделях - по цене которые превосходят цицку в несколько раз.... |
Автор: | cosmonaft [ 17 сен 2019, 17:22 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Silent_D писал(а): cosmonaft писал(а): А собственно почему он их должен на втором маршрутизаторе восстанавливать? Если мы про GRE, то потому, что он на удаленном роутере терминируется. cosmonaft писал(а): Мы используем mGRE. К сожалению это так не работает. Проверенно А какой MTU у вас стоит на GRE? 1400 |
Автор: | root99 [ 17 сен 2019, 17:25 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
для того чтобы VXLAN заработал на тех же Нексус 93180YC-EX or FX в любом случ нужно заказывать канал точка-точка с нужными характеристиками..., через обычный интернет Вам ничего не светит. |
Автор: | Silent_D [ 17 сен 2019, 17:37 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
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 будет грузить роутер, да оверхед, но это лучше, чем ничего. |
Автор: | root99 [ 17 сен 2019, 17:47 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
как вы можете на GRE выставить 1600 если ETH интерфейс вашего рутера и вашего аплинка имеет 1500 а максимум в лучшем случ 1518 На GRE максимум что можно выставить 1500 - 24 = 1476 это в стандарте... |
Автор: | Silent_D [ 17 сен 2019, 18:07 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
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 (см. выше еще раз). |
Автор: | root99 [ 17 сен 2019, 18:23 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Туннельный интерфейс имеет прямое отношение к физическому интерфейсу поверх которого он собирается ходить и соот. если стандартным МТУ является 1500 - то более 1476 ( или 1480 байт в режиме IP-IP ) на туннельном интерфейсе для туннельного транспорта не может быть... для VXLAN есть системные требования к МТУ - значение МТУ 1550 ( 1500 + VXLAN 50 байт ) не взято с потолка..., для того чтобы проходили такие фреймы нужно включать jumbo frame - а это платные услуги ( и работают в рамках ДЦ или каналах точка-точка ) |
Автор: | Silent_D [ 17 сен 2019, 19:00 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
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, но идея везде одна. |
Автор: | Silent_D [ 17 сен 2019, 19:32 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
root99 писал(а): для VXLAN есть системные требования к МТУ - значение МТУ 1550 ( 1500 + VXLAN 50 байт ) не взято с потолка..., для того чтобы проходили такие фреймы нужно включать jumbo frame - а это платные услуги ( и работают в рамках ДЦ или каналах точка-точка ) То, что вы говорите, возможно так и есть, на L2 уровне внутри свитчей. Но для доставки VXLAN фреймов между сайтами, они инкапсулируются в UDP. Все. Вот эти самые UDP нам нужно доставить на ту сторону через VPN, не испортив (не фрагментировав). С учетом оверхеда это как бы невозможно, но мы эту фрагментацию переносим на уровень обертки. GRE, IPSec VTI etc. Да, это будет жрать проц. ресурсы роутера на больших пакетах, но зато будет работать. Нужно это или нет такой ценой - решать каждому на месте. Введение в VXLAN https://habr.com/ru/post/344326/ |
Автор: | root99 [ 17 сен 2019, 19:46 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
т.е. вы предлагайте строить туннель в туннеле, причём более новый протокол пропускать через более старый... не проще просто иметь канал связи с jumbo frame и нативно использовать VxLAN без сторонних обвёрток.... |
Автор: | Silent_D [ 17 сен 2019, 19:50 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
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 |
Автор: | root99 [ 17 сен 2019, 20:08 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
как это нет для IPSec overhead - минимум 50-57 байт |
Автор: | Silent_D [ 17 сен 2019, 20:11 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
root99 писал(а): как это нет для IPSec overhead - минимум 50-57 байт Там ключевое слово было - "лишнего", т.е. GRE-шного. Совсем без оверхеда VPN естественно не бывает. root99 писал(а): не проще просто иметь канал связи с jumbo frame и нативно использовать VxLAN без сторонних обвёрток.... Кто же спорит?! Но это если он есть, или есть на него средства. А так можно хоть через паблик Инет гонять. |
Автор: | brat95 [ 17 сен 2019, 20:47 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Можете попробовать сбросить DF бит с помощью QoS или PBR (если поддерживаются аппаратно). |
Автор: | Silent_D [ 18 сен 2019, 07:30 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Еще можно попробовать включить 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. Но в общем то можно включить и то и то. |
Автор: | cosmonaft [ 18 сен 2019, 11:01 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
Коллеги, Снимать df бит - это не помогает. Мы это и так делаем, чтобы маршрутизатор фрагментировал. ip virtual-reassembly in - это мы тоже пробовали делать, не помогает. Silent_D спасибо за идею, попробуем проверить. |
Автор: | root99 [ 18 сен 2019, 11:25 ] |
Заголовок сообщения: | Re: Фрагментация и реасеблинг VXLAN |
маловероятно что туннель эмулирующий работу L2 и которому нужен цельный фрейм размером 1550 байт пробросите через по сути такой же туннель ( иначе было бы куча примеров в инете по этому вопросу ) |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |