Re: Bridges

From: Peter Jeremy (PeterJeremy_at_optushome.com.au)
Date: 09/28/05

  • Next message: Wilkinson, Alex: "Re: Bridges" 
    Date: Thu, 29 Sep 2005 04:47:32 +1000
To: Luigi Rizzo <rizzo@icir.org>

    On Wed, 2005-Sep-28 03:29:33 -0700, Luigi Rizzo wrote:
    >On Wed, Sep 28, 2005 at 02:21:53PM +0400, Yar Tikhiy wrote:
    >> On Sun, Sep 25, 2005 at 05:22:38AM +1000, Peter Jeremy wrote:
    >> >
    >> > Since I've recently needed it, neither bridge.c nor if_bridge.c allow
    >> > you to bridge VLAN trunks (you can bridge individual VLANs but that
    >> > becomes unwieldly when you have dozens of VLANs). I have code to do
    >> > this in bridge.c.
    >>
    >> Couldn't you bridge across the parent, or trunk, physical interfaces
    >> carrying tagged VLAN traffic then? (Of course, hardware support for
    >> VLAN should be turned off on them in that case.)

    That's actually what I was trying to do.

    >yes in fact i was wondering what's wrong with that because
    >we have been using bridge.c like this for ages now...

    The problem is that the current bridge code only considers the MAC
    address for forwarding. When VLANs are in use, this is incorrect as
    both the MAC address and VLAN tag must be considered. The difference
    is crucial when you have the same MAC address appearing in multiple
    VLANs. This can occur when using DECnet Phase IV or Solaris with
    Cassini NICs - both of which have a per-host MAC address rather than a
    per-NIC MAC address.

    As an example, consider a system with a host-based MAC address that
    has two NICs. One NIC attaches to VLAN 123 on switch a, the other
    attaches to VLAN 124 on switch b [this is the situation we have in our
    test lab]. If I then attempt to join trunks from both switches using
    bridge(4), it sees the same MAC address on both bridged interfaces and
    shuts down. In reality, this situation is safe because the MAC
    addresses are in different VLANs. 

    -- 
Peter Jeremy
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Wilkinson, Alex: "Re: Bridges"

    Relevant Pages

    • Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
      ... interfaces with the same MAC from the POV of a bridge. ... if several vlan interfaces are ...
      (freebsd-net)
    • Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
      ... Speaking about vlan problems: the original problem is to do something ... with VLAN interfaces only because they are sharing the MAC of their ... What would be good is if there was a way to record additional MAC ... interfaces with the same MAC from the POV of a bridge. ...
      (freebsd-net)
    • Re: arp-proxy
      ... address allocated by DHCP ... the MAC address for cust1 must never appear as a source MAC ... a broadcast from the service subnet should appear on all customer VLANs ... to the correct customer VLAN ...
      (freebsd-net)
    • Re: arp-proxy
      ... Not a big fan of Linux though. ... >> separate vlan trunked. ... > IIUC, you want to do some kind of NAT of MAC addresses, this is not ... > simple router which has one route for each customer pointing to the ...
      (freebsd-net)
    • RE: Dhcp security
      ... One way "depending on how many clients you are servicing" would be to ... create MAC (layer 2) based reservations, ... MAC reservation). ... aforementioned would be VLAN membership rubbish. ...
      (Focus-Microsoft)