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.lsong@gmail.com
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!
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.lsong@gmail.com
If your ISP utilizes Juniper platforms, you might have to ask them to allow the advertisement of these routes, see http://www.firstdigest.com/2012/09/cisco-vs-juniper-different-ebgp-behavior/ On 28 January 2015 at 09:32, Song Li <refresh.lsong@gmail.com> 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?
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.lsong@gmail.com
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?
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.lsong@gmail.com
On 28/01/2015, at 07:32, Song Li <refresh.lsong@gmail.com> 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?
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.lsong@gmail.com
-- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"
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.lsong@gmail.com
-- Patrick Tracanelli
FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@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.lsong@gmail.com
On 28/01/2015, at 23:38, Song Li <refresh.lsong@gmail.com> wrote:
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!
OK here you go. 1) Brazil import: Local ASN here: 61894 BGP routing table entry for 177.10.159.0/24 28250 3549 7018 28640 61894 Nexthop 187.1.94.17 (via 187.1.94.17) from Telbrax (187.1.95.241) Origin IGP, metric 0, localpref 100, weight 0, external, best Last update: 20:39:17 ago Communities: 3549:2473 3549:30840 Note that the above route is on my BGP RIB table but will never go into FIB, it’s not marked valid as you can see on a short summary: flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incompleteflags destination gateway lpref med aspath origin 177.10.159.0/24 187.1.94.17 100 0 28250 3549 7018 28640 61894 i It’s lacking * flag (valid). And how the same route when I enable allowas-in: BGP routing table entry for 177.10.159.0/24 28250 3549 7018 28640 61894 Nexthop 187.1.94.17 (via 187.1.94.17) from Telbrax (187.1.95.241) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 20:44:42 ago Communities: 3549:2473 3549:30840 Now you can see “valid, best” and on summary you have *> flags: flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *> 177.10.159.0/24 187.1.94.17 100 0 28250 3549 7018 28640 61894 i 2) USA import: Local ASN here: 28640 Source ASN here: 61894 (same as local above) BGP routing table entry for 177.10.157.0/24 7018 3549 12989 28640 61894 Nexthop 12.122.120.7 (via 12.222.230.129) from 7018-ATT (12.122.120.7) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 20:59:52 ago As you can guess, due to “valid, best” this routing entry also has allowas-in. 3) USA import: Local ASN here: 28640 Source ASN here: 4.1392 Another sample is for a transit customer in Latin America from the USA perspective: BGP routing table entry for 191.5.130.0/23 7018 3549 12989 28640 4.1392 4.1392 4.1392 4.1392 Nexthop 12.122.120.7 (via 12.222.230.129) from 7018-ATT (12.122.120.7) Origin IGP, metric 0, localpref 100, weight 0, external, valid, best Last update: 21:21:24 ago I have more samples and scenarios which I can share on private anytime. Here I am using OpenBGP, and first scenario where route is on RIB but never goes on FIB is due to OpenBGP default loop control on route decision engine (RDE.) This is something you can not disable on OpenBGP, so, I had to add this feature to OpenBGP, my patch for it is available here: http://177.10.156.226/~eksffa/l/local-patch-openbgpd-allowas-in.c In the patch header I mention my understanding on how wrong are symptoms where you need to use it, so I will reproduce my understanding: This is a feature that should rarely be needed. Usually the need for this feature suggests something wrong on the current BGP setup. However in some particular setups it's just needed, and can be used without breaking BGP or adding loops. Cisco, Juniper and other BGP routing daemons do offer the same feature, sometimes with explicit control of how many times the AS number is accepted in the as-path. It does not help, the wrong setup will loop anyway Why this is a symptom for something wrong? First, one should not advertise a CIDR prefix on a different location using the same AS number. I know I am doing it wrong and I will fix it, I have a LACNIC assigned ASN, and started a process to get an ARIN assigned ASN. In a couple days I will have my ARIN assigned ASN and I will use it on ARIN locations, so, this scenario will be fixed and I will not see my own ASN in as-path anymore. Other scenarios I have faced, it’s not myself but some customers of mine, on different cities or different neighbors, and they contract independent upstream to the Internet. Say: City1 -> ATT -> Internet City2 -> Level3 -> Internet But city1 and city2 is the same company, and they need to be reached by each other (City1 -> Internet -> City2). What is wrong here is that this setup should have been done on iBGP as a primary option since it’s the same company. But sometimes this is just not possible immediately. Maybe you don’t have that cross connection, and maybe you are doing it right, you DO have an iBGP session but your fiber circuit or wireless circuit comes DOWN for any reason. If you don’t have another backup circuit, City1 will reach City2 via eBGP and therefore the “wrong / unusual” scenario will raise. Maybe a multihop iBGP using eBGP session ("qualify via bgp” on OpenBGP) might be more “correct” from the BGP perspective, but… it’s just the same original problem. The thing is, workarounds like using allowas-in should always be treated as temporary and is a symptom that something is strange, and a good setup should be aimed to stop having your own ASN on a RIB as-path. It’s also very important to notice that this loop prevention mechanism is also a security mechanism. This security mechanism is sometimes used for a good reason by network engineers. Say, if someone start to DDoS you w/ a good DDoS, with forged/spoofed IP addresses etc. I am not able to block by IP, source-as or anything like since I have no reliable information what's the DDoS real source. But with a little help from upstream providers and a few telemetry (flows) we can map the usual as-path for attacking packets to reach me. Therefore you may decide to manipulate your CIDR advertisements and include the AS number that is common path from the attacking vector to me. I confidently rely that when I add someone else’s AS path in my advertisement, this “someone else” will drop the route as a loop prevention when the announcement reaches their router. So, say, if you are attacked from an unknown spoofed source but you can check it is a certain East Europe or Asia or South America or Russian carrier as a common as-path, you can have the effect of blackholing your advertisement on those ASN hops without dealing with BGP communities or other mechanisms that have to be previously agreed and set among peers. So, on the other hand if you, somehow, disable this mechanism, like I just did with allowas-in, you have a potential security problem where someone announcing your CIDR with your ASN or just your ASN somewhere, and this advertisement happens to reach you, You can be victim of attack of different types, ranging from hijacking to other forms of denial of service. So it makes much more urgent the sense that if by any reason you see your own as on prefixes you receive, and you “just need it on FIB”, you must treat it as a temporary configuration and try to get rid of such workaround, getting yourself another ASN or full meshing iBGP among your locations, as the usual first moves to be taken. Regards, -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!"
On 1/28/15 1:32 AM, 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.
There is also the non-zero probability that they don't arrive. If this is and edge router if your neighbor is a juniper and the only instance of prefix advertisement with this case is your advertisement from your router your're not going to get it. From: --- https://www.juniper.net/documentation/en_US/junos14.2/topics/topic-map/bgp-r... Disabling Suppression of Route Advertisements Junos OS does not advertise the routes learned from one EBGP peer back to the same external BGP (EBGP) peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same AS as the originating peer, regardless of the routing instance. You can modify this behavior by including the advertise-peer-as statement in the configuration. To disable the default advertisement suppression, include the advertise-peer-as statement: Note: The route suppression default behavior is disabled if the as-override statement is included in the configuration. If you include the advertise-peer-as statement in the configuration, BGP advertises the route regardless of this check. To restore the default behavior, include the no-advertise-peer-as statement in the configuration: no-advertise-peer-as; If you include both the as-override and no-advertise-peer-as statements in the configuration, the no-advertise-peer-as statement is ignored. You can include these statements at multiple hierarchy levels. For a list of hierarchy levels at which you can include these statements, see the statement summary section for these statements. --- If this is an edge router and your provider is filtering those either from above or other reasons then you won't recieve them. If this in an ibgp session and they're not being accepted on the edge router you will never see them.
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!
participants (5)
-
Chuck Anderson -
joel jaeggli -
Patrick Tracanelli -
Pedro Cavaca -
Song Li