On 2 Sep 2015, at 0:44, Jared Mauch wrote:
I think the key here is that Roland isn't often constrained by these financial considerations.
That's entirely true. I deal every day with customers who are, though.
I would respectfully disagree with Roland here and agree with Job, Niels, etc.
I understand where you and they are coming from, in this regard. I just disagree, as well.
A few networks have robust out of band networks, but most I've seen have an interesting mixture of things
Concur 100%.
and inband is usually the best method.
Let me be clear - OOB for flow telemetry can be actually provisioned on the same boxes which are handling the production network traffic. It isn't ideal, but it's better than running it truly inband in the production network, mixed in with customer traffic. VLANs, VRFs, whatever are a reasonable compromise, and a lot of folks do this. Inband is a huge risk, especially in a world of multi-hundred gb/sec reflection/amplification attacks (not to mention the other catastrophic failure scenarios). I know you sink a lot of UDP at the edges of your network to ameliorate this problem, but not all operators do that or agree with it either in principle or as a matter of optimal utility. I understand that this sort of thing is a decision that all network operators must make for themselves based upon their knowledge of their own networks and customer needs.
Those that do have "seperate" networks may actually be CoC services from another deparment in the same company riding the same P/PE devices (sometimes routers).
Yes, that's what I'm getting at above. It isn't ideal, but there's no reason to make the perfect the enemy of the merely good, agreed.
I've seen oob networks on DSL, datacenter wifi or cable swaps through the fence to an adjacent rack.
Absolutely. All kinds of creative lashups to get console access in difficult situations (and, as you noted previously, an increasing number of devices don't support serial console at all, which is highly annoying). ----------------------------------- Roland Dobbins <rdobbins@arbor.net>