1. 05 8月, 2014 1 次提交
  2. 17 5月, 2014 1 次提交
  3. 28 4月, 2014 1 次提交
  4. 02 1月, 2014 1 次提交
  5. 20 12月, 2013 1 次提交
  6. 11 12月, 2013 1 次提交
  7. 19 10月, 2013 1 次提交
  8. 16 9月, 2013 1 次提交
  9. 21 8月, 2013 1 次提交
  10. 11 6月, 2013 2 次提交
  11. 29 3月, 2013 1 次提交
  12. 25 3月, 2013 1 次提交
  13. 18 3月, 2013 1 次提交
  14. 12 3月, 2013 2 次提交
  15. 15 2月, 2013 1 次提交
  16. 14 2月, 2013 4 次提交
  17. 03 1月, 2013 1 次提交
  18. 30 12月, 2012 1 次提交
  19. 20 12月, 2012 1 次提交
  20. 11 12月, 2012 1 次提交
  21. 06 12月, 2012 1 次提交
    • D
      bridge: implement multicast fast leave · c2d3babf
      David S. Miller 提交于
      V3: make it a flag
      V2: make the toggle per-port
      
      Fast leave allows bridge to immediately stops the multicast
      traffic on the port receives IGMP Leave when IGMP snooping is enabled,
      no timeouts are observed.
      
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Stephen Hemminger <shemminger@vyatta.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      c2d3babf
  22. 19 11月, 2012 2 次提交
  23. 15 11月, 2012 3 次提交
    • S
      bridge: add root port blocking · 1007dd1a
      stephen hemminger 提交于
      This is Linux bridge implementation of root port guard.
      If BPDU is received from a leaf (edge) port, it should not
      be elected as root port.
      
      Why would you want to do this?
      If using STP on a bridge and the downstream bridges are not fully
      trusted; this prevents a hostile guest for rerouting traffic.
      
      Why not just use netfilter?
      Netfilter does not track of follow spanning tree decisions.
      It would be difficult and error prone to try and mirror STP
      resolution in netfilter module.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1007dd1a
    • S
      bridge: implement BPDU blocking · a2e01a65
      stephen hemminger 提交于
      This is Linux bridge implementation of STP protection
      (Cisco BPDU guard/Juniper BPDU block). BPDU block disables
      the bridge port if a STP BPDU packet is received.
      
      Why would you want to do this?
      If running Spanning Tree on bridge, hostile devices on the network
      may send BPDU and cause network failure. Enabling bpdu block
      will detect and stop this.
      
      How to recover the port?
      The port will be restarted if link is brought down, or
      removed and reattached.  For example:
       # ip li set dev eth0 down; ip li set dev eth0 up
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2e01a65
    • S
      bridge: bridge port parameters over netlink · 25c71c75
      stephen hemminger 提交于
      Expose bridge port parameter over netlink. By switching to a nested
      message, this can be used for other bridge parameters.
      
      This changes IFLA_PROTINFO attribute from one byte to a full nested
      set of attributes. This is safe for application interface because the
      old message used IFLA_PROTINFO and new one uses
       IFLA_PROTINFO | NLA_F_NESTED.
      
      The code adapts to old format requests, and therefore stays
      compatible with user mode RSTP daemon. Since the type field
      for nested and unnested attributes are different, and the old
      code in libnetlink doesn't do the mask, it is also safe to use
      with old versions of bridge monitor command.
      
      Note: although mode is only a boolean, treating it as a
      full byte since in the future someone will probably want to add more
      values (like macvlan has).
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      25c71c75
  24. 01 11月, 2012 2 次提交
    • J
      net: set and query VEB/VEPA bridge mode via PF_BRIDGE · 2469ffd7
      John Fastabend 提交于
      Hardware switches may support enabling and disabling the
      loopback switch which puts the device in a VEPA mode defined
      in the IEEE 802.1Qbg specification. In this mode frames are
      not switched in the hardware but sent directly to the switch.
      SR-IOV capable NICs will likely support this mode I am
      aware of at least two such devices. Also I am told (but don't
      have any of this hardware available) that there are devices
      that only support VEPA modes. In these cases it is important
      at a minimum to be able to query these attributes.
      
      This patch adds an additional IFLA_BRIDGE_MODE attribute that can be
      set and dumped via the PF_BRIDGE:{SET|GET}LINK operations. Also
      anticipating bridge attributes that may be common for both embedded
      bridges and software bridges this adds a flags attribute
      IFLA_BRIDGE_FLAGS currently used to determine if the command or event
      is being generated to/from an embedded bridge or software bridge.
      Finally, the event generation is pulled out of the bridge module and
      into rtnetlink proper.
      
      For example using the macvlan driver in VEPA mode on top of
      an embedded switch requires putting the embedded switch into
      a VEPA mode to get the expected results.
      
      	--------  --------
              | VEPA |  | VEPA |       <-- macvlan vepa edge relays
              --------  --------
                 |        |
                 |        |
              ------------------
              |      VEPA      |       <-- embedded switch in NIC
              ------------------
                      |
                      |
              -------------------
              | external switch |      <-- shiny new physical
      	-------------------          switch with VEPA support
      
      A packet sent from the macvlan VEPA at the top could be
      loopbacked on the embedded switch and never seen by the
      external switch. So in order for this to work the embedded
      switch needs to be set in the VEPA state via the above
      described commands.
      
      By making these attributes nested in IFLA_AF_SPEC we allow
      future extensions to be made as needed.
      
      CC: Lennert Buytenhek <buytenh@wantstofly.org>
      CC: Stephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2469ffd7
    • J
      net: create generic bridge ops · e5a55a89
      John Fastabend 提交于
      The PF_BRIDGE:RTM_{GET|SET}LINK nlmsg family and type are
      currently embedded in the ./net/bridge module. This prohibits
      them from being used by other bridging devices. One example
      of this being hardware that has embedded bridging components.
      
      In order to use these nlmsg types more generically this patch
      adds two net_device_ops hooks. One to set link bridge attributes
      and another to dump the current bride attributes.
      
      	ndo_bridge_setlink()
      	ndo_bridge_getlink()
      
      CC: Lennert Buytenhek <buytenh@wantstofly.org>
      CC: Stephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5a55a89
  25. 11 9月, 2012 1 次提交
  26. 27 6月, 2012 1 次提交
  27. 16 4月, 2012 2 次提交
    • J
      net: add generic PF_BRIDGE:RTM_ FDB hooks · 77162022
      John Fastabend 提交于
      This adds two new flags NTF_MASTER and NTF_SELF that can
      now be used to specify where PF_BRIDGE netlink commands should
      be sent. NTF_MASTER sends the commands to the 'dev->master'
      device for parsing. Typically this will be the linux net/bridge,
      or open-vswitch devices. Also without any flags set the command
      will be handled by the master device as well so that current user
      space tools continue to work as expected.
      
      The NTF_SELF flag will push the PF_BRIDGE commands to the
      device. In the basic example below the commands are then parsed
      and programmed in the embedded bridge.
      
      Note if both NTF_SELF and NTF_MASTER bits are set then the
      command will be sent to both 'dev->master' and 'dev' this allows
      user space to easily keep the embedded bridge and software bridge
      in sync.
      
      There is a slight complication in the case with both flags set
      when an error occurs. To resolve this the rtnl handler clears
      the NTF_ flag in the netlink ack to indicate which sets completed
      successfully. The add/del handlers will abort as soon as any
      error occurs.
      
      To support this new net device ops were added to call into
      the device and the existing bridging code was refactored
      to use these. There should be no required changes in user space
      to support the current bridge behavior.
      
      A basic setup with a SR-IOV enabled NIC looks like this,
      
                veth0  veth2
                  |      |
                ------------
                |  bridge0 |   <---- software bridging
                ------------
                     /
                     /
        ethx.y      ethx
          VF         PF
           \         \          <---- propagate FDB entries to HW
           \         \
        --------------------
        |  Embedded Bridge |    <---- hardware offloaded switching
        --------------------
      
      In this case the embedded bridge must be managed to allow 'veth0'
      to communicate with 'ethx.y' correctly. At present drivers managing
      the embedded bridge either send frames onto the network which
      then get dropped by the switch OR the embedded bridge will flood
      these frames. With this patch we have a mechanism to manage the
      embedded bridge correctly from user space. This example is specific
      to SR-IOV but replacing the VF with another PF or dropping this
      into the DSA framework generates similar management issues.
      
      Examples session using the 'br'[1] tool to add, dump and then
      delete a mac address with a new "embedded" option and enabled
      ixgbe driver:
      
      # br fdb add 22:35:19:ac:60:59 dev eth3
      # br fdb
      port    mac addr                flags
      veth0   22:35:19:ac:60:58       static
      veth0   9a:5f:81:f7:f6:ec       local
      eth3    00:1b:21:55:23:59       local
      eth3    22:35:19:ac:60:59       static
      veth0   22:35:19:ac:60:57       static
      #br fdb add 22:35:19:ac:60:59 embedded dev eth3
      #br fdb
      port    mac addr                flags
      veth0   22:35:19:ac:60:58       static
      veth0   9a:5f:81:f7:f6:ec       local
      eth3    00:1b:21:55:23:59       local
      eth3    22:35:19:ac:60:59       static
      veth0   22:35:19:ac:60:57       static
      eth3    22:35:19:ac:60:59       local embedded
      #br fdb del 22:35:19:ac:60:59 embedded dev eth3
      
      I added a couple lines to 'br' to set the flags correctly is all. It
      is my opinion that the merit of this patch is now embedded and SW
      bridges can both be modeled correctly in user space using very nearly
      the same message passing.
      
      [1] 'br' tool was published as an RFC here and will be renamed 'bridge'
          http://patchwork.ozlabs.org/patch/117664/
      
      Thanks to Jamal Hadi Salim, Stephen Hemminger and Ben Hutchings for
      valuable feedback, suggestions, and review.
      
      v2: fixed api descriptions and error case with both NTF_SELF and
          NTF_MASTER set plus updated patch description.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77162022
    • E
      net: cleanup unsigned to unsigned int · 95c96174
      Eric Dumazet 提交于
      Use of "unsigned int" is preferred to bare "unsigned" in net tree.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      95c96174
  28. 02 4月, 2012 1 次提交
  29. 02 12月, 2011 1 次提交
  30. 19 10月, 2011 1 次提交