Marcell GAL wrote:
> Hi Guys,
> Having many ATM VCs, each having its own ethernet segment inside
> I am exactly in the same situation as the VLAN guys.
> (the kernel code for rfc2684/~1483/ bridged encapsulation is coming out
> those who want an early look /perhaps audit/, please write to me)
Does that mean we will be able to do cool things like bridge a PVC to/from
> My users want many interfaces, they want to ifconfig them, see counters,
> set MAC addresses, they want whatever they do with their physical
> ethernet interfaces. Several hundred interfaces per physical ATM card.
> (still less than 409x VLANs though :)
Heh, if you bridged a single PVC to a single VLAN (ie PVCoE), then you
could have twice as many interfaces!! :)
> ;) I do not see a reason to restrict her.
> Besides having a longer (but acceptable for 99%) creation and listing
> time for interfaces
> the only remarkable thing was /proc/sys/net/ipv4/conf.
> (in our case only 145 entries were accessible, so we had to use the
> conf/default directory
> -ugly,eh?- before creating the devices and forget about changing those
> values thereafter)
Why is the limit 145...is that how many can fit into a single 4k 'block'
in the proc FS?
> Sorry to stir this again, maybe I just want to hear that large number of
> traditional interfaces is OK for now until we get back to this at 2.5
If you, or anyone else, can think up a scheme that fixes this perceived
problem, please let the list or me know so I can consider changes to
the VLAN code too...
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)