[j-nsp] remove-private for iBGP session

[Karsten Thomann]

Hello,

the point should be that the remove-private isn't a standard RFC based path modification.
How would you configure the remove-private when it isn't done by the ingress PE Router before 
sending the route to the RR?
How should the RR/Egress PE know from which routes it should remove the private AS and from 
which it shouldn't? There is no secret flag afaik to the route to tell the egress PE's to remove the 
private as number.

I'm a bit curious how Cisco is doing it, or where you expect that the AS is removed from the AS 
path.

Regards,
Karsten

Am Sonntag, 27. September 2015, 19:23:18 schrieb Cydon Satyr:
> Hello,
> 
> I'm very well aware of that which is why I'm confused.
> Here, PE is removing private AS before sending update to RR.
> 
> Could anyone explain what are we missing here?
> 
> Regards
> 
> On Sun, Sep 27, 2015 at 6:09 PM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> wrote:
> > Hello Cydon,
> > 
> > > Of Cydon Satyr
> > > Sent: Saturday, September 26, 2015 12:35 PM
> > > 
> > > Hello,
> > > 
> > > I was under the impression that remove-private works for eBGP sessions,
> > 
> > as
> > 
> > > it does on Cisco routers (if my memory serves me right).
> > > 
> > > But I notices that remove-private on a PE router would remove private AS
> > > (from customer's vrf bgp session) before sending it to a route
> > > reflector.
> > > 
> > > Is this normal behavior, or I'm missing something?
> > > 
> > > Regards
> > 
> > It's not normal according to the RFC4271 section 5.1.2.a
> > 
> > 5.1.2.  AS_PATH
> > 
> > >snip
> > >
> >    When a BGP speaker propagates a route it learned from another BGP
> >    speaker's UPDATE message, it modifies the route's AS_PATH attribute
> >    based on the location of the BGP speaker to which the route will be
> >    
> >    sent:
> >       a) When a given BGP speaker advertises the route to an internal
> >       
> >          peer, the advertising speaker SHALL NOT modify the AS_PATH
> >          attribute associated with the route.
> >       
> >       b) When a given BGP speaker advertises the route to an external
> >       
> >          peer, the advertising speaker updates the AS_PATH attribute as
> > >
> >          follows:
> > >snip
> > 
> > There are other attributes (e.g. MED springs to mind) that can't be
> > modified or set on iBGP sessions.
> > 
> > 
> > For iBGP to iBGP (on a RR)
> > On XR you can modify all attributes only when cmd "ibgp policy out
> > enforce-modifications"
> > Because by default:
> > In addition, when a RR reflects a route, it SHOULD NOT modify the
> > 
> >    following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
> >    Their modification could potentially result in routing loops.
> > 
> > adam
> > 
> >         Adam Vitkovsky
> >         IP Engineer
> > 
> > T:      0333 006 5936
> > E:      Adam.Vitkovsky at gamma.co.uk
> > W:      www.gamma.co.uk
> > 
> > This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents
> > of this email are confidential to the ordinary user of the email address
> > to
> > which it was addressed. This email is not intended to create any legal
> > relationship. No one else may place any reliance upon it, or copy or
> > forward all or any of it in any form (unless otherwise notified). If you
> > receive this email in error, please accept our apologies, we would be
> > obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or
> > email postmaster at gamma.co.uk
> > 
> > Gamma Telecom Limited, a company incorporated in England and Wales, with
> > limited liability, with registered number 04340834, and whose registered
> > office is at 5 Fleet Place London EC4M 7RD and whose principal place of
> > business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp