Forum Debian Users Gang

Nicram · 2014-12-05 10:25:50

Witam
Muszę postawić debiana jako serwer do bgp + ospf na serwerku HP, na którym są 1GB sieciówki intela.
z doświadczenia wiem, że przy dużej ilości pakietów moga być problemy z "wyciekaniem" pakietów. Oprócz zwiększenia dostępnych buforów w karcie należy jeszcze ztuningować kernel.
podpowiedzcie jakich konkretnie wartości używać i gdzie, by maszyna była wydajna? do jakiej wartości conntrack?

z góry dzięki.
pozdrawiam

Jacekalex · 2014-12-05 10:33:46

Pod warunkiem, że to musi być Debian.
Radziłbym spróbować OpenBSD i demona BGPD, razem z CARP,
PF i ewentualnie PFsync daje to środowisko, do którego Linuxowi czasami troszkę brakuje pod względem konfiguracji i funkcjonalności.
W przypadku serwera BDG zaczynałbym właśnie od OpenBSD. ;)

Sznurki:
http://www.openbgpd.org/
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-curr … gpd&sec=8

Ostatnio edytowany przez Jacekalex (2014-12-05 10:37:33)

Nicram · 2014-12-05 10:36:25

Jacekalex napisał(-a):
Pod warunkiem, że to musi być Debian.
Radziłbym spróbować OpenBSD i demona BGPD, razem z PF
i ewentualnie PFsync daje to środowisko, do którego Linuxowi czasami troszkę brakuje pod względem konfiguracji i funkcjonalności.
W przypadku serwera BDG zaczynałbym właśnie od OpenBSD. ;)

czy daemon bgpd w openbsd konfiguruje się identycznie jak quagga/cisco? nigdy nie uzywałem tego zestawu, zawsze quagga/cisco

Jacekalex · 2014-12-05 10:53:39

Podobnie, nie wiem, jak Cisco, ale Quagga i OpenBGPD mają porównywalne konfigi, a cały konfig jednego czy drugiego, to max 20% tego, co normalnie trzeba rzeźbić w zwykłym Postfixie czy Nginxie.

Tu masz opis konfigu bgpd:
http://aeriebsd.org/man/man5/bgpd.conf.html
Zarządzanie bgpd przez socket robi się narzędziem bgpctl:
http://aeriebsd.org/man/man8/bgpctl.html

Przewaga OpenBSD leży głownie w PF - i PFsync - czyli synchronizacji stanów FW między maszynami, w Linuxie nigdy nic podobnego nie widziałem.
Tam też pojawiła się pierwsza implementnacja protokołu CARP, która potem trafiła do Linuxa jako Ucarp.
http://www.openbsd.org/faq/pf/carp.html

Różnicy między Pocket Filterem na Netfilterem chyba nie muszę specjalnie tłumaczyć, dopiero NFtables może kiedyś dorośnie do poziomu PF.
Bazujący na FreeBSD PFSense też elegancko bryka na protokole BGP.

W dodatku OpenBSD, to bezsprzecznie najbezpieczniejszy gotowy OS na świecie, a to ma w przypadku serwera BGP kluczowe znaczenie.

W przypadku Linuxa możesz się pobawić Vyatta albo jakimś innym gotowym rozwiązaniem,
i dokładnie obejrzeć wynik z:

Kod:

sysctl -a

1 Gbit, to nie są jakieś niewiarygodne prędkości, które są poza zasięgiem Linuxa, wielkich zmian w jaju nie trzeba, poza drobiazgami, które masz tutaj na forum w tutku Biexi.

Konkretnie chodzi mi o te ustawienia:

Kod:

# wlaczenie w kernelu forwardowania 
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward
# Ochrona przed atakiem typu Smurf
/bin/echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Nie aktceptujemy pakietow "source route"
/bin/echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
# Nie przyjmujemy pakietow ICMP rediect, ktore moga zmienic tablice routingu
/bin/echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
# Wlaczamy ochrone przed blednymi komunikatami ICMP error
/bin/echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Wlaczenie mechanizmu wykrywania oczywistych falszerstw 
# (pakiety znajdujace sie tylko tablicy routingu)
/bin/echo 65536 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
/bin/echo 36024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
# zwiekszenie rozmaru tablicy ARP
/bin/echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
/bin/echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
/bin/echo 8192 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
# Blokada przed atakami typu SYN FLOODING
/bin/echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Właczenie proxy arp - dzieki temu serwer nie zdycha po kilku
#/bin/echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
# Zwiekszenie rozmiarutablic routingu
/bin/echo "18192" > /proc/sys/net/ipv4/route/max_size

I oczywiście sprzęt musi być odpowiedniej mocy i jakości, w każdym razie to nie jest 10Gbit (choć 10Gbit router też się udało komuś (niby możliwe) na Linuxie zrobić).

Ostatnio edytowany przez Jacekalex (2014-12-05 11:03:25)

Nicram · 2014-12-05 11:12:49

qrde, mam pewnie obawy co do OpenBSD, nigdy go produkcyjnie nie używałem.
Czy w nim, również muszę jakieś zmiany w kernelu robić czy jakoś dodatkowo tuningować jak w linuxie? czy wogole jest 64bitowy?

Jacekalex · 2014-12-05 11:17:48

Przykład konfigu BGPD:
ftp.cc.uoc.gr/mirrors/OpenBSD/src/etc/bgpd.conf

Nic strasznego w nim nie widzę.

OpenBSD 64 bit owszem, istnieje, i to od dawna.
Nie mam pewności co do IA64 (x64), ale x86_64 jest na pewno.

I nie panikuj, 1Gbit, to nie są jakieś niewiarygodne prędkości, istotne jest, jaka jest faktyczna rurka od ISP, i co jest podłączone na np eth1 po lanie.
Wyzwaniem jest dopiero 10Gbit.

W razie czego, czy to na OpenBSD czy na Linuxie masz logi, żeby w nie patrzeć.

Wszystkie Junipery i Cisco bazują na systemach BSD, w których zbyt dużo nie zmieniają, poza nazwą OS i interfejsem CLI.

Ostatnio edytowany przez Jacekalex (2014-12-05 11:21:58)

uzytkownikubunt · 2014-12-05 11:35:43

1299

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:03:50)

Jacekalex · 2014-12-05 11:43:32

Tu conieco o Linuxie jako 10Gbit router:
http://jacekalex.sh.dug.net.pl/router/LinuxCon2009_ … uer_final.pdf

A tutaj tutek o OpenBSD i demonach OpenBGPD i OpenOSPFD:
www.openbsd.org/papers/linuxtag06-network.pdf

