[Xorp-users] wanted: OSPF metrics per neighbor. can vif help?

Nick Feamster feamster@lcs.mit.edu
Wed, 9 Nov 2005 19:29:41 -0500


Atanu,

Thanks for the quick, clear reply.   A few comments inline...

On Wed, Nov 09, 2005 at 03:58:13PM -0800, Atanu Ghosh wrote:
> The interface-cost is a per interface setting and it was a mistake in
> the template file to require it to be set at the address level. It
> should be set at the interface level with the link-type.

That makes sense.  Is this fixed in the current CVS version of XORP? 

> In the OSPF implementation the interface and vif are combined to form a
> PeerOut (which is the equivalent of an OSPF interface). The PeerOut is
> where the interface-cost is stored.

I guess I am confused as to the point of the vif.  It isn't really
explained in the user's manual.  Why have it at all if I can't create
multiple virtual interfaces with different names on top of a single
phyiscal interface?

> At the moment the FEA enforces that the interface and vif name are the
> same. Which is why you haven't been able to change the vif name. There
> have been some discussions on this issue over the last few days on
> xorp-hackers.
> 
> If you can create a separate tap device per neighbour then you will be
> able to set the interface cost with the current code.

This option presently does not exist, so we are looking for workarounds.

> The other option is add code to take the interface cost per neigbour in
> a similar manor to the way that the neighbour router-id is
> configured. If you make a bugzilla entry requesting the enhancement and
> upload the patch that would be useful.
> 
> >From my reading of the specification all links from a particular
> interface should all have the same link cost.
> 
> ---------------------------------------- RFC 2328
> 		o   For each fully adjacent neighbor associated with the
> 		    interface, add an additional Type 1 link (point-to-
> 		    point) with Link ID set to the Router ID of the
> 		    neighboring router, Link Data set to the IP
> 		    interface address and cost equal to the interface's
> 		    configured output cost.
> ----------------------------------------
> 
> We would be slightly concerned about adding code that may violate the
> standard, however, this seems like a useful feature.

I understand what the RFC says, and sticking to standards seems like a
good idea in general.  If I could create multiple virtual interfaces
(vifs) on top of a single phyiscal interface (e.g., one vif per
neighbor) and subsequently set the interface cost per vif, then would
that not comply with the standard and give me the functionality we
want/need?

Cheers,
Nick