> Tim Warnock > Sent: Friday, October 12, 2018 2:14 AM > > > -----Original Message----- > > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf > > Of Robert Raszuk So for educational purposes could you describe some > > real valid use cases to apply bgp policies on routes *received* over > > IBGP ? > > > > Thx, > > Robert. > > Setting local preference? > > Rewriting next hop? > I think Robert was interested in use cases not what attribute can be set in ingress on an iBGP session.
This question got me thinking actually, There are several possible attach-points that can be used to manipulate the iBGP route before it gets installed into RIB, (ibgp session/vrf import/BGP->RIB) Now would you say all of these are sort of in the inbound direction from the iBGP perspective? After all the iBGP route would be subject to all these before it gets installed to RIB. With regards to the use cases, I think that one common trait of all the use cases relying on either of the above mentioned attach points, is the need to manipulate how the route is treated locally on the receiving BGP speaker -which ,driven by the use case, would be in contrary with how the same route is treated on all other speakers in the AS. (think one size does not fit all) Thinking about it this need for ingress policy on iBGP sessions is rooted in the fact that one (by default and no hacks) can't "process" a BGP route for the same prefix multiple times where each copy would be intended only for a specific receiver or a set of receivers. The specifics of how that is accomplished are irrelevant, but what stays is that a policy in "ingress" direction is indeed required in these use cases. //yes I know I should not be using term "bgp route" in context of bgp process and should be using term "prefix" or "path" instead. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/