Hi Shashidhar,

Are you testing with multiple ASBRs or multiple paths to a single ASBR?

I suspect it is the latter. In this case, RFC 2328 (or 1583 for that matter) isn't completely clear as to whether the selection rules extend to a single ASBR path lockup. Given where we are in OSPFv2 life cycle and being the pragmatic WG chair that I am, I'd say this is an implementation choice. Personally, I've worked on implementations doing it both ways.

Besides, everyone should be using the new ASBR selection rules by now and for OSPFv3 these are the only rules.

Thanks,
Acee

On Feb 28, 2007, at 6:43 AM, techmail technology wrote:

Hi All,

I have one interesting question regarding the behavior of certain
routers (including CISCO), when rfc1583Compatibility is enabled. (By
default it is disabled).

According to rfc2328, it clearly says in section 16.4, when
rfc1583Compatibility is enabled, the preference rules mentioned in
16.4.1 should not be applied in choosing the best path to ASBR.
Instead it should select the path based on the cost only i.e whichever
path has the lowest cost should be considered as the best path, and if
there are multiple low cost paths to ASBR, then choose that path
through highest AREA ID, when considered as an unsigned integer.

With this background, I tested the behavior of CISCO series 2651 IOS
software release 12.4. I was surprised with the CISCO's behavior.
Instead of choosing a low cost path when rfc1583compatibility is
enabled, it continued to select the path to ASBR based on the
preference rules (i.e path through non-backbone intra-area path).

I know that rfc2328 uses preference rules specified in 16.4.1 to avoid
formation of routing loops, in rfc1583 implementation in certain
topologies as explained by Richard Woundy in rfc2178. But still
network provider can have a topology where there is no chance of such
loops forming, so he may want to use rfc1583 behavior to select the
low cost path to ASBR, CISCO doesn't seem to be allowing that.

Is there any specific reason why CISCO doesn't allow such behavior, I
couldn't immediately find the reason, why CISCO(as well as other
implementations like IP Infusion ZebOS) is behaving like this. If
there are multiple routers behaving similarly, but not the way rfc2328
has specified, then there must be some reason.

Does any one know the reason to this behavior ?

regards,
Shashidhar

_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf


_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf

Reply via email to