On 5 May 2015 at 11:24, Adam Vitkovsky <[email protected]> wrote:
> Hi Dan, > > > Dan Peachey > > Sent: 05 May 2015 10:51 > > > > > On 5 May 2015 at 10:02, Adam Vitkovsky <[email protected]> > > wrote: > > > > > > > > > > > > Mark Tinka > > > > Sent: 04 May 2015 21:21 > > > > > > > > > > We don’t run Internet in a VRF, we have no real use cases where we > > > can’t > > > > control what we need through policy. Our core infrastructure isn’t > > > accessible > > > > from our customers or the Internet, but it does require using the > right > > > > infrastructure ACLs. If I was doing a greenfield build may do it but > > > having the > > > > complexity of putting different transits, peers, etc. in their own > VRFs > > > is kind > > > > of overkill IMHO. > > > > > > > > +1. > > > > > > > > Mark. > > > > > > > > > Hi folks, > > > > > > Assuming you have more than one AS-exit and you don't have full-mesh > > > between all BGP speakers, then how do you get the alternate/backup AS- > > Exit > > > paths for Internet prefixes to all the PEs please? > > > Although I admit that the convergence times of Internet services might > not > > > be a cause for concern so a minute of downtime might be acceptable. > > > > > > adam > > > > > > > > > > BGP add-paths can achieve this: > > > > http://www.cisco.com/c/en/us/td/docs/ios- > > xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/irg-additional- > > paths.html > > > > This gives visibility of backup routes to your whole network (or more > than > > a single backup route if you want). You can also apply policy if you want > > to be selective about which backup routes are advertised. > > > > As far as convergence is concerned, BGP next-hop tracking can be tuned to > > get you ~1 second convergence (or less if you like to live life on the > > edge) for next-hop changes and for transit/peering failures your edge > > routers can re-route traffic to the backup exit point whilst it's > > withdrawing BGP routes for the failed peering/transit so minute(s) of > > downtime can be avoided. > > > > Cheers, > > > > Dan > > I'm aware of the add-path feature though the drawback is that you'd have > to deploy yet another feature whereas with Internet in a VRF you can just > use unique RDs. > Of course in both cases you'd still need to run best-external and BGP-PIC > to achieve the ultra-fast local repair. > So the point is that instead of "BGP-ipv4 + add-path & BGP-ipv6 + add-path > & BGP-vpnv4 & BGP-vpnv6" > -you can run just "BGP-vpnv4 & BGP-vpnv6" on the RRs > > adam > Sure it's a drawback deploying a new feature but it depends on the network/situation. If you have a network that already has Internet in GRT and you want to improve routing diversity and convergence, then add-paths is a lot less painful than trying to move Internet into a VRF. Internet in VRF has it's merits and I'm not against it but personally I prefer Internet in GRT - I've never come across a situation where I couldn't achieve something with Internet in GRT vs. in a VRF and I'd prefer to avoid the extra resource usage it entails and the potential for someone to sausage finger something and import the full table into another VRF and kill the FIB. IIRC, enabling add-paths overrides best-external (enables it anyway) but that may be platform dependent. I don't know why PIC would be required - I don't see any need for sub-second convergence of Internet prefixes (and more than a single FIB entry for an Internet prefix). I'm sure someone will come along with a use case... :) Cheers, Dan _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
