> On Sep 1, 2015, at 6:39 PM, Roland Dobbins <rdobb...@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
