Re: ISIS: outgoing-metric

From: Peter van Oene (pvo@usermail.com)
Date: Sun Mar 02 2003 - 01:07:38 GMT-3


At 03:31 AM 3/2/2003 +0000, Sage Vadi wrote:
>Peter,
>
>There is a simple concept here.

Is it?

>OUTgoing metrics.

What does that mean though? Whatever cost you set on the link will be
populated into the 128/130/135 TLVs that the router uses to advertise the
prefix. Other routers will use this in their SPF calcs. You can't tell
the router on the other end of the link what cost to use for that link as
that isn't in keeping with how link state routing works.

>As I have reiterated through the course of my emails,
>OSPF, EIGRP, RIP can all set some form of OUTgoing
>metric.

How do you set it in OSPF? If you set a link metric, it has the same effect
as in ISIS. OSPF again looks at a topology from a unidirectional standpoint.

>Q) Can it be done with ISIS?

Again, I'm not really sure what you are trying to do.

>Simple question, no or yes.

It isn't that simple as I see it. What are you trying to do? If it is A
telling B what the cost of the A--B link is, than no, you can't do it. And
no, you can't do it in OSPF either.

>Nobody has been able to authoritatively say - nor do I
>need an explanation on how LSRPs work... as this can
>obviously found.

If it can be obviously found, you might not be asking this question as you
would likely have looked it up already.

>I was hoping for a shorter answer rather than going
>through the RFC primarily since the big day is looming
>up real soon.

If you don't care for the why, I'd build out your lab to 4 routers and give
A two paths to B through C and D. From there, you should be able to play
with metrics on C and D to influence path selection over the A to B path.

>OSPF being a LSP has 3 ways/toggles to set the
>OUTgoing metric, 1) neighbor cost, 2) auto-cost, 3) ip
>ospf cost... obviously I'm excluding changing the
>interface type, but you get my drift. It has got
>_nothing_ to do with the RP being an LSP, if it can be
>done with one it can be done with another.

I don't really get your drift for what its worth. 1) allows a cost per
neighbor to override a flat interface cost on multi-access networks. 2)
allows costs to be derived from bandwidth via a calculation. 3) sets a
manual cost. All of these costs are unidirectional in nature. In your A
to B example, none of these costs as set on A will change B's perspective
of the cost of the B to A link. Said another way, there are two links
here, BtoA and AtoB. The AtoB link is assigned a cost on A and the BtoA
link on B. You can't set the cost of BtoA from A. Furthermore, it has a
lot to do with the use of an spf-like algorithm which is a typical
characteristic of link state protocols.

>The only viable explanation is the fact that in IA,
>OSPF defaults to using distance-vector algorithm,
>wherease for IA ISIS uses SPF - ALL the time, no
>matter what. This could have a bearing on the
>situation, but I do not know for sure.

This is incorrect. IS-IS uses a distance vector based routing methodology
between levels as in OSPF. PNNI is the only mainstream link state routing
protocol that is Link State between levels(areas). Furthermore, OSPF area
boundaries are within the router and it is mandatory that two adjacent
routers on the same link share an area and therefore your A-B topology must
be within the same area. In IS-IS, it could be inter-area.

>I will probably end up reading the RFC as a curiosity
>thing after the lab =) as I said the big day is
>looming up REAL soon...

>rgds,
>Sage
>
>
>__________________________________________________
>Do You Yahoo!?
>Everything you'll ever need on one web page
>from News and Sport to Email and Music Charts
>http://uk.my.yahoo.com



This archive was generated by hypermail 2.1.4 : Sat Apr 05 2003 - 08:51:30 GMT-3