NetFlow - path from Routers to Collector

Wed Sep 2 16:20:26 UTC 2015

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 at 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 at arbor.net>
>