On Tue, Jan 16, 2001 at 08:23:09AM -0500, jamal wrote:
> On Mon, 15 Jan 2001 kuznet@xxxxxxxxxxxxx wrote:
> > Hello!
> > > A vlan device could be a simple IP-alias.
> > Sorry, Jamal you messed all the things completely.
> > ifaddr is not a virtual device. "Alias" was virtual device, but
> > this was bogus ill-defined device which created nothing but problems for
> > routing,
> > that's why we have no "aliases", but use plain ifaddrs.
> > VLAN is true "virtual" device, using nice well-defined encapsulation,
> > and from viewpoint of routing/addressing such device is not distinguishable
> > of "physical" one. The question: "physical" or "virtual" is just meaningless
> > from the viewpoint of routing and from any other viewpoint but packet
> > scheduling and policing.
> I mixed the terminology ifaddr != alias. sorry. Infact just looking at
> zebra 0.90 it seems they know how to handle multiple ifas per ifindex.
Yes, zebra can handle multiple ifas, but ospf cannot. ospf can only advertise
secondary ips as stab networks and cannot form adjacency through them, so no
traffic. AFAIK CISCO does the same thing. The only way I see to handle
ips and be able to route transit traffic through them is to create virtual
for each ip alias in zebra and feed them to ospf as real interfaces. Possible,
very complicated, and then what about the ifindexes of these interfaces?
> So no problem there. From a SNMP perspective, (as Gleb pointed out) it is
> an issue. secondary addresses for example do not have counters. You have a
> counters per ifindex only. I think this could be one of the main reasons
> people end up intuitevely choosing a device as is today. That's why i
> changed my opinion that for now, until we come with something better, a
> a netdevice is a good brute force abstraction.
> > What's about VLANs, they can be handled as separate virtual devices
> > provided you have _couple_ of them. It the number is higher, they must
> > be clustered as single nbma interface via framing (i.e neighbour) level
> > or via tags in routing tables. The same thing is with MPLs.
> I think i would prefer the neighbour framing. Most of these
> protocols already have some form of ndisc. This would also work nicely
> with dynamic type of "virtual" interfaces eg L2TP etc. Caching headers
> etc would also be advantageous. Maybe the additional route table tag is
> useful. It's sort of tricky if you want to generalize for all sorts if
> tunnels etc;