Juniper Management Routing Instances

If you’re doing network security properly, you are running the management interfaces of your network devices – (routers, switches, server management boards) – on a completely separate network from your end user traffic, so that management traffic is maintained out-of-bounds (OOB).

OOB networks achieve several things – it separates management traffic, through which login credentials may be passed – from operational network traffic, providing a layer of security. Administrative access to the device should not be available from any other network to which the device is connected.

Secondly, OOB networks can provide a non-flooded network path to the device if the operational interfaces of the device are under some kind of attack – (eg: DDoS) – increasing your chance of getting onto the device to take remedial action without having to take the device completely offline.

So, pretty useful.

I’m currently working on a firewall deployment and found myself needing to configure the management interfaces on a pair of Juniper firewalls. It used to be difficult to connect the management interface to the network without using the same routing table as the operational traffic.

Yes it could be separate, but you weren’t able to get the management interface – (typically “fxp0”) – into its own virtual routing instance so that it could be physically connected to a different physical network, while still being routed. This would be required when you’re not on the same network as the device, and you have to get to it remotely.

I’ve achieved this in the past, but it’s been a super long time since I’ve had to do it, so had to go Googling to remind myself what you had to do. The Juniper document has all the pieces required, but smooshed it all up in other discussion and for some people it will be hard to follow.

It only requires three commands and JunOS 17.3R1 and above to achieve – (you have been doing updates, right?)

Let’s say your management network is 192.168.11.0/24, with a default gateway of 192.168.11.254.

The first thing you need to do is tell the device that you want to use a management virtual routing instance. This is a special kind of virtual routing instance that works slightly differently than any others you might need to run on the device.

Just turn the feature on with the following:

set system management-instance

This tells the device to enable a routing instance specifically for the management interface, which for most Juniper devices is “fxp0”.

Next, set the address you want within your network range, for example “192.168.11.11”, noting that it needs to be on the management interface – (noting the “fxp0” reference):

set interfaces fxp0 unit 0 family inet address 192.168.11.11/24

Then you need to create the special routing instance to tie it all together. This routing instance must be called “mgmt_junos” – (when you enable management-instance with the first command, it tells JunOS to look for a routing instance with that name, so that it knows to treat it as management traffic only, and therefore prevents you from creating two of them) – and then set the default route on that management network:

set routing-instances mgmt_junos routing-options static route 0.0.0.0/0 next-hop 192.168.11.254

Done.

The device will now route traffic within your management network, independently of the routing table for the rest of the traffic – thereby separating the management traffic from anywhere the bad guys might be hitting you from!

The Little Server That Could

Eight months ago, we had a catastrophic sequence of failures that – (as one of several consequences) – brought down our web infrastructure at the place of employment.

Due to the nature of some of those consequences, we weren’t able to immediately bring that web infrastructure back up on any of our tier 1 equipment.

So I had to compromise.

Running around the office, I scrounged the most powerful PC I could find, and as much memory as possible to run up a temporary hypervisor – (Xen) – then copy the virtual hard disks off our storage array, fire all four virtual machines up on this temporary hardware, and finally get the suite of corporate websites back up and running.

I also didn’t have a switch to connect it all back up to the fibre link serving our websites. You’ll notice in the picture of this Frankenstein below, a Telstra VDSL NBN business modem acting as the switch. It was just laying around!

Yes – one of these!

Given the fibre link is 100Mbps, and the “switch” is a 1000Mbps “switch”, this shouldn’t have been a problem, but I was worried about the switching backplane of this little fellow. Was it going to be able to cope? I had my doubts.

And all of this was supposed to be temporary.

Temporary.

Right.

Got it.

Obviously, it didn’t work out that way, and it was eight months later that I was finally able to shut this “temporary” server down, having finally migrated everything back out onto proper hardware and networking again.

For eight months, this conglomeration hosted 28 corporate websites and served millions and millions and millions of web requests. I can’t tell you how many – if I’d known it was going to hang around for 8 months, I would have made provisions to log and find out exactly how many!

What I’m most proud of when it comes to this beast, is that nobody knew it was like that. The performance of the websites dropped only marginally – (almost negligibly) – and this thing just kept on trucking.

Day after day. Night after night. Week after week.

I lived in constant fear of arriving at the office each day and finding the little Telstra router melted into oblivion, or the PC itself having died.

But it never did, not once.

It was the little server that could, and I’m going to miss it!

The moral of the story is that even in the midst of massive IT disasters, there’s always a way – and that sometimes, the basics can get you by!

And above all, don’t panic!