Acee,
> AND non-zero forwarding address
I missed this. Thanks for correcting.
Thanks,
Anton
Acee Lindem wrote:
Hi Anton,
On Oct 25, 2007, at 9:40 AM, Anton Smirnov wrote:
Hi Shashidhar,
this list is not a proper place to ask questions about
vendor-specific behavior.
Regarding question on what should be happening - please refer to
updated algorithm to compute and compare routes to external
destinations described in RFC 3101. It applies to both NSSA and
external routes and has tiebreaker if advertisements from two ASBRs
seem undestinguishingly equal.
Nope. As pointed out by Pat Murphy, that tie break ONLY applies if the
LSA has the same prefix, cost, AND non-zero forwarding address. In this
case, the next-hops are inherited from the forwarding address route
anyway so it shouldn't make a difference. Excerpted from RFC 3101:
(e) If the current LSA is functionally the same as an
installed LSA (i.e., same destination, cost and non-zero
forwarding address) then apply the following priorities in
deciding which LSA is preferred:
1. A Type-7 LSA with the P-bit set.
2. A Type-5 LSA.
3. The LSA with the higher router ID.
From an implementation standpoint, I don't see a reason not to use
multiple ASBRs (given the other rules are followed).
Thanks,
Acee
Thanks,
Anton
techmail technology wrote:
Hi All,
I just got curious to know (since I have a related problem to solve in
our router), how the router should behave in the case of multiple
ASBRs scenario, in both the cases when rfc1583compatible is
enabled/disabled.
When there are multiple ASBRs in the autonomous system, each
originating a type-5 AS external LSA for a single external destination
say N1, how does the rules in section 16.4 should be applied by a
router to compute the paths to N1. How does the router prune from
among the number of ECMP paths available to each of those ASBRs. rfc
2328 doesn't not talk about the multiple ASBR scenario. It explains
the rules in section 16.4 assuming multiple paths to a single ASBR.
But if there are multiple paths to multiple ASBRs, should the rules be
simply be extended or is there something more to it. Please explain.
Thanks in advance.
regards,
Shashidhar
On 2/28/07, Acee Lindem <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
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] <mailto:[email protected]>
https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected] <mailto:[email protected]>
https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected] <mailto:[email protected]>
https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