@użytkownikubuntu

Co ma piernik do wiatraka, a cross-kompilacja i multiarch do routera BGP?

Ostatnio edytowany przez Jacekalex (2014-12-05 11:59:13)

zlyZwierz · 2014-12-05 12:19:47

Nicram, nie cuduj z tym tuningiem.
Bez nata i kolejek, to maszyna dmuchnie ten ruch aż sie kurz podniesie :)

nie wklejaj tego wynalazku:

Kod:

(...)
/bin/echo "18192" > /proc/sys/net/ipv4/route/max_size

Tablica BGP ma teraz >512k :)
Śmieci dot. conntracków też Cię nie interesują, bo nie używasz conntracka.

Wyłacz tylko rp_filter i włącz ip_forward.

Bardziej tym się zainteresuj:

Kod:

/sbin/ethtool -K eth1 tso off
/sbin/ethtool -K eth1 ufo off
/sbin/ethtool -K eth1 tx off
/sbin/ethtool -K eth1 rx off
/sbin/ethtool -K eth1 gro off
/sbin/ethtool -K eth1 gso off

/sbin/ethtool -G eth1 rx 4096 tx 4096

/sbin/ethtool -C eth1 rx-usecs 512
/sbin/ethtool -A eth1 autoneg off rx off tx off

Nicram · 2014-12-05 12:44:09

zlyZwierz napisał(-a):
Nicram, nie cuduj z tym tuningiem.
Bez nata i kolejek, to maszyna dmuchnie ten ruch aż sie kurz podniesie :)

nie wklejaj tego wynalazku:
Kod:
(...)
/bin/echo "18192" > /proc/sys/net/ipv4/route/max_size
Tablica BGP ma teraz >512k :)

obecnie mam odpalone u siebe bgp na debianie na starszym delu. co prawda nie ma z nim większych problemów, ale od czasu do czasu jakiś dziwny zonk sie z nim dzieje a to ospf zuzywa 100% mocy, a to przepełnia się conntrack a do tego wyciekają pakiety od strony "lanowej" gdzie na sieciówce jest około 350Mbps. conntrack mi na nim jest potrzeby do blokowania zakresu portów. Muszę go tuningować "na żywca" ztąd to moje pytanie na forum by ktoś z większym doświadczeniem w tej dziedzinie podpowiedział kilka ustawień.

Jacekalex · 2014-12-05 13:18:46

Jak się conntrack przepełnia, to możesz go zrobić np 25x większy przez sysctl, klucz net.nf_conntrack_max.
Możesz też zmniejszyć timeout wpisu w tablicy conntrack (osobno dla tcp i udp - masz tam razem ze 20 kluczy dla nf-conntrack i drugie tyle dla ip-conntrack), większość routerów stosuje wartość 120s, poza tym conntrack jest potrzebny przy FW i NAT, natomiast przy BGP jest zbędnym dodatkiem, bo BGP nie obsługuje NATu, tylko operuje publicznymi IP.
Conntrack przyda się dopiero wtedy, gdy zechcesz zrobić FW z kontrolą stanu, ale tego zazwyczaj nie robi się na routerach BGP, tylko na osobnej maszynie, najczęściej za routerem BGP.

Ospf - 100% procka?
Logi albo debugowanie dziada, to może być zarówno błąd w programie, jak i reakcja na jakieś anomalia czy ataki sieciowe.

Sieciówka ma problemy z 350Mbps? to już chyba ze sterem karty coś nie teges.
System przy takich prędkościach nie powinien szaleć, na żadnym w miarę współczesnym sprzęcie (nie starszym niż 7 lat).

Ostatnio edytowany przez Jacekalex (2014-12-05 13:32:26)

zlyZwierz · 2014-12-05 13:27:54

Ja mam tak:

rc.local:

Kod:

/usr/local/sbin/set_irq_affinity eth1

/sbin/ethtool -K eth1 tso off
/sbin/ethtool -K eth1 ufo off
/sbin/ethtool -K eth1 tx off
/sbin/ethtool -K eth1 rx off
/sbin/ethtool -K eth1 gro off
/sbin/ethtool -K eth1 gso off

/sbin/ethtool -G eth1 rx 4096 tx 4096

/sbin/ethtool -C eth1 rx-usecs 512
/sbin/ethtool -A eth1 autoneg off rx off tx off

sysctl.conf

Kod:

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
net.ipv4.ip_forward=1
net.nf_conntrack_max = 524288
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.default.arp_filter = 1
net.ipv4.conf.all.arp_ignore = 2
net.ipv4.conf.default.arp_ignore = 2
net.ipv4.ip_early_demux = 0

Daje radę bez marudzenia:
http://imgur.com/a/QOtpv

Robi DNETMAP i OSPF i BGP :)

Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)

Nicram · 2014-12-05 14:41:06

zlyZwierz napisał(-a):
Ja mam tak:

Daje radę bez marudzenia:
http://imgur.com/a/QOtpv

Robi DNETMAP i OSPF i BGP :)

Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)

Dzięki. Ja mam do wykorzystania jakiegoś starszego HP DL360 G5 z dwoma 2,3 Quadami + jakaś podwójna sieciówka intela, jaka konkretnie jeszcze nie wiem bo fizycznie nie dostałem tego na biurko.

@Jacekalex - czy bgpd na OpenBSD ma takie CLI jak quagga?

uzytkownikubunt · 2014-12-05 14:54:51

1300

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:03:51)

Jacekalex · 2014-12-05 15:17:08

@złyZwierz

Kod:

/usr/local/sbin/set_irq_affinity eth1

Ten skrypcio bardzo się rożni od takiego polecenia?

Kod:

egrep 'net|lan' /proc/interrupts  | awk -F':' '{print $1}' |while read IRQ; do echo 3 >/proc/irq/$IRQ/smp_affinity; done;

Nicram napisał(-a):
@Jacekalex - czy bgpd na OpenBSD ma takie CLI jak quagga?

Jacekalex napisał(-a):
Zarządzanie bgpd przez socket robi się narzędziem bgpctl:
http://aeriebsd.org/man/man8/bgpctl.html

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-12-05 15:20:01)

Nicram · 2014-12-05 15:23:41

Jacekalex napisał(-a):
Jacekalex napisał(-a):
Zarządzanie bgpd przez socket robi się narzędziem bgpctl:
http://aeriebsd.org/man/man8/bgpctl.html
Pozdro
;-)

:) jakoś tego linka przeoczyłem :/

Jacekalex · 2014-12-05 16:22:51

@up

