question about AS relationship
mark.tinka at seacom.mu
Fri Feb 21 09:13:20 UTC 2014
On Friday, February 21, 2014 08:57:07 AM Song Li wrote:
> the AS relationship between AS1 and AS2/3 is peer, and
> AS1 cannot announce routes from AS3 to provider1 by
Or even Peer-AS2's routes to Peer-AS3 (and vice versa), in
general best practice filtering rules, unless transit is
> But if AS1 do it, and the realtionship between AS1
> and AS3 is invisible to provider1, how can provider1
> detect this route leak without knowing the privacy?
Provider-1 wouldn't care whether it's a route leak or not.
In Provider-1's mind, Peer-AS3 could (suddenly) be a
customer of AS1. And since AS1 is a customer of Provider-1,
Provider-1 will be happy to move those packets along as it
represents more revenue for Provider-1 (more so if traffic
is sold on a 95th percentile or volume utilization basis).
It is, really, up to AS3 to detect that AS1 has leaked its
routes (or paths, to be precise) to Provider-1, and then
pick up the phone and scream at AS1 to get that leak fixed
Of course, all of this is a moot point if Provider-1 is a
good provider and makes sure they only accept routes and
paths from AS3 that AS3 should be sending to Provider-1 in
the first place. But as we know, some providers are a bit
(actually, very) lazy here.
> In other words, could the business relationship between
> AS1 and AS3 be known to provider1/2?
Not really (or not that easily, to be specific).
With enough time and access to several looking glasses and
public route servers, one could "infer" (to a certain degree
of error) business relationships between peering
relationships, i.e., whether they relationships are
customer, peer or provider.
But in your particular case, unless AS3 has a direct
connection toward Provider-1/2 (where a route leak would
introduce more problems), Provider-1/2 don't really care
about whether this is a leak or not from AS1.
But again, this whole discussion is mooted if Provider-1/2
do proper background checks and filtering before they turn-
up the service for AS1.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the NANOG