Virtual Interfaces.. (fwd)

[Jean-Francois Dive]

Hello Eddie,

pleased to read from you.

In fact, this virtualInterface should fulfill the following reqirements:

--> I need a representation of an interface to know if the received Gre
packet belong to one of the configured tunnel, the packet have to be
droped if not.
--> I need to hold interface counters.
--> I think this interface should be added to the linux stack dev struct
list. My main reason is to be able to interact in a standard way with
existing user level application processes.

>From there, implementation wise, i see two ways:

--> Like you say, group encap ,decap, potentially a linux kernel
interface, which would hook with the kernel and the classifier, containing
all of this in a configuration group.
A Probleme is that we loose the granularity of having a behavior associated with only one GRE interface at
element level. If we split this into multiple instances of the same group
of element per configured interface, then i dont know how where i can put
the general GRE checks.

FromInterface(eth0)->Classifier(gre)->[GRE_Stack]->[IpRouting]
[IpRouting]->[GRE_Stack]

--> My way is to add a new elements which does handle the linux interfaces
mapping and some others functions. This would be a C++ class. I think this
will increase the possibilites of interconnecting other objects(C++ wise)
which needs to communicate with this virtual interface.
It would then probably be interesting to have a super class which does
represent the common object interface to all network interfaces.

FromInterface(eth0)->classifier(gre)->greDecap->VirtualTunnelInterface->[IpRouting]
[IpRouting]->VirtualTunnelInterface->greEncap->[IpRouting]

JeF

On Wed, 28 Nov 2001, Eddie Kohler wrote:

> Hi Jean-Francois,
>
> Very sorry for the delay in getting back to you.
>
> > How would be the click way to handle virtual interfaces in click: i have
> > actually wroten GreEncap and GreDecap elements, but i need to hook this
> > with an interface to route properly the traffic in and out of this
> > interface and to check the validity of the Gre packet (to avoid loops,
> > etc.., cf RFC).
>
> I'm not sure I completely understand your question. You might want to try
> writing again with more detail. You want an element with one input and one
> output. Where do packets go when they are sent to the input? What about
> packets emitted from the output -- where would they come from? Basically,
> how is the element different from Null?
>
> I would _not_ likely use AnyDevice to handle virtual interfaces. It's
> specialized for handling actual devices.
>
> We've always thought of a virtual interface as just a collection of
> elements that emulated what that "tunnel" did.
>
> Maybe other people on the list have a better conception.
>
> > Another point is the existance of this interface in the linux dev table,
> > how should this be handled ?
>
> FromLinux provides an example for how to handle this.
>
> Eddie
>