[161338] in North American Network Operators' Group
RE: internet routing table in a vrf
daemon@ATHENA.MIT.EDU (Matt Newsom)
Fri Mar 8 13:18:06 2013
From: Matt Newsom <matt.newsom@RACKSPACE.COM>
To: Saku Ytti <saku@ytti.fi>, "nanog@nanog.org" <nanog@nanog.org>
Date: Fri, 8 Mar 2013 18:17:51 +0000
In-Reply-To: <20130308172324.GA18010@pob.ytti.fi>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
If you run PIC and hide the next hop information between a loopback wh=
ich is what will happen in a vpn environment you will lose awareness of the=
failure of an edge link on a remote PE. The remote PE will continue to sen=
d traffic to the PE with the failed link until it has completely converged =
both at the control plane, and written to the FIB. If the remote PE has PIC=
running he can bounce that traffic back to his backup path via another PE.=
There will be some percentage of your traffic that will then form a transi=
ent micro loop though because that remote PE will have his primary path thr=
ough the failed link due to shortest as path length etc, and he will not ha=
ve converged yet around the failure on the remote PE and has no awareness o=
f the failure. One possible solution to this is to guarantee that a PE will=
never use another PE for a primary transit route. This can be accomplished=
via metrics such as weight etc.. Again one of the downsides of this is you=
need to run VRF labels so that a local IP lookup can be done on the PE wit=
h the failed link and it can execute a local repair when it see's the link =
drop.=20
-----Original Message-----
From: Saku Ytti [mailto:saku@ytti.fi]=20
Sent: Friday, March 08, 2013 11:23 AM
To: nanog@nanog.org
Subject: Re: internet routing table in a vrf
On (2013-03-08 16:40 +0000), Matt Newsom wrote:
> 2) forward plane (recursive lookup issues)
> Most platforms program prefix's with associated labels slower s=
o your base convergence will suffer.=20
Do you have any reference you could share? What level of penalty per prefix=
have you observed in each platform tested?
>In addition if you want to run PIC you will likely be left with a bit of c=
ustom engineering to make it work. VPN's hide the next hop behind the loo=
pback of the PE so next hop failure awareness of an edge tie will be lost. =
If you can stomach the double lookup you can run per-vrf labels (per prefix=
isn't feasible on most platforms) and weight up your edge ties and force a=
bounce back to another PE, otherwise you will be stuck with bgp control pl=
ane based convergence with per-ce labels.
PIC is about converging each prefix at the same time. It does not make stat=
ement where next_hop is pointing, is it loop0 (next-hop-self in INET) or is=
it edge CE.
If your IGP carries all edge links, and you don't run next-hop-self, far en=
d PE can converge faster in INET scenario. But current efforts are not to f=
ix this, current efforts are to make the local PE do hitless repair when ar=
riving frame is pointing to dead edge interface.
It seems to be very rare to run INET in this way, majority don't carry edge=
links in IGP and do run next-hop-self.
--
++ytti
