Tuesday, December 18, 2018

Regarding Juniper OOB Mgmt Interfaces

JUNOS 17 code finally introduced the new feature of "putting management interface in a non-default routing-instance."

This allows a truly OOB Mgmt Interface in its own separate VRF. (What Cisco has been doing for years.)

However, am I correct in saying that Juniper has been putting these OOB Mgmt interfaces (usually called me0 or fxp0) on their gear for years and years before this 17 code came out?

So... how did you use that mgmt interface before 17 code? It just kinda boggles my mind.

One thing I've done is to leave only the mgmt interface in the default routing-instance, and all other layer 3 interfaces on the box go in a separate routing-instance (usually type virtual-router) and boom you kinda get a hacky version of the 17 code mgmt vrf, without 17 code.

Now the one big problem I have with this, is that it needlessly complicates configuration and also breaks some things, as some features just don't support routing-instance and have to be left in the default instance.

To make matters worse the new feature in 17 code isn't perfect. Want to do Radius Authentication using the new mgmt vrf? Better upgrade to 18 code, because on 17 code Radius will force using the default routing-instance. 18 code includes an enhancement to Radius allowing it to use the new management VRF.

I mean.. just what in the Hell is going on with this!? The 18 code is buggy and not recommended by JTAC for production yet!

From what I've seen on blogs and forum posts it seems the most popular solution is to simply not use the OOB Mgmt Interface on Juniper gear, instead using in-band mgmt like an IRB or lo0 interface.

Is that what you all do, too? I'm genuinely curious in you bigger Juniper shops, how do you guys manage your devices? Do you use em0/fxp0 interfaces? Or do you ignore them. How do you work around the flaws with trying to use them?

One thing suggested to me is to go ahead and leave the oob interface in the same routing-instance as the production layer 3 interfaces, but to just have specific /32 routes pointed out it, like point the route for your radius server, your snmp server, etc out the em0/fxp0 interface, including the network management subnet (i.e. where will you SSH to the box from?)

My problem with that is, at that point, your device participates in routing traffic onto your management interface. In other words, doing it that way, to me, would allow someone to send a packet to your device and the device will then happily route that packet out the oob interface! Ugh, that just really bugs me, and it's not secure especially like for an Internet edge router, you REALLY want the production interfaces in a different VRF from the mgmt network, period! Or compromises can happen, seriously.

Ok I'm done ranting and raving now. Reddit please tell me how wrong I am and how to correctly and painlessly use these interfaces to manage my devices, and I will be eternally grateful.

Thanks!



No comments:

Post a Comment