> There is nothing to stop me creating a horribly complex iBGP policy Decent bgp implementation should not allow iBGP learned routes to be subject to any bgp policy as doing so will easily result with inconsistent routing. So on this ground there can be bgp code path differences on how the routes are processed.
But if you have accept all policy for eBGP without any inbound modifications (match/set) then iBGP vs eBGP should indeed be pretty similar. Other processing ie. best path selection, rib insertion then fib insertion should be quite similar timing wise regardless of the type of the route. Thx, R. On Thu, Oct 11, 2018 at 10:38 PM James Bensley <[email protected]> wrote: > On Thu, 11 Oct 2018 at 15:30, Robert Raszuk <[email protected]> wrote: > > I think the difference Mark may have in mind that iBGP routes say from > RR are advertised from RR's control plane. Many RRs today are just x86 > control plane boxes with no forwarding. > > > > On the other hand number of implementations before sending route over > eBGP must make sure that those routes are installed in data plane locally > before being advertised. > > > > Of course non of this really matters if those routes are already > installed when you trigger advertisements to UUT. > > > Hi Rob, Mark, > > So that's not really an apples to apples comparison then. Are you > interested in seeing the different in vRR vs. physical RR vs physical > PE? > > > There are also few more little "delays" for eBGP vs iBGP depending on > your BGP code base - regarding policy processing or origin validation :). > > There is nothing to stop me creating a horribly complex iBGP policy so > I'm not sure policy length that is a factor. I was referring strictly > to the code performance, e.g. router model A, with firmware version B, > receives the exact same route set from an eBGP and iBGP neighbor (and > those two neighbors are the exact same spec). Is there till scope for > a difference in convergence time here? > > Cheers, > James. > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
