Jump to content
Калькуляторы

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

#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 работает замечательно.

Share this post


Link to post
Share on other sites

Сразу была такая мысль, но: размер фрейма от конечного устройства <=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 байта.

Share this post


Link to post
Share on other sites

Сразу была такая мысль, но: размер фрейма от конечного устройства <=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). ????????

Share this post


Link to post
Share on other sites

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

#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 если исползаете .

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Что было сделано: значение 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 (обычный тегированный траффик).

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

У вас что тут 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] Проходит?
Edited by nnm

Share this post


Link to post
Share on other sites

На интерфейсах между 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

Edited by dovecot

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this