[j-nsp] SNMP on logical-system fxp0
Brandon Ross
bross at pobox.com
Thu Apr 25 11:07:18 EDT 2013
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
More information about the juniper-nsp
mailing list