Skip to content

Juniper SRX management routing-instance limitations

Juniper SRX management routing-instance limitations published on No Comments on Juniper SRX management routing-instance limitations

Having utilized routing-instances in the MX series to segregate management functions/protocols away from insecure internet sources I ran into an instance that’s quite unique to the SRX platform only.

Normally for management items on an MX series one would create a separate routing instance away from the routing instance (see image below). This allows for segregation and reduces potential security holes in your design.

Design Main Points:
Create a MGMT routing-instance and import/export ribs between the the main and mgmt inet.0 routing tables, NAT and re-route certain management protocols/functions (NTP, netconf, syslog, snmp, etc…) from the main routing table (inet.0) to mgmt.inet.0.

Note: This assumes that your company is very strict on opening ports and doing NAT device cross talk between your outside region. Valid in corporations with standards…not so much within smaller companies that don’t care for security of course.


Underlying Problem:
While most items can be re-routed and transferred over, one particular item is not doable on the SRX systems themselves.

If you want to use an internal ntp client to maintain and manage time for all of your server equipment SRX series routers simply cannot route ntp over any instance but the main one (IE. inet.0).

So why doesn’t it work on the SRX Series?
It’s the way the SRX bootup procedures are setup. It will always use the main routing table (inet.0).

KB Article:;=KB22499&actp;=RSS

The little things and difference are usually annoying so hopefully somebody will find this article in case they have similar designs and requirements.