dovecot Опубликовано 17 января, 2012 Всем привет! Имеется 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 Мистика какая-то))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 17 января, 2012 Возможно MTU? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 января, 2012 +1 к mtu. тунель подняли, а про увеличение размера фрейма забыли, скорее всего Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 17 января, 2012 MTU. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dovecot Опубликовано 17 января, 2012 Сразу была такая мысль, но: размер фрейма от конечного устройства <=1500 байт, + транспортная MPLS метка + MPLS VPN метка = итого 1508 байт. В тестовом MPLS облаке значения MTU на интерфейсах P маршрутизаторов (для теста) - 1520 байт, значения MTU на интерфейсах PE маршрутизаторов (смотрящих в сторону Р) - 1520 байт, значения MTU на интерфейсах (транковых) PE маршрутизаторов (смотрящих в сторону клиента) - 1504 байт. На сколько я понимаю проблем быть не должно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 января, 2012 Т.е. пинги нужных размером с DF-битом у вас нормально проходят? Тут ведь дело такое, где-нибудь в одном месте закралось маленькое mtu и будет ситуация как раз как у вас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dovecot Опубликовано 17 января, 2012 Пинги с одного сервера на другой: #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 работает замечательно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 17 января, 2012 Сразу была такая мысль, но: размер фрейма от конечного устройства <=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 байта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dovecot Опубликовано 17 января, 2012 Вы правы, так оно и получается... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 17 января, 2012 Сразу была такая мысль, но: размер фрейма от конечного устройства <=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). ???????? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 17 января, 2012 Пинги с одного сервера на другой: #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 если исползаете . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dovecot Опубликовано 17 января, 2012 Я так понимаю, лучше в ядре на всех интерфейсах включить 9216 и не иметь головной боли в будущем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 17 января, 2012 Я так понимаю, лучше в ядре на всех интерфейсах включить 9216 и не иметь головной боли в будущем. Главное, чтоб control plane не начал генерить большие PDU, а то видел я такой случай, когда bgp-апдейты не пролезали из-за того, что на интерфейсе mtu выкрутили больше, чем на транзитном железе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dovecot Опубликовано 18 января, 2012 Что было сделано: значение 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 (обычный тегированный траффик). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 18 января, 2012 Повторюсь, что клиент включается не непосредственно в 6509, а в 3750, у него на интерфейсах MTU - 1504 (обычный тегированный траффик). У меня на 3750 почему-то 1508 :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 18 января, 2012 (изменено) У вас что тут 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] Проходит? Изменено 18 января, 2012 пользователем nnm Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dovecot Опубликовано 18 января, 2012 (изменено) На интерфейсах между 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 Изменено 18 января, 2012 пользователем dovecot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dovecot Опубликовано 18 января, 2012 Всем спасибо! Проблема решилась установкой MTU 9000 байт на всех внутренних интерфейсах (физика и логика) всех устройств MPLS ядра, а НЕ ТОЛЬКО на тех, через которые проходит траффик туннеля EoMPLS. Почему именно так - сейчас трудно сказать, но стало работать нормально. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...