Re: NetFlow - path from Routers to Collector

[Jared Mauch <jared () puck nether net>]

> On Sep 1, 2015, at 6:39 PM, Roland Dobbins <rdobbins () arbor net> wrote:
>
> On 2 Sep 2015, at 3:45, Chuck Church wrote:
>
> > Most OOB is lacking redundancy too, so a single failure can really take the shine off an OOB deployment.
>
> Even if you're using old, grandfathered equipment for it, there's no reason why your OOB/DCN can't have a reasonable 
> degree of redundancy.  Since, it's like, *what you use to control your entire network*.

Most networks use inband to manage them.

> Underinvesting in management capabilities and capacities has always been a problem, of course.  Some organizations 
> just won't learn until they've gone through a disaster or three.

Yes.  let me know when the vendors catch up in this area.  I often see people say to create a new network as job 
security vs making the inband network survive attacks or be provisioned properly.

Most people I’ve seen have little data or insight into their networks, or don’t have the level that they would desire 
as tools are expensive or impossible to justify due to capital costs.  Tossing in a recurring opex cost of DC XC fee  + 
transport + XC fee + redundant aggregation often doesn’t have the ROI you infer here.  I’ve put together some models in 
this area.  It seems to me the DC/real estate companies involved could make a lot (more) money by offering an OOB 
service that is 10Mb/s flat-rate for the same as an XC fee and compete with their customers.

Things continue to be a challenge as less equipment works with a serial console and the expectation of developers of 
these embedded solutions don’t take into account low bitrate connections that are often used in last-resort situations.

We have a well oiled set of processes and checklists to monitor and test our management network.  Patrick Gilmore has 
personally mocked me because of its method and technique, but the reality is it works.

- Jared