netdev
[Top] [All Lists]

Re: routable interfaces

To: <kuznet@xxxxxxxxxxxxx>
Subject: Re: routable interfaces
From: jamal <hadi@xxxxxxxxxx>
Date: Tue, 16 Jan 2001 08:23:09 -0500 (EST)
Cc: <netdev@xxxxxxxxxxx>
In-reply-to: <200101151928.WAA12705@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

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.
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;

cheers,
jamal


<Prev in Thread] Current Thread [Next in Thread>