[j-nsp] Full table in L3VPN

[Mike Daniels]

2 reasons immediately come to mind as to a good reason to run it in a VRF. Firstly no need for RIB-groups!! :) Secondly you can separate your core / manangement  routes from public routes, this can act as another line of defence (as well as good firewall filters of course).



-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Saku Ytti
Sent: 02 September 2014 07:44
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Full table in L3VPN

On (2014-09-02 06:56 +0200), Mark Tinka wrote:

> This is one of those polarizing questions where you'll get an equal 
> share of answers from both sides of the bench.

I think main reason is, because it appears scary, and I subscribe to that notion myself.

When I try to explain it to myself in technical terms, I'm drawing up short.
In smart implementation, there should be insignificant DRAM use increase due to few bytes of RT and RD, none of these should affect HW resource use in anyway.
Infact JunOS and IOS should not have implied 'Default' VRF, it should be configured VRF like any other VRF. Because it simplifies the code-base, when you do not create VRF-aware and VRF-unaware features.
Infact if you look at FIB/HW, there global table is already just another VRF, as these structures lend poorly to exceptions. It's only the control-plane code, which due to legacy reasons contain duplicate code for exact same stuff, causing annoying feature parity problems amongst others.

I think the main benefit would be obviously the ease of adding Internet access to other VRFs.


--
  ++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

Any prices quoted in this email are for indicative purposes only and are subject to further technical appraisal. Additional installation charges may apply and all orders are subject to survey. Unless otherwise specified, prices are in GB Pounds and exclude VAT (or equivalent taxes). Acceptance of any proposal contained in this email is subject to formal contract. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virtual1.

Virtual1 is registered in England and Wales with company number 6177891. Our registered address is: 8 Angel Court, London, EC2R 7HP

This communication may contain confidential information. It may also be the subject of legal professional privilege and/or under copyright. If you are not an intended recipient, you must not keep, forward, copy, use, save or rely on this communication, and any such action is unauthorised and prohibited. If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery, and then delete both it and your reply.