[Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
Atanu Ghosh
atanu@ICSI.Berkeley.EDU
Sat, 12 Nov 2005 09:31:18 -0800
Hi,
We have been thinking about the interface-cost configuration change for
the last few days. In your configuration you were able to set the
interface-cost to two separate values but only one of the settings was
used. Your configuration was legal but I have restated it below to show
that all the neighbours belong to a single address block hence only one
interface-cost.
area 0.0.0.0 {
interface tap0 {
link-type: "p2m"
vif tap0 {
address 10.13.79.1 {
interface-cost: 5
/* planetlab02.cs.washington.edu */
neighbour 10.0.35.1 {
router-id: 128.208.4.198
}
/* planetlab2.arizona-gigapop.net */
neighbour 10.0.10.1 {
router-id: 206.207.248.35
}
}
}
}
}
At the moment an interface and vif combination can support only one
address, but in the future we may want to support more than one address
per interface. In which case we may want to set interface-cost and other
parameters per address, so we are going to leave the setting where it is
for now.
It seems that the only solution available to you is to add the ability
to change the interface-cost setting per neighbour.
The clean way to add the code is to add a new XRL to set the
interface-cost on a per neighbour basis. The fast hack would be to add
an interface-cost argument to the add_neighbour XRL
(xorp/xrl/interfaces/ospfv2.xif).
Also add the argument in ospf/xrl_target.{cc,hh} then follow the chain
of calls through to the peer code. Store the interface-cost in the
neighbour structure and make sure that the point-to-point and
point-to-multipoint use this interface-cost when building the router
links that go into a Router-LSA.
Atanu.
>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
Nick> Atanu, Thanks for the quick, clear reply. A few comments
Nick> inline...
Nick> 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.
Nick> That makes sense. Is this fixed in the current CVS version of
Nick> 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.
Nick> I guess I am confused as to the point of the vif. It isn't
Nick> really explained in the user's manual. Why have it at all if
Nick> I can't create multiple virtual interfaces with different
Nick> 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.
Nick> This option presently does not exist, so we are looking for
Nick> 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.
Nick> I understand what the RFC says, and sticking to standards
Nick> seems like a good idea in general. If I could create multiple
Nick> virtual interfaces (vifs) on top of a single phyiscal
Nick> interface (e.g., one vif per neighbor) and subsequently set
Nick> the interface cost per vif, then would that not comply with
Nick> the standard and give me the functionality we want/need?
Nick> Cheers, Nick