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

Всем добрый день!

 

продолжаем тестировать и внедрять IPv6 )))

 

Биллингом выдается только префикс, хостовая часть исходя из конфигурации самого accel-ppp.

 

что касается работы при pppoe или ppptp вопросов нет, а вот при ipoe хотелось бы уточнить...

 

в разделе [ppp] есть параеметры которые задают какие адреса брать в хостовой части префикса

ipv6-intf-id=0:0:0:1

ipv6-peer-intf-id=0:0:0:2

ipv6-accept-peer-intf-id=0

 

При подключении по pppoe или pptp клиент получает в конце адреса 2 и тут все логично....

 

А вот при подключении по ipoe таких параметро нет.

И клиент получает все время 1й адрес и плюс то что он сам себе сгенерил из mac адреса.

 

Так вот, хотелось бы уточнить по какому принципу при ipoe выдается хостовая часть у клиента? и по какому принципу берется 1 ?

 

в логах при подключении по pppoe или pptp

ppp0: recv [DHCPv6 ******* {IA-Addr 2a00:ede0:1f01:101::2 *****

 

в логах при подключении по ipoe

eth1.1001.1101: recv [DHCPv6 ******* {IA-Addr 2a00:ede0:1f01:101::1 *****

 

а вот когда подключем роутер с поддержкой ipv6 к примеру mikrotik так в логах вообще показывает только делегированный префикс

eth1.1001.1101: recv [DHCPv6 ******* {IA-Prefix 2a00:ede0:1d01:1010::/60 ******

 

 

P.S. у клиента на ipoe все работае, но хочется понимать почему именно так )

Share this post


Link to post
Share on other sites

Всем привет.

в конфиге

[cli]
verbose=1
telnet=172.16.0.230:2000
tcp=172.16.0.230:2001
password=12345

 

telnet 172.16.0.230 2000 отрабатывает честно,

а вот

accel-cmd -H 172.16.0.230 show session

ничего не показывает. М.б. это изза пароля? но пароль некуда передавать для accel-cmd

 

И еще, планируется сделать pppoe концентратор, что нужно тюнить?

 

спасибо

Share this post


Link to post
Share on other sites

Всем добрый день!

 

продолжаем тестировать и внедрять IPv6 )))

 

Биллингом выдается только префикс, хостовая часть исходя из конфигурации самого accel-ppp.

 

что касается работы при pppoe или ppptp вопросов нет, а вот при ipoe хотелось бы уточнить...

 

в разделе [ppp] есть параеметры которые задают какие адреса брать в хостовой части префикса

ipv6-intf-id=0:0:0:1

ipv6-peer-intf-id=0:0:0:2

ipv6-accept-peer-intf-id=0

 

При подключении по pppoe или pptp клиент получает в конце адреса 2 и тут все логично....

 

А вот при подключении по ipoe таких параметро нет.

И клиент получает все время 1й адрес и плюс то что он сам себе сгенерил из mac адреса.

 

Так вот, хотелось бы уточнить по какому принципу при ipoe выдается хостовая часть у клиента? и по какому принципу берется 1 ?

 

в логах при подключении по pppoe или pptp

ppp0: recv [DHCPv6 ******* {IA-Addr 2a00:ede0:1f01:101::2 *****

 

в логах при подключении по ipoe

eth1.1001.1101: recv [DHCPv6 ******* {IA-Addr 2a00:ede0:1f01:101::1 *****

 

а вот когда подключем роутер с поддержкой ipv6 к примеру mikrotik так в логах вообще показывает только делегированный префикс

eth1.1001.1101: recv [DHCPv6 ******* {IA-Prefix 2a00:ede0:1d01:1010::/60 ******

 

 

P.S. у клиента на ipoe все работае, но хочется понимать почему именно так )

С IPv6 вы не должны мыслить категориями адресов, а должны мыслить категориями префиксов. Вас не должно сильно волновать какие адреса назначены на интерфейсах ppp и у клиента, т.к. в режиме бриджа клиент может использовать любой адрес из /64 префикса (или какой вы выдаете). Мы у себе отдаем с помощью RADIUS Framed-IPv6-Prefix (/64) и Delegated-IPv6-Prefix (/60). Я задавал выше вопрос по этому поводу, потом мы это реализовали. Всё работает. С IPoE не разбирался, но подозреваю, что все точно так же. Поэтому неважно, что у вас будет в хвостовой части IPv6 адреса клиента, т.к. по этому адресу вы не сможете идентифицировать трафик абонента. У нас вообще стоит ipv6-peer-intf-id=ipv4, но это чисто для удобства, а не для идентификации.

 

По поводу того, что с роутером отдается только Delegated префикс, есть предположение. Думается мне, что между роутером и NAS используется Link Scope адрес и маршрут для Delegated префикса прописан на него. Для понимания посмотрите ip -6 route на сервере с accel.

Edited by SokolovS

Share this post


Link to post
Share on other sites

а должны мыслить категориями префиксов

Все верно, радиусом передаются в accel именно префиксы для линковых /64 для делегировнных /60

 

но в случае pppoe и pptp для удобства было указано ipv6-peer-intf-id=0:0:0:2

по той же причине.... как Вы сказали

это чисто для удобства

этот адрес используется для диагностики...

 

А вот в случае ipoe этих параметров нет, и в хостовой части присутствует адрес у которого в конце 1 ну и еще то что он сам себе сгенерил из mac адреса.

 

Повторюсь, что все работает, но .... хотелось бы понимать этот адрес у которого 1 по какому принципу выдался, ну и как следствие можно ли его использовать для удобства при диагностики... Вопрос сейчас только в удобстве диагностики.

 

Думается мне, что между роутером и NAS используется Link Scope адрес

скорее всего, но я еще не смотрел, но при pppoe или pptp маршрут прописывался на линковый адрес

поэтому и обратил внимание.

Share this post


Link to post
Share on other sites

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

Если это адрес из Delegated префикса, то КМК вряд ли. Роутер может выдавать автоматом адреса в домашнюю сеть (или в интерфейс в случае IPoE) двумя способами:

1. SLAAC (IP, префикс, шлюз) + DHCPv6 (DNS, доп.маршруты, опции и.т.д)

2. DHCPv6

 

Т.е. контроля выделения адресов из Delegated префикса со стороны провайдера в любом случае нет. При использовании SLAAC вообще может использоваться "Privacy Extensions for SLAAC" https://tools.ietf.org/html/rfc4941 и адрес меняется постоянно и не зависит от аппаратного, хотя адрес основанный на аппаратном на интерфейсе может висеть, но он почему-то не используется при работе в сети, видимо имеет меньший приоритет. На моем домороутере так.

 

Если вы по адресу хотите идентифицировать тип подключения, то КМК это неправильно. Тип должен идентифицироваться по активным сессиям в биллинге, в которых должен быть поиск по любому IPv6-адресу.

 

Думаю лучше чтобы xeb прояснил принцип выделения адреса из Delegated префикса при использования IPoE. Тоже интересно.

Share this post


Link to post
Share on other sites

Если это адрес из Delegated префикса

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

 

А вот диагностировать до роутера клиента удобно бы было когда знаешь какой адрес линковый у клиента.

не используется при работе в сети, видимо имеет меньший приоритет

Да, но если его пинговать то он будет отвечать.

 

Думаю лучше чтобы xeb прояснил принцип выделения адреса

это да.. при pppoe и pptp все понятно, а в ipoe пока что только судя из результатов тестирования... )

Share this post


Link to post
Share on other sites

У кого accel-ppp как говорится годами работает без проблем (в качестве pppoe-сервера), можете сказать, какая версия accel-ppp, какая версия ядра и какой дистрибутив?

Share this post


Link to post
Share on other sites

У кого accel-ppp как говорится годами работает без проблем (в качестве pppoe-сервера), можете сказать, какая версия accel-ppp, какая версия ядра и какой дистрибутив?

 

Не годами, но полгода уже где-то.

 

accel-cmd 30cff41b56be0d4c3e407e8aa4de5b289eef2ab0

Linux pppoe 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u3 x86_64 GNU/Linux

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.9 (wheezy)
Release:        7.9
Codename:       wheezy

Share this post


Link to post
Share on other sites

Не годами, но полгода уже где-то.

 

А сетевой адаптер и конфигурация системы (железо) у вас какие?

 

Работало все сносно на CentOS 7 с парой патчей (те что исправляют падения связанные с PPPoE), поменяли сетевые 82576 на 82598EB, и начались падения раз в неделю.

 

[545444.673270] BUG: unable to handle kernel paging request at ffff88a005040200
[545444.673306] IP: [<ffffffff811c0e95>] kmem_cache_alloc+0x75/0x1d0
[545444.673335] PGD 0
[545444.673348] Oops: 0000 [#1] SMP
[545444.673367] Modules linked in: arc4 ppp_mppe act_police cls_u32 sch_ingress sch_tbf pptp gre pppoe pppox ppp_generic slhc 8021q garp stp mrp llc
iptable_nat nf_conn track_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat iptable_filter xt_TCPMSS iptable_mangle xt_CT nf_conntrack iptable_raw w83793 hwmon_vid
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec coretemp snd_hda_core iTCO_wdt
kvm iTCO_vendor_support snd_hwdep snd_seq snd_seq_device ipmi_ssif ppdev lpc_ich snd_pcm pcspkr mfd_

core sg ipmi_si snd_timer snd i2c_i801 ipmi_msghandler ioatdma parport_pc parport shpchp soundcore i7core_edac tpm_infineon edac_core
ip_tables ext4 mbcache jbd2 sd_mod crct10dif_generic crc_t10dif crct10dif_common syscopyarea sysfillrect
firewire_ohci sysimgblt i2c_algo_bit drm_kms_helper ata_generic pata_acpi
[545444.674383]  ttm firewire_core crc_itu_t serio_raw drm ata_piix libata crc32c_intel i2c_core ixgbe(OE) vxlan e1000e ip6_udp_tunnel udp_tunnel aacraid dca ptp pps_core
[545444.674783] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G           OE ------------   3.10.0-327.10.1.el7.dsip.x86_64 #1
[545444.675032] Hardware name: empty empty/S7010, BIOS 'V2.06  ' 03/31/2010
[545444.675162] task: ffff880139c55c00 ti: ffff880139c84000 task.ti: ffff880139c84000
[545444.675400] RIP: 0010:[<ffffffff811c0e95>]  [<ffffffff811c0e95>] kmem_cache_alloc+0x75/0x1d0
[545444.675641] RSP: 0018:ffff88023fc23ce8  EFLAGS: 00010286
[545444.675766] RAX: 0000000000000000 RBX: ffff8802302eab00 RCX: 000000010eb8edbe
[545444.676002] RDX: 000000010eb8edbd RSI: 0000000000000020 RDI: ffff88013b803700
[545444.676237] RBP: ffff88023fc23d18 R08: 00000000000175a0 R09: ffffffff81517e70
[545444.676472] R10: 000000000000006b R11: 0000000000000000 R12: ffff88a005040200
[545444.676706] R13: 0000000000000020 R14: ffff88013b803700 R15: ffff88013b803700
[545444.676942] FS:  0000000000000000(0000) GS:ffff88023fc20000(0000) knlGS:0000000000000000
[545444.677180] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[545444.677307] CR2: ffff88a005040200 CR3: 0000000237e63000 CR4: 00000000000007e0
[545444.677543] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[545444.677779] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[545444.678014] Stack:
[545444.678127]  ffff880237ea2040 ffff8802302eab00 0000000000000280 0000000000000280
[545444.678370]  0000000000000006 ffff880236bb1b60 ffff88023fc23d40 ffffffff81517e70
[545444.678614]  0000000000000280 ffff8802302eab00 0000000000000000 ffff88023fc23d60
[545444.678857] Call Trace:
[545444.678973]  <IRQ>

[545444.678982]
[545444.679100]  [<ffffffff81517e70>] build_skb+0x30/0x1d0
[545444.679222]  [<ffffffff8151a973>] __alloc_rx_skb+0x63/0xb0
[545444.679349]  [<ffffffff8151a9db>] __netdev_alloc_skb+0x1b/0x40
[545444.679492]  [<ffffffffa0104d8e>] ixgbe_clean_rx_irq+0xee/0xa50 [ixgbe]
[545444.679624]  [<ffffffff8152862f>] ? __napi_complete+0x1f/0x30
[545444.679756]  [<ffffffffa0106738>] ixgbe_poll+0x2d8/0x6d0 [ixgbe]
[545444.679886]  [<ffffffff8152b092>] net_rx_action+0x152/0x240
[545444.680015]  [<ffffffff81084aef>] __do_softirq+0xef/0x280
[545444.680144]  [<ffffffff8164735c>] call_softirq+0x1c/0x30
[545444.680277]  [<ffffffff81016fc5>] do_softirq+0x65/0xa0
[545444.680402]  [<ffffffff81084e85>] irq_exit+0x115/0x120
[545444.680529]  [<ffffffff81647ef8>] do_IRQ+0x58/0xf0
[545444.680660]  [<ffffffff8163d1ad>] common_interrupt+0x6d/0x6d
[545444.680786]  <EOI>
[545444.680794]
[545444.680914]  [<ffffffff81058e96>] ? native_safe_halt+0x6/0x10
[545444.681041]  [<ffffffff8101dbcf>] default_idle+0x1f/0xc0
[545444.681168]  [<ffffffff8101e4d6>] arch_cpu_idle+0x26/0x30
[545444.681297]  [<ffffffff810d62c5>] cpu_startup_entry+0x245/0x290
[545444.681427]  [<ffffffff810475fa>] start_secondary+0x1ba/0x230
[545444.681554] Code: ce 00 00 49 8b 50 08 4d 8b 20 49 8b 40 10 4d 85 e4 0f 84 1f 01 00 00 48 85 c0 0f 84 16 01 00 00 49 63 46 20
48 8d 4a 01 4d 8b 06 <49> 8b 1c 04 4c 89 e0 65 49 0f c7 08 0f 94 c0 84 c0 74 b9 49 63
[545444.682056] RIP  [<ffffffff811c0e95>] kmem_cache_alloc+0x75/0x1d0
[545444.682186]  RSP <ffff88023fc23ce8>
[545444.682305] CR2: ffff88a005040200

 

Причина всегда одинаковая, проблем с памятью нет. Драйвер ixgbe последний. По функции в которой ошибка очень похоже на одну проблему с SCTP, но он у нас не используется (даже модуль не загружен).

Edited by avb1987

Share this post


Link to post
Share on other sites

ethtool -i eth0
driver: igb
version: 5.0.5-k
firmware-version: 1.4.3
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

 

Два L5639

 

lshw -class network
 *-network:0
      description: Ethernet interface
      product: 82576 Gigabit Network Connection
      vendor: Intel Corporation
      physical id: 0
      bus info: pci@0000:01:00.0
      logical name: eth0
      version: 01
      serial: 
      size: 1Gbit/s
      capacity: 1Gbit/s
      width: 32 bits
      clock: 33MHz
      capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
      configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.0.5-k duplex=full firmware=1.4.3 latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s
      resources: irq:17 memory:fbde0000-fbdfffff memory:fbdc0000-fbddffff ioport:dc00(size=32) memory:fbd9c000-fbd9ffff memory:fbda0000-fbdbffff
 *-network:1
      description: Ethernet interface
      product: 82576 Gigabit Network Connection
      vendor: Intel Corporation
      physical id: 0.1
      bus info: pci@0000:01:00.1
      logical name: eth1
      version: 01
      serial: 
      size: 1Gbit/s
      capacity: 1Gbit/s
      width: 32 bits
      clock: 33MHz
      capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
      configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.0.5-k duplex=full firmware=1.4.3 latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s
      resources: irq:16 memory:fbd60000-fbd7ffff memory:fbd40000-fbd5ffff ioport:d880(size=32) memory:fbd1c000-fbd1ffff memory:fbd20000-fbd3ffff

Share this post


Link to post
Share on other sites

Здравствуйте, сложилась непонятная ситуация, до позавчера всё работало без сбоев. Теперь у одного клиента не подключается pptp при этом l2tp работает. в дебаге выдаёт следующее:

[2016-04-08 19:00:30.273] accel-ppp version 87ddec14232bec6d533a0bd337468a7e56de0b80

[2016-04-08 19:09:00.881] pptp: new connection from XXX.XXX.XXX.XXX

[2016-04-08 19:09:00.882] : : recv [PPTP Start-Ctrl-Conn-Request <Version 1> <Framing 1> <Bearer 1> <Max-Chan 0>]

[2016-04-08 19:09:00.884] : : send [PPTP Start-Ctrl-Conn-Reply <Version 1> <Result 1> <Error 0> <Framing 3> <Bearer 3> <Max-Chan 1>]

[2016-04-08 19:09:00.887] : : recv [PPTP Outgoing-Call-Request <Call-ID c09e> <Call-Serial 2> <Min-BPS 300> <Max-BPS 100000000> <Bearer 3> <Framing 3> <Window-Size 64> <Delay 0>]

[2016-04-08 19:09:00.887] : : send [PPTP Outgoing-Call-Reply <Call-ID 2b8b> <Peer-Call-ID c09e> <Result 1> <Error 0> <Cause 0> <Speed 100000000> <Window-Size 64> <Delay 0> <Channel 0>]

[2016-04-08 19:09:00.887] : : lcp_layer_init

[2016-04-08 19:09:00.887] : : auth_layer_init

[2016-04-08 19:09:00.888] : : ccp_layer_init

[2016-04-08 19:09:00.888] : : ipcp_layer_init

[2016-04-08 19:09:00.888] : : ipv6cp_layer_init

[2016-04-08 19:09:00.888] : : ppp establishing

[2016-04-08 19:09:00.889] : 1e84de89344e78d5: lcp_layer_start

[2016-04-08 19:09:00.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:00.894] : 1e84de89344e78d5: recv [PPTP Set-Link-Info]

[2016-04-08 19:09:03.889] : 1e84de89344e78d5: fsm timeout 9

[2016-04-08 19:09:03.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:06.889] : 1e84de89344e78d5: fsm timeout 8

[2016-04-08 19:09:06.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:09.889] : 1e84de89344e78d5: fsm timeout 7

[2016-04-08 19:09:09.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:12.889] : 1e84de89344e78d5: fsm timeout 6

[2016-04-08 19:09:12.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:15.889] : 1e84de89344e78d5: fsm timeout 5

[2016-04-08 19:09:15.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:18.889] : 1e84de89344e78d5: fsm timeout 4

[2016-04-08 19:09:18.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:21.889] : 1e84de89344e78d5: fsm timeout 3

[2016-04-08 19:09:21.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:24.889] : 1e84de89344e78d5: fsm timeout 2

[2016-04-08 19:09:24.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:27.889] : 1e84de89344e78d5: fsm timeout 1

[2016-04-08 19:09:27.889] : 1e84de89344e78d5: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1280> <magic 6b8b4567>]

[2016-04-08 19:09:30.889] : 1e84de89344e78d5: fsm timeout 0

[2016-04-08 19:09:30.889] : 1e84de89344e78d5: lcp_layer_finished

[2016-04-08 19:09:30.890] : 1e84de89344e78d5: terminate

[2016-04-08 19:09:30.890] : 1e84de89344e78d5: lcp_layer_finish

[2016-04-08 19:09:30.891] : 1e84de89344e78d5: send [PPTP Echo-Request <Identifier 327b23c6>]

[2016-04-08 19:09:30.900] : 1e84de89344e78d5: lcp_layer_free

[2016-04-08 19:09:30.900] : 1e84de89344e78d5: auth_layer_free

[2016-04-08 19:09:30.900] : 1e84de89344e78d5: ccp_layer_free

[2016-04-08 19:09:30.900] : 1e84de89344e78d5: ipcp_layer_free

[2016-04-08 19:09:30.900] : 1e84de89344e78d5: ipv6cp_layer_free

[2016-04-08 19:09:30.900] : 1e84de89344e78d5: pptp: ppp finished

[2016-04-08 19:09:30.900] : 1e84de89344e78d5: send [PPTP Call-Disconnect-Notify <Call-ID 9ec0> <Result 3> <Error 0> <Cause 0>]

[2016-04-08 19:09:30.901] : 1e84de89344e78d5: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>]

[2016-04-08 19:09:30.901] : 1e84de89344e78d5: recv [PPTP Echo-Reply <Identifier 327b23c6>]

[2016-04-08 19:09:31.101] : 1e84de89344e78d5: recv [PPTP Stop-Ctrl-Conn-Reply <Result 1> <Error 0>]

[2016-04-08 19:09:31.101] : 1e84de89344e78d5: pptp: disconnect

[2016-04-08 19:09:31.101] : 1e84de89344e78d5: disconnected

при этом остальные работают в штатном режиме, может кто сталкивался.

Share this post


Link to post
Share on other sites

поменяли сетевые 82576 на 82598EB, и начались падения раз в неделю.

Судя по логу у вас ixgbe или ядро глючат, accel то тут при чем.

Share this post


Link to post
Share on other sites

Возможно. Просто в каждой версии (ядра/драйвера/акцеля) получаются какие-то глюки. Хочется какой то стабильности.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Просто в каждой версии (ядра/драйвера/акцеля) получаются какие-то глюки

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

Share this post


Link to post
Share on other sites

Возможно. Просто в каждой версии (ядра/драйвера/акцеля) получаются какие-то глюки. Хочется какой то стабильности.

 

Так нафига вы обновляетесь? Если речь об уязвимостях ПО, то просто зафаервольте все локальные сервисы

Share this post


Link to post
Share on other sites

Так нафига вы обновляетесь? Если речь об уязвимостях ПО, то просто зафаервольте все локальные сервисы

 

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

Edited by avb1987

Share this post


Link to post
Share on other sites

Изначально была установлена CentOS 7, все пакеты из дистрибутива (кроме accel) - система вываливалась в панику при опускании сетевого интерфейса на котором запущено PPPoE. После ручного наложения патчей на ядро, паники стали реже (но все же случались), при этом пару раз было что сам accel вылетел по SIGABRT (без всяких ошибок в логах). Добавили патчей для PPPoE в ядро, заменили сетевую (т.к. уже нужно больше 1 гигабита) и поставили новую версию accel. Паники стали четко раз в неделю (с точностью до часа), по одной и той же причине.

 

Протестировали память - проблем не обнаружено. Сейчас поставили Debian Wheezy, уже пару дней полет нормальный, но это не показатель.

Edited by avb1987

Share this post


Link to post
Share on other sites

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

 

На другой машине стоит такая же сетевая (но это не PPPoE-сервер), аптайм уже несколько месяцев без единой проблемы. Может конечно экземпляр бракованный, но никаких других проблем кроме указанного зависания раз в неделю в работе сетевой не наблюдается.

Edited by avb1987

Share this post


Link to post
Share on other sites

Соберите нормальное ядро с kernel.org, 3.18.30 например. Дистрибутивное, покрытое мхом, на роутере не айс. Да и патчи ваши на новых ядрах вроде как не нужны, могут даже в них грабли быть.

Share this post


Link to post
Share on other sites

Соберите нормальное ядро с kernel.org, 3.18.30 например.

 

Если и на 3.2 будут похожие проблемы, наверное так и сделаем.

Некоторые высказывали мнение на этом форуме что ветка 3.2 наиболее стабильна в этом плане.

Edited by avb1987

Share this post


Link to post
Share on other sites

3.2 стабильная, но медленная. 3.10 и 3.14 ванильные очень стабильны

Share this post


Link to post
Share on other sites

3.2, 3.10 - работают уже по несколько месяцев без каких-либо вопросов... 3.4 - аптайм был пару лет до планового апдейта.

 

на 4.1.х (а вернее, 3.19 и старше - там немного добавили асинхронности в инит/шатдаун пппое туннелей) - были грабли, связанные с тем что и ядро (т.к. rp-pppoe шатдаун не обрабатывал), и аксель пытаются шатдаунить туннель. не паника, просто ошибка и отсыхание управления сетевой подсистемой.

вроде как в 4.4 (или 4.5?) появилась опция модуля, указывающая кто будет заниматься прибиванием туннеля - ядро или демон. бэкпортили ли - не смотрел.

Share this post


Link to post
Share on other sites

Всем привет. Подниму старый вопрос на тему не возможности собрать ipoe драйвер.

Мои действия:

Скачал с гита

создал папку буилд, зашел в нее

делаю cmake -DBUILD_IPOE_DRIVER=TRUE -DBUILD_PPTP_DRIVER=TRUE -DRADIUS=TRUE -DKDIR=/usr/src/linux-headers-`uname -r` ..

потом make

и получаю

[ 98%] Generating driver/ipoe.ko

/home/accel-ppp-code/build/drivers/ipoe/driver/ipoe.c:20: fatal error: linux/u64_stats_sync.h: Нет такого файла или каталога

compilation terminated.

make[4]: *** [/home/accel-ppp-code/build/drivers/ipoe/driver/ipoe.o] Ошибка 1

make[3]: *** [_module_/home/accel-ppp-code/build/drivers/ipoe/driver] Ошибка 2

make[2]: *** [drivers/ipoe/driver/ipoe.ko] Ошибка 2

make[1]: *** [drivers/ipoe/CMakeFiles/ipoe_drv.dir/all] Ошибка 2

make: *** [all] Ошибка 2

 

Имею:

uname -a

Linux ppp-server 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:45:36 UTC 2010 x86_64 GNU/Linux

 

apt-get install linux-kernel-headers

Чтение списков пакетов... Готово

Построение дерева зависимостей

Чтение информации о состоянии... Готово

Заметьте, вместо linux-kernel-headers выбирается linux-libc-dev

Уже установлена самая новая версия linux-libc-dev.

 

ls /usr/src/

linux linux-headers-2.6.35-22-generic linux-OLDVERSION.1333960503 netfilter-extensions.tar.bz2

linux-headers-2.6.35-22 linux-OLDVERSION.1333957341 modules xtables-addons.tar.bz2

 

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

Share this post


Link to post
Share on other sites

Посмотрите есть ли у вас такой файл там?

 

find /usr/src -type f -name u64_stats_sync.h

 

Если есть, то укажите полный путь к каталогу заголовков в -DKDIR.

Edited by avb1987

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