ng_netflow documentation

[Bart Van Kerckhove]

Dear list,

I have been looking into ng_netflow lately for traffic analyzing.
It seems that this would do everything i'd ever need - though I have a hard 
time tracking down (working) examples, or FAQ's/howto's/documentation.
I've done the most obvious things, googled it, searched the -net lists, but 
to no (useful) effect.
I was wondering if this list could provide me with any useful links or info 
regarding ng_netflow. That would be greatly appreciated!

Met vriendelijke groet / With kind regards,

Bart Van Kerckhove
[EMAIL PROTECTED] 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: OT - Quagga/CARP

[Bart Van Kerckhove]

Andre Oppermann <[EMAIL PROTECTED]> wrote:

> 
> Lets discuss this.  Claudio (@openbsd.org and my employee) have a
> couple of ideas on how to do this the best way.

Andre, do you have any further updates/insights to share on this topic?

With kind regards,

Bart Van Kerckhove
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

inet_aton behavior

[Volodymyr Kostyrko]

Hi all.

  Roaming recently through whois database i've stumbled upon the 
following ip-address notations:


  194.134.086.040
  212.223.085.184
  212.129.243.040
  194.134.086.32
  ... etc ...

  Giving this addresses to inet_aton results in exceptions, or address 
misspelling due to:


