[j-nsp] SNMP on logical-system fxp0

[Pavel Lunin]

Well, I agree, if you are brave enough to run a real OOB management
network, you have reasons to use fxp0 on the devices, that don't have 1G
ports, though I believe it's at least not cheaper than buying 1GE ports
just for management :) But in my experience real OOB mgt is a too rare
case in real life of the ISP world. BTW, yes, there is much more sense
in real OOB management in the access, but you first gave an example of
an all 10/100GE core, which is a slightly different thing. And even in
the access nothing really pushes you to use fxp0 for OOB mgt.

However it doesn't really matter, whether and when it's common or not.

If you know what and why you are doing, there is no problem. But most
people, who I talk with about using fxp0, want to use it just because,
with no good reason except "it is specially developed by vendors, so I
think, it's better to manage devices through it" and they just don't
really understand implications of bypassing data plane.

BTW, I don't say it's useless. When you need to remotely upload software
to a non-operationg box, this is an only option. But I'm sure it's
better to not use it for every day routine management like SNMP, if only
you have an option.


25.04.2013 19:07, Brandon Ross wrote:
> 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.
>