nixp.ru v3.0

25 апреля 2024,
четверг,
07:33:07 MSK

junkware написал 20 ноября 2007 года в 00:36 (1252 просмотра) Ведет себя неопределенно; открыл 1 тему в форуме, оставил 2 комментария на сайте.

Имеется сервер с pptpd и pppoed.

Copyright (c) 1992-2007 The FreeBSD Project.

Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994

The Regents of the University of California. All rights reserved.

FreeBSD is a registered trademark of The FreeBSD Foundation.

FreeBSD 7.0-BETA2 #0: Fri Nov 16 10:49:31 EET 2007

user@vpn.host.ru:/usr/obj/usr/src/sys/VPN

Timecounter «i8254» frequency 1193182 Hz quality 0

CPU: Intel(R) Xeon(R) CPU E5310 @ 1.60GHz (1595.93-MHz K8-class CPU)

Origin = «GenuineIntel» Id = 0×6f7 Stepping = 7

Features=0xbfebfbff

Features2=0×4e33d

AMD Features=0×20100800

AMD Features2=0×1

Cores per package: 4

usable memory = 1065545728 (1016 MB)

avail memory = 1027014656 (979 MB)

ACPI APIC Table:

FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

cpu0 (BSP): APIC ID: 0

cpu1 (AP): APIC ID: 1

cpu2 (AP): APIC ID: 2

cpu3 (AP): APIC ID: 3

bge0: flags=8843 metric 0 mtu 1500

options=9b

ether 00:xx:xx:xx:xx:xx

media: Ethernet autoselect (100baseTX )

status: active

vlan100: flags=8843 metric 0 mtu 1500

options=3

ether 00:уу:уу:уу:уу:уу

inet 123.123.123.69 netmask 0xfffffff8 broadcast 123.123.123.71

media: Ethernet autoselect (100baseTX )

status: active

vlan: 100 parent interface: bge0

pppoed слушает остальные vlan’ы и там проблем нет.

pptpd слушает vlan100 (он внешний + к нему и подключаются пользователи)

пользователей несколько сотен.

junkware

В 80% случаев соединение проходит нормально, в 20 — на этапе подключения возникают ошибки (Windows трактовка) :

800 — практически сразу (в самом начале)

629 — в конце = на этапе проверки сетевых протоколов

Вот как это примерно выглядит:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

629 ошибка

20:49:39.339145 IP vpn > 192.168.131.8: GREv1, call 2188, seq 24, ack 17, length 40: IPCP, Conf-Ack (0×02), id 10, length 24

20:49:39.339158 IP vpn > 192.168.131.8: GREv1, call 2188, seq 25, length 18: IPCP, Term-Request (0×05), id 3, length 6

20:49:39.339174 IP vpn > 192.168.131.8: GREv1, call 2188, seq 26, length 56: LCP, Ident (0×0c), id 7, length 42

20:49:39.411743 IP 192.168.131.8 > vpn: GREv1, call 49408, ack 26, no-payload, length 12

20:49:39.414958 IP 192.168.131.8 > vpn: GREv1, call 49408, seq 18, length 53: IP 123.123.123.53 > IGMP.MCAST.NET: [|igmp]

20:49:39.442733 IP 192.168.131.8 > vpn: GREv1, call 49408, seq 19, length 341: IP 123.123.123.53 > 255.255.255.255: [|udp]

20:49:39.451852 IP 192.168.131.8 > vpn: GREv1, call 49408, seq 20, length 18: IPCP, Term-Ack (0×06), id 3, length 6

20:49:39.452858 IP vpn > 192.168.131.8: GREv1, call 2188, seq 27, ack 20, length 24: LCP, Term-Request (0×05), id 3, length 6

20:49:39.456240 IP 192.168.131.8.2188 > vpn.pptp: P 373:389(16) ack 189 win 65347: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0) [|pptp]

20:49:39.456311 IP vpn.pptp > 192.168.131.8.2188: F 189:189(0) ack 389 win 65535

20:49:39.464025 IP 192.168.131.8.2188 > vpn.pptp: F 389:389(0) ack 190 win 65347

20:49:39.464050 IP vpn.pptp > 192.168.131.8.2188: . ack 390 win 65534

XXXXXXX—тут дисконект

Нормальное соединение

20:48:09.592272 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 16, ack 21, length 28: IPCP, Conf-Ack (0×02), id 2, length 12

20:48:09.611547 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 17, ack 23, length 40: IPCP, Conf-Request (0×01), id 10, length 24

20:48:09.623383 IP vpn > 192.168.131.8: GREv1, call 2145, seq 24, ack 17, length 40: IPCP, Conf-Ack (0×02), id 10, length 24

20:48:09.665972 IP 192.168.131.8 > vpn: GREv1, call 47872, ack 24, no-payload, length 12

20:48:09.721225 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 18, length 53: IP 123.123.123.228 > IGMP.MCAST.NET: [|igmp]

20:48:09.771601 IP vpn > 192.168.131.8: GREv1, call 2145, ack 18, no-payload, length 12

20:48:09.804380 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 19, length 341: IP 123.123.123.228 > 255.255.255.255: [|udp]

20:48:09.809781 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 20, length 174: IP 123.123.123.228 > 239.255.255.250: [|udp]

20:48:09.860637 IP vpn > 192.168.131.8: GREv1, call 2145, ack 20, no-payload, length 12

20:48:10.647033 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 21, length 53: IP 123.123.123.228 > IGMP.MCAST.NET: [|igmp]

20:48:10.677224 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 22, length 83: IP 123.123.123.228 > irc.host.ru: [|udp]

20:48:10.686758 IP vpn > 192.168.131.8: GREv1, call 2145, seq 25, ack 22, length 322: IP [|ip]

20:48:10.703409 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 23, ack 25, length 65: IP [|ip]

20:48:10.753638 IP vpn > 192.168.131.8: GREv1, call 2145, ack 23, no-payload, length 12

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

800 ошибка

17:01:36.512238 IP 10.7.0.2.gandalf-lm > vpn.pptp: S 886674397:886674397(0) win 65535

17:01:36.512268 IP vpn.pptp > 10.7.0.2.gandalf-lm: S 3727705929:3727705929(0) ack 886674398 win 65535

17:01:36.526061 IP 10.7.0.2.gandalf-lm > vpn.pptp: P 1:157(156) ack 1 win 65535: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) [|pptp]

17:01:36.527748 IP vpn.pptp > 10.7.0.2.gandalf-lm: F 1:1(0) ack 157 win 65535

17:01:36.539267 IP 10.7.0.2.gandalf-lm > vpn.pptp: F 157:157(0) ack 2 win 65535

17:01:36.539287 IP vpn.pptp > 10.7.0.2.gandalf-lm: . ack 158 win 65534

XXXXXXX—тут дисконект

Нормальное соединение

17:02:04.560230 IP 10.7.0.2.blueberry-lm > vpn.pptp: S 2054453977:2054453977(0) win 65535

17:02:04.560258 IP vpn.pptp > 10.7.0.2.blueberry-lm: S 3856560329:3856560329(0) ack 2054453978 win 65535

17:02:04.573731 IP 10.7.0.2.blueberry-lm > vpn.pptp: P 1:157(156) ack 1 win 65535: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) [|pptp]

17:02:04.575561 IP vpn.pptp > 10.7.0.2.blueberry-lm: P 1:157(156) ack 157 win 65535: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) [|pptp]

17:02:04.591256 IP 10.7.0.2.blueberry-lm > vpn.pptp: P 157:325(168) ack 157 win 65379: pptp CTRL_MSGTYPE=OCRQ CALL_ID(0) [|pptp]

17:02:04.592095 IP vpn.pptp > 10.7.0.2.blueberry-lm: P 157:189(32) ack 325 win 65535: pptp CTRL_MSGTYPE=OCRP CALL_ID(14720) [|pptp]

17:02:04.607229 IP 10.7.0.2.blueberry-lm > vpn.pptp: P 325:349(24) ack 189 win 65347: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(14720) [|pptp]

17:02:04.613105 IP 10.7.0.2 > vpn: GREv1, call 14720, seq 0, length 37: LCP, Conf-Request (0×01), id 0, length 23

17:02:04.663761 IP vpn > 10.7.0.2: GREv1, call 0, ack 0, no-payload, length 12

17:02:04.702037 IP vpn > 10.7.0.2: GREv1, call 0, seq 0, length 53: LCP, Conf-Request (0×01), id 1, length 39

17:02:04.702047 IP vpn > 10.7.0.2: GREv1, call 0, seq 1, length 23: LCP, Conf-Reject (0×04), id 0, length 9

17:02:04.702056 IP vpn > 10.7.0.2: GREv1, call 0, seq 2, length 56: LCP, Ident (0×0c), id 0, length 42

17:02:04.706733 IP vpn.pptp > 10.7.0.2.blueberry-lm: . ack 349 win 65535

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

в логе проскакивают ошибки (может они и не имеют отношения к проблеме)

Nov 19 22:15:01 vpn pptpd[19800]: GRE: read(fd=7,buffer=510be0,len=8196) from PTY failed: status = 0 error = No error

Nov 19 22:15:01 vpn pptpd[19800]: CTRL: PTY read or GRE write failed (pty,gre)=(7,6)

Nov 19 22:15:07 vpn pptpd[20051]: GRE: read(fd=7,buffer=510be0,len=8196) from PTY failed: status = 0 error = No error

Nov 19 22:15:07 vpn pptpd[20051]: CTRL: PTY read or GRE write failed (pty,gre)=(7,6)

сервер особо не загружен — ресурсов хватает

на bge0 траффик 50% в пике.

Пул ip достаточно большой, максимальное количество соединений (connections в pptpd.conf) тоже.

увеличил также

#define CONNECTIONS_DEFAULT

#define MAX_CALLS

но картина таже

В чем причина, и какие есть варианты решения данной проблемы?

junkware

Причина как оказалось в mtu/mru.

Но всеравно окончательного понимания нет — и следовательно оптимально настроить не получается.

Просто выставил в настройках демонов 1400 — стало лучше, но всеравно появляются ошибки.

Слишком низкий MTU будет неэфективен для канала, слишком высокий будет вызывать лаги.

В данном случае MTU есть у

- Ethernet он фиксирован = 1500 (+ там есть VLAN_MTU, который насколько я понял передается дочерним VLAN’ам)

- VLAN’а на этом интерфейсе

- демоноа pptpd

- демона pppoed

- настройках ppp для pptp

- настройках ppp для pppoe

По идее у второго должно быть меньше чем у первого, у последних четырех меньше чем у второго?

Объясните как их подобрать для оптимальной работы по ADSL?

Последние комментарии

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.