LINUX.ORG.RU
Форум — Admin  

XEN Short packet

 ,


0

2

Xen 4.0 debian 6.0
Создал гостя для роутинга.
Пакеты ходят, но при подключении к домену идет задержка и станция не может зайти в домен.
tcpdump показал, что проблеммы с 445 портом:
WARNING: Short packet. Try increasing the snap length by ...
Если роутинг делаю не на xen все работает!

★★
← Сохранение настроек сети wi-fi в Slackware 13.37
UnKnown can't find ya.ru: Query refused →

подозреваю речь про то, что надо было ключ -s0 использовать, если снимал дамп посредством tcpdump

zolden ★★★★★
()
Ответ на: комментарий от zolden

не вопрос... iptables чист, все разрешено кусок tcpdump: 

09:30:06.953581 IP (tos 0x0, ttl 127, id 12720, offset 0, flags [none], proto TCP (6), length 79)
    10.0.1.1.1347 > 192.168.10.251.445: Flags [P.], seq 3361:3400, ack 1140, win 63709, length 39WARNING: Short packet. Try increasing the snap length by 3
SMB PACKET: SMBtdis (REQUEST)

09:30:06.954198 IP (tos 0x0, ttl 128, id 31103, offset 0, flags [DF], proto TCP (6), length 79)
    192.168.10.251.445 > 10.0.1.1.1347: Flags [P.], seq 1140:1179, ack 3400, win 63798, length 39WARNING: Short packet. Try increasing the snap length by 3
SMB PACKET: SMBtdis (REPLY)
станция 10.0.1.1, сервер 192.168.10.251

само-сабой на domU: 

%# sysctl net.bridge.bridge-nf-filter-vlan-tagged=0
%# sysctl net.bridge.bridge-nf-call-ip6tables=0
%# sysctl net.bridge.bridge-nf-call-iptables=0
%# sysctl net.bridge.bridge-nf-call-arptables=0
DomU->DomX интерфейс в режиме bridge

lioncub ★★
() автор топика
Ответ на: комментарий от zolden

c -s0 тоже косяки, как будто пакеты рвутся...: 

09:58:06.639842 IP (tos 0x0, ttl 128, id 25171, offset 0, flags [DF], proto TCP (6), length 170)
    192.168.10.251.445 > 10.0.1.1.1213: Flags [P.], cksum 0x9f00 (correct), seq 1640:1770, ack 5532, win 64152, length 130SMB PACKET: SMBtrans2 (REPLY)

09:58:06.654968 IP (tos 0x0, ttl 64, id 54744, offset 0, flags [DF], proto TCP (6), length 150)
    192.168.10.10.445 > 10.0.1.1.1225: Flags [P.], cksum 0xd63b (incorrect -> 0x548f), seq 392:502, ack 726, win 8576, length 110SMB PACKET: SMBsesssetupX (REPLY)

09:58:06.655980 IP (tos 0x0, ttl 127, id 2923, offset 0, flags [DF], proto TCP (6), length 132)
    10.0.1.1.1225 > 192.168.10.10.445: Flags [P.], cksum 0x66f1 (correct), seq 726:818, ack 502, win 63739, length 92SMB PACKET: SMBtconX (REQUEST)

09:58:06.661763 IP (tos 0x0, ttl 64, id 54745, offset 0, flags [DF], proto TCP (6), length 106)
    192.168.10.10.445 > 10.0.1.1.1225: Flags [P.], cksum 0xd60f (incorrect -> 0x9278), seq 502:568, ack 818, win 8576, length 66SMB PACKET: SMBtconX (REPLY)

09:58:06.624484 IP (tos 0x0, ttl 127, id 2908, offset 0, flags [none], proto TCP (6), length 576)
    10.0.1.1.1213 > 192.168.10.251.445: Flags [.], cksum 0x80f2 (correct), seq 3924:4460, ack 609, win 64240, length 536SMB-over-TCP packet:(raw data or continuation?)

09:58:06.624493 IP (tos 0x0, ttl 127, id 2909, offset 0, flags [none], proto TCP (6), length 284)
    10.0.1.1.1213 > 192.168.10.251.445: Flags [P.], cksum 0x8e21 (correct), seq 4460:4704, ack 609, win 64240, length 244SMB-over-TCP packet:(raw data or continuation?)

10:05:16.214756 IP (tos 0x0, ttl 127, id 3099, offset 0, flags [DF], proto TCP (6), length 222)
    10.0.1.1.1228 > 192.168.10.251.139: Flags [P.], cksum 0xb87d (correct), seq 1670:1852, ack 214, win 64027, length 182 NBT Session Packet: Unknown packet type 0xF1Data: (181 bytes)