Pytałeś też o OSPF:
http://en.wikipedia.org/wiki/OpenOSPFD
Demon:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-curr … pfd&sec=8
Zarządzany przez ospfctl
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-curr … ctl&sec=8

Ostatnio edytowany przez Jacekalex (2014-12-05 16:30:33)

Nicram · 2014-12-05 21:25:27

zlyZwierz napisał(-a):
Ja mam tak:

rc.local:
Kod:
/usr/local/sbin/set_irq_affinity eth1

/sbin/ethtool -K eth1 tso off
/sbin/ethtool -K eth1 ufo off
/sbin/ethtool -K eth1 tx off
/sbin/ethtool -K eth1 rx off
/sbin/ethtool -K eth1 gro off
/sbin/ethtool -K eth1 gso off

/sbin/ethtool -G eth1 rx 4096 tx 4096

/sbin/ethtool -C eth1 rx-usecs 512
/sbin/ethtool -A eth1 autoneg off rx off tx off
sysctl.conf
Kod:
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
net.ipv4.ip_forward=1
net.nf_conntrack_max = 524288
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.default.arp_filter = 1
net.ipv4.conf.all.arp_ignore = 2
net.ipv4.conf.default.arp_ignore = 2
net.ipv4.ip_early_demux = 0
Daje radę bez marudzenia:
http://imgur.com/a/QOtpv

Robi DNETMAP i OSPF i BGP :)

Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz
02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)

czy przy tych wartościach i takim ruchu nie masz errorów na sieciówkach?
bo u mnie jest tak:

Kod:

$ sudo ifconfig eth2
eth2      Link encap:Ethernet  HWaddr 00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1873587744 errors:0 dropped:34974370 overruns:0 frame:0
          TX packets:2783131079 errors:20 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2719292350 (2.5 GiB)  TX bytes:954034266 (909.8 MiB)
          Interrupt:21 

01:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
01:08.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
01:08.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
05:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)
05:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15)

to jest na sieciówce od wewnątrz sieci, na której jest największy ruch. system niestety 32bit więc liczniki danych szybko się przekręcaja.
rosną dropy na rx, co prawda nie w astronomicznym tempie, ale jednak.

Jacekalex · 2014-12-05 21:58:55

System 32bit na router ~500 Mbit?
To trochę jakby jazda gołym tyłkiem po nieheblowanej desce.

Ile to cudo ma RAMu i jaki procek?

Pytam, bo ja bym na początek mocno powiększył wszystkie limity pamięci dla obsługi sieci, jakie są w jaju.
Przydałoby się też poszczególne karty na stałe przypisać do poszczególnych rdzeni, żeby np dwa mocno obciążone interfejsy nie wisiały na jednym rdzeniu.

Chociaż takie klocki przy transferach rzędu ~300 - 500 Mbit, to bardzo dziwne.

Na początek zobacz na nowym routerze PFSense, gotowy, ma sprawne klikajło do zarządzania przez przeglądarkę, i na podobnych łączach śmiga jak marzenie.
Bazuje na FreeBSD, do OpenBSD brakuje mu ekstremalnego podejścia do spraw bezpieczeństwa systemu, FreeBSD podobnie jak Debian,
to kompromis między bezpieczeństwem i łatwością użytkowania.

Nicram napisał(-a):

Kod:

$ sudo ifconfig eth2
eth2      Link encap:Ethernet  HWaddr 00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1873587744 errors:0 dropped:34974370 overruns:0 frame:0
          TX packets:2783131079 errors:20 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2719292350 (2.5 GiB)  TX bytes:954034266 (909.8 MiB)
          Interrupt:21

Kosmiczne masz te transfery, u mnie - net 30Mbit przez PPPOE, karta Tplink TG-3269 (29 zł),
ster R8169 wbudowany w jajo na stałe:

Kod:

root ~> ifconfig net
net: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ea94:f6ff:fe02:ebd7  prefixlen 64  scopeid 0x20<link>
        ether e8:94:f6:02:eb:d7  txqueuelen 1000  (Ethernet)
        RX packets 4186361  bytes 6125915025 (5.7 GiB)
        RX errors 0  dropped 13  overruns 0  frame 0
        TX packets 3979635  bytes 284501322 (271.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-12-05 23:23:57)

Nicram · 2014-12-05 22:05:57

Jacekalex napisał(-a):
System 32bit na router ~500 Mbit?
To trochę jakby jazda gołym tyłkiem po nieheblowanej desce.

Ile to cudo ma RAMu i jaki procek?

Pytam, bo ja bym na początek mocno powiększył wszystkie limity pamięci dla obsługi sieci, jakie są w jaju.
Przydałoby się też poszczególne karty na stałe przypisać do poszczególnych rdzeni, żeby np dwa mocno obciążone interfejsy nie wisiały na jednym rdzeniu.

Chociaż takie klocki przy transferach rzędu ~300 - 500 Mbit, to bardzo dziwne.

Na początek zobacz na nowym routerze PFSense, gotowy, ma sprawne klikajło do zarządzania przez przeglądarkę, i na podobnych łączach śmiga jak marzenie.
Bazuje na FreeBSD, do OpenBSD brakuje mu ekstremalnego podejścia do spraw bezpieczeństwa systemu, FreeBSD podobnie jak Debian,
to kompromis między bezpieczeństwem i łatwością użytkowania.

Ten system stoi dobre 5-6 lat a i sprzęt nie był "nowy".
ma to 2x Xeona 2.4 dualnego, 4GB ramu

Jacekalex · 2014-12-05 22:12:18

4 GB RAM i 2*Xeon 2.4 Ghz?
I to się nie wyrabia na ~500Mbit?
Jakieś błędy?

Może coś te stery do Broadcoma wariują, to jednak nie jest takie wsparcie, jak Intel.

W dmesg i kernel.log są jakieś komunikaty błędów?

Ostatnio edytowany przez Jacekalex (2014-12-05 22:12:54)

Nicram · 2014-12-05 22:43:03

Jacekalex napisał(-a):
4 GB RAM i 2*Xeon 2.4 Ghz?
I to się nie wyrabia na ~500Mbit?
Jakieś błędy?

Może coś te stery do Broadcoma wariują, to jednak nie jest takie wsparcie, jak Intel.

W dmesg i kernel.log są jakieś komunikaty błędów?

Ja nie twierdzę, że się nie wyrabia, tylko, że od czasu do czasu robi jakiś zonk. typu proces ospf zabiera 100% procka, atak wykluczam, gdzyż ospf chodzi w zamknniętym segmencie. a to np. wszystkie łącza nagle są wysycane w rx, idzie na maksa. wiem, że to nie jest nowy sprzęt, ma to już dobre 10 lat jak nie więcej. kernel.log pokazywał ostatnio:

