Subject: Re: [Idr] Transient loop prevention when using the best external and add-path approaches

From: Uli Bornhauser <[email-masked]>
Date: Mon, 1 Mar 2010 10:20:10 +0100

Hi Xu,

Am 01.03.2010 um 03:59 schrieb Xu Xiaohu:

> Hi
>  
> If the route reflector Rnew chooses the route to P learnt from R1 as the best one, it will not reflect the route to P learnt from R2 to other clients such as R1.

all reflectors are at the same hierarchy level, there is no client in this example. As I already stated, the example only represents the physical network structure and all reflectors are of course fully meshed via iBGP. Thus, R2 directly advertises its best path to all other Route Reflectors, in particular R1. There is no need of reflection.

Alternatively, you can think of a simple iBGP full-mesh without Route Reflection (which is also possible in your original example as only reflectors on the same hierarchy level are specified).

Regards

Uli

>  
> Best wishes,
> Xiaohu
>  
> 发件人: Uli Bornhauser [mailto:[email-masked]] 
> 发送时间: 2010年2月28日 4:48
> 收件人: xuxiaohu 41208
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [Idr] Transient loop prevention when using the best external and add-path approaches
>  
> Hi Xu,
>  
> independent of your discussion about the IGP next-hop down event and the possible corresponding problems, regarding your original issue, I want to point out that the transient loop effect you have described is IMHO no design problem of best-external and add-path, respectively.
> In principle, the effect you have described may also appear if classical BGP and Route Reflection are used. Consider your original example and add a fourth reflector "Rnew" in the following way (BGP sessions are of course kept between all reflectors):
>  
>          AS#2                   AS#3
>           |                       |
>           |                       |
>    +------+-----------------------+------+
>    |   +--+--+  2  +-----+  2  +--+--+   |
>    |   |  R1 +-----+ Rnew+-----+  R2 |   |
>    |   +-----+     +--+--+     +-----+   |
>    |          \       +       /          |
>    |           \      +      /           |
>    |            \   1 +     /            |
>    |           1 \    +    / 3           |
>    |              \   +   /              |
>    |               *--+--*               |
>    |               |  R3 |               |
>    |               +-----+               |
>    |                              AS#1   |
>    +-------------------------------------+
>  
>  
> Assume that both paths to P via AS#2 and AS#3 are of equal preference regarding the first path attributes up and including step b) (ORIGIN_CODE).
> The MED is not compared, as both paths have different peer-ASs. W.l.o.g., let R1 specify the lower BGP ID. So all routers route via R1, except of R2 - this router of course prefers the externally learned path.
> When R1's connection to AS#2 breaks (or the path is withdrawn), the same basic effect you have described temporarily appears:
> - R3 forwards traffic to R1. 
> - R1 forwards traffic to R2 via Rnew due to fast local repair (as R2 uses the path via AS#3, it is known by all reflectors)
> - Rnew forwards traffic back to R1.
>  
> Thus, we have the same problem in principle, but this time best-external and add-path are not involved.
>  
> Regards
>  
> Uli
>  
> Am 27.02.2010 um 16:18 schrieb xuxiaohu 41208:
> 
> 
> Hi Robert,
> 
> ----- 原邮件 -----
> 发件人: Robert Raszuk <[email-masked]>
> 日期: 星期六, 二月 27日, 2010 下午7:16
> 主题: Re: [Idr] Transient loop prevention when using the best external and add-path approaches
> 收件人: Xu Xiaohu <[email-masked]>
> 抄送: [email-masked]
> 
> 
> Hi Xu,
>>  
>>>> It sure can. "Tracking all atomic next hops" is the key here.
>>>  
>>> For example, one remote peer is down while another one is still
>> OK, should
>>> the IGP route to the local ASBR itself be withdrawn?
>>  
>> The simplest (but not only approach) is to remove the local next hop
>> from the IGP only when all original next hops go down.
>>  
>> That is still better then to attract traffic to such ASBR when all
>> external peering go down.
>>  
>> But the main question to ask is why to set next hop to self on
>> ASBR for
>> IPv4 Internet ?
> 
> There does exist some scenarios where the local ASBR should set the next-hops of iBGP routes to self. BGP-free core and Softwire Mesh are two examples. Even in a normal BGP scenario, if a given local ASBR is connected to a remote AS via two remote peers (e.g., P1 and P2), it would be better for the local ASBR to set the next-hops of the iBGP routes to self. In case that the nexthop of a learnt eBGP route is changed from P1 to P2, if all of 
> the path attributes except the nexthop attribute are identical, there is no need for the local ASBR to withdraw the previous route update and then advertise a new one. In this way, the route advertisement traffic can be reduced greatly.
> 
> Best wishes,
> Xiaohu
> 
> 
> That clearly seems to have the disadvantage of blocking the original
>> fast next hop down event propagation of peering ASBR or interface
>> to it.
>>  
>> In fact this is not related to best external or add-paths or
>> diverse-path ways of distributing additional paths. The same issue
>> happens with simple IBGP full mesh today.
>>  
>> In the past I had one proposal to still signal it in BGP to
>> address the
>> case you are pointing out:
>>  
>> http://ftp.iptel.org/pub/standards/internet-drafts/draft-raszuk-
>> ext-failure-propagation-00.txt
>>  
>> But it seemed that it is much better and faster to leave the next hop
>> unchanged.
>>  
>> Cheers,
>> R.
>>  
>>  
>>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>  
> -- 
> _______________________________________________________
> ULI BORNHAUSER
> University of Bonn - Institute of Computer Science IV
> c/o Bonn-Aachen International Center for Information Technology B-IT 
> Dahlmannstr. 2 - D-53113 Bonn - Germany
> 
> Web: www.cs.bonn.edu/IV/ub
> Email: [email-masked]          
> Phone: +49 (228) 73 - 4550
> Fax: +49 (228) 73 - 4571
>  

-- 
_______________________________________________________
ULI BORNHAUSER
University of Bonn - Institute of Computer Science IV
c/o Bonn-Aachen International Center for Information Technology B-IT 
Dahlmannstr. 2 - D-53113 Bonn - Germany

Web: www.cs.bonn.edu/IV/ub
Email: [email-masked]			
Phone: +49 (228) 73 - 4550
Fax: +49 (228) 73 - 4571