Juniper virtual lab guide for JNCIA/JNCIS

[wintermute000]

Here is a virtual lab that I designed to assist in my JNCIA/JNCIS pursuit from the point of view as a Cisco engineer. Unfortunately being virtual there is no switching, but it covers a large chunk of the routing syllabus and can be easily expanded upon with more knobs to fiddle with. You'll also gain a ton of familiarity with the command line/ system features as you go.

Be adventurous and constantly try out system features like config rollback, loading external backup configs, saving configs to external FTP, etc to get you through the JNCIA sysadmin side.
I attach the finished configurations as a reference point.

It is built in Vmware (ESXi) but there is no reason why you can't use any other hypervisor that can run the appliance, so far Juniper have provided vmware and KVM builds. If you don't have a ESXi yet, then why the heck not?

I've tried to be descriptive without handing it 'copy-and-paste' to you. If any newbies find this difficult to follow then apologies in advance, and I can only suggest to look at the finished configs as a reference point.

LAB DIAGRAM
https://anonfile.com/34s0Pab0b0/junos-lab.pdf
LAB FINAL CONFIGURATIONS
https://anonfile.com/9fs6P3b7b4/junos-lab-final-configurations.rar

Juniper Fast Track Resources
Obtain a Learning Portal account (free) and read the JNCIA / JNCIS-ENT study guide PDFs (again, free). For existing Cisco guys this will be a walk in the park conceptually, its just a case of getting your head around the syntax / juniper 'way'.
https://learningportal.juniper.net/juniper/user_fasttrack_home.aspx

1.) Obtain Juniper Firefly (vSRX) OVA or KVM appliance from here. You can evaluate for free!

http://www.juniper.net/au/en/products-services/security/firefly-perimeter/#evaluation

2.) Provision 6x vSRX hosts (fireflies) with at least 4x NICs each and connect up as per attached topology. You can stick them all on the same vswitch or dvswitch, basically use a separate VLAN to simulate a separate link.

- Note that each firefly should have at least 1 interface in your 'production' LAN - this will be your management interface.
- Note firefly1 and firefly2 have 2 interfaces in your production LAN (i.e. your real life network with internet connectivity). One will be for forwarding traffic to the real world, the other for management.
- In Vsphere/Vcenter, Ge-0/0/0 corresponds to vmnic1, Ge-0/0/1 to vmnic2, etc.
- In my reference diagram my production LAN is 192.168.0.x, substitute your own.

3.) Put in first-time system configuration into each host via vmware console. (As per your JNCIA material!) – root password, hostname, create a super-user classs login. Enable SSH for system management.

4.) Put the management interface into a separate management routing-instance (I used a virtual router type) and the functional-zone management. Give it an IP address in your production range. Enable your desired system services (minimum ping+SSH, I suggest just using all as this is a lab after all). At this stage you should be able to SSH into your new virtual router.

- if you can't ping or SSH, check that you have put the interface into the correct functional-zone and enabled the correct host-inbound-services. Remember you need to also enable SSH as a system service and create a login (user).

5.) Now you have the ability to SSH to your devices and continue to configure/manage them without affecting or touching your native routing instance (for Cisco guys, we've basically configured a management VRF). I suggest at this point creating a rescue configuration (again, JNCIA question!).

6.) Configure the appropriate IP addressing and zones. Allow the following protocols and services to host-inbound-services – note the difference between system-services and protocols

- Trust interfaces – allow everything.
- Untrust interfaces – allow ping, traceroute, ssh for system services. For protocols, allow the appropriate....
- Verify all interfaces can ping point to point.

7.) Create a GRE tunnel using the source/dest interfaces of firefly1 and firefly2's production LAN NICs. Verify the tunnel IPs can ping each other.

6.) Turn on OSPF area 0 between firefly1, firefly2 and firefly3. Verify all interfaces including loopbacks can ping each other.

7.) Use metrics to make the GRE tunnel and the path between firefly2-firefly3 less preferred.

8.) Configure static default routes and source NAT using the interface IP of the production LAN interfaces of firefly1/firefly2. Verify that now you can ping the real world.

