Re: look for BGP routes containing local AS#
Thanks!
It seems hard to see such routes on the edge router. Nonetheless, we do
believe there must exist such routes in the wild. We still hope to find
some real cases of them. If anybody see them in your routers, please let
us know.
Regards!
Song
在 2015/1/28 21:27, Chuck Anderson 写道:
It used to be the case that looped routes didn't even show up as
hidden routes, because Junos discarded them even from Adj-RIB-In,
although this may have changed at some Junos version.
Also, Junos won't even advertise such looped routes to a neighbor with
the same AS by default, so in many cases you won't see it at all if
you are peering with a Juniper unless it is specifically configured to
send these looped routes with advertise-peer-as, or change the AS
number with as-override.
On Wed, Jan 28, 2015 at 05:32:34PM +0800, Song Li wrote:
Hi Joel,
It is right that the BGP route containing the local ASN will be
droped. However, such routes can still be displayed on router. For
example, you can run show route hidden terse aspath-regex .*local
ASN.* on Juniper to check them. We are looking for those routes.
If you can run the command on your Juniper and find such routes,
could you please provider them for us?
Thanks!
Regards!
Song
在 2015/1/28 16:23, joel jaeggli 写道:
On 1/27/15 5:45 AM, Song Li wrote:
Hi everyone,
Recently I studied the BGP AS path looping problem, and found that in
most cases, the received BGP routes containing local AS# are suspicious.
However, we checked our BGP routing table (AS23910,CERNET2) on juniper
router(show route hidden terse aspath-regex .*23910.* ), and have not
found such routes in Adj-RIB-In.
Updates with your AS in the path are discarded as part of loop
detection, e.g. they do not become candidate routes.
https://tools.ietf.org/html/rfc4271 page 77
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
route should be excluded from the Phase 2 decision function. AS loop
detection is done by scanning the full AS path (as specified in the
AS_PATH attribute), and checking that the autonomous system number of
the local system does not appear in the AS path. Operations of a BGP
speaker that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.
in junos
neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number
where number is the number of instances of your AS in the path you're
willing to accept will correct that.
We believe that the received BGP routes containing local AS# are related
to BGP security problem.
You'll have to elaborate, since their existence is a basic principle in
the operation of bgp and they are ubiquitous.
Island instances of a distributed ASN communicate with each other by
allowing such routes in so that they can be evaluated one the basis of
prefix, specificity, AS path length and so forth.
Hence, we want to look for some real cases in
the wild. Could anybody give us some examples of such routes?
--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com
Re: look for BGP routes containing local AS#
Hi Joel,
It is right that the BGP route containing the local ASN will be droped.
However, such routes can still be displayed on router. For example, you
can run show route hidden terse aspath-regex .*local ASN.* on
Juniper to check them. We are looking for those routes. If you can run
the command on your Juniper and find such routes, could you please
provider them for us?
Thanks!
Regards!
Song
在 2015/1/28 16:23, joel jaeggli 写道:
On 1/27/15 5:45 AM, Song Li wrote:
Hi everyone,
Recently I studied the BGP AS path looping problem, and found that in
most cases, the received BGP routes containing local AS# are suspicious.
However, we checked our BGP routing table (AS23910,CERNET2) on juniper
router(show route hidden terse aspath-regex .*23910.* ), and have not
found such routes in Adj-RIB-In.
Updates with your AS in the path are discarded as part of loop
detection, e.g. they do not become candidate routes.
https://tools.ietf.org/html/rfc4271 page 77
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
route should be excluded from the Phase 2 decision function. AS loop
detection is done by scanning the full AS path (as specified in the
AS_PATH attribute), and checking that the autonomous system number of
the local system does not appear in the AS path. Operations of a BGP
speaker that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.
in junos
neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number
where number is the number of instances of your AS in the path you're
willing to accept will correct that.
We believe that the received BGP routes containing local AS# are related
to BGP security problem.
You'll have to elaborate, since their existence is a basic principle in
the operation of bgp and they are ubiquitous.
Island instances of a distributed ASN communicate with each other by
allowing such routes in so that they can be evaluated one the basis of
prefix, specificity, AS path length and so forth.
Hence, we want to look for some real cases in
the wild. Could anybody give us some examples of such routes?
Thanks!
Best Regards!
--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com
Re: look for BGP routes containing local AS#
Hi Patrick,
We want to know what's the reason for the received routes containing
local ASN. Hence we need real cases of those routes in the Internet. And
any routes like that are welcome, whether they are on Juniper router or
other BGP software.
Thank you!
Regards!
Song
在 2015/1/29 1:50, Patrick Tracanelli 写道:
Sorry, what do you need exactly? A sample? For education purposes are you
looking for something specific?
You need it to be on Juniper router or other BGP software will do?
I have this scenario from Brazil-US, with specifics getting received both ways
but it’s not Juniper.
Thanks!
Regards!
Song
在 2015/1/28 16:23, joel jaeggli 写道:
On 1/27/15 5:45 AM, Song Li wrote:
Hi everyone,
Recently I studied the BGP AS path looping problem, and found that in
most cases, the received BGP routes containing local AS# are suspicious.
However, we checked our BGP routing table (AS23910,CERNET2) on juniper
router(show route hidden terse aspath-regex .*23910.* ), and have not
found such routes in Adj-RIB-In.
Updates with your AS in the path are discarded as part of loop
detection, e.g. they do not become candidate routes.
https://tools.ietf.org/html/rfc4271 page 77
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
route should be excluded from the Phase 2 decision function. AS loop
detection is done by scanning the full AS path (as specified in the
AS_PATH attribute), and checking that the autonomous system number of
the local system does not appear in the AS path. Operations of a BGP
speaker that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.
in junos
neighbor { ipAddress | ipv6Address | peerGroupName } allowas-in number
where number is the number of instances of your AS in the path you're
willing to accept will correct that.
We believe that the received BGP routes containing local AS# are related
to BGP security problem.
You'll have to elaborate, since their existence is a basic principle in
the operation of bgp and they are ubiquitous.
Island instances of a distributed ASN communicate with each other by
allowing such routes in so that they can be evaluated one the basis of
prefix, specificity, AS path length and so forth.
Hence, we want to look for some real cases in
the wild. Could anybody give us some examples of such routes?
Thanks!
Best Regards!
--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com
--
Patrick Tracanelli
FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
Long live Hanin Elias, Kim Deal!
--
Song Li
Room 4-204, FIT Building,
Network Security,
Department of Electronic Engineering,
Tsinghua University, Beijing 100084, China
Tel:( +86) 010-62446440
E-mail: refresh.ls...@gmail.com
look for BGP routes containing local AS#
Hi everyone, Recently I studied the BGP AS path looping problem, and found that in most cases, the received BGP routes containing local AS# are suspicious. However, we checked our BGP routing table (AS23910,CERNET2) on juniper router(show route hidden terse aspath-regex .*23910.* ), and have not found such routes in Adj-RIB-In. We believe that the received BGP routes containing local AS# are related to BGP security problem. Hence, we want to look for some real cases in the wild. Could anybody give us some examples of such routes? Thanks! Best Regards! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
Re: command that can display routes containing AS loops
Hi Dave, thanks! I tried the command and found that it works. Do you know the similar command on cisco? Regards, Song 在 2015/1/12 21:16, Dave Bell 写道: On a Juniper, you could do something like: show route hidden aspath-regex .*Target-AS.* Regards, Dave On 12 January 2015 at 13:05, Song Li refresh.ls...@gmail.com wrote: Hi everyone, I am curious about the AS loops in the AS-path. I think there should be a very, very few received BGP routes that contain the local AS#. But because such routes will be dropped and not installed in Loc-RIB, I want to know if there is a command that can display the dropped routes containing AS loops (in cisco or juniper router). Does anybody know? Thanks! Best! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
command that can display routes containing AS loops
Hi everyone, I am curious about the AS loops in the AS-path. I think there should be a very, very few received BGP routes that contain the local AS#. But because such routes will be dropped and not installed in Loc-RIB, I want to know if there is a command that can display the dropped routes containing AS loops (in cisco or juniper router). Does anybody know? Thanks! Best! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
Re: something strange about bgp community
Thanks! Because there is no standard syntax on the description of BGP community, I think the problem is hard to understand. 在 2015/1/7 23:25, joel jaeggli 写道: 2914:429 is ntt's do not advertise to any peer community bgp communities are transitive attributes, e.g. you can just pass them to peers unmolested. so someone that's presumably not ntt ( e.g. the neighbor is digital ocean) is sending that commmunity to route views as part of their export. Their utility in routviews depends on context, when I see communities I tagged on my own routes in routviews for example I can tell what pop the announcement originated from which is rather useful. other's like the one above do tell you something about the policy of somebody on the internet. you can also tell who strips communities... On 1/7/15 5:35 AM, Song Li wrote: Hi everyone, Today when I check one route in Routeviews I find something strange as follows: route-viewssh ip bgp 176.108.0.0 BGP routing table entry for 176.108.0.0/19, version 23405621 Paths: (33 available, best #28, table default) Not advertised to any peer Refresh Epoch 1 202018 35320 35320 57800 5.101.110.2 from 5.101.110.2 (5.101.110.2) Origin IGP, localpref 100, valid, external Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 20485:54050 47541:10001 rx pathid: 0, tx pathid: 0 the AS-Path is 202018 35320 35320 57800 but the community is 702:120 2914:429 20485:52990 According to RFC 1997, the community format is AA:NN and AA means the AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and as a result they should not appear in the community. Could anybody tell me what's the reason they do appear in the community of this route? Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
something strange about bgp community
Hi everyone, Today when I check one route in Routeviews I find something strange as follows: route-viewssh ip bgp 176.108.0.0 BGP routing table entry for 176.108.0.0/19, version 23405621 Paths: (33 available, best #28, table default) Not advertised to any peer Refresh Epoch 1 202018 35320 35320 57800 5.101.110.2 from 5.101.110.2 (5.101.110.2) Origin IGP, localpref 100, valid, external Community: 702:120 2914:429 20485:52990 20485:53990 20485:54040 20485:54050 47541:10001 rx pathid: 0, tx pathid: 0 the AS-Path is 202018 35320 35320 57800 but the community is 702:120 2914:429 20485:52990 According to RFC 1997, the community format is AA:NN and AA means the AS#. Here, AS702, AS2914 and AS20485 do not appear in the AS-Path and as a result they should not appear in the community. Could anybody tell me what's the reason they do appear in the community of this route? Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
Is there list of IXPs (containing the information of the AS# of the IXP)
Hi everyone, I'm searching for a list of IXPS which contains the information of the ASN of the IXP. Some resources are good: https://prefix.pch.net/applications/ixpdir/?show_active_only=0sort=trafficorder=desc https://www.telegeography.com/products/internet-exchange-directory/profiles-by-name/index.html but they do not contain the AS# of the IXP. Can anybody help me? Thanks! Best! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
Re: Is there list of IXPs (containing the information of the AS# of the IXP)
在 2014/12/22 22:26, Nick Hilliard 写道: On 22/12/2014 13:50, Jeroen Massar wrote: IXs themselves do not have ASNs, as they are Layer 2 providers. most modern IXPs will have an ASN for their route server, and possibly a separate asn for their mgmt infrastructure. Not sure how useful the mgmt ASN is, although most IXPs will paradoxically include this on their list of members. Nick Thanks for your help! I studied all the AS-Path in the routing table (from routeviews and RIPE), and found that some ASN of IXPs were included in some AS-Path. I think that under normal circumstances they should not appear in the AS-Path, hence i want to filter out them. Best! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
question about bgp incremental updates
Hi everyone, I have a question about bgp updates: BGP uses an incremental update strategy to conserve bandwidth and processing power. That is, after initial exchange of complete routing information, a pair of BGP routers exchanges only the changes to that information. ( from RFC4274) According to this principle, if an AS suddenly announced a lot of updates (as below), can it be regarded as an anomaly such as BGP session reset? I wish to know if there are other reasons can result in this anomaly. Thanks! BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.24.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.28.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.20.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/20|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/22|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.204.0/23|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.208.0/21|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.8.0/24|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.1.32.0/20|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.204.0/23|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.208.0/21|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.24.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.28.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.20.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.16.0/20|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.12.0/22|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|218.189.8.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.1.32.0/20|6939 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|114.134.83.0/24|6939 3549 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|203.90.243.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|203.90.251.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|118.143.224.0/20|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|118.143.232.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.57.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.53.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.61.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|202.46.49.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|103.17.240.0/22|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|103.17.240.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:12|A|216.218.252.164|6939|112.73.6.0/23|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.194.231.0/24|6939 3549 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.198.0/24|6939 3549 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|175.100.206.0/24|6939 15412 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.0.209.0/24|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.3.0.0/22|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|210.3.4.0/23|6939 4436 25973 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.227.207.0/24|6939 1299 3257 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|114.134.83.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|203.90.243.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|203.90.251.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.143.224.0/20|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.143.232.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.57.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.53.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.61.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|202.46.49.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.17.240.0/22|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|103.17.240.0/24|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|112.73.6.0/23|6939 9304|IGP BGP4MP|04/23/14 13:05:13|A|216.218.252.164|6939|118.194.231.0/24|6939 9304|IGP
question about bogon prefix
Hi everyone, I found many ISP announced bogon prefix, for example: OriginAS Announcement Description AS7018 172.116.0.0/24 unallocated AS209 209.193.112.0/20 unallocated my question is why the tier1 and other ISP announce these unallocated bogon prefixes, and another interesting question is: If I am ISP, can I announce the same bogon prefix(172.116.0.0/24) with AS7018 announced? Will this result in prefix hijacking? Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
Re: bgp convergence problem
Hi Dennis, I think there are two possible convergence results: 1/ AS3 accepted route 16.1/16(2 4 5) from AS1, then it will withdraw announce of 16.1/16(5) towards AS1. And AS1 will remain 16.1/16 (2 4 5). 2/ AS1 accepted route 16.1/16(3 5) from AS3, then it withdraw 16.1/16(2 4 5), and AS3 will remain 16.1/16(5). I simulated this case in GNS3, and only got the first kind of result, i don't know why? Song 于 2014/5/6 18:13, ISP Services 写道: Hi Song Li, As far as I know there are 2 mechanisms that should prevent this situation you describe from happening: - Not advertising routes that are not in the RIB Once AS1's peering with AS3 comes back up, the route through AS3 is learned and preferred. Therefore the route via AS2 is purged from the RIB. Once it is no longer in the RIB, AS1 cannot announce that path anymore. - AS Path loop prevention If AS1 still leaks the prefix to AS3, it can only announce the active path which points to AS3 itself. Therefore AS3 will see a prefix with its own ASN in the path and (should) drop the prefix. Crisis avoided. My textbook knowledge is a bit rusty though.. Dennis Hagens Song Li schreef op 5/6/14 5:58 AM: Hi everyone, I have one bgp convergence problem which confused me. The problem is as follows: ++ | AS5 | +--+16.1/16 | | +-+--+ || +---+--+ | | AS4 | | | | | ++-+ | | | | | | | +-+--+ +-+-+ | AS2 | | AS3 | 16.1/16 (5) | ISP | | ISP | +---^+ +---^---+ | | | ++| +-+ AS1 ++ |customer| ++ 16.1/16 (2 4 5) AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). After a while, the BGP seesion between AS1 and AS3 reestablished but AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) as best route. 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), according to local_pref it will select 16.1/16(2 4 5). in this case, AS1 and AS3 select each other as the best route to AS5, i wonder which route will be the final best route after bgp convergence in AS1 and AS3. Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
bgp convergence problem
Hi everyone, I have one bgp convergence problem which confused me. The problem is as follows: ++ | AS5 | +--+16.1/16 | | +-+--+ || +---+--+ | | AS4 | | | | | ++-+ | | | | | | | +-+--+ +-+-+ | AS2 | | AS3 | 16.1/16 (5) | ISP | | ISP | +---^+ +---^---+ | | | ++| +-+ AS1 ++ |customer| ++ 16.1/16 (2 4 5) AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3, and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5). After a while, the BGP seesion between AS1 and AS3 reestablished but AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point, 1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and 16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5) as best route. 2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5), according to local_pref it will select 16.1/16(2 4 5). in this case, AS1 and AS3 select each other as the best route to AS5, i wonder which route will be the final best route after bgp convergence in AS1 and AS3. Thanks! -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
Re: question about AS relationship
Thanks. I'm doing some research on route leaks, you are a great help to me. Sky li 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 rule. Or even Peer-AS2's routes to Peer-AS3 (and vice versa), in general best practice filtering rules, unless transit is requested. 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 plugged. 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. Mark. -- Song Li Room 4-204, FIT Building, Network Security, Department of Electronic Engineering, Tsinghua University, Beijing 100084, China Tel:( +86) 010-62446440 E-mail: refresh.ls...@gmail.com
question about AS relationship
Hi everyone, I have one simple question: as for AS relationship, should customer tell its provider the AS# of its own customers, or the provider have the right to require its customers to do that? Thanks! -- Sky Li
Re: question about AS relationship
Thanks. In order to prevent route leaking, this imformation should be provided to providers. but another question, should the AS relationships between customer and its other neighbors (downstrem/peer/another provider) be private? -- Sky Li On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote: so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented. don't turn up bgp customers without filtering, that kills kittens. For all the leaking I've seen in the last four weeks (including a well-known operator that was involved in the Youtube/Pakistan saga + other well-known global operators that could be classified as a reasonably large tier), we're still a long way away ensuring all customer prefixes are filtered correctly at the inter-domain peering edge. A lng way away... Mark.
Re: question about AS relationship
+--+ +-+ | provider1| |provider2| +--+ +-+ ^ ^ | | | | ++ ++---+++--+ |peer AS2+-+ AS 1 ++peer AS3 | ++ +-++--+ ^ ^ | | ++ +-+ |customer AS4| |customer AS5 | ++ +-+ um sorry, my question is: the AS relationship between AS1 and AS2/3 is peer, and AS1 cannot announce routes from AS3 to provider1 by rule. 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? In other words, could the business relationship between AS1 and AS3 be known to provider1/2? Thanks. Sky li perhaps you should draw a little ascii art, I think you're asking: DS1 - customer - you - isp can DS1's relationship to 'customer' be secret no. well, not if they want: 1) to use a public ASN 2) use ip space which isn't part of 'customer' aggregate 3) want to be reachable on the internet It's safe to say that your goal as an ISP and a customer of an ISP, should be: Make sure that all of my routes and the routes of my customers and their customers, that I'm expected to provide transit for, are in my ISP's filters. -chris (and as someelse pointed out: If they use BGP and expect global reachabilty... then the information isn't private anyway.) -- Sky Li On Thursday, February 20, 2014 08:09:35 PM Christopher Morrow wrote: so, yes. pleass tell your upstream your customers so proper filtering can be automated and implemented. don't turn up bgp customers without filtering, that kills kittens. For all the leaking I've seen in the last four weeks (including a well-known operator that was involved in the Youtube/Pakistan saga + other well-known global operators that could be classified as a reasonably large tier), we're still a long way away ensuring all customer prefixes are filtered correctly at the inter-domain peering edge. A lng way away... Mark.
