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.lsong@gmail.com
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!
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.lsong@gmail.com
I suggest you work your way down :-) http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/137... Dennis Hagens Song Li schreef op 5/6/14 1:42 PM:
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!
On Tue, 06 May 2014 11:58:58 +0800, Song Li said:
I have one bgp convergence problem which confused me. The problem is as follows:
You may want to Google for 'BGP Wedgie'. https://www.nanog.org/meetings/nanog31/presentations/griffin.pdf http://www.rfc-base.org/txt/rfc-4264.txt Once you understand how and why they happen, your routing question will become clear. :)
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.
this is a bgp wedgie. is it real and caught in the wild? tim would be cheered. randy
Operationally speaking, AS1 should not be leaking routes from one upstream to the other. Bad route policy. Also, AS3 should not accept routes from AS1 that don't belong to it. Customer router filtering would prevent this.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Song Li Sent: Monday, May 5, 2014 11:59 PM To: NANOG Subject: 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.lsong@gmail.com
On Wednesday, May 07, 2014 07:28:46 PM Peter Rubenstein wrote:
Operationally speaking, AS1 should not be leaking routes from one upstream to the other. Bad route policy. Also, AS3 should not accept routes from AS1 that don't belong to it. Customer router filtering would prevent this.
How I wish this happened in real life. We are chasing route leaks several AS's down the path that are not even remotely connected to us on a weekly basis. But I guess that's what they pay us for :-(. Mark.
On Thu, May 8, 2014 at 1:51 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On Wednesday, May 07, 2014 07:28:46 PM Peter Rubenstein wrote:
Operationally speaking, AS1 should not be leaking routes from one upstream to the other. Bad route policy.
ideally it'd be nice to be valley-free... so to speak.
Also, AS3 should not accept routes from AS1 that don't belong to it. Customer router filtering would prevent this.
always with the route filtering... routes want to be free man, free!
How I wish this happened in real life.
We are chasing route leaks several AS's down the path that are not even remotely connected to us on a weekly basis. But I guess that's what they pay us for :-(.
if only there were some technology that could be used to thwart such things.
On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow wrote:
if only there were some technology that could be used to thwart such things.
It's gotten to a point where a repeat offender has me wound up enough to prepend his AS into some of my paths. I wish there was a simpler way to "turn them off". Mark.
On Thu, May 8, 2014 at 10:51 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On Thursday, May 08, 2014 04:41:21 PM Christopher Morrow wrote:
if only there were some technology that could be used to thwart such things.
It's gotten to a point where a repeat offender has me wound up enough to prepend his AS into some of my paths.
I wish there was a simpler way to "turn them off".
:( that's bad news... config hackery is brittle. (but fun)
participants (7)
-
Christopher Morrow -
ISP Services -
Mark Tinka -
Peter Rubenstein -
Randy Bush -
Song Li -
Valdis.Kletnieks＠vt.edu