[31634] in North American Network Operators' Group
Re: Not so newbie BGP question...
daemon@ATHENA.MIT.EDU (Danny McPherson)
Tue Oct 3 01:11:20 2000
Message-Id: <200010030509.XAA25003@tcb.net>
To: nanog@merit.edu
From: Danny McPherson <danny@tcb.net>
Reply-To: danny@tcb.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Oct 2000 23:09:44 -0600
Errors-To: owner-nanog-outgoing@merit.edu
I can think of a couple of viable options.
One approach would be to ask AS65501 to permit _65503$, versus 65502_65503$.
This would result in transit behavior for both the "Regional Exchange" path to
reach AS65503 destinations under normal behavior, and would also permit use of
the AS65502 path should the Regional Exchange path become unavailable. Of
course, it could potentially result in odd, or at least non-deterministic
behavior, if folks are filtering based on the sequence of ASs in the AS_PATH.
Alternatively, AS65501 could do as lots of sensible folks do and always prefer
customer routes over peer routes [of the same length] (usually via LOCAL_PREF
for "AS wide" scope), though this would mean that the Regional Exchange path
would only be used if the AS65502 path becomes unavailable, and even then the
direct route would NOT be provided with transit service by AS65501.
Or, one other option which would likely seem the most elegant to AS65503, but
perhaps annoy some folks (with good reason). Depending on the prefix length,
AS65503 could announce the aggregate via the AS65502 session, and announce two
following more-specific (i.e. longer prefixes) via the direct peering with
AS65501. Presumably, this would result in all the AS65501 traffic preferring
the Regional Exchange, with only the aggregate route being propagated to the
"Internet", though still resulting in the same transit behavior. However,
depending on the relationship with AS65502, additional provisions would
perhaps need to be implemented to ensure that AS65502 doesn't prefer the two
more specific's via the AS65501-AS65503 path versus the direct path between
the two.
And yes, IMO, 1 & 3 above are hacks...
HTH,
-danny
> Since the direct (exchange) route to 65503 is selected as the best path it
> is passed throughout their network to the edges as the best path. It
> doesn't pass through their as-path access-list filters on the edge however
> since 65503 isn't a TRANSIT customer of theirs and as such, the
> 65501_65502_65503 routes never get announced at the 65501 borders.
>
> The regional exchange operates in transparent mode. (transparent AS,
> transparent nexthop)
>
> Is there a way to have 65501 see routes in it's core to 65503, yet
> announce the 65502_65503 routes to its other bilateral peers on its
> borders?
