Перейти к содержимому
Калькуляторы

CISCO EoMPLS мистика... очень странное поведение EoMPLS

Всем привет!

 

Имеется MPLS сеть. В двух точках (PE) осуществлено включение двух серверов. Тестируется сервис EoMPLS. Настройка порта включения имеет такой вид:

interface GigabitEthernet2/5.699
description #TEST EOMPLS#
encapsulation dot1Q 699
xconnect ***.***.8.28 699 encapsulation mpls
end

 

В качестве PE - Catalyst 6509 (S720-10G). Клиент включен не непосредственно в 6509, а в коммутатор доступа 3750, который транком подключается к 6509.

 

Устройства друг друга видят, как-бы все прекрасно, НО. Для тестирования скорости используется утилита iperf. В процессе тестирования она зависает (проблема точно не в ней). На одной и другом сервере настроен FTP сервер, НО скачивать файлы более (приблизительно) 1Кбайт не получается. В логпх сервера происходит подключения, проверка логина/пароля, но как только доходит до передачи данных - как черная дыра - ничего не передается. Сервера меняли, питались также качать с помощью SCP/wget/http - аналогично.

 

Тут тоже как-бы порядок

 

6509#show mpls l2transport vc 699

Local intf     Local circuit              Dest address    VC ID      Status
-------------  -------------------------- --------------- ---------- ----------
Gi2/5.699      Eth VLAN 699               ***.***.8.28    699        UP

 

Мистика какая-то)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно MTU?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

+1 к mtu. тунель подняли, а про увеличение размера фрейма забыли, скорее всего

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

MTU.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сразу была такая мысль, но: размер фрейма от конечного устройства <=1500 байт, + транспортная MPLS метка + MPLS VPN метка = итого 1508 байт.

В тестовом MPLS облаке значения MTU на интерфейсах P маршрутизаторов (для теста) - 1520 байт, значения MTU на интерфейсах PE маршрутизаторов (смотрящих в сторону Р) - 1520 байт, значения MTU на интерфейсах (транковых) PE маршрутизаторов (смотрящих в сторону клиента) - 1504 байт.

 

На сколько я понимаю проблем быть не должно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Т.е. пинги нужных размером с DF-битом у вас нормально проходят? Тут ведь дело такое, где-нибудь в одном месте закралось маленькое mtu и будет ситуация как раз как у вас.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пинги с одного сервера на другой:

#ping -D -s 1473 10.10.10.2
PING 10.10.10.2 (10.10.10.2): 1473 data bytes
ping: sendto: Message too long

 

при уменьшении размера - проходят, но мне не понятно почему именно такой маленький размер?

 

также, два PE, между которыми строиться туннель, соеденены напрямую друг с другом:

interface GigabitEthernet2/1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan ***
switchport mode trunk
mtu 1520
end

 

при этом, L3VPN работает замечательно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сразу была такая мысль, но: размер фрейма от конечного устройства <=1500 байт, + транспортная MPLS метка + MPLS VPN метка = итого 1508 байт.

В тестовом MPLS облаке значения MTU на интерфейсах P маршрутизаторов (для теста) - 1520 байт, значения MTU на интерфейсах PE маршрутизаторов (смотрящих в сторону Р) - 1520 байт, значения MTU на интерфейсах (транковых) PE маршрутизаторов (смотрящих в сторону клиента) - 1504 байт.

 

1500 байт это размер payload Ethernet фрейма. У Вас EoMPLS т.е. передается весь Ethernet фрейм. Будет 1500+6(DMAC)+6(SMAC)+2(Ethertype)+4(опционально Control Word)+2*4(MPLS)=1522 или 1526.

Еще при некоторых условиях может передаваться 802.1q заголовок еще +4 байта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сразу была такая мысль, но: размер фрейма от конечного устройства <=1500 байт, + транспортная MPLS метка + MPLS VPN метка = итого 1508 байт.

В тестовом MPLS облаке значения MTU на интерфейсах P маршрутизаторов (для теста) - 1520 байт, значения MTU на интерфейсах PE маршрутизаторов (смотрящих в сторону Р) - 1520 байт, значения MTU на интерфейсах (транковых) PE маршрутизаторов (смотрящих в сторону клиента) - 1504 байт.

 

1500 байт это размер payload Ethernet фрейма. У Вас EoMPLS т.е. передается весь Ethernet фрейм. Будет 1500+6(DMAC)+6(SMAC)+2(Ethertype)+4(опционально Control Word)+2*4(MPLS)=1522 или 1526.

Еще при некоторых условиях может передаваться 802.1q заголовок еще +4 байта.

У вас что тут Mac-in-mac (вроде 802.1ah) что вы прикинули сюда 6(DMAC)+6(SMAC)+2(Ethertype)+4(опционально Control Word). ????????

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пинги с одного сервера на другой:

#ping -D -s 1473 10.10.10.2
PING 10.10.10.2 (10.10.10.2): 1473 data bytes
ping: sendto: Message too long

 

при уменьшении размера - проходят, но мне не понятно почему именно такой маленький размер?

 

