4

Out of the box, it seems that the Juniper management routing is part of the default route table. Can I use logical systems to isolate the service plane from management routing? Are there any drawbacks?

1
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 5, 2021 at 22:52

1 Answer 1

8

This can easily turn into a debate, sure you could do management in different logical-system, but what are the perceived gains? You're still going to need to protect the main instance just the same.
In my opinion you gain nothing but you add complexity, which means added risk of downtime.

It would be different matter on SUP2T or Nexus7k with CMP, where you truly have separate out-of-band interface available.

My recommendation would be to optimize for least complexity, do on-band ssh management via normal main instance and have RS232 (alas, necessary evil) as back-up out-of-band.

If you go through this route, it'll work, there will be some inconveniences like copying software, but you can cope with it, with 'set cli logical-system MGMT'

You need two solution, one for normal day-to-day work, and another for OOB, when system or network is broken. OOB is easy, you need RS232, as RS232 is only solution you can use, to try to reboot box when junos is not running or unresponsive (set system debugger-on-break).
For your main day-to-day work, it's more debatable, you have three options:

  1. use on-band (same routes as production INET)
  2. use routing-instance (you'll get routing separation, but use same copy of RPD, but I guess you're using FXP0, which is not supported here)
  3. use logical-system, another copy of RPD is ran just for MGMT

You mentioned need to have symmetric route. I assume from this, that you want to use FXP0 for MGMT and you have another competing route for return traffic, which you need, as NMS server network is used for something else than just NMS, which is bit worrying.
In my opinion FXP0 is simply not needed, as it's not OOB (like CMP is) you cannot even protect FXP0 port via FW filter, as it's not HW interface.

But if we assume that you want to keep using FXP0 then you indeed pretty-much MUST put it in logical-system, even if you didn't have competing route for NMS, you'd still need to put FXP0 in logical-system, otherwise you expose your NMS network to attacks from the on-band, which you cannot protect, as you cannot put HW FW filter in the FXP0 interface.

6
  • 1
    I added content. I hope it's not too rambling.
    – ytti
    Jun 7, 2013 at 6:59
  • 1
    Note you can't actually put fxp0 in an LS, you can only put the rest of the device in one and leave fxp0 out.
    – LapTop006
    Jun 7, 2013 at 8:47
  • 1
    I think you might mix LS and RI, you can't put FXP0 on RI, but you can put it on LS.
    – ytti
    Jun 7, 2013 at 8:52
  • 1
    Not on MX/T last I tried, this may have finally been fixed in 12.X
    – LapTop006
    Jun 7, 2013 at 9:58
  • 1
    I just tried on 11.4R6.6 on MX80 at least commits just fine and 'show interfaces' lists just fxp0.0 interface. fxp's are not wired in lab, so cannot test if it pings, but as it's just 'software' port, I can't see why not.
    – ytti
    Jun 7, 2013 at 10:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.