Hej!
(Cc Mattias som vet massor om routing, FreeBSD och DDoS.)
Visst har vi några personer på listan som gillar routing och sådant? Peter hjälpte oss med openbgpd för ett tag sedan, t.ex.
Vi kör en FreeBSD 8.2 som router på lite gammal hårdvara med ett hyggligt nätverkskort. Fram tills nu har vi inte haft råd att köpa så mycket bandbredd och har haft ca 35 Mbps in och ut, ca 5 kpps.
Tidigare i kväll fick vi in betydligt fler paket, ca 100 kpps, vilket gav en del problem. Det ser ut som om vi ansåg ca 80% av dessa vara trasiga och vårt nät gick ner.
Nu frågar jag mig hur mycket man _borde_ kunna få ut ur en FreeBSD-baserad router. Var sitter begränsningarna? Vad skall man tweaka för att få ut max osv? Det enda vi gjort hittills är att slå på polling för att få ner interrupten lite.
Tips?
Linus Nordberg linus@nordberg.se writes:
(Cc Mattias som vet massor om routing, FreeBSD och DDoS.)
Visst har vi några personer på listan som gillar routing och sådant? Peter hjälpte oss med openbgpd för ett tag sedan, t.ex.
Vi kör en FreeBSD 8.2 som router på lite gammal hårdvara med ett hyggligt nätverkskort. Fram tills nu har vi inte haft råd att köpa så mycket bandbredd och har haft ca 35 Mbps in och ut, ca 5 kpps.
Tidigare i kväll fick vi in betydligt fler paket, ca 100 kpps, vilket gav en del problem. Det ser ut som om vi ansåg ca 80% av dessa vara trasiga och vårt nät gick ner.
Nu frågar jag mig hur mycket man _borde_ kunna få ut ur en FreeBSD-baserad router. Var sitter begränsningarna? Vad skall man tweaka för att få ut max osv? Det enda vi gjort hittills är att slå på polling för att få ner interrupten lite.
Tips?
Vad är det för nätverkskort, enligt dmesg?
Jag har haft bra erfarenhet av två kretsfamiljer, Broadcom BCM5704C och vissa av Intels kretsar som FreeBSD kallar em. Det finns trilljarder Broadcom-kretsar med liknande beteckning som enligt mitt begränsade sample är sämre (men säkert också andra bra kretsar). Likaså finns det olika bra Intel-kretsar i em-familjen.
Om jag fattat rätt är en väsentlig skillnad mellan kretsarna buffert- storleken. Med mycket trafik kan det hinna bli fullt innan kernel hinner pilla undan paketen.
Torbjorn Granlund tg@gmplib.org wrote Thu, 22 Mar 2012 22:40:12 +0100:
| Vad är det för nätverkskort, enligt dmesg?
Bägge korten (med två portar var) identifieras som "Intel(R) PRO/1000 Legacy Network Connection 1.0.3". Enligt pciconf så är de två "on board" av typen 82541EI och instickskortet 82546EB.
Den övervägande största mängden trafik tar vi in och ut på samma kort, olika VLAN. Jag undrar om det är icke-optimalt. Vi har en ledig port på instickskortet som man skulle kunna flytta vårt eget nät till. Det kostar dock en port i switchen, vilket är en bristvara f.n.
Linus Nordberg linus@nordberg.se writes:
Bägge korten (med två portar var) identifieras som "Intel(R) PRO/1000 Legacy Network Connection 1.0.3". Enligt pciconf så är de två "on board" av typen 82541EI och instickskortet 82546EB.
Jag tror 82541EI är bra. (Därmed inte sagt att 82546EB är dålig eller sämre, jag har inte bra koll på alla varianter.)
Några som har utrett detta är bifrostfolket, t ex Olof Hagsand.
Den övervägande största mängden trafik tar vi in och ut på samma kort, olika VLAN. Jag undrar om det är icke-optimalt. Vi har en ledig port på instickskortet som man skulle kunna flytta vårt eget nät till. Det kostar dock en port i switchen, vilket är en bristvara f.n.
Vet inte om VLAN kostar.
Eget interface för skötsel anske är en poäng just för att alltid komma in, även vid extrem last?
Men är problem vid 100 kilopaket/s konstigt? Hur stora är paketen? Jag antar att en stor andel är contents, och därför nära MTU. Antar man att alla är MTU-stora och MTU=1500 så blir det 1.2 Gb/s som är ganska mycket på ett Gb-snöre... Är det inte contents som dominerar kanske CPUerna är lastade av RSA-räkningar och därför obenägna att hämta paket från nätverkskortet?
En annan sak: jag tror Intelkorten vill ha custom-kernel för polling. Man kan också vilja sätta HZ=1000 även med storbuffriga nätverkskort. (Detta kan ha blivit inaktuellt med senare FreeBSD-kernel.)
options DEVICE_POLLING options HZ=1000
Torbjorn Granlund tg@gmplib.org wrote Fri, 23 Mar 2012 09:24:54 +0100:
| options DEVICE_POLLING | options HZ=1000
Jo, vi har polling.
Jag tror att jag har hittat en ganska plausibel förklaring till våra problem -- slut på states i pf. Lite newbie, för jag trodde att vi lät bli att hålla state för trafik som vi routade men jag hade fel.
Så tills vidare får vi anse det här avklarat.
Tack för alla bra kommentarer, vi kommer tillbaka till det här när vi närmar oss riktig last!
On 23 Mar, 2012, at 00:15 AM, Linus Nordberg wrote:
Den övervägande största mängden trafik tar vi in och ut på samma kort, olika VLAN. Jag undrar om det är icke-optimalt. Vi har en ledig port på instickskortet som man skulle kunna flytta vårt eget nät till. Det kostar dock en port i switchen, vilket är en bristvara f.n.
Tjo!
Kanske är svårt att svara på i efterhand men kollade ni hur det såg ut med interrupts när det var problem.. antar det är lite det du är inne på, åker paketen in och ut på samma interface så skulle det ju eventuellt vid hög last bli en hel del, vilket jag antar du skulle kunna mitigera med att ha det på 2 olika fysiska interface.. om nu inte dom delar irq.
Och som Torbjörn nämnde så borde eventuellt device polling kunna hjälpa om nu irq är problemet.
Kör ni även pf så kan det ju vara läge att kolla hur stor statetabellen är och liknande.
Men blir också nyfiken hur "vi ansåg ca 80% av dessa vara trasiga och vårt nät gick ner" framgick det?
Mvh Peter
Peter Norin peter@xpd.se wrote Fri, 23 Mar 2012 11:19:09 +0100:
| Kör ni även pf så kan det ju vara läge att kolla hur stor statetabellen är och liknande.
Ka-tching!
| Men blir också nyfiken hur "vi ansåg ca 80% av dessa vara trasiga och vårt nät gick ner" framgick det?
Vi såg att 80% av inkommande paket räknades på 'incoming error' i netstat -ndi och bgpd blev ledsen och "nätet gick ner" eftersom BGP-sessionerna gick sönder.
Tack för hjälpen!
-
Linus Nordberg -
Peter Norin -
Torbjorn Granlund