Hi all, Just been reading the cisco thread about reading/graphing traffic stats. I'm bogged down with too much and I know FreeBSD can easily provide the answer to everyone's graphing needs. FreeBSD works too well even in bridged mode. Can anyone do a MRTG solution ( 5 minute average graphing, user account access and protocol analyser ) on FreeBSD and market for themselves to those who need the graphing solution? If you are a network admin/edge admin, would you like to have a device in bridged mode ( not transparent in the network but requires an ip ) that will help you graph and perform internet traffic stats which may aslo help you discuss your SLAs with your provider. Hope you all will be able to connect on this one if you have the time, between developer and admin. Just sharing a thot and suggestion with fellow skunks.... Rgds.
For network admins, here is how FreeBSD with graphing will make your life easy. A sample config : ++++++++++++++++ ++++++++++++++++ Internet ======+ +-ETH---ETH--+ FREEBSD BOX IN +ETH------SWITCH etc to INTERNAL NETWORK + Cisco Router + + BRIDGED MODE + ++++++++++++++++ ++++++++++++++++ With Bridged Mode, there is no need to subnet/segment your network. The bridge can be on the same subnet as the Cisco ETH subnet. Incase you want to use the FreeBSD as router, then segmenting necessary. Use the Bridge to trap and poll each device too. Many functions can be done but simplest is that of Monitor and Graphing. Anyway, its upto FreeBSD gurus and yourselves. HTHs. On Tue, Sep 29, 2009 at 8:52 PM, aki <aki275@googlemail.com> wrote:
Hi all,
Just been reading the cisco thread about reading/graphing traffic stats. I'm bogged down with too much and I know FreeBSD can easily provide the answer to everyone's graphing needs. FreeBSD works too well even in bridged mode. Can anyone do a MRTG solution ( 5 minute average graphing, user account access and protocol analyser ) on FreeBSD and market for themselves to those who need the graphing solution?
If you are a network admin/edge admin, would you like to have a device in bridged mode ( not transparent in the network but requires an ip ) that will help you graph and perform internet traffic stats which may aslo help you discuss your SLAs with your provider.
Hope you all will be able to connect on this one if you have the time, between developer and admin.
Just sharing a thot and suggestion with fellow skunks....
Rgds.
ahem... this doesn't appear to be FreeBSD-specific behavior, but rather very standard in *nix derivatives (of which *BSD is one of them, Linux being another). <begin_hesitation> Or is that not the case? If not, gimme a moment to don my flame-suit on before I get hosed ;) </end_hesitation> saidi On Tue, Sep 29, 2009 at 2:12 PM, aki <aki275@googlemail.com> wrote:
For network admins, here is how FreeBSD with graphing will make your life easy. A sample config :
++++++++++++++++ ++++++++++++++++ Internet ======+ +-ETH---ETH--+ FREEBSD BOX IN +ETH------SWITCH etc to INTERNAL NETWORK + Cisco Router + + BRIDGED MODE + ++++++++++++++++ ++++++++++++++++
With Bridged Mode, there is no need to subnet/segment your network. The bridge can be on the same subnet as the Cisco ETH subnet. Incase you want to use the FreeBSD as router, then segmenting necessary. Use the Bridge to trap and poll each device too. Many functions can be done but simplest is that of Monitor and Graphing.
Anyway, its upto FreeBSD gurus and yourselves.
HTHs.
On Tue, Sep 29, 2009 at 8:52 PM, aki <aki275@googlemail.com> wrote:
Hi all,
Just been reading the cisco thread about reading/graphing traffic stats. I'm bogged down with too much and I know FreeBSD can easily provide the answer to everyone's graphing needs. FreeBSD works too well even in bridged mode. Can anyone do a MRTG solution ( 5 minute average graphing, user account access and protocol analyser ) on FreeBSD and market for themselves to those who need the graphing solution?
If you are a network admin/edge admin, would you like to have a device in bridged mode ( not transparent in the network but requires an ip ) that will help you graph and perform internet traffic stats which may aslo help you discuss your SLAs with your provider.
Hope you all will be able to connect on this one if you have the time, between developer and admin.
Just sharing a thot and suggestion with fellow skunks....
Rgds.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science: http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi: http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general
Hehehe..Saidimu, what can I say, I'm a beliver in FreeBSD. I've just suggested an answer to a question. lol! :-) On Tue, Sep 29, 2009 at 9:29 PM, saidimu apale <saidimu@gmail.com> wrote:
ahem... this doesn't appear to be FreeBSD-specific behavior, but rather very standard in *nix derivatives (of which *BSD is one of them, Linux being another).
<begin_hesitation> Or is that not the case? If not, gimme a moment to don my flame-suit on before I get hosed ;) </end_hesitation>
Saidimu, I think it has to with packets per second. But someone else says it better ( corrections welcome ) about FreeBSD 7.0 : "In a world of big files (video clips, entire DVDs, etc.), fast network connections (ADSL, VDSL, Cable, fiber to the home), and global distribution, the traditional TCP default configuration was hitting the socket buffer limit. Because TCP offers reliable data transport it has to keep a buffer of data sent until the remote end has acknowledged reception of it. It takes the ACK a full round trip (RTT, as seen with ping) to make it back. Thus for fast connections over large distances, like from U.S.A. to Europe or Asia, we need large socket buffer to keep all the unacknowledged data around. FreeBSD had a default 32 K send socket buffer. This supports a maximal transfer rate of only slightly more than 2 Mbit/s on a 100 ms RTT trans-continental link. Or at 200 ms just above 1 Mbit/s. With TCP send buffer auto scaling in its default settings it supports 20 Mbit/s at 100 ms and 10 Mbit/s at 200 ms (socket buffer at 256 KB) per TCP connection. That's an improvement of factor 10, or 1000%. If you have very fast Internet connections very far apart you may want to further adjust the defaults upwards. The nice thing about socket buffer auto-tuning is the conservation of kernel memory which is in somewhat limited supply. The tuning happens based on actual measured connection parameters and are adjusted dynamically. For example a SSH session on a 20 Mbit/s 100 ms link will not adjust upwards because the initial default parameters are completely sufficient and do not slow down the session. On the other hand a 1GB file transfer on the same connection will cause the tuning to kick in and to quickly increase the socket buffers to the max." On Tue, Sep 29, 2009 at 9:35 PM, aki <aki275@googlemail.com> wrote:
Hehehe..Saidimu, what can I say, I'm a beliver in FreeBSD. I've just suggested an answer to a question. lol! :-)
On Tue, Sep 29, 2009 at 9:29 PM, saidimu apale <saidimu@gmail.com> wrote:
ahem... this doesn't appear to be FreeBSD-specific behavior, but rather very standard in *nix derivatives (of which *BSD is one of them, Linux being another).
<begin_hesitation> Or is that not the case? If not, gimme a moment to don my flame-suit on before I get hosed ;) </end_hesitation> saidi
Relax, keep your T-shirt on. You're correct. But rather than do all that, if your router supports NetFlow, why introduce a single point of failure in the network path, just for graphing? You can set up flow-tools or ntop on your *nix box, have the router export flows to the box and visualize your traffic really nicely. (unless your *nix box is doing something more, like bandwidth management/transparent firewall) BR, S
participants (3)
-
aki -
saidimu apale -
Steve Muchai