I'm doing bridging between vlans without any rules, I use debian, here is
how I setup my bridge interfaces:
auto br954
iface br954 inet static
address 10.193.79.1
netmask 255.255.255.255
bridge_ports eth0.954 eth1.1955
bridge_maxwait 0
The IP on the bridge is irrelevant, it was needed for the ifup to work.
This bridges traffic between the two vlans without any rules in etables.
I'm using this to translate vlan numbers between different L2 domains.
Both eth0 and eth1 go to switches with tag ports. No untagged packets come
to eth0 or eth1.
On one box I have over 50 bridges, and it just works.
K
On Sun, 16 Jul 2006, Linux wrote:
> > >
> > > Not so strange once you get your head around how it all hangs together
> > > (someone please correct me if what I'm saying is wrong).
> > >
> > > When a tagged (or untagged) packet comes in on the Ethernet interface,
> > > it is first presented to the bridge. If the bridge accepts it (broute's
> > > it), then the packet is taken from the ethernet interface and routed
> > > onto the bridge interface, so your bridge would contain both tagged and
> > > untagged (native) packets. If the machine running the bridge doesn't
> > > care about the vlans at all, then this would probably just work (unless
> > > you have a rule in your iptables that doesn't like the tagged packets).
> > >
> > > If the bridge doesn't accept the packet (a DROP on the BROUTING chain in
> > > the broute table in ebtables), then the packet is passed to the next
> > > thing listening on the Ethernet interface, which should be vlan. The
> > > vlan see's the tagged packet, removes the tag, and 'routes' it onto the
> > > eth0.X interface. Then the whole cycle begins again, only this time the
> > > bridge code does pick it up, and routes it onto the appropriate bridge.
> > >
> > > With the above in mind, you should see why iptables does or doesn't see
> > > a packet. If it isn't obvious, don't rule out the possibility that
> > > something I've said above is not quite right, and do post the rule you
> > > expect to see the packet on and we'll have a look. I believe that
> > > iptables only see's the packet once the IP stack get's involved, which
> > > is after bridging and vlan have both had a crack at it.
> > >
> > > Now, I have a vague idea that there is some trickery involved concerning
> > > exactly where tcpdump fits in here... I think it see's all the packets
> > > that get received on a physical interface, but it might have a blind
> > > spot concerning packets transmitted from the bridge and/or vlan stacks,
> > > or maybe I'm thinking of when I was first figuring out the above and had
> > > one of my rules backwards...
> > >
> > > Fun, isn't it!
> >
> > And very confusing it.
> >
> > Hopefully I will find out tomorrow everything is working and then I have
> > to
> > start to enforce rules on it, to limit the destinations.
> >
> > I was hopping to do this with iptables as I know them better than ebtables
> > but tend to cheat and use shorewall.
> >
> > I am not sure why I see the packets on br1 but not br0 through iptables.
> >
>
> I can not be sure 100% until tomorrow but I think they iptables only see
> broadcast traffic and traffic going within the same subnet.
>
> Therefore I think using bridging is not going to work, normally I would use
> straight routing but due to the vlans it make life more complex.
>
> Basically traffic coming in on eth3, needs to go out through a default
> gateway of 192.168.20.1 through eth0
>
> For traffic on eth3.40 I need this to route to 192.168.40.1 via eth0.40
>
> If that makes sense, both are wanting to go to the same IP 135.166.X.Y.
>
> To make things more complex the route 192.168.20.1\40.1 is running the DHCP
> server which I need to continue to use.
>
> I need to control traffic so that they can only access certain ports ranges
> and IPs
>
> If anyone has any suggestions on how this would be possible, I would be
> grateful.
>
> Thanks,
>
> Adam
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager. http://www.mettoni.com
> **********************************************************************
>
> _______________________________________________
> Vlan mailing list
> Vlan@xxxxxxxxxxxxxxx
> http://www.candelatech.com/mailman/listinfo/vlan
>
