From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Sat May 28 2005 - 22:13:06 GMT-3
At 11:26 PM -0700 5/24/05, Ralph Sherry wrote:
>I think i have confused myself on the the route decisions of BGP and
>OSPF. With BGP the router finds the quickest route out of the
>current AS into the next AS path. The current AS doesn't care if
>the way it enters the next AS is the best path as long as it is the
>quickest path out of its current AS.
That's default behavior, also called closest-exit or hot potato. It
certainly is not always the routing policy of real-world ISPs, which
may use additional information, carried in BGP or not, to do
best-exit (cold-potato) routing.
There are perfectly valid reasons to use both closest-exit and best-exit.
BGP really doesn't tell you what is the closest or best exit, but can
give you more information to make your own decisions. For example,
communities may tell the receiving AS to do anything from set a high
preference, to pick a particular exit, to blackhole the route.
Think of BGP as a protocol that simply tells you a destination is
reachable, and gives you various policy information.
IGPs, in the absence of hierarchy and other policies, does try to
give you the best path. Again ignoring deliberate information
suppression such as areas, type II externals, etc., this is a fairly
general characteristic of IGPs.
>
>
>My questions is if OSPF operates in the same way when dealing with
>stubs, NSSA, and different areas. Right now I am thinking it does
>but I may have all my routing protocols confused.
>
In general (e.g., no metric manipulation), IGPs give you best path
within a given routing scope, such as an area or a level of EIGRP
summarization. When leaving the area, it depends. If an OSPF path
includes type I externals realistically reflecting the quality of the
external link, it's best path to the destination. From regular area
to regular area, it's best path. From total stub to something
outside, it's best path inside the area but closest path leaving it.
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:03 GMT-3