[j-nsp] SNMP on logical-system fxp0

[Alex Arseniev]

  ----- Original Message ----- 
  From: Pavel Lunin 
  To: Alex Arseniev 
  Cc: juniper-nsp 
  Sent: Thursday, April 25, 2013 9:56 PM
  Subject: Re: [j-nsp] SNMP on logical-system fxp0








  In a big enough network — anything. Broken NMS (it turns out to happen more often than I could think), malware on management PC, misconfigured something (IP address of a syslog server), intentional hack, etc. Also, routing does not mean that you don't have broadcast domains and BUM storms are not possible.


  [AA] if You actually still dealing with such issues in Your customer networks, my condolences. Especially sad is the issue with "management PC" - do Your customers use commodity Windows PC with freeware Solarwinds version as NMS?




  Even if you have a firewall behind each fxp0 (and how do you manage that hell of firewalls, another OOB MGT network for OOB management devices? And we still consider price of a single port? :) — I bet you don't rate limit SNMP and even ICMP on the firewalls.

  [AA] The firewalls are usually clustered, so if one fails, the second one takes over.
  [AA] The providers I worked with usually know how many ports they need now and in the nearest future so the overall cost of adding single revenue port for OOB could reach thousands of $$$ if in order to add just 1 more port the whole new FPC/DPC/MPC need to be purchased.


  Let's be honest, any big ISP have more than one mgt network and they rarely resemble the Eden. Just because ISPs merge and split, different BU manage different parts of the network, sometimes BU merge too, clever folks leave the company and stupid ones  sometimes come, etc.



  This is why I'd prefer to have more tools to be sure.


    [AA] Not sure if I follow, if BUs are administratively separate, how having a "true OOB interface" (i.e. CMP in Routing Engine) would make Your life easier?



  It becomes even worse, when it comes to multi-vendorness. Different equipment have different limitations for those ports. And all this makes the MGT network less and less flexible.

  I've once been involved in a project of a centralized monitoring system deployment for a big ISP. They had about 7 different routed OOB mgt networks (Core, Access, ATM, SDH, etc), I can't even say it was wrongly done. But just the need to provide connectivity to everything ended up with GRE over NAT over GRE over NAT salted with NAT and served through GRE sort of solutions (not everywhere, but partly). I won't say all or even most, but A LOT of troubles they had, came from the limitations of dedicated mgt interfaces.

  [AA] I also had to do a new OOB network design for another national ISP to replace similar mess of OOB networks because this national ISP clearly saw the value of unified OOB solution. Maybe Your ISP is not educated propely on the value of well-designed OOB network?