Adding VRFs/VLAN's/anything else to separate the traffic to reduce fate sharing is only adding complexity that will likely result in operator errors. While many of us have clue, even when we don't agree on the solutions, there are many more out there typing at routers at 2am, when even the simplest of configs will mix someone up and cause an out. The stats prove out these types of errors are more likely to cause an outage then DDoS or anything else. Now if we could only build and sell devices to stop operator error. On Wed, Sep 2, 2015 at 1:11 PM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 2 Sep 2015, at 22:26, Mark Tinka wrote:
When the line card congests, it doesn't care that one bit was part of a
VRF and the other doesn't. It all goes kaboom (even with the best of QoS intentions).
You don't necessarily have to put everything on the same fiber, interface, the same ASIC cluster, the same LC-CPU/-NPU, the same linecard, etc.
Fat-fingers in the global table or the Internet VRF or whatever won't cause problems in the management VRF, unless via route-leaking policies which allow them to do so or the kind of routing-table explosion which takes down a linecard or the whole box. A hardware casualty or software fault which takes down a linecard may not take down the whole box. And so forth.
iACLs are simpler, don't have to be updated so frequently to account for moves/adds/changes of the management infrastructure. It's easier to apply QoS policies to reserve bandwidth for telemetry and other management-plane traffic, etc. And so forth.
All this is highly variable and situationally-specific, but logical separation of management-plane traffic from production data-plane traffic is in general desirable, even as it's running on (at least some of) the same hardware. It isn't as good as true physical separation, but there's no sense in making the perfect the enemy of the merely good.
----------------------------------- Roland Dobbins <rdobbins@arbor.net>