Home page logo
/

nanog logo nanog mailing list archives

Re: Not so newbie BGP question...
From: John Fraizer <nanog () EnterZone Net>
Date: Tue, 3 Oct 2000 01:30:41 -0400 (EDT)



Danny,

Option 2 (prefer customer routes over peer routes) seems to be the best
bet.

In this dilemma, I represent 65502 having 65501 be one of our transit
providers and 65503 being one of our transit customers.

It wouldn't bother me at all if 65501 announced 65503-direct routes on
their borders.  I'm sure it wouldn't bother 65503 either.  It does bring
about a billing problem though.

Since "regional exchange" is a layer 2 shared media fabric with
route-servers running in transparent mode, there is no way for 65501 to
bill 65502 for the "transit" they'd be providing to 65503 via the regional
exchange.

I'm not positive but, is it possible to have 65501 prefer 65502_65503
(using localpref on the 65501<->65502 transit connection) over 65503
direct routes learned via the regional exchange?

In this situation, all concerned have agreed that since 65501 is a common
transit provider, it is not expected that they pref routes TO customers or
customers of customers via the regional exchange.

In a perfect world (someone speak up if you know how to do this!) we could
do this:

Have 65501 pref regional exchange routes to 65502 and 65503 for traffic
originating inside of 65501 or from other 65501 transit customers.

Have 65501 pref the 65501<->65502 transit connection for traffic
originating from outside their AS or their transit customers.

I don't think this is really possible and certainly won't be easy if it IS
possible but, it never hurts to ask!


---
John Fraizer
EnterZone, Inc


On Mon, 2 Oct 2000, Danny McPherson wrote:



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?








  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault