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, and delivers no value if RS232 is also implemented with in-band. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp