Devil's Advocate - Segment Routing, Why?

Baldur Norddahl baldur.norddahl at gmail.com
Sat Jun 20 20:00:10 UTC 2020


On Sat, Jun 20, 2020 at 12:38 PM Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 20/Jun/20 11:27, Baldur Norddahl wrote:
>
>
>>
> We run the Internet in a VRF to get watertight separation between
> management and the Internet. I do also have a CGN vrf but that one has very
> few routes in it (99% being subscriber management created, eg. one route
> per customer). Why would this create a scaling issue? If you collapse our
> three routing tables into one, you would have exactly the same number of
> routes. All we did was separate the routes into namespaces, to establish a
> firewall that prevents traffic to flow where it shouldn't.
>
>
> It may be less of an issue in 2020 with the current control planes and how
> far the code has come, but in the early days of l3vpn's, the number of
> VRF's you could have was directly proportional to the number of routes you
> had in each one. More VRF's, less routes for each. More routes per VRF,
> less VRF's in total.
>
> I don't know if that's still an issue today, as we don't run the Internet
> in a VRF. I'd defer to those with that experience, who knew about the
> scaling limitations of the past.
>
>
I can't speak for the year 2000 as I was not doing networking at this level
at that time. But when I check the specs for the base mx204 it says
something like 32 VRFs, 2 million routes in FIB and 6 million routes in
RIB. Clearly those numbers are the total of routes across all VRFs
otherwise you arrive at silly numbers (64 million FIB if you multiply, 128k
FIB if you divide by 32). My conclusion is that scale wise you are ok as
long you do not try to have more than one VRF with a complete copy of the
DFZ.

More worrying is that 2 million routes will soon not be enough to install
all routes with a backup route, invalidating BGP FRR.

Regards,

Baldur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200620/b89c9d52/attachment.html>


More information about the NANOG mailing list