Blogroll

Virtual Routing Instances – SRX style

I discussed in my previous post that I wanted to add virtual routing instances to the SRX. This would allow me to learn OSPF in a real device see how it handles on JUNOS. Kurt Bales (@networkjanitor) dropped some hints and I found some resources over at 3fives. After looking at how it was done, I decided to use what I had seen and learn via CLI. I contemplated a screen cast but I still am quite slow at the CLI. My results are below. Lets journey together into making a one box lab.

“A virtual SRX appears”“Pokeball go”

Once you nail your first configuration it seems to get a bit manageable. Breaking it down we are creating a network using the logical tunnel interfaces. We assign unit, peer-unit, specify ethernet encapsulation, and assign an IP address. We do this for each interface on each device in the topology. Important to remember that the SRX110 supports three routing instances.

Right. So what does this mean? Well think about it. What we have essentially done is create distinct firewalls. Due to the fact we are in flow mode each routing Instance needs its own unique security zone. In packet mode (router mode) you don’t need to care about this. So now lets create a trust and untrust zones per routing instance.

Remember your fellow co-workers and also change request ticket IDs when commenting commits. It will save them burning effigies of you later. Alright, now the pings before didn’t work. Time to test direct connectivity.

Next blog we will look at establishing a basic OSPF area and explore what JUNOS has to offer network engineers in configuring and deploying OSPF networks. I am still amazed that this machine picture above can do all this. I am looking at you ASA 5500 series. I am excited. Thank you for reading and I hope you have gained something from this.

Yeah it is. Thanks for the reference. I had a good look at what you did and understood the concept then sought to reproduce it. It is awesome the fact that you can have one physical box but do so much with it and not get tripped up by licensing at each step.

Notice that the security zone limits are strictly enforced, while the number of virtual routing instances are a recommendation, and are not enforced. If you get carried away and try to use 10 VRs with a SRX110 cluster, you will be punished by extremely long commit times, even with lightweight configurations.

Thanks for that. I hadn’t noticed that it wasn’t hard capped, I just used the datasheet. I did notice the IDP did affect boot and commit times once activated on the default and 2 of the RI’s. It didn’t seem to affect runtime performance. SRX110 cluster would be a nice little HA branch deployment.

I was introduced to Junos when the M40 went live in Quest’s backbone, needless to say I was addicted! I know you worked on the ASA platform which isn’t too bad but you’ll notice the ease of use with the SRX and its fun . ASA- I personally don’t prefer the use “outside, inside, global” naming convention and the flat config when trouble shooting complex cases…just my two cents …!

I don’t mind the ASA – they are my primary $JOB1 device – problem is that they can sometimes be far too expensive to keep the whole notion of end to end Cisco. Comparable SRX + staff training still don’t come close to the price of the SRX.

Yeah, Inside, Outside, DMZ are default security zones. I think people run with it for familiarity reasons.