9.) Can you ping the internet using firefly3? If not, why do you think that is? Create the appropriate route and 'redistribute' into OSPF – in JunOS this will be via an export policy.

- Note firefly3 should be using firefly1 as its primary path. You can easily simulate links breaking via simply reassigning the virtual machine's VMNIC to a dummy vlan. Verify via using show commands on the appropriate Nat tables and/or for bonus points, setup a telnet or ftp target in the real world and confirm the source IP is coming from the correct firefly1.

10.) Onto BGP! Configure up eBGP adjacencies between firefly4/5 and firefly4/6, and an iBGP adjacency between firefly5/6. Turn on BFD and flap some links, watch the convergence speed.

- Remember you will have to use export policies to manually define what routes BGP will advertise. I suggest sending all OSPF routes for now. This should result in the default route being sent as well.

11.) Back to OSPF – setup area 0 between firefly4, firefly5 and area 6 between firefly4/6 and 5/6. Make firefly6 a NSSA. Configure OSPF to import routes learnt from BGP.

- Why does firefly 6 not have the default route? Review your OSPF/NSSA notes and fix! Make firefly6 prefer firefly4 to firefly5 via a superior default route metric.
- Turning to BGP again – which eBGP path is firefly3 preferring, firefly4 or firefly5? Why is that, since their attributes are almost the same? Hint: a relevant command is in the diagram, the full behaviour can be easily found here http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/general/routing-ptotocols-address-representation.html

At this point you should have full routing connectivity throughout the network more or less – though note where your untrusted zones are. Now for the fun stuff!

12.) Mostly so your testing is easier  Configure zone policies on firefly3, firefly4 and firefly5 to allow your typical test protocols (ping, trace, SSH etc.) through your untrusted interfaces. I know I'm drifting into JNCIS-SEC material here, but its unavoidable as the SRX is a trusty firewall as well as a router 

- If you can hit the internet from your left hand side network (ASN65535) but not the right hand side (ASS65530), check your NAT configurations – have you allowed all the correct source ranges?
- Note UDP traceroute has to be manually defined as a custom application using UDP ports (research homework!). I have no idea why Juniper thought this was a good  idea, as Juniper devices use UDP traceroute...... note my final configs have the wrong port range in them, I was fooling around 
- Don't confuse the host-inbound-services configuration with zone policies. The former only defines traffic allowed to target the router's interfaces, not traffic traversing the router.

13.) Add route filtering to firefly4/5 BGP export policies so only explicitly defined networks are advertised. Define all networks in the right hand side of the network EXCEPT in place of all the 172.31.x.x /32 loopbacks, only allow /30 summaries.

- i.e. for firefly4's networks, instead of allowing 172.31.255.252, 253, 254/32, only allow 172.31.255.252/30. Repeat for firefly5 and firefly6's networks.

14.) Make firefly4, firefly5 generate aggregate routes for these /30s. Make them appear in OSPF then BGP.

- use a standard aggregate route for firefly4
- use a generated aggregate route for firefly5
- use OSPF ABR summary to summarise the range of /32s coming from firefly6

15.) Make firefly4 and firefly5 tag community for all routes sent to firefly3.

16.) Use BGP policy to tag local preference @ 200 for routes between firefly3/4 and 120 for firefly 3/5 - tag the preference on both sides

- What direction and where should you apply a policy for this?
- Why doesn't export policy work?
- Observe how firefly5 prefers firefly4's iBGP instead of firefly3's eBGP routes. Why is this? Understanding the various factors in this mechanism is critical for understanding BGP operation. Note this is nowhere as confusing for JunOS as for Cisco due to the fact that JunOS has the same preference (admin distance) for IBGP and EBGP so the really common question in this scenario doesn't come up as readily....  .

