dovecot Posted January 17, 2012 · Report post Всем привет! Имеется 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
Hawk128 Posted January 17, 2012 · Report post Возможно MTU? Share this post Link to post Share on other sites
s.lobanov Posted January 17, 2012 · Report post +1 к mtu. тунель подняли, а про увеличение размера фрейма забыли, скорее всего Share this post Link to post Share on other sites
dovecot Posted January 17, 2012 · Report post Сразу была такая мысль, но: размер фрейма от конечного устройства <=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
s.lobanov Posted January 17, 2012 · Report post Т.е. пинги нужных размером с DF-битом у вас нормально проходят? Тут ведь дело такое, где-нибудь в одном месте закралось маленькое mtu и будет ситуация как раз как у вас. Share this post Link to post Share on other sites
dovecot Posted January 17, 2012 · Report post Пинги с одного сервера на другой: #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
nnm Posted January 17, 2012 · Report post Сразу была такая мысль, но: размер фрейма от конечного устройства <=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
dovecot Posted January 17, 2012 · Report post Вы правы, так оно и получается... Share this post Link to post Share on other sites
config Posted January 17, 2012 · Report post Сразу была такая мысль, но: размер фрейма от конечного устройства <=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
config Posted January 17, 2012 · Report post Пинги с одного сервера на другой: #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
dovecot Posted January 17, 2012 · Report post Я так понимаю, лучше в ядре на всех интерфейсах включить 9216 и не иметь головной боли в будущем. Share this post Link to post Share on other sites
s.lobanov Posted January 17, 2012 · Report post Я так понимаю, лучше в ядре на всех интерфейсах включить 9216 и не иметь головной боли в будущем. Главное, чтоб control plane не начал генерить большие PDU, а то видел я такой случай, когда bgp-апдейты не пролезали из-за того, что на интерфейсе mtu выкрутили больше, чем на транзитном железе. Share this post Link to post Share on other sites
dovecot Posted January 18, 2012 · Report post Что было сделано: значение 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
YuryD Posted January 18, 2012 · Report post Повторюсь, что клиент включается не непосредственно в 6509, а в 3750, у него на интерфейсах MTU - 1504 (обычный тегированный траффик). У меня на 3750 почему-то 1508 :) Share this post Link to post Share on other sites
nnm Posted January 18, 2012 (edited) · Report post У вас что тут 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 January 18, 2012 by nnm Share this post Link to post Share on other sites
dovecot Posted January 18, 2012 (edited) · Report post На интерфейсах между 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 January 18, 2012 by dovecot Share this post Link to post Share on other sites
dovecot Posted January 18, 2012 · Report post Всем спасибо! Проблема решилась установкой MTU 9000 байт на всех внутренних интерфейсах (физика и логика) всех устройств MPLS ядра, а НЕ ТОЛЬКО на тех, через которые проходит траффик туннеля EoMPLS. Почему именно так - сейчас трудно сказать, но стало работать нормально. Share this post Link to post Share on other sites
