On Thu, 25 Apr 2013, Pavel Lunin wrote:
No, I propose to not even bother with copper, if you prefer. Just use a VLAN or any other type of virtual circuit inside those TerabitEthernet / SONET / FrameRelay / whatever.
So you propose to do away with the out of band network entirely, and instead do all of your management inband. While that is a certainly a fine choice for some networks, others do not want to fate share their management capabilities with their production traffic. Is that unreasonable?
And do you propose to use dedicated fibers just for management?
I don't just propose it, I do it. Depends on the network of course, but if you'd like an example, the network we put together for Interop every year has what we call "Access Ether". It is a true out of band management network. It's flat layer 2 (to keep it simple since it doesn't have to scale greater than a 100 devices or so), runs on completely independent switches from production traffic and runs on separate backhaul fiber (or copper in some cases).
There are operators that run their networks in a similar way.
Or, otherwise, how would you pass traffic to/from the copper switch, into which you plug the fxp0 of a remote router? I bet in >99% of cases, connectivity from NOC to the "OOB" switch shares fate with the connectivity to the router, whose fxp0 is plugged into this switch.
At some level there's fate sharing, sure. If Darth Vader uses the Death Star against Earth, then I'll lose both my inband and out of band management capabilities. If, however, I have a failure of the data plane somewhere in my production network, at least I can still reach the processor and send it new code or whatever I need to do.
Not even mentioning that this OOB switch is an additional point of failure with little chances to be backed up.
That's only the case if you completely disable inband management capabilities. Some networks choose to do this, some do not. For those that do not (again see the Interop network) it is not an additional failure point at all, but actually redundancy.
So there is nothing in the fxp0's "OOBness", what is worth its clumsiness.
Please don't get me wrong. I think the way fxp0 is implemented sucks big time. The fact that I have to use the default logical-system to make it useful and move all of my production traffic to others is super annoying. The lack of other features on that port makes it downright dangerous if you don't pay attention, but it is NOT useless.
-- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