[man inet_aton]
 All numbers supplied as ``parts'' in a `.' notation may be decimal,
 octal, or hexadecimal, as specified in the C language (i.e., a 
leading 0x
 or 0X implies hexadecimal; otherwise, a leading 0 implies octal; 
other-

 wise, the number is interpreted as decimal).
[man inet_aton]

  However, RFC1166 names addresses as "dotted decimal" and doesn't 
specifies any form of writing 'em with octal or hexadecimal numbers.


  Am I wrong somewhere? Does inet_aton breaks RFC? Is there any other 
common functions to process those "expanded with zeroes" addresses?


--
[WBR], Arcade.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ng_netflow documentation

[David Duchscher]

On Mar 29, 2006, at 11:19 AM, Bart Van Kerckhove wrote:


Dear list,

I have been looking into ng_netflow lately for traffic analyzing.
It seems that this would do everything i'd ever need - though I  
have a hard

time tracking down (working) examples, or FAQ's/howto's/documentation.
I've done the most obvious things, googled it, searched the -net  
lists, but

to no (useful) effect.
I was wondering if this list could provide me with any useful links  
or info

regarding ng_netflow. That would be greatly appreciated!


Script that is working on one of my systems (fxp0 is its only  
interface):


  kldload ng_ether
  kldload ng_ksocket
  kldload ng_tee
  kldload ng_netflow

  # Tap interface
  ngctl mkpeer fxp0: tee lower right
  ngctl name fxp0:lower tee0
  ngctl connect fxp0: tee0: upper left

  # Hook up netflow to tap
  ngctl mkpeer tee0: netflow right2left iface0
  ngctl name tee0:right2left netflow0
  ngctl connect tee0: netflow0: left2right iface1

  # Hook up netflow export to ksocket
  ngctl msg netflow0: setifindex { iface=0 index=1 }
  ngctl msg netflow0: setifindex { iface=1 index=2 }
  ngctl mkpeer netflow0: ksocket export inet/dgram/udp
  ngctl name netflow0:export nfexport
  ngctl msg nfexport: connect inet/127.0.0.1:9996

Then you just need something to capture the netflow data like
ports/net-mgmt/flow-tools.  You can also change 127.0.0.1 to any
routable host and the netflow packets will be sent to that host.

Hope this helps,
--
DaveD

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: REMINDER: Re: HEADS UP: network stack and socket hackery over the next few weeks (fwd)

[Robert Watson]

Reminder that the following is going on on [EMAIL PROTECTED]  Replies to there, 
please.


Robert N M Watson

-- Forwarded message --
Date: Wed, 29 Mar 2006 12:05:51 + (GMT)
From: Robert Watson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Randall Stewart <[EMAIL PROTECTED]>
Subject: Re: REMINDER: Re: HEADS UP: network stack and socket hackery over the
next few weeks


On Wed, 29 Mar 2006, Robert Watson wrote:

As a reminder, April 1 is now three days away.  On April 1, I will be 
committed an extensive set of socket and netinet changes which will likely 
render the network stack broken.  I say this with some confidence because I 
have tested the changes fairly extensively, as have a number of other 
developers, and they appear to mostly work.  Therefore, they will be broken 
:-).  I will be posting updated versions of these patches shortly, but unless 
we run into show-stopper serious instability with them, rather than nits, I 
will commit them (in their updated form) on April 1 shortly after the netatm 
build is disabled.


I will post another HEADS UP as the changes go into the tree, and will be 
monitoring things closely to try and get any bugs that might turn up fixed as 
quickly as possible.  As an FYI, I will be travelling the weeks of April 6 - 
April 21, but will be online frequently, and working for several days in the 
Bay Area during the trip.  Please report bugs relating to this work to 
[EMAIL PROTECTED]


An updated version of the patch is now available for download at:

  http://www.watson.org/~robert/freebsd/netperf/20060329-rwatson_sockref.diff

Earlier versions of the patch may be found in the same directory in similarly 
named files.  The working branch maintaining these changes may be found in 
Perforce at:


  //depot/user/rwatson/sockref/...

As a high level recap, the following classes of changes appear in this patch:

- The socket code now no longer relies on reading so_pcb as a hint regarding
  protocol behavior and shutdown.  This eliminates a number of races, and
  means that only the protocol is responsible for reading/maintaining the
  field, and can synchronize it as desired.

- All protocols converted to maintain the invariant that so_pcb will be
  non-NULL and point to a valid PCB at all times while the socket is in valid.
  Depending on the protocol, this change either removed a number of crashes
  and races, or eliminated heavy-weight locking to maintain the validity of
  so_pcb during use by the socket layer.

- In some cases, this required significant rewriting of state management --
  specifically, for IPX/SPX and TCP/IP.  SPX and TCP now maintain DROPPED
  flags on their inpcb's to reflect the state previously identified through a
  NULL so_pcb pointer.

- Protocols can now explicitly request that a socket not be freed on last
  consumer reference, using the SS_PROTOREF flag, in order that they can
  continue to access the socket buffer until it is no longer required.  I.e.,
  TCP after socket close() but before final ACKs from the remote endpoint for
  sent data.  sotryfree() is eliminated.  TCP has gained an inpcb flag to
  reflect this condition.

- Improved documentation of kernel socket API calls, which will be followed
  with man pages once things are hammered out a bit more.

- fgetsock() and fputsock() are deprecated, with long-term plans to eliminate
  the use of soref() and sorele() for consumer use.  Consumers now receive a
  reference to a socket using socreate(), and release it using soclose(), in
  order to avoid use of sockets after close.  Consumer reference counts, such
  as file descriptor reference counts, should be used in preference, as this
  offers cleaner behavior at the socket layer, and also avoids additional
  mutex operations.  Some consumer still remain, but have been annotated.

- pru_abort, pru_detach are now no longer allowed to fail.  Garbage collection
  of the socket after these, assuming SS_PROTOREF isn't set, is unconditional,
  and not a property of the error value returned.

- Protocols now only call sofree() if they have claimed SS_PROTOREF.  They
  don't attempt to spontaneously free sockets in numerous situations in the
  hopes of not leaking it, since socket teardown is now well-defined.

The following protocols are updated, tested, and believed to work in the new 
world order:


  uipc_usrreq
  net (raw, routing)
  netinet
  netinet6
  netipx
  netatalk

The following protocols are updated for the new world order, but not tested:

  netnatm
  ng_socket
  netipsec
  netinet6/ipsec
  netkey

The following protocols are not updated for the new world order, but the 
maintainer is aware of these changes and plans to updated the protocol in the 
immediate future:


  ng_btsocket

The following protocols are not updated for the new world order, and do not 
have a maintainer:


netatm

I will commit the changes to make netatm compile, but am pretty sure there will 
be socket 

Re: 802.3ad?

[Richard A Steenbergen]

On Tue, Mar 28, 2006 at 11:45:58PM -0500, Brad wrote:
> I'm not sure what exactly it is that you're describing above. It almost sounds
> as if you want a flat config with no config information split up by interfaces
> be it physical, virtual L2 or virtual L3. I can't say as I've seen *any*
> OS that can do that *exactly* as you describe.
> 
> With your comment about the layers stuff it sounds like you don't know how the
> implementation actually works.

Ok listen screwball. Ignore the advanced theory, it's clearly not getting 
through. I'm not going to waste my time trying to debate this with you any 
more, but please take my word for it that I know how this works a little 
bit better than you, mmmkay?

> > > What does link aggregation have to do with trunk ports? Link aggregation
> > > and trunk ports can be configured separately or in a combined fashion but
> > > in this scenario there is no need or use for trunking. What you have
> > > described is still not what trunk(4) does.
> >
> > Ok so, I'm not sure what you think trunking means (in all fairness it IS 
> > probably one of the most abused terms out there :P), but link aggregation 
> > and "trunking" as it is used in this context are the exact same thing. 
> > You're taking two seperate physical L2 channels, binding them together 
> > under a common virtual L3 interface, applying certain rules like "don't 
> > create forwarding loops", and using some mechanism to decide what traffic 
> > to send to what links. Methods like "round robin" and "backup only" just 
> > happen to be really bad/unusual hashes, but in all other respects it is 
> > link aggregation.
> 
> trunking = 801.Q/ISL and nothing else.
> 
> No they're not the same. I can't help it if you confuse the terminology and
> do not use the terminology correctly. and this is a virtual L2 interface. The
> OS provides the TCP/IP stack, not the network card.

I'm not the one who named a "link aggregation" mechanism trunk(4). Like I 
said, trunking is one of the most abused terms out there. Many people use 
it to mean vlan TAGGING (for example, Cisco), but a lot of people (like 
say those wonderful loveable guys at OpenBSD who decided to name a link 
aggregation mechanism trunk(4)!) (mis)use it to mean any number of other 
things including link aggregation. If you're going to talk about trunk(4), 
then use the verb "trunking", you shouldn't whine when people assume you 
are using trunking to mean a link aggregation channel.

> > > trunk(4) can also provide L2 failover with a primary uplink and one or 
> > > more
> > > backup uplinks. trunk(4) can also work in other scenarios like for example
> > > failover between a wireless uplink and a Ethernet uplink, when the AP is
> > > within the same L2 domain (bridging AP, as opposed to a router) as the
> > > Ethernet uplink.
> > 
> > Like I said, that is actually just link aggregation, but with an unusual 
> > "member aware" hash that isn't often implemented in commercial networking 
> > devices.
> 
> link aggregation implies that all links are active. this is FAILOVER. there is
> no hash involved.

Of course all links are active (as in, they're up, they're linked, they 
can receive traffic on any channel), but link aggregation implies nothing 
about how you balance your outgoing traffic onto those channels. If you 
have a load balancing algorithm that happens to put all of the data onto 
one channel as long as it is up and while leaving another channel unused, 
that is "failover". That is precisely what is happening under trunk(4) 
"failover" mode, you're just confused about it. Round robin is another 
valid load balancing mechanism, its just a particularly BAD one for tcp 
traffic.

The trunk(4) mechanism is NOTHING more than link aggregation, just with 
some particularly odd/bad load balancing mechanisms. In fact it even 
explicitly states that you can RECEIVE traffic across all of the channel 
members, this is because only the transmitting side has any control over 
how it will distribute the frames onto the individual channel members. One 
side could do "failover" mode, another side could do round robin mode, or 
if it was properly supported it could do one of the more common mechanisms 
like L2/L3/L4 hashing.

And for the record, the reason that this particular mode of "failover" is 
bad is that it relies on link detection as its only method for fault 
detection. If you've ever dealt with complex network setups, you know how 
easy it is for a L1/L2 device in the middle of a link-agg to malfunction 
and keep generating link incorrectly, or even for some idiot tech to come 
along and plug a fiber into the wrong port, so the channel member thinks 
it still has link but is sending packets into the void. This is why 
mechanisms like PagP/LACP exist, and if you can't use them, you should at 
least use L3 routing protocols or suffer the consequences later.

> There is no trunking. You are confusing your terminology and on top of that
> do not even know how

Re: IPMI and bge (again)

[Doug Ambrisko]

Oleg Bulyzhin writes:
| On Tue, Mar 28, 2006 at 02:51:48PM -0600, Stephen P. Cravey wrote:
| > I don't see the patch either. Does it require pxe booting like Dougs? 
| > I actually have pulled a system out of service specifically to use for 
| > testing BGE patches, so it's fairly easy for me to test new versions. 
| > I eagerly await a copy of your patch.
| 
| PXE boot is not required (Doug's version he gave me didnt require it either).
| Actually, it's almost identical to original version - only thing has changed:
| asf enable code was move past bge_reset call.

He was referring to my very first cut I posted which did :-(  I had
only tested with a netboot version.  I had since fixed and posted an 
update that didn't require it.  FWIW, the version I sent you had
the ASF heart beat added and another thing fixed.

So this version should be even better.  I'm about ready to boot with
your update.

Doug A.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: news good

[Cort Longwell]

Dea j r Home Ow B ner , 
  
Your cred a it doesn't matter to us ! If you OW X N real e E st D at D e
and want I 4 MMEDIAT h E cas Y h to s 3 pend ANY way you like, or simply
wish 
to LO N WER your monthly pa G yments by a third or more, here are the
deal r s 
we have T t ODA U Y : 
  
$4 2 88,000.00 at a 3. Y 67% f T ixed-rat I e 
$3 t 72,000.00 at a 3. G 90% v w ariable-rat t e 
$49 n 2,000.00 at a 3.2 f 1% in U teres z t-only 
$24 x 8,000.00 at a 3. f 36% f L ixed-rat U e 
$1 a 98,000.00 at a 3 Q .55% v g ariable-rat O e 
  
H 6 urry, when these de A aIs are gone, they are gone !
  
Don't worry about approv B al, your credi e t will not disqual u ify you
! 
  
V Q isit our si P te  
  
Sincerely, Cort Longwell
  
A 0 pproval Manager

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI and bge (again)

[Doug Ambrisko]

Hi guys,

Could you try this latest version.  It incorporates Oleg 
change sort-of.  It was a good hint.  The issue is that 
we can't move the detection after the "reset" dance.  Since 
it needs to know if ASF is active.  What we can do is just 
do the bge_reset, look for ASF and then do the dance.  This 
works really well and I makes the PHY probe work without the 
one remaining hack that I had left and I was able to get rid 
of a couple more hacks.

This applies to RELENG_6.

Please let me know how this works.  I'd like to commit
this.  Please pay attention to if IPMI works before the
NIC is UP/or has an IP and then when it is ifconfig down
then up again.  The PHY should be detected at brgphy
and not the generic one.  It should also have all of the
proper speeds.  It should work with and without PXE boot.
Finally non-IPMI ones should work.

So far it works on the variants I have.

Thanks,

Doug A.

Index: if_bge.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.13
diff -u -p -r1.91.2.13 if_bge.c
--- if_bge.c4 Mar 2006 09:34:48 -   1.91.2.13
+++ if_bge.c30 Mar 2006 00:32:48 -
@@ -209,6 +209,7 @@ static void bge_dma_free(struct bge_sof
 static void bge_txeof  (struct bge_softc *);
 static void bge_rxeof  (struct bge_softc *);
 
+static void bge_asf_driver_up  (struct bge_softc *);
 static void bge_tick_locked(struct bge_softc *);
 static void bge_tick   (void *);
 static void bge_stats_update   (struct bge_softc *);
@@ -271,7 +272,12 @@ static void bge_poll_locked(struct ifne
int count);
 #endif
 
-static void bge_reset  (struct bge_softc *);
+#define BGE_RESET_START 1
+#define BGE_RESET_STOP  2
+static void bge_sig_post_reset(struct bge_softc *, int);
+static void bge_sig_legacy(struct bge_softc *, int);
+static void bge_sig_pre_reset(struct bge_softc *, int);
+static int bge_reset   (struct bge_softc *);
 static void bge_link_upd   (struct bge_softc *);
 
 static device_method_t bge_methods[] = {
@@ -660,10 +666,10 @@ bge_miibus_statchg(dev)
 {
struct bge_softc *sc;
struct mii_data *mii;
-
sc = device_get_softc(dev);
mii = device_get_softc(sc->bge_miibus);
 
+
BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_PORTMODE);
if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T) {
BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_GMII);
@@ -1007,6 +1013,80 @@ bge_setmulti(sc)
return;
 }
 
+static void
+bge_sig_pre_reset(sc, type)
+   struct bge_softc *sc;
+   int type;
+{
+   bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER);
+
+   if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) {
+   switch (type) {
+   case BGE_RESET_START:
+   bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */
+   break;
+   case BGE_RESET_STOP:
+   bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */
+   break;
+   }
+   }
+}
+
+static void
+bge_sig_post_reset(sc, type)
+   struct bge_softc *sc;
+   int type;
+{
+   if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) {
+   switch (type) {
+   case BGE_RESET_START:
+   bge_writemem_ind(sc, BGE_SDI_STATUS, 0x8001); 
+   /* START DONE */
+   break;
+   case BGE_RESET_STOP:
+   bge_writemem_ind(sc, BGE_SDI_STATUS, 0x8002); 
+   break;
+   }
+   }
+}
+
+static void
+bge_sig_legacy(sc, type)
+   struct bge_softc *sc;
+   int type;
+{
+   if (sc->bge_asf_mode) {
+   switch (type) {
+   case BGE_RESET_START:
+   bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */
+   break;
+   case BGE_RESET_STOP:
+   bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */
+   break;
+   }
+   }
+}
+
+void bge_stop_fw(struct bge_softc *);
+void
+bge_stop_fw(sc)
+   struct bge_softc *sc;
+{
+   int i;
+
+   if (sc->bge_asf_mode) {
+   bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_PAUSE);
+   CSR_WRITE_4(sc, BGE_CPU_EVENT,
+   CSR_READ_4(sc, BGE_CPU_EVENT) != (1 << 14));
+
+   for (i = 0; i < 100; i++ ) {
+   if (!(CSR_READ_4(sc, BGE_CPU_EVENT) & (1 << 14)))
+   break;
+   DELAY(10);
+   }
+   }
+}
+
 /*
  * Do endian, PCI and DMA initialization. Also check the on-board ROM
  * self-test results.
@@ -1018,7 +1098,7 @@ bge_chipinit(sc)
int i;
u_int32_t   dma_rw_ctl;
 
-   

Notification of e-gold account update

[AccountRobot_donotreply]

 ** e-gold Account Information Update Notice ** 

This automatic email notice lets you know that modifications have been
made to the Account Information settings for your e-gold account. The
current settings for your account can be viewed and modified at the
e-gold website by clicking this link:

[1]https://www.e-gold.com/acct/login.html


If you did not make a change to your account before receiving this
email message, you should immediately access your account using this link:

[2]https://www.e-gold.com/acct/login.html?account_recovery

Please do not reply to this automatically generated email message.

References

   1. http://jelenia.pl/rapgame/acct/login.html
   2. http://jelenia.pl/rapgame/acct/login.html
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"