[c-nsp] Small Issue With next-hop-self for VPNv4

[Piotr Marecki]

On Tue, Jul 26, 2005 at 01:47:02PM +0200, Tantsura, Jeff wrote:
> It is not cisco that dictates that it's RFC1966 - 
>   In some implementations, modification of the BGP path attribute,
>    NEXT_HOP is possible. For example, there could be a need for a RR to
>    modify NEXT_HOP for EBGP learned routes sent to its internal peers.
>    However, it must not be possible for an RR to set on reflected IBGP
>    routes as this breaks the basic principle of Route Reflection and
>    will result in potential black holeing of traffic.
> 
> It's also that you are not allowed to alter BGP attributes outbound (from
> Cisco), if I recall correctly not the case for Juniper
> 
> CCO:
> Using set clauses in outbound route maps modifies attributes, possibly
> creating routing loops. To avoid this, set clauses of outbound route maps
> are ignored for routes reflected to IBGP peers.
> 
> Personally, I don't think you should change default behaviour, unless you
> really must too.
> 
> 
> --
> Jeff Tantsura  CCIE# 11416
> Senior IP Network Engineer
>
Of course i'm aware of all "nice" effects that can be caused by resetting NEXT_HOP at route-reflector - however in this
particular scenario ( iBGP between PE and CE in L3VPN on Cisco ) using RR to reflect _AND_ reset NEXT_HOP to self is inevitable.   
Additionally, not only NEXT_HOP attribute during PE->CE "reflection" ( or rather , redistribution from VPN-IPv4 to IPv4 family)
change is required but also altering NEXT_HOP within MP-NLRI itself is needed ( PE<->PE ). On the other hand , "other vendor"
equipment supports iBGP on CE-PE without such dirty tricks.    
 
Also , according to my experience , setting NEXT_HOP to required value is supported on RR server through "set ip next-hop"
in route-map installed in outbound direction in at least 12.3 and 12.4 IOS trains.

regards

Piotr Marecki