Hi Mike > Mike > Sent: 05 May 2015 19:43 > > Hi, > > Now that I set off a very interesting fire storm about Internet in > a vrf, I have the next question, which is how do I accomplish it? > > I envision two vrf for example - > > internet - contains all my best paths and maybe including a default > route > subscribers - contains all of my internet subscriber routes, mostly > /32's (ipoe/pppoe customers), with a small number of /29's and larger. > > What would a simple config look like that lets my subscribers route > via the internet? Do I have to import the whole internet table into > subscribers, or ? > > Mike- >
Think about it, if you redistribute all prefixes from one VRF into the other and vice versa you might as well put everything into a single VRF right? >From a high level perspective there are two approaches: Either you maintain discrete tables and have a policy dictating which table to use in order to look up destination address of an incoming packet. -this approach involves no route leaking thus require policy-based routing. Or you maintain tables that share some prefixes between each other while NH for the leaked prefix points outside the VRF. -this approach could be memory intensive if the number of shared prefixes (prefixes that will reside in both tables) is high. As you can see the aim would be to share the least number of prefixes. That's where the summary routes come in handy. So packets destined for your IPoE/PPPoE customers coming from the Internet that end up in internet VRF need to have a route for your customer subnets. A route summarizing your /32 assignments would be enough plus the some /29 and some other routes In the opposite direction packets form your IPoE/PPPoE customers that end up in the services VRF and destined to internet need a route to various inet destinations. A single default route would be enough in most cases. You can create these summary routes manually/statically in each VRF pointing to the other VRF Or you can create them while redistributing the prefixes into BGP in a local VRF and let BGP to leak these to the other VRF -this works also later on if you decide to put the VRFs onto different routers. adam --------------------------------------------------------------------------------------- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com --------------------------------------------------------------------------------------- _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
