On Sat, 3 Jun 2000, Mitchell Blank Jr wrote:
> Currently, atm *cards* don't show up as a network device (since they
> can't be bound directly to L3 protocols), but that may need to change
didnt know this.
> > You try adding all those thousands of
> > VLANs as devices and i can _guarantee you_ that you are not optimizing for
> > the common case.
>
> ...or thousands of routes, or gigabytes of RAM, etc... do you suggest we
> drop kernel support for those too? It's all a matter of finding an
> algorithm that scales.
We dont wanna start changing the whole network stack just so that
we can fit in VLANS, do we?
Routes and gigabytes of RAM ? not comparing oranges to oranges here ..
>
> Again, how do I write an IP filter that discerns traffic on
> two different VLANSs - for instance imagine we had one shared
> ethernet switch that included
>
> * (VLAN 1) Router to outside world
> * (VLAN 1, VLAN 2) Linux box acting as masquerading firewall
> * (VLAN 2) Internal machines
>
> How do I do this under your system? Keep in mind that for security's
> sake we need to make sure that traffic on VLAN1 doesn't spoof an
> internal IP address.
>
based on VLANS; thats why building a table is so useful. Put your
ACL on the "VLAN table"; someone makes a policy call that gets inserted
into the VLAN table of the appropriate device (which in itself might be a
simple pointer to a general filter database eg iptables).
I dont have a problem with extending things like dst cache to have a
pointer to some VLAN entry
> > I have heard that the authors of 802.1q
> > have already apologized to the world for the mess ;->
>
> Do you have a reference, or is this just flamebait?
>
I heard about this in more than one place. I'll try and get you a
reference.
cheers,
jamal
|