[c-nsp] Internet in VRF

[Dan Peachey]

On 5 May 2015 at 11:24, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:

> Hi Dan,
>
> > Dan Peachey
> > Sent: 05 May 2015 10:51
>
> >
> > On 5 May 2015 at 10:02, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> > 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