[000] D1 D3 5D 9B A4 E5 06 3A  14 35 39 08 B2 72 E9 8A  \0xd1\0xd3]\0x9b\0xa4\0xe5\0x06: \0x1459\0x08\0xb2r\0xe9\0x8a
[010] EA 68 E3 8D 38 4E F3 B7  60 9F 5F B6 FA 59 01 B8  \0xeah\0xe3\0x8d8N\0xf3\0xb7 `\0x9f_\0xb6\0xfaY\0x01\0xb8
[020] 68 4B BF F2 C7 FB 97 6E  20 7A D0 99 BF A4 D5 D0  hK\0xbf\0xf2\0xc7\0xfb\0x97n  z\0xd0\0x99\0xbf\0xa4\0xd5\0xd0
[030] 61 C7 33 1D AC FB 00 C3  31 1D E5 2E B5 F3 1D 7C  a\0xc73\0x1d\0xac\0xfb\0x00\0xc3 1\0x1d\0xe5.\0xb5\0xf3\0x1d|
[040] FD 4D 28 FD C3 33 CA 61  58 65 C7 3C 35 80 00 57  \0xfdM(\0xfd\0xc33\0xcaa Xe\0xc7<5\0x80\0x00W
[050] 00 69 00 6E 00 64 00 6F  00 77 00 73 00 20 00 32  \0x00i\0x00n\0x00d\0x00o \0x00w\0x00s\0x00 \0x002
[060] 00 30 00 30 00 32 00 20  00 53 00 65 00 72 00 76  \0x000\0x000\0x002\0x00  \0x00S\0x00e\0x00r\0x00v
[070] 00 69 00 63 00 65 00 20  00 50 00 61 00 63 00 6B  \0x00i\0x00c\0x00e\0x00  \0x00P\0x00a\0x00c\0x00k
[080] 00 20 00 33 00 20 00 32  00 36 00 30 00 30 00 00  \0x00 \0x003\0x00 \0x002 \0x006\0x000\0x000\0x00\0x00
[090] 00 57 00 69 00 6E 00 64  00 6F 00 77 00 73 00 20  \0x00W\0x00i\0x00n\0x00d \0x00o\0x00w\0x00s\0x00 
[0A0] 00 32 00 30 00 30 00 32  00 20 00 35 00 2E 00 31  \0x002\0x000\0x000\0x002 \0x00 \0x005\0x00.\0x001
[0B0] 00 00 00 00 00                                    \0x00\0x00\0x00\0x00\0x00

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

Предупреждение про длину - это всего лишь предупреждение, что дефолтных 64 байт не хватает для разбора пакета.
К реальной проблеме это отношения никакого не имеет.
Сами можете видеть, что во втором логе это предупреждение пропало.
Я честно говоря так и не понял, что у вас за топология, что значит роутинг в данном контексте и что там за домен.
Также, я бы предпочёл анализ дампа в wireshark, в голой консоли это слишком трудоёмко.
Попробуйте дать больше данных, либо подождём телепатов

zolden ★★★★★
()
Ответ на: комментарий от zolden

Имеем сервер Xen 4.0 на debian 6.0, на нем 2 гостевые системы, linux (для маршрутизации) и windows в качестве AD.
Все клиентские машины введены в AD домен.
На данном примере при включении клиентской машины XP 10.0.1.1 она обращается к домену 192.168.10.251, через linux машину (10.0.1.254, 192.168.10.1) и получается зависание клиентской машины (грешу на передачу пакетов).
Если в этой схеме маршрутизатор вынести на отдельныю тачку, то все работает прекрасно.
Поэтому затык где-то в XEN. Либо рвет некторые пакеты, либо «проглатывает» их....
Кстати пинг нормально ходит между ними (без потерь).

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

Вариант в лоб: попробовать уменьшить MTU на винде

zolden ★★★★★
()
Ответ на: комментарий от lioncub

ставите дампы
на станции:
tcpdump -i интерфейс_в_сторону_домена host IP_домена -s0 -w station2domain.pcap -v
на домене
tcpdump -i интерфейс_в_сторону_станции host IP_станции -s0 -w domain2station -v

воспроизводите проблему, останавливаете дампы

ну или вайршарком вместо tcpdump

zolden ★★★★★
()

Дамп пока не смотрел. Какой mtu на интерфейсах гостевых операционок? Что будет, если у клиентской винды (которая должна заходить в домен) поставить в настройках ethernet-интерфейса MTU поменьше, допустим 1200?

Правильно ли я понял, что одна клиентская винда может пинговать другую клиентскую винду большими пакетами, но она же может пинговать Линукс только 1468 байтами?

mky ★★★★★
()
Ответ на: комментарий от mky

клиент xp может пинговать сервер 2008R2 пакетами только 1468
маршрутизатор, он же линукс, может пинговать сервер 2008R2 большими пакетами
выстовить mtu на виндовых машинах нет возможности... (не поддерживается сетевками)

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

В дампе 1.pcap постоянно дублируются пакеты, это так и должно быть?

Ещё, в tcp-сессиях винда переключается на MSS 536 байт, то есть большие пакеты не проходят и винда начинает работать маленькими, но не сразу http://support.microsoft.com/kb/136970/ru , в общем, копайте в сторону прохождения больших пакетов.

mky ★★★★★
()
Ответ на: комментарий от lioncub

Клиент может пинговать других клиентов большими пакетами?

не поддерживается сетевками

А если править реестр? И пока не нужно выставлять на всех, хотя бы на одной, чтобы проверить, как это повлияет.

mky ★★★★★
()
Ответ на: комментарий от mky

1.pcap постоянно дублируются пакеты

думается из-за неответа или не правильного ответа

в tcp-сессиях винда переключается на MSS 536 байт

про это более красиво написано тут http://sergey-s-betke.blogs.novgaro.ru/windows-xp/1400-bajt-enablepmtubhdetec...

не помогло!

чтобы проверить, как это повлияет

выствил в реестре клиента на интерфейсе MTU 1400

помогло! теперь надо в xen найти эти ограничения т.к. нет возможности всем исправить это значение в реестре (каждый интерфейс имеет свой id в реестре) + если маршрутизатор не на xen, то все работает!

lioncub ★★
() автор топика
Ответ на: комментарий от zolden

пока не спас: 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: peth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:c1:de:02:3f:f2 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:c1:de:02:3f:f3 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 0a:a1:8a:32:36:5d brd ff:ff:ff:ff:ff:ff
5: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN 
    link/ether 00:c1:de:02:3f:f2 brd ff:ff:ff:ff:ff:ff
6: vlanbr153: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
7: eth0.153@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
8: vlanbr200: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN 
    link/ether 26:e7:19:72:4c:58 brd ff:ff:ff:ff:ff:ff
9: eth0.200@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
10: vlanbr203: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN 
    link/ether 3a:53:11:39:64:ff brd ff:ff:ff:ff:ff:ff
11: eth0.203@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
12: vif1.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
13: vif1.1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
14: vif2.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
15: vif2.1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
16: tap2.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 7a:d7:41:57:33:6f brd ff:ff:ff:ff:ff:ff
17: tap2.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 0a:a1:8a:32:36:5d brd ff:ff:ff:ff:ff:ff
18: vif3.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
19: vif3.1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
20: vif4.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
21: vif4.1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
22: vif5.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
23: tap5.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 7a:8f:f8:62:94:be brd ff:ff:ff:ff:ff:ff
24: tap5.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 2a:5c:18:9d:bc:5e brd ff:ff:ff:ff:ff:ff
25: vif5.1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
29: vif7.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
30: vif7.1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
31: vif7.2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
32: tap7.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 46:27:95:3d:6a:55 brd ff:ff:ff:ff:ff:ff
33: tap7.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 26:e7:19:72:4c:58 brd ff:ff:ff:ff:ff:ff
34: tap7.2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 3a:53:11:39:64:ff brd ff:ff:ff:ff:ff:ff
35: tap7.3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether ca:9e:95:2c:00:4f brd ff:ff:ff:ff:ff:ff
36: vif7.3: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
47: vif10.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
48: vif10.1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
49: vif10.2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 32
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

eth0 в бридже... на гостевую систему

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

1.pcap постоянно дублируются пакеты

думается из-за неответа или не правильного ответа

Нет, я вот про что:

15:02:48.675467 IP 10.0.1.1.62135 > 192.168.10.41.53: 26940+ SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.dkb74.loc. (79)
15:02:48.675486 IP 10.0.1.1.62135 > 192.168.10.41.53: 26940+ SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.dkb74.loc. (79)
15:02:48.676328 IP 192.168.10.41.53 > 10.0.1.1.62135: 26940*- 1/1/2 SRV wispa.dkb74.loc.:389 0 100 (163)
15:02:48.678719 IP 10.0.1.1.53087 > 192.168.10.41.53: 50502+ SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.dkb74.loc. (79)
15:02:48.678744 IP 10.0.1.1.53087 > 192.168.10.41.53: 50502+ SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.dkb74.loc. (79)

15:02:45.982793 IP 10.0.1.1.62135 > 192.168.10.41.53: 26940+ SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.dkb74.loc. (79)
15:02:45.985712 IP 10.0.1.1.53087 > 192.168.10.41.53: 50502+ SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.dkb74.loc. (79)

Первый фрагмент из 1.pcap, второй из 251.pcap. Время у вас не синхронизированно, но дублирование пакетов налицо. Или это особенности работы wireshark под windows?

про это более красиво написано тут

Красиво, только лет на 15 позже оригинала :-)

не помогло!

Что не помогло? Это у вас уже работает, и tcp-сесии с тормозами, но работают. Я приводил это как аргумет того, что есть проблемы с передачей больших пакетов. tcp эти проблемы обходит, а другие протоколы (udp, icmp) страдают.

Сколько у вас сетевых интерфейсов в гостевом линуксе, тот, который (10.0.1.254, 192.168.10.1)?

mky ★★★★★
()
Ответ на: комментарий от lioncub

MTU 1400 — это вы накрутили?

Опишите подробно все интерфейсы, через которые идут рассматриваемые пакеты. А то у вас там и Xen, и bridge и ещё VLAN'ы.

mky ★★★★★
()
Ответ на: комментарий от mky

время немного расходится...согласен
вижу про большие пакеты... ищу косяк на xen... говорят в 4.1 исправили...но нужно на 4.0
и еще, не могу установить на xen пакеты больше 1500:

# ip link set dev eth0 mtu 2048
RTNETLINK answers: Invalid argument
# ip link set dev eth0 mtu 9000
RTNETLINK answers: Invalid argument
гость:
1. lo
2. 10.0.1.254 - eth0.11, tagged vlan на eth0
3. 192.168.10.1 - eth0
и еще 3 не используются...
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:3e:00:07:00 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:3e:00:07:01 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:16:3e:00:07:02 brd ff:ff:ff:ff:ff:ff
10: eth0.11@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:16:3e:00:07:00 brd ff:ff:ff:ff:ff:ff
11: eth0.15@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:16:3e:00:07:00 brd ff:ff:ff:ff:ff:ff

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

и еще, не могу установить на xen пакеты больше 1500:

Ethernet фрейм максимум 1518 байт может быть, так что в эту сторону не смотри

zolden ★★★★★
()
Ответ на: комментарий от lioncub

1400 я кручу тут верчу...
в xen делаю мостом eth0 (средствами xen, eth0 -> peth0 -> vif10.0) и отправляю гостю...

eth0		8000.00c1de023ff2	no		peth0
							tap2.0
							tap5.0
							tap7.0
							vif1.0
							vif10.0
							vif2.0
							vif3.0
							vif4.0
							vif5.0
							vif7.0
у гостя eth0 (192.168.10.1) и далее я в госте добавляю интерфейс eth0.11 (10.0.1.254)
все остальное к данной схеме не относится... там реально несколько серваков со своими сетями, которые нельзя трогать... от клиента (10.0.1.1) на 10.0.1.254 пакеты в 1500 доходят, а на 192.168.10.1 нет!

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

Ethernet фрейм максимум 1518 байт может быть, так что в эту сторону не смотри

а как же joombo frame в 9000?

lioncub ★★
() автор топика
Ответ на: комментарий от zolden

за железяки уверен....
jumbo frames - мне на данном этапе не нужны...
xen с debian'ом - их не держит у меня

lioncub ★★
() автор топика
Ответ на: комментарий от zolden

В случае тегированых 802.1q VLAN-ов максимальный размер 1522 байта, похоже это как раз случай ТС, он прокидывает в XEN тегированый vlan. И гугл обещает проблемы в таком случае.

mky ★★★★★
()
Ответ на: комментарий от mky

тут и без обещаний...
даже если я в xen создаю тегированный интерфейс и потом его прокидываю... ситуация аналогичная...

lioncub ★★
() автор топика
Ответ на: комментарий от lioncub

Думаю, стоит попробовать создать новую тему, а то заголовок этой не очень правильный. И там спросить, можно ли прокинуть тегированый vlan через bridge в Xen 4.0. Может, кто-нибудь что-то полезно и скажет.

Вот обсуждение этой проблемы http://xen.1045712.n5.nabble.com/Ethernet-MTU-td2493262.html

mky ★★★★★
()
Ответ на: комментарий от mky

ладно....

спасибо, за разбор... дальше думаю маршрутизатор выкинуть отдельно... все равно киску ждать, легче менять будет...

lioncub ★★
() автор топика

скорее всего ошибка в эмуляции сетевой карты, смени на другой тип или почини баг.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Сохранение настроек сети wi-fi в Slackware 13.37
Admin
UnKnown can't find ya.ru: Query refused →