Kod:

Dec  1 19:06:35 bgp kernel: 
Dec  1 19:06:35 bgp kernel: Pid: 3508, comm: zebra Not tainted (2.6.24.5-grsec_bgp #7)
Dec  1 19:06:35 bgp kernel: EIP: 0060:[<f8ca11cf>] EFLAGS: 00000292 CPU: 3
Dec  1 19:06:35 bgp kernel: EIP is at udp_pkt_to_tuple+0x5d/0x60 [nf_conntrack]
Dec  1 19:06:35 bgp kernel: EAX: 00000001 EBX: f8c9ad80 ECX: f68dda7c EDX: d434d834
Dec  1 19:06:35 bgp kernel: ESI: e1b97780 EDI: f68dda7c EBP: e1b97780 ESP: f68dd9f8
Dec  1 19:06:35 bgp kernel:  DS: 0068 ES: 0068 FS: 00d8 GS: 0033 SS: 0068
Dec  1 19:06:35 bgp kernel: CR0: 8005003b CR2: 22052b0c CR3: 3685c000 CR4: 000006d0
Dec  1 19:06:35 bgp kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Dec  1 19:06:35 bgp kernel: DR6: ffff0ff0 DR7: 00000400
Dec  1 19:06:35 bgp kernel:  [<f8c9d350>] nf_ct_get_tuple+0x6c/0x78 [nf_conntrack]
Dec  1 19:06:35 bgp kernel:  [<f8ca1014>] udp_error+0x0/0x15e [nf_conntrack]
Dec  1 19:06:35 bgp kernel:  [<f8c9e387>] nf_conntrack_in+0x16d/0x46e [nf_conntrack]
Dec  1 19:06:35 bgp kernel:  [<f8ca167c>] nf_ct_deliver_cached_events+0x9/0x69 [nf_conntrack]
Dec  1 19:06:35 bgp kernel:  [<f8cdb1b3>] ipv4_conntrack_in+0x0/0xe [nf_conntrack_ipv4]
Dec  1 19:06:35 bgp kernel:  [<c0a7036a>] nf_iterate+0x3a/0x6e
Dec  1 19:06:36 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:06:36 bgp kernel:  [<c0a7040f>] nf_hook_slow+0x4d/0xb5
Dec  1 19:06:36 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:06:36 bgp kernel:  [<c0a7594e>] ip_rcv+0x1fc/0x237
Dec  1 19:06:36 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:06:36 bgp kernel:  [<c0a548f2>] netif_receive_skb+0x2ea/0x356
Dec  1 19:06:36 bgp kernel:  [<c0995658>] remove_probe_files+0x19/0x1a
Dec  1 19:06:36 bgp kernel:  [<c099f0b7>] e1000_clean_rx_irq+0x383/0x452
Dec  1 19:06:36 bgp kernel:  [<c099ed34>] e1000_clean_rx_irq+0x0/0x452
Dec  1 19:06:36 bgp kernel:  [<c099b3f5>] e1000_clean+0x5e/0x20c
Dec  1 19:06:36 bgp kernel:  [<c0a56828>] net_rx_action+0x9f/0x197
Dec  1 19:06:36 bgp kernel:  [<c0a56be9>] net_tx_action+0xcc/0xf0
Dec  1 19:06:36 bgp kernel:  [<c08290ef>] __do_softirq+0x66/0xd3
Dec  1 19:06:36 bgp kernel:  [<c08291a1>] do_softirq+0x45/0x53
Dec  1 19:06:36 bgp kernel:  [<c08293c2>] local_bh_enable_ip+0x35/0x40
Dec  1 19:06:36 bgp kernel:  [<c0a71f57>] rt_run_flush+0x68/0x8f
Dec  1 19:06:36 bgp kernel:  [<c0a9e677>] fn_hash_delete+0x119/0x1c5
Dec  1 19:06:36 bgp kernel:  [<c0a9b891>] inet_rtm_delroute+0x0/0x2f
Dec  1 19:06:36 bgp kernel:  [<c0a9b8bb>] inet_rtm_delroute+0x2a/0x2f
Dec  1 19:06:36 bgp kernel:  [<c0a5d1f4>] rtnetlink_rcv_msg+0x18d/0x1a7
Dec  1 19:06:36 bgp kernel:  [<c0a5d067>] rtnetlink_rcv_msg+0x0/0x1a7
Dec  1 19:06:36 bgp kernel:  [<c0a6db1d>] netlink_rcv_skb+0x2d/0x7e
Dec  1 19:06:36 bgp kernel:  [<c0a5d061>] rtnetlink_rcv+0x14/0x1a
Dec  1 19:06:36 bgp kernel:  [<c0a6d904>] netlink_unicast+0x199/0x1f4
Dec  1 19:06:36 bgp kernel:  [<c0a6e0e9>] netlink_sendmsg+0x27c/0x288
Dec  1 19:06:36 bgp kernel:  [<c0a4b03a>] sock_sendmsg+0xc9/0xe4
Dec  1 19:06:36 bgp kernel:  [<c0ae518c>] _read_lock_bh+0x8/0x17
Dec  1 19:06:36 bgp kernel:  [<c08355e5>] autoremove_wake_function+0x0/0x35
Dec  1 19:06:36 bgp kernel:  [<f8cea408>] nf_nat_fn+0x16c/0x17b [iptable_nat]
Dec  1 19:06:36 bgp kernel:  [<f8ca167c>] nf_ct_deliver_cached_events+0x9/0x69 [nf_conntrack]
Dec  1 19:06:36 bgp kernel:  [<f8cdb15e>] ipv4_confirm+0x34/0x39 [nf_conntrack_ipv4]
Dec  1 19:06:36 bgp kernel:  [<f8cdb12a>] ipv4_confirm+0x0/0x39 [nf_conntrack_ipv4]
Dec  1 19:06:36 bgp kernel:  [<c0a7036a>] nf_iterate+0x3a/0x6e
Dec  1 19:06:36 bgp kernel:  [<c0a4b1e9>] sys_sendmsg+0x194/0x1f9
Dec  1 19:06:36 bgp kernel:  [<c0a5110b>] __netdev_alloc_skb+0x1c/0x35
Dec  1 19:06:36 bgp kernel:  [<c099e7aa>] e1000_alloc_rx_buffers+0x1c7/0x291
Dec  1 19:06:36 bgp kernel:  [<c0a548f2>] netif_receive_skb+0x2ea/0x356
Dec  1 19:06:36 bgp kernel:  [<c099f0f7>] e1000_clean_rx_irq+0x3c3/0x452
Dec  1 19:06:37 bgp kernel:  [<c080a662>] sched_clock+0x8/0x18
Dec  1 19:06:37 bgp kernel:  [<c0803023>] __switch_to+0xa9/0x12a
Dec  1 19:06:37 bgp kernel:  [<c0a4c505>] sys_socketcall+0x240/0x261
Dec  1 19:06:37 bgp kernel:  [<c082b5a1>] sys_capset+0x26e/0x295
Dec  1 19:06:37 bgp kernel:  [<c0804069>] sysenter_past_esp+0x72/0xb9
Dec  1 19:06:37 bgp kernel:  =======================
Dec  1 19:06:37 bgp kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Dec  1 19:06:37 bgp kernel:   Tx Queue             <0>
Dec  1 19:06:37 bgp kernel:   TDH                  <d0>
Dec  1 19:06:37 bgp kernel:   TDT                  <d0>
Dec  1 19:06:37 bgp kernel:   next_to_use          <d0>
Dec  1 19:06:37 bgp kernel:   next_to_clean        <25>
Dec  1 19:06:37 bgp kernel: buffer_info[next_to_clean]
Dec  1 19:06:37 bgp kernel:   time_stamp           <7574e675>
Dec  1 19:06:37 bgp kernel:   next_to_watch        <25>
Dec  1 19:06:37 bgp kernel:   jiffies              <7574e7ff>
Dec  1 19:06:37 bgp kernel:   next_to_watch.status <1>
Dec  1 19:06:59 bgp kernel: BUG: soft lockup - CPU#3 stuck for 11s! [zebra:3508]
Dec  1 19:06:59 bgp kernel: 
Dec  1 19:06:59 bgp kernel: Pid: 3508, comm: zebra Not tainted (2.6.24.5-grsec_bgp #7)
Dec  1 19:06:59 bgp kernel: EIP: 0060:[<c0a56ff5>] EFLAGS: 00000246 CPU: 3
Dec  1 19:07:00 bgp kernel: EIP is at dev_queue_xmit+0x181/0x2b0
Dec  1 19:07:00 bgp kernel: EAX: 0000000e EBX: f7c97000 ECX: df8b2780 EDX: 00000000
Dec  1 19:07:00 bgp kernel: ESI: 00000000 EDI: df8b2780 EBP: 0000000e ESP: f68dda90
Dec  1 19:07:00 bgp kernel:  DS: 0068 ES: 0068 FS: 00d8 GS: 0033 SS: 0068
Dec  1 19:07:00 bgp kernel: CR0: 8005003b CR2: 9bea0000 CR3: 3685c000 CR4: 000006d0
Dec  1 19:07:00 bgp kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Dec  1 19:07:00 bgp kernel: DR6: ffff0ff0 DR7: 00000400
Dec  1 19:07:00 bgp kernel:  [<c0a78c3c>] ip_finish_output+0x1d8/0x210
Dec  1 19:07:00 bgp kernel:  [<c0a79b12>] ip_output+0x80/0x95
Dec  1 19:07:00 bgp kernel:  [<c0a76460>] ip_forward_finish+0x2c/0x2e
Dec  1 19:07:00 bgp kernel:  [<c0a754be>] ip_rcv_finish+0x272/0x291
Dec  1 19:07:00 bgp kernel:  [<c0a7594e>] ip_rcv+0x1fc/0x237
Dec  1 19:07:00 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:07:00 bgp kernel:  [<c0a548f2>] netif_receive_skb+0x2ea/0x356
Dec  1 19:07:00 bgp kernel:  [<c099f0b7>] e1000_clean_rx_irq+0x383/0x452
Dec  1 19:07:00 bgp kernel:  [<c099ed34>] e1000_clean_rx_irq+0x0/0x452
Dec  1 19:07:00 bgp kernel:  [<c099b3f5>] e1000_clean+0x5e/0x20c
Dec  1 19:07:00 bgp kernel:  [<c0a56828>] net_rx_action+0x9f/0x197
Dec  1 19:07:00 bgp kernel:  [<c0a56be9>] net_tx_action+0xcc/0xf0
Dec  1 19:07:00 bgp kernel:  [<c08290ef>] __do_softirq+0x66/0xd3
Dec  1 19:07:00 bgp kernel:  [<c08291a1>] do_softirq+0x45/0x53
Dec  1 19:07:00 bgp kernel:  [<c08293c2>] local_bh_enable_ip+0x35/0x40
Dec  1 19:07:00 bgp kernel:  [<c0a71f57>] rt_run_flush+0x68/0x8f
Dec  1 19:07:00 bgp kernel:  [<c0a9ef7f>] fn_hash_insert+0x5dd/0x67b
Dec  1 19:07:00 bgp kernel:  [<c0ae5255>] _spin_lock_bh+0x8/0x18
Dec  1 19:07:00 bgp kernel:  [<c0a6f23b>] nla_validate+0x3a/0x47
Dec  1 19:07:00 bgp kernel:  [<c0a9bcfe>] inet_rtm_newroute+0x0/0x2f
Dec  1 19:07:00 bgp kernel:  [<c0a9bd28>] inet_rtm_newroute+0x2a/0x2f
Dec  1 19:07:00 bgp kernel:  [<c0a5d1f4>] rtnetlink_rcv_msg+0x18d/0x1a7
Dec  1 19:07:00 bgp kernel:  [<c0a6dae8>] netlink_ack+0x189/0x191
Dec  1 19:07:00 bgp kernel:  [<c0a5d067>] rtnetlink_rcv_msg+0x0/0x1a7
Dec  1 19:07:00 bgp kernel:  [<c0a6db1d>] netlink_rcv_skb+0x2d/0x7e
Dec  1 19:07:00 bgp kernel:  [<c0a5d061>] rtnetlink_rcv+0x14/0x1a
Dec  1 19:07:00 bgp kernel:  [<c0a6d904>] netlink_unicast+0x199/0x1f4
Dec  1 19:07:00 bgp kernel:  [<c0a6e0e9>] netlink_sendmsg+0x27c/0x288
Dec  1 19:07:00 bgp kernel:  [<c0a4b03a>] sock_sendmsg+0xc9/0xe4
Dec  1 19:07:00 bgp kernel:  [<c08355e5>] autoremove_wake_function+0x0/0x35
Dec  1 19:07:00 bgp kernel:  [<c08355e5>] autoremove_wake_function+0x0/0x35
Dec  1 19:07:00 bgp kernel:  [<f8ca167c>] nf_ct_deliver_cached_events+0x9/0x69 [nf_conntrack]
Dec  1 19:07:00 bgp kernel:  [<c0a62af7>] __qdisc_run+0xd7/0x196
Dec  1 19:07:00 bgp kernel:  [<c0a4b1e9>] sys_sendmsg+0x194/0x1f9
Dec  1 19:07:00 bgp kernel:  [<c0a40068>] do_mirror+0xf0/0xa87
Dec  1 19:07:00 bgp kernel:  [<c099a468>] e1000_unmap_and_free_tx_resource+0x1b/0x23
Dec  1 19:07:00 bgp kernel:  [<c099a63b>] e1000_clean_tx_irq+0xbc/0x2c5
Dec  1 19:07:00 bgp kernel:  [<c099f156>] e1000_clean_rx_irq+0x422/0x452
Dec  1 19:07:00 bgp kernel:  [<c099ed34>] e1000_clean_rx_irq+0x0/0x452
Dec  1 19:07:00 bgp kernel:  [<c099b579>] e1000_clean+0x1e2/0x20c
Dec  1 19:07:00 bgp kernel:  [<c0a4c505>] sys_socketcall+0x240/0x261
Dec  1 19:07:00 bgp kernel:  [<c082b5a1>] sys_capset+0x26e/0x295
Dec  1 19:07:00 bgp kernel:  [<c0804069>] sysenter_past_esp+0x72/0xb9
Dec  1 19:07:00 bgp kernel:  =======================
Dec  1 19:07:46 bgp kernel: BUG: soft lockup - CPU#1 stuck for 11s! [events/1:16]
Dec  1 19:07:46 bgp kernel: 
Dec  1 19:07:46 bgp kernel: Pid: 16, comm: events/1 Not tainted (2.6.24.5-grsec_bgp #7)
Dec  1 19:07:46 bgp kernel: EIP: 0060:[<c0ae4ee9>] EFLAGS: 00000287 CPU: 1
Dec  1 19:07:46 bgp kernel: EIP is at __write_lock_failed+0x9/0x20
Dec  1 19:07:46 bgp kernel: EAX: f8c9a000 EBX: f8c9a000 ECX: f2935680 EDX: 00000002
Dec  1 19:07:46 bgp kernel: ESI: f2b14b6c EDI: f2935680 EBP: f2935680 ESP: f7cb1c94
Dec  1 19:07:46 bgp kernel:  DS: 0068 ES: 007b FS: 00d8 GS: 0000 SS: 0068
Dec  1 19:07:46 bgp kernel: CR0: 8005003b CR2: b4021014 CR3: 268a1000 CR4: 000006d0
Dec  1 19:07:46 bgp kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Dec  1 19:07:46 bgp kernel: DR6: ffff0ff0 DR7: 00000400
Dec  1 19:07:46 bgp kernel:  [<c0ae5341>] _write_lock_bh+0x18/0x1a
Dec  1 19:07:46 bgp kernel:  [<f8c9d99c>] __nf_ct_refresh_acct+0x24/0x127 [nf_conntrack]
Dec  1 19:07:46 bgp kernel:  [<f8ca1251>] udp_packet+0x7f/0x8a [nf_conntrack]
Dec  1 19:07:46 bgp kernel:  [<f8ca11d2>] udp_packet+0x0/0x8a [nf_conntrack]
Dec  1 19:07:46 bgp kernel:  [<f8c9e5f7>] nf_conntrack_in+0x3dd/0x46e [nf_conntrack]
Dec  1 19:07:46 bgp kernel:  [<c0a54f1b>] dev_hard_start_xmit+0x214/0x289
Dec  1 19:07:46 bgp kernel:  [<f8ca167c>] nf_ct_deliver_cached_events+0x9/0x69 [nf_conntrack]
Dec  1 19:07:46 bgp kernel:  [<f8cdb1b3>] ipv4_conntrack_in+0x0/0xe [nf_conntrack_ipv4]
Dec  1 19:07:46 bgp kernel:  [<c0a7036a>] nf_iterate+0x3a/0x6e
Dec  1 19:07:46 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:07:46 bgp kernel:  [<c0a7040f>] nf_hook_slow+0x4d/0xb5
Dec  1 19:07:46 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:07:46 bgp kernel:  [<c0a7594e>] ip_rcv+0x1fc/0x237
Dec  1 19:07:46 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:07:46 bgp kernel:  [<c0a548f2>] netif_receive_skb+0x2ea/0x356
Dec  1 19:07:46 bgp kernel:  [<c099f0b7>] e1000_clean_rx_irq+0x383/0x452
Dec  1 19:07:46 bgp kernel:  [<c099ed34>] e1000_clean_rx_irq+0x0/0x452
Dec  1 19:07:46 bgp kernel:  [<c099b3f5>] e1000_clean+0x5e/0x20c
Dec  1 19:07:46 bgp kernel:  [<c0a56828>] net_rx_action+0x9f/0x197
Dec  1 19:07:46 bgp kernel:  [<c082c35b>] run_timer_softirq+0x30/0x193
Dec  1 19:07:46 bgp kernel:  [<f8c9d55c>] death_by_timeout+0x0/0xae [nf_conntrack]
Dec  1 19:07:46 bgp kernel:  [<c0a56bcb>] net_tx_action+0xae/0xf0
Dec  1 19:07:46 bgp kernel:  [<c08290ef>] __do_softirq+0x66/0xd3
Dec  1 19:07:46 bgp kernel:  [<c08291a1>] do_softirq+0x45/0x53
Dec  1 19:07:46 bgp kernel:  [<c08293c2>] local_bh_enable_ip+0x35/0x40
Dec  1 19:07:46 bgp kernel:  [<c0a74c55>] ipv4_dst_destroy+0x23/0x4a
Dec  1 19:07:46 bgp kernel:  [<c0a5849c>] dst_destroy+0x5f/0xa9
Dec  1 19:07:46 bgp kernel:  [<c0a58599>] dst_gc_task+0x57/0x16b
Dec  1 19:07:46 bgp kernel:  [<c081d9e2>] update_curr+0x62/0xef
Dec  1 19:07:46 bgp kernel:  [<c081d9e2>] update_curr+0x62/0xef
Dec  1 19:07:46 bgp kernel:  [<c0803023>] __switch_to+0xa9/0x12a
Dec  1 19:07:46 bgp kernel:  [<c0ae401e>] schedule+0x587/0x5ea
Dec  1 19:07:46 bgp kernel:  [<c0832b84>] queue_delayed_work_on+0x8e/0x9a
Dec  1 19:07:46 bgp kernel:  [<c0a58542>] dst_gc_task+0x0/0x16b
Dec  1 19:07:46 bgp kernel:  [<c0832420>] run_workqueue+0x7c/0x107
Dec  1 19:07:46 bgp kernel:  [<c08356f8>] prepare_to_wait+0x12/0x49
Dec  1 19:07:46 bgp kernel:  [<c0832c8d>] worker_thread+0x0/0x83
Dec  1 19:07:46 bgp kernel:  [<c0832d06>] worker_thread+0x79/0x83
Dec  1 19:07:46 bgp kernel:  [<c08355e5>] autoremove_wake_function+0x0/0x35
Dec  1 19:07:46 bgp kernel:  [<c083551f>] kthread+0x38/0x5d
Dec  1 19:07:46 bgp kernel:  [<c08354e7>] kthread+0x0/0x5d
Dec  1 19:07:46 bgp kernel:  [<c0805367>] kernel_thread_helper+0x7/0x10
Dec  1 19:07:47 bgp kernel:  =======================
Dec  1 19:07:47 bgp kernel: e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
Dec  1 19:07:47 bgp kernel:   Tx Queue             <0>
Dec  1 19:07:47 bgp kernel:   TDH                  <ba3>
Dec  1 19:07:47 bgp kernel:   TDT                  <ba3>
Dec  1 19:07:47 bgp kernel:   next_to_use          <ba3>
Dec  1 19:07:47 bgp kernel:   next_to_clean        <667>
Dec  1 19:07:47 bgp kernel: buffer_info[next_to_clean]
Dec  1 19:07:47 bgp kernel:   time_stamp           <75752bb5>
Dec  1 19:07:47 bgp kernel:   next_to_watch        <667>
Dec  1 19:07:47 bgp kernel:   jiffies              <75752ce6>
Dec  1 19:07:47 bgp kernel:   next_to_watch.status <1>
Dec  1 19:08:19 bgp kernel: BUG: soft lockup - CPU#1 stuck for 11s! [events/1:16]
Dec  1 19:08:19 bgp kernel: 
Dec  1 19:08:19 bgp kernel: Pid: 16, comm: events/1 Not tainted (2.6.24.5-grsec_bgp #7)
Dec  1 19:08:19 bgp kernel: EIP: 0060:[<c0ae5192>] EFLAGS: 00000216 CPU: 1
Dec  1 19:08:19 bgp kernel: EIP is at _read_lock_bh+0xe/0x17
Dec  1 19:08:19 bgp kernel: EAX: f8c8c0cc EBX: f8c8c0cc ECX: 00000000 EDX: f5c54020
Dec  1 19:08:19 bgp kernel: ESI: f7cb1da4 EDI: 00000000 EBP: e3571280 ESP: f7cb1ce0
Dec  1 19:08:19 bgp kernel:  DS: 0068 ES: 0068 FS: 00d8 GS: 0000 SS: 0068
Dec  1 19:08:19 bgp kernel: CR0: 8005003b CR2: b4021014 CR3: 00bdd000 CR4: 000006d0
Dec  1 19:08:19 bgp kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Dec  1 19:08:19 bgp kernel: DR6: ffff0ff0 DR7: 00000400
Dec  1 19:08:19 bgp kernel:  [<f8c83231>] ipt_do_table+0x75/0x474 [ip_tables]
Dec  1 19:08:19 bgp kernel:  [<f8c90000>] ipt_route_hook+0x0/0x15 [iptable_mangle]
Dec  1 19:08:19 bgp kernel:  [<c0a7036a>] nf_iterate+0x3a/0x6e
Dec  1 19:08:19 bgp kernel:  [<c0a7040f>] nf_hook_slow+0x4d/0xb5
Dec  1 19:08:19 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:08:19 bgp kernel:  [<c0a7594e>] ip_rcv+0x1fc/0x237
Dec  1 19:08:19 bgp kernel:  [<c0a7524c>] ip_rcv_finish+0x0/0x291
Dec  1 19:08:19 bgp kernel:  [<c0a548f2>] netif_receive_skb+0x2ea/0x356
Dec  1 19:08:19 bgp kernel:  [<c099f0b7>] e1000_clean_rx_irq+0x383/0x452
Dec  1 19:08:19 bgp kernel:  [<c099ed34>] e1000_clean_rx_irq+0x0/0x452
Dec  1 19:08:19 bgp kernel:  [<c099b3f5>] e1000_clean+0x5e/0x20c
Dec  1 19:08:19 bgp kernel:  [<c0a56828>] net_rx_action+0x9f/0x197
Dec  1 19:08:19 bgp kernel:  [<c0a56be9>] net_tx_action+0xcc/0xf0
Dec  1 19:08:19 bgp kernel:  [<c08290ef>] __do_softirq+0x66/0xd3
Dec  1 19:08:19 bgp kernel:  [<c08291a1>] do_softirq+0x45/0x53
Dec  1 19:08:19 bgp kernel:  [<c08293c2>] local_bh_enable_ip+0x35/0x40
Dec  1 19:08:19 bgp kernel:  [<c0a74c55>] ipv4_dst_destroy+0x23/0x4a
Dec  1 19:08:19 bgp kernel:  [<c0a5849c>] dst_destroy+0x5f/0xa9
Dec  1 19:08:19 bgp kernel:  [<c0a58599>] dst_gc_task+0x57/0x16b
Dec  1 19:08:19 bgp kernel:  [<c082c8a0>] lock_timer_base+0x19/0x35
Dec  1 19:08:19 bgp kernel:  [<c082c9b3>] __mod_timer+0x99/0xa3
Dec  1 19:08:19 bgp kernel:  [<c0832b84>] queue_delayed_work_on+0x8e/0x9a
Dec  1 19:08:19 bgp kernel:  [<c0a58542>] dst_gc_task+0x0/0x16b
Dec  1 19:08:19 bgp kernel:  [<c0832420>] run_workqueue+0x7c/0x107
Dec  1 19:08:19 bgp kernel:  [<c08356f8>] prepare_to_wait+0x12/0x49
Dec  1 19:08:19 bgp kernel:  [<c0832c8d>] worker_thread+0x0/0x83
Dec  1 19:08:19 bgp kernel:  [<c0832d06>] worker_thread+0x79/0x83
Dec  1 19:08:19 bgp kernel:  [<c08355e5>] autoremove_wake_function+0x0/0x35
Dec  1 19:08:19 bgp kernel:  [<c083551f>] kthread+0x38/0x5d
Dec  1 19:08:19 bgp kernel:  [<c08354e7>] kthread+0x0/0x5d
Dec  1 19:08:19 bgp kernel:  [<c0805367>] kernel_thread_helper+0x7/0x10
Dec  1 19:08:19 bgp kernel:  =======================

po ostatnim wpisie z loga sytuacja powróciła do normy.
dlatego też szukam alternatywy. generalnie to chodzi. mam odpalić bgp u znajomego i jak to będzie ładnie sie zachowywało to postawię podobnie u siebie.

Jacekalex · 2014-12-05 23:00:51

Kod:

Dec  1 19:07:46 bgp kernel: Pid: 16, comm: events/1 Not tainted (2.6.24.5-grsec_bgp #7)

Czemu do cholery nie napisałeś, że masz jajo z Grsec/Paxem?

Po pierwsze, wersja jajka prehistoryczna, skompiluj sobie jakieś świeże, aktualne stabilne ze stabilną łatką Grsec, np 3.14.25, a jak Ci przy przekroczeniu jakiejś kwoty pamięci PAX rozrabia i ubija proces sterownika czy jakiegoś demona, to takie błędy się na forum Grsec zgłasza, i problem masz zazwyczaj załatwiony w ciągu 48 godzin.

Grsec - to łatka, która też poprawia i modyfikuje większość istotnych sterowników w jaju, jak powoduje kłopoty, to po pierwsze się sprawdza na czystym jaju z kernel.org, żeby wiedzieć, czy jajo winne, czy łatka, a jeśli błąd powoduje łatka, to loga pod pachę i biegiem na forum Grsec.

Grsec i pax to bardzo fajne i pancerne zabezpieczenie, ale ma takie mechanizmy obrony pamięci RAM, że u mnie na jaju 3.17 próba załadowania Nouveau kończy się na kernel-panic ostatnio,
natomiast binarny ster Nvidii potrzebuje dwóch łatek od Pax-team.

A u Ciebie wyraźnie cyrk zaczyna się od reakcji Paxa.

Jeśli jeszcze masz włączony MPROTECT na Debianie, który był aktualny w czasie wydania jajka 2.6.24, to dziękuj Bogu, że Ci Grsec i Pax z tego systemu nie zrobiły mielonki.

Jak chcesz się Grseciem bawić, to zainteresuj się Gentoo hardened, tam masz oficjalne wsparcie do Grsec/Paxa, i łatki na GCC i Glibc, żeby wszystko brykało jak należy.
A mimo to i tak z Grseciem i przede wszystkim Paxem jest czasem niezła jazda.

Ostatnio edytowany przez Jacekalex (2014-12-05 23:12:40)

Nicram · 2014-12-05 23:13:11

wspominałem, że nie jest to nowy system :)
do wymiany sprzętu boss przymierza sie już długo, ale jak to bywa w małych firmach, takie rzeczy robi się jak już coś się spieprzy i trzeba zrobić na wczoraj :/
zawsze brakuje kasy na zakup czegoś nowego a jak już coś to ebay.
spróbuję go namówić na kupno jakiegoś sensownego, oczywiście używanego, serwerka. może da się przekonać. zobaczę, jak będzie ten HP chodził, może kupi coś takiego.

z drugiej strony, na dwóch serwerkach (dell 1950, nie zbyt nowy, ale wydajny, generalnie się nudzą), na których jest PPPoE też na sieciówkach mam dropy pakietów na TX. bufory zwiększone na maksa. ale tam są standardowe broadcomy

Jeszcze raz dzięki za sugestie.
Pozdrawiam

Ostatnio edytowany przez Nicram (2014-12-05 23:16:57)

Jacekalex · 2014-12-05 23:31:40

Z błędami takimi, jak masz w logu, to najpierw szoruj na forum Grseca.
Oczywiście pod warunkiem, że masz aktualne jajo i łatkę, bo przy takim starociu to Cię najpierw po latest-stable-patch wygonią.

I nie chodzi tu o sprzęt, bo mój grat ma lat 7, i na jaju 3.17.4-grsec śmiga bardzo grzecznie.
Tylko że cały system jest kompilowany przez GCC z wtyczkami Paxa, Glibc z łatkami hardened,
a w Debianie instalujesz Grsec i Paxa na systemie, którego Developerzy w ogóle nie brali pod uwagę używania takich zabezpieczeń.

Jak chcesz mieć stabilny i gotowy system o poziomie bezpieczeństwa podobnym do Grsec/Pax bez "koszmarnych" kompilacji, to tylko OpenBSD spełnia ten warunek, bo FreeBSD czy Debian już nie.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-12-05 23:36:31)

Forum Debian Users Gang

Ogłoszenie

#1 2014-12-05 10:25:50

Nicram - Użytkownik

debian jako bgp - tuning kernela

#2 2014-12-05 10:33:46

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

#3 2014-12-05 10:36:25

Nicram - Użytkownik

Re: debian jako bgp - tuning kernela

Jacekalex napisał(-a):

#4 2014-12-05 10:53:39

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

Kod:

Kod:

#5 2014-12-05 11:12:49

Nicram - Użytkownik

Re: debian jako bgp - tuning kernela

#6 2014-12-05 11:17:48

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

#7 2014-12-05 11:35:43

uzytkownikubunt - Zbanowany

Re: debian jako bgp - tuning kernela

#8 2014-12-05 11:43:32

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

#9 2014-12-05 12:19:47

zlyZwierz - Moderator

Re: debian jako bgp - tuning kernela

Kod:

Kod:

#10 2014-12-05 12:44:09

Nicram - Użytkownik

Re: debian jako bgp - tuning kernela

zlyZwierz napisał(-a):

Kod:

#11 2014-12-05 13:18:46

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

#12 2014-12-05 13:27:54

zlyZwierz - Moderator

Re: debian jako bgp - tuning kernela

Kod:

Kod:

#13 2014-12-05 14:41:06

Nicram - Użytkownik

Re: debian jako bgp - tuning kernela

zlyZwierz napisał(-a):

#14 2014-12-05 14:54:51

uzytkownikubunt - Zbanowany

Re: debian jako bgp - tuning kernela

#15 2014-12-05 15:17:08

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

Kod:

Kod:

Nicram napisał(-a):

Jacekalex napisał(-a):

#16 2014-12-05 15:23:41

Nicram - Użytkownik

Re: debian jako bgp - tuning kernela

Jacekalex napisał(-a):

Jacekalex napisał(-a):

#17 2014-12-05 16:22:51

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

#18 2014-12-05 21:25:27

Nicram - Użytkownik

Re: debian jako bgp - tuning kernela

zlyZwierz napisał(-a):

Kod:

Kod:

Kod:

#19 2014-12-05 21:58:55

Jacekalex - Podobno człowiek...;)

Re: debian jako bgp - tuning kernela

Nicram napisał(-a):