From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Mon May 26 2003 - 16:59:02 GMT-3
At 5:29 PM +0900 5/26/03, hoon wrote:
>?hi group,
>
>Is there any way that a destination is routed over inter-area
>network rather than intra-area network???
OSPF, and indeed several other protocols, are specifically designed
_not_ to do this as a means of avoiding loops and other malfunctions.
The fundamental principle is that an inter-area or external route
could potentially be advertised out of the area, then imported back
in and cause a loop. By always selecting the intra-area route,
regardless of metric, this can't happen.
ISIS does the same thing in never preferring a L2 route over an L1.
There are several parallels in BGP, ranging from the basic path
vector algorithm of never accepting a route that contains your AS, to
the avoidance of temporary oscillation conditions in clusters and
confederations. See RFC 3345.
>This is an example diagram;
>
>(R1) ---- area 0 (metric 1) ----- (R2)
> | |
> | |
>area 1 (metric 1) area 1 (metric 1)
> | |
>(R3) ----- area 1 (metric 2) -----(R4 )
> |
> ---------
> Network A
>
>A normal behavior of OSPF routing for Network A from R1, based on
>its preference to intra-area routes over inter-area routes is the
>following;
>(R1) -> (R3) -> (R4) -> A
>
>Without combining two areas into one area, or extra cabling, is
>there any way a packet destined to network A to be routed over the
>path "(R1) -> (R2) -> (R4) -> A" ??
Now, the question becomes, "what problem are you trying to solve?".
OSPF itself will _not_ let you do this.
There can be legitimate traffic engineering reasons to prefer a
certain path over what the routing protocol would select. I describe
one such technique using static routes with an administrative
distance preferred to OSPF in http://www.nanog.org/mtg-9910/ospf.html
Use of RSVP-TE with MPLS also might be a solution, depending on your
problem, and to what extent the routing protocol cooperates with
RSVP. ISIS-TE is probably more advanced than OSPF in this regard.
This archive was generated by hypermail 2.1.4 : Mon Jun 02 2003 - 15:13:48 GMT-3