[Xorp-hackers] Large Number of Interfaces

Yonghong Ren ren@sandmail.sandburst.com
Thu, 20 Jan 2005 11:00:24 -0500


Pavlin,

>On the other hand, if you want to use, say, a virtual tunnel,
>currently that tunnel cannot be created by XORP itself; the tunnel
>must be created externally (by user-level UNIX program, etc).

As long as I can create and delete interfaces dynamically from XORP, it
would be fine. Like in a commercial router, I just want to be able to
create and delete interfaces without doing this through OS, in other
words, the interface will be added into or removed from UNIX kernel
programmatically through XORP.

>If you want to use a network interface in XORP, you must explicitly
>tell XORP about it,

Is this done statically from a configuration file? Again, I just want to
be able to do it on the fly inside XORP.

Thanks!

Regards,
Yonghong Ren


-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin@icir.org] 
Sent: Tuesday, January 18, 2005 4:08 PM
To: Yonghong Ren
Cc: atanu@ICSI.Berkeley.EDU; Pavlin Radoslavov; xorp-hackers@xorp.org
Subject: Re: [Xorp-hackers] Large Number of Interfaces 

> I would like to set the compilation issues aside for a moment and
> discuss a different aspect, namely the best way to support large
number
> of interfaces.
> 
> A system may have say 40 physical interfaces, with X number of logical
> interfaces (virtual router interface for example).
> 
> The current design choice appears to be leveraging the native OS
> Ethernet interface mechanism. In other words, every interface would
> appears as a native OS interface.

A clarification: we can deal with every interface that appears in
the kernel and is visible by "ifconfig -a" (including virtual
interfaces, etc). We wanted to use what is already in the system
rather than inventing our own virtual interface space.
On the other hand, if you want to use, say, a virtual tunnel,
currently that tunnel cannot be created by XORP itself; the tunnel
must be created externally (by user-level UNIX program, etc).

> What are the pros and cons (if there is any :)) of this approach? Some
> questions I have are:
> 
> 1) Is this scalable? That is, would say 100 interfaces cause problems
to
> the OS?

For a number of reasons there are some places inside the FEA where
we use linear processing when some of the interface-related info
has changed. Obviously, this is scalable up to a point, but I doubt
the CPU overhead will be notable with hundreds of interfaces.

> 2) The interfaces may be added and removed dynamically. Would this be
> OK?

If you want to use a network interface in XORP, you must explicitly
tell XORP about it, otherwise XORP doesn't know it is suppose to use
it. At least, you must tell XORP the name of the interface. Then,
the design allows to dynamically track the state of that interface
(e.g., if an IP address is added/deleted, if the interface itself is
enabled/disabled/deleted, etc). Though, admittably, the dynamic
tracking functionality hasn't been tested well.

> 3) What assumptions and requirements does XORP stack requires each
> interface? For example, the routing protocols would be assuming socket
> library access through the interfaces and therefore the interface has
to
> provide socket access. So, that would be a big advantage to make each
> interface a network interface at the OS level so to leverage the
TCP/IP
> stack and socket mechanism.

Probably I don't understand this question, but all interfaces used
by XORP are at the OS level, hence we always use the TCP/IP stack
and socket mechanism provided by the system.

> 4) I wonder how this is typically done in a large commercial router.

I don't know.
Given that we use the UNIX kernel, we leverage on the
functionalities it provides already. The downside is that an
interface may be modified on-the-fly by user-level commands (outside
of XORP), hence we need to consider this scenario.
I guess that in commercial routers the configuration is controlled
via the router startup configuration or the CLI, hence everything is
explicit.

Regards,
Pavlin