[j-nsp] SNMP on logical-system fxp0

joel jaeggli joelja at bogus.com
Thu Apr 25 13:21:20 EDT 2013


On 4/25/13 8:47 AM, Saku Ytti wrote:
> On (2013-04-25 08:29 -0700), joel jaeggli wrote:
>
>>>> It's not OOB, it's completely fate-sharing the freebsd/junos.
>> it's not part of the forwarding plane so it certainly is not
>> in-band, what you connect it to of course is your business. we
>> connect them to our oob network.
> Yes it's not fate-sharing forwarding-plane, but it's fate-sharing the whole
> control-plane.
> You need ports, wiring to build fxp0 management network, which isn't even
> redundant, single port down and it's not reachable.
>
> Lot of cost+complexity for only benefit of being able to configure router
> when forwarding is broken but router not.
>
>> power cycle the SCB that the alternate RE is in. but having serial
>> console on on ethernet for example would eliminate a terminal server
>> potentiallly and that needs to happen eventually imho.
> Sadly Cisco did CMP, but removed in Nexus7k RP2, citing thermal/pincount
> and lack of customer demand.
> People aren't asking for proper solution to this problem in RFQs.
>
>> inline flow export is generated in linecard asics so it's not really
>> suitable for the oob port.
> I think this is really my point, you need
>
> * fxp0 for ssh, snmp
> * inband for netflow, snmp (if HW)  (redundant)
> * rs232 to attempt recovering box from control-plane software failure
>
> Why build fxp0, if you need inband for something anyhow? It costs money,
> adds complexity,
I doubt the impact on the BOM is signficant. the EM0/EM1 interfaces and 
the two ethernet switches embedded in the SCBs are a substantially more 
complex bit of RE supporting ethernet, then the third nic which is an 
intel 0x100f8086 sitting on one of the shared 32 pci busses and a port 
out the back. In the more embedded paltforms that's certainly just 
another ethernet embedded in the SOC.

pciconf -lv on your RE can point out just how simple an embedded pc 
you're actually dealing with, there's not a lot of magic there.

compared to what I'd rather have which would be a bmc or chassis 
management controller which actually probably is a significant 
integration issue particularly if you want access to both RE's and the 
SCBs and the linecards because that has to get physically connected via 
the midplane as the current REs are through the SCBs
>   and delivers no value if RS232 is also implemented with
> in-band.
>



More information about the juniper-nsp mailing list