[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