17.)  Finally, attach a host to firefly 4 (doesn't really matter at this stage where, as long as its in ASN65530 and its network is routable!) and get fancy with the zone policies in firefly3.

- For my lab environment, I used a windows host and the following fancy rules
- Allow all AD related protocols to hit its domain controller / linux server only
- Allow only web traffic to hit the internet
- Note policy order is important, learn how to insert and/or move policies around!
- Note the default policies (like the default deny....) are not logging – change this for profit!

Enjoy and hope this helps! You can now keep fiddling to your heart's content – play with metrics and/or more BGP attributes, add more routers or routing-instances, add ipv6, add multicast.... Happy Juniper labbing!

Wintermute000

HINT:  learn your JunOS 'debug'; i.e. tracing options and 'term mon' i.e. monitor options. If something doesn't work, turning on the appropriate trace will usually reveal the issue. I went through hell with debugging security flows whilst learning policy configuration, and I consider myself an ASA veteran....

Caveat: JunOS is a bit funny with management VRFs

–   for example I had trouble getting syslog to work via the mgt interface despite defining a source interface. It kept wanting to use a interface in the 'real' routing-instance, as I could clearly see in firewall logs. Nevertheless for purposes of labbing r&s this is not important. Some googling revealed this to be known buggy behaviour
–   DNS resolution appears to be similarly affected and further defaults to using ipv6 AAAA records if they exist – even though you haven't turned on ipv6. So if you say ping cisco.com you have to also define the inet used....

[Seittit]

nice write-up!

I've got my weekend planned now

[wintermute000]

Hahaha go for it. It's sidetracking me big time from CCIE but I am hell bent on getting my JNCIS-SP - actually need to build a service provider topology now... at least the SP track still requires all the routing topics labbed in above lab

[wintermute000]

If anyone is curious, here is the SP topology I ended up with.

http://skaffen.planetexpress.com.au/jncis-sp-lab.pdf


Features labbed: build this in sequence more or less

- ISIS (design is actually very basic but its what real world ISPs do - straight up Level 2 adjacencies in one single area - this is to preserve BGP Next-Hop as well as ease Traffic Engineering)
- LDP / RSVP (your choice in the core, convert it back and forth) and any RSVP knobs you want to fiddle with
- MPLS-VPN with BGP as PE-CE (your choice of vrf-target or manual vrf import/export, suggest lab both)
- MPLS-VPN with OSPF as PE-CE including backdoor link
- BGP RR with route target filtering for MP-BGP core
- BGP signalled L2VPN (used as OSPF backdoor link)
- Inter routing-instance route leaking with rib-groups

Features in syllabus not possible due to Juniper Firefly feature-set
- Provider Bridging
- STP
- Metro Ethernet features
- Multi chassis / redundancy options

Features to be labbed in future
- VPLS
- RSVP tunnelling of LDPs

Features not labbed because I can't be bothered and its not on the JNCIS-SP syllabus and I'm not worrying about JNCIP-SP juuuuuuust yet....
- Multicast and P2MP LSPs


Prerequisites (assumed knowledge)
- JNCIA level familiarity with platform
- CCNP level knowledge of BGP, OSPF


Any CCIP or CCNP-SP (or CCIE R&S for most part, minus a few extras) would find this lab easy and just the juniper fascimile of their existing knowledge

[Seittit]

Very juicy info, thanks for the fantastic write-up!

[wintermute000]

I'll try to expand on the JNCIS-SP lab later down the track  (e.g. after I pass LOL). I've forgotten half of the struggles already!
I found that the JNCIS-SP fast-track material is good for detail but terrible for overall understanding, if I hadn't gone in already knowing how to do basic MPLS-VPN on Cisco I'd be completely lost I reckon. My main gripe is that they don't really explain how all the layers fit together and in particular LDP vs RSVP (both? LOL - thats for JNCIP-SP level labbing...). The ISIS material is also terrible from a hands on POV, I read a lot of other articles before 'getting' it and furthermore they don't even tell you that IRL most ISPs chuck everything into a single area

[SimonV]

Booked my JNCIA exam for the 16th of February, so three weeks to go over it again. Far away from the amount of work you've put into it though

[85adventures]

The links to the lab diagram and lab final configurations don't work for me.  Anyone have copies they can share?