Re: Multicast stats and bridging

From: William Carrel (william.carrel_at_infospace.com)
Date: 11/19/03

  • Next message: Colin Watson: "Connecting subnet over PPP" 
    To: freebsd-net@freebsd.org
Date: Wed, 19 Nov 2003 14:28:36 -0800

    In article
    <FE045D4D9F7AED4CBFF1B3B813C8533701D9B49F@mail.sandvine.com>,
     Alex Hoff <ahoff@sandvine.com> wrote:

    > well I want my stats to match, so I can follow the data. For example, lets
    > say I send 1000 multicasts packets from pc A through bridge B to pc C. I
    > want the stats for multicasts packets to add up - Incoming 1000 mcast pkts
    > on A-B interface and 1000 outgoing mcasts packets on the B-C interface. (And
    > Im strictly talking about stack counters). Right now they are getting
    > counted as unicast when they leave the bridge. Does that make more sense?
    > Sorry if I was not clear before.

    The logic to record these packets differently would be needed to be
    inserted into src/sys/net/bridge.c:bdg_forward().

    >From cursory reading of the code though, the destination is only
    recorded on incoming packets. All outgoing packets forwarded out an
    interface are just counted as BDG_OUT. To have BDG_MCAST counted both
    in and out packets would introduce some complexity to trying to make
    sense of those numbers. Besides, unless the interface is full or some
    other error condition all multicast (and broadcast) packets will be
    bridged. If an error results bdg_dropped will be incremented.

    In sum, it isn't really "counted as unicast" at all. It's simply
    counted as an outgoing packet, just like all the other outgoing packets. 

    -- 
William A. Carrel
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Colin Watson: "Connecting subnet over PPP"

    Relevant Pages

    • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
      ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
      (Linux-Kernel)
    • RE: Multicast stats and bridging
      ... well I want my stats to match, so I can follow the data. ... say I send 1000 multicasts packets from pc A through bridge B to pc C. ... want the stats for multicasts packets to add up - Incoming 1000 mcast pkts ... counted as unicast when they leave the bridge. ...
      (freebsd-net)
    • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
      ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
      (Linux-Kernel)
    • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
      ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
      (Linux-Kernel)
    • Re: Question regarding using AES in CTR mode to encrypt UDP
      ... but in CTR mode I have a problem synchronising the counter of the CTR ... Reject old packets with a soft error ... synchronization of the CTR counters (assuming I still want to use CTR, ... and I need the exact same counters in order to reverse the encryption ...
      (sci.crypt)