[161324] in North American Network Operators' Group
RE: internet routing table in a vrf
daemon@ATHENA.MIT.EDU (Adam Vitkovsky)
Fri Mar 8 03:38:01 2013
From: Adam Vitkovsky <adam.vitkovsky@swan.sk>
To: 'beavis daniels' <beavis.daniels@gmail.com>, <nanog@nanog.org>
In-Reply-To: <CA+MOkACrH1LJekpne4dDsrw7d0T13Pnge5FviX8vVOcLS1u+fg@mail.gmail.com>
Date: Fri, 8 Mar 2013 09:37:49 +0100
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi
1) control plane (route reflectors )
- you can either run a separate control plane infrastructure for inet vrf or
you can use common RRs that depends on your hardware capabilities (or you
can run a separate BGP process for reflecting inet vrf).
- no need to worry about data-plane as VPN routes are not installed into FIB
on RRs.
- as it was mentioned already porting inet prefixes into VPN table increases
control-plane demands.
2) forward plane (recursive lookup issues)
- for inet vrf I'd recommend per CE/next-hop labels instead of per prefix
labels to save up some label space.
- per next-hop label still points directly to outgoing interface so no
recursive lookups.
- recursive lookups are only needed with per VRF label -but I would not
recommend that as it could introduce loops when PIC is used in some
scenarios.
3) Operational
- I find it operationally complex to keep inet table on the P-Core
boxes/vrf-default.
4) DDOS
- as I mentioned you can run a separate infrastructure for inet vrf i.e.
dedicated box or SDR for inet PEs and inet RRs.
- or you can use separate BGP processes so in case some university decides
to test some special attribute on their BGP advertisements it will not
reload your VPN BGP process.
- or you can deploy enhanced BGP error handling on the edges and hope for
the best (actually this is what should be implemented as a first thing).
adam