также, два PE, между которыми строиться туннель, соеденены напрямую друг с другом:

interface GigabitEthernet2/1
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan ***
switchport mode trunk
mtu 1520
end

 

при этом, L3VPN работает замечательно.

1473 + icmp(28) = уже 1501 ну и плюс MPLs ну и дальше MPLs VPN и MPLs TE если исползаете .

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я так понимаю, лучше в ядре на всех интерфейсах включить 9216 и не иметь головной боли в будущем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я так понимаю, лучше в ядре на всех интерфейсах включить 9216 и не иметь головной боли в будущем.

 

Главное, чтоб control plane не начал генерить большие PDU, а то видел я такой случай, когда bgp-апдейты не пролезали из-за того, что на интерфейсе mtu выкрутили больше, чем на транзитном железе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что было сделано: значение mtu на физических и логических интерфейсах было поднято до 9000 байт.

 

6509#show mpls l2transport vc 699 det
Local interface: Gi2/5.699 up, line protocol up, Eth VLAN 699 up
 Interworking type is Ethernet
 Destination address: ***.***.8.28, VC ID: 699, VC status: up
   Output interface: Vl104, imposed label stack {110}
   Preferred path: not configured
   Default path: active
   Next hop: ***.***.8.102
 Load Balance: none
 Flow Label: Disabled
 Create time: 01:22:56, last status change time: 01:22:56
 Signaling protocol: LDP, peer ***.***.8.28:0 up
   Targeted Hello: ***.***.8.27(LDP Id) -> ***.***.8.28, LDP is UP
   ....
   MPLS VC labels: local 107, remote 110
   Group ID: local 0, remote 0
   MTU: local 9000, remote 9000

 

***.***.8.27 и ***.***.8.28 - Loopback0 интерфейсы коробок.

***.***.8.101 - 102 - смотрящие друг на друга логические int vlan

 

На одном сервере включил tcpdump, на втором пускаю пинг, и вот что получаю:

[b]# ping -s 1470 10.10.10.1[/b]
............ 
[b]# tcpdump -vvv -i re1[/b]
tcpdump: listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes
07:59:03.221715 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1498)
   10.10.10.2 > 10.10.10.1: ICMP echo request, id 11151, seq 1, length 1478
07:59:03.221731 IP (tos 0x0, ttl 64, id 37655, offset 0, flags [DF], proto ICMP (1), length 1498, bad cksum 0 (->79f5)!)
   10.10.10.1 > 10.10.10.2: ICMP echo reply, id 11151, seq 1, length 1478
07:59:03.221779 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1498)
   10.10.10.2 > 10.10.10.1: ICMP echo request, id 11151, seq 1, length 1478
07:59:03.221790 IP (tos 0x0, ttl 64, id 37656, offset 0, flags [DF], proto ICMP (1), length 1498, bad cksum 0 (->79f4)!)

а так

 

[b]# ping -s 1480 10.10.10.1[/b]
...........
[b]# tcpdump -vvv -i re1[/b]
07:59:59.542402 IP (tos 0x0, ttl 64, id 43265, offset 1480, flags [none], proto ICMP (1), length 28)
   10.10.10.2 > 10.10.10.1: icmp
08:00:00.541899 IP (tos 0x0, ttl 64, id 43266, offset 1480, flags [none], proto ICMP (1), length 28)
   10.10.10.2 > 10.10.10.1: icmp
08:00:01.541977 IP (tos 0x0, ttl 64, id 43267, offset 1480, flags [none], proto ICMP (1), length 28)
   10.10.10.2 > 10.10.10.1: icmp

 

MTU даже на интерфейсах ключения клиентов Gi2/5.699 - 9000.

Повторюсь, что клиент включается не непосредственно в 6509, а в 3750, у него на интерфейсах MTU - 1504 (обычный тегированный траффик).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Повторюсь, что клиент включается не непосредственно в 6509, а в 3750, у него на интерфейсах MTU - 1504 (обычный тегированный траффик).

 

У меня на 3750 почему-то 1508 :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас что тут Mac-in-mac (вроде 802.1ah) что вы прикинули сюда 6(DMAC)+6(SMAC)+2(Ethertype)+4(опционально Control Word). ????????

 

В первом посте пишут, что EoMPLS. У Вас есть сомнения, что в EoMPLS передаются MAC инкапсулируемого фрейма?

 

Что было сделано: значение mtu на физических и логических интерфейсах было поднято до 9000 байт.

 

На интерфейсах между PE?

[b]# ping -s 1472 10.10.10.1[/b] Проходит?
Изменено пользователем nnm

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На интерфейсах между PE даже так работает:

6509#ping  ***.***.8.102 size 9000 df-bit
Type escape sequence to abort.
Sending 5, 9000-byte ICMP Echos to ***.***.8.102, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Изменено пользователем dovecot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем спасибо!

Проблема решилась установкой MTU 9000 байт на всех внутренних интерфейсах (физика и логика) всех устройств MPLS ядра, а НЕ ТОЛЬКО на тех, через которые проходит траффик туннеля EoMPLS. Почему именно так - сейчас трудно сказать, но стало работать нормально.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.