We will use this network diagram for this lab.
The IPsec VPN will be created between Outside-R and the ASAv.

Traffic from 192.168.20.0/24 and 10.1.1.0/24 subnets will be encrypted using the tunnel.

The tricky part on the ASA is that ASDM doesn't allow you to remove or let's say limit the number of cipher suits to be used with the IPsec tunnel which is the phase-2 of the IPsec IKEv1. It'll be clear with the CLI below.

Here's the VPN config on the IOS router.

Outside-R#show running-config | section crypto
crypto isakmp policy 1
 encr aes
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto ipsec transform-set ourset esp-aes
crypto map ourmap 1 ipsec-isakmp
 set peer 192.168.2.1
 set transform-set ourset
 match address 100
 crypto map ourmap

For the ASA config it's highly recommended to just use the IPsec VPN wizard from the wizards menu.

Here's the ASA config from the CLI anyway.

ciscoasa# show running-config cryptocrypto ipsec security-association pmtu-aging infinite
crypto map outside_map 1 match address outside_cryptomap
crypto map outside_map 1 set peer 192.168.2.2
crypto map outside_map 1 set ikev1 transform-set ESP-AES-128-MD5 ESP-AES-128-MD5-TRANS
crypto map outside_map interface outside
crypto ca trustpool policy
crypto ikev1 enable outside
crypto ikev1 policy 1
 authentication pre-share
 encryption aes
 hash md5
 group 2
 lifetime 86400

I have edited the ASA output to exclude a huge section which is unnecessary and which actually causes the problem.

Let's see the IOS router debug first.

Outside-R# debug crypto isakmp
*Mar  1 03:15:12.955: ISAKMP:(1001): retransmitting phase 2 QM_IDLE       1349190959 ...
*Mar  1 03:15:12.955: ISAKMP (0:1001): incrementing error counter on node, attempt 2 of 5: retransmit phase 2
*Mar  1 03:15:12.955: ISAKMP (0:1001): incrementing error counter on sa, attempt 2 of 5: retransmit phase 2
*Mar  1 03:15:12.955: ISAKMP:(1001): retransmitting phase 2 1349190959 QM_IDLE
*Mar  1 03:15:12.959: ISAKMP:(1001): sending packet to 192.168.2.1 my_port 500 peer_port 500 (R) QM_IDLE
*Mar  1 03:15:12.959: ISAKMP:(1001):Sending an IKE IPv4 Packet.
*Mar  1 03:15:12.975: ISAKMP (0:1001): received packet from 192.168.2.1 dport 500 sport 500 Global (R) QM_IDLE
*Mar  1 03:15:12.975: ISAKMP: set new node -619099427 to QM_IDLE
*Mar  1 03:15:12.975: ISAKMP:(1001): processing HASH payload. message ID = -619099427
*Mar  1 03:15:12.975: ISAKMP:(1001): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
        spi 0, message ID = -619099427, sa = 66772820
*Mar  1 03:15:12.975: ISAKMP:(1001):deleting node -619099427 error FALSE reason "Informational (in) state 1"
*Mar  1 03:15:12.975: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
*Mar  1 03:15:12.975: ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

The highlighted part in the last line show us that Phase-1 is complete.

Which means NOTIFY PROPOSAL_NOT_CHOSEN is a phase-2 problem. And the reason is a mismatch between the ciphers used for the phase 2 negotiation.

Refer back to the config lines on both the devices we see:
crypto ipsec transform-set ourset esp-aes - router

crypto map outside_map 1 set ikev1 transform-set ESP-AES-128-MD5 - ASA

These lines show control the phase-2 cipher negotiation and both do look the same, here the part which I omitted from the ASA config comes in to play.

Here's the complete ASA config from the CLI

ciscoasa# show running-config crypto
crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-AES-128-SHA-TRANS esp-aes esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-128-SHA-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-AES-128-MD5-TRANS esp-aes esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-AES-128-MD5-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-AES-192-SHA-TRANS esp-aes-192 esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-192-SHA-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-AES-192-MD5-TRANS esp-aes-192 esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-AES-192-MD5-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-AES-256-SHA-TRANS esp-aes-256 esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-256-SHA-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-AES-256-MD5-TRANS esp-aes-256 esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-AES-256-MD5-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-3DES-SHA-TRANS esp-3des esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-3DES-SHA-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-3DES-MD5-TRANS esp-3des esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-3DES-MD5-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-DES-SHA-TRANS esp-des esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-DES-SHA-TRANS mode transport
crypto ipsec ikev1 transform-set ESP-DES-MD5-TRANS esp-des esp-md5-hmac
crypto ipsec ikev1 transform-set ESP-DES-MD5-TRANS mode transport
crypto ipsec security-association pmtu-aging infinite
crypto map outside_map 1 match address outside_cryptomap
crypto map outside_map 1 set peer 192.168.2.2
crypto map outside_map 1 set ikev1 transform-set ESP-AES-128-MD5 ESP-AES-128-MD5-TRANS
crypto map outside_map interface outside
crypto ca trustpool policy
crypto ikev1 enable outside
crypto ikev1 policy 1
 authentication pre-share
 encryption aes
 hash md5
 group 2
 lifetime 86400

Now see the highlighted line above, that's the only cipher we need - because that's the one in use on the router or else the phase 2 negotiation won't match and we keep getting the error as shown in the debug.

The whole confusion is that the ASDM doesn't properly display this and the only thing you see there is just a single cipher.

Maybe this is a bug or I missed something. But for now to get this VPN to work you simply have to remove all the other non-matching ciphers with a "no" command in the ASA CLI.

That is just keep the one cipher which is highlighted or whichever you use in your case.

no crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-AES-128-SHA-TRANS esp-aes esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-AES-128-SHA-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-AES-128-MD5-TRANS esp-aes esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-AES-128-MD5-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-AES-192-SHA-TRANS esp-aes-192 esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-AES-192-SHA-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-AES-192-MD5-TRANS esp-aes-192 esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-AES-192-MD5-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-AES-256-SHA-TRANS esp-aes-256 esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-AES-256-SHA-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-AES-256-MD5-TRANS esp-aes-256 esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-AES-256-MD5-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-3DES-SHA-TRANS esp-3des esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-3DES-SHA-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-3DES-MD5-TRANS esp-3des esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-3DES-MD5-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-DES-SHA esp-des esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-DES-MD5 esp-des esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-DES-SHA-TRANS esp-des esp-sha-hmac
no crypto ipsec ikev1 transform-set ESP-DES-SHA-TRANS mode transport
no crypto ipsec ikev1 transform-set ESP-DES-MD5-TRANS esp-des esp-md5-hmac
no crypto ipsec ikev1 transform-set ESP-DES-MD5-TRANS mode transport

That's it. Now your beautiful VPN tunnel will come up the moment you send the interesting traffic.

This entire confusion is because of the way ASDM displays the ciphers. I hope to find more info on that and update this further.

As I'm working through the CBTnuggets course for f5 BIG-IP LTM I have set up the following lab as required in the course.

Chapter/Video 15 focuses on the concept of persistence.

Here's persistence from the f5 manual;

Using BIG-IP Local Traffic Manager, you can configure session persistence. When you configure session persistence, Local Traffic Manager tracks and stores session data, such as the specific pool member that serviced a client request. The primary reason for tracking and storing session data is to ensure that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions.

Persistence is simply the BIG-IP tracking the client/user session in a way that the client is sent to the same server till that session expires or till the persistence timeout as set on the BIG-IP expires. For e.g. one type of persistence explained in the course is cookie persistence, which tracks the user by storing an HTTP cookie in the user's browser. 

This cookie is obviously added by the BIG-IP in the HTTP response. We as BIG-IP admins have the option to add a timer in mins for which the cookie remains active on the client and then the cookie expires.

A example would be a user hitting the BIG-IP public IP to fill a form. The first initially selection of the server from the back-end pool is done by the BIG-IP based on the load balancing method in place. Let's say server green is chosen, once the user hits green server, BIG-IP then adds an HTTP cookie to the HTTP response and from then onwards the remaining requests from the user will only be sent to the green server instead of being load balanced, this can go on till the cookie time as set on the BIG-IP expires or till the session expires—whichever is configured.

In my lab above the issue is that the cookie persistence profile was simply not taking effect and the client kept load balancing to all the three back-end servers in the pool.

f5 troubleshooting manuals strongly recommended setting the correct time on the BIG-IP. I did that rebooted.

[root@big-ip-test:Active:Standalone] config # date
Thu May 18 19:14:31 GST 2017
[root@big-ip-test:Active:Standalone] config #

Wireshark shows that the cookie was being added correctly to the HTTP response but expiry time was wrong. I am adding the cookie at 18:40 GST and the cookie expiry is set to 14:29.

Which means by the time I test this, the cookie has already expired!

This is strange. Also the cookie timezone in wireshark is GMT while I'm in Dubai and the BIG-IP is set to use Asia/Dubai timezone which is GST.



To be updated as I troubleshoot this.

UPDATE - 21 May 2017

DISCLAIMER: It turns out this could simply be a issue with my lab as I'm using my own windows host machine to test the load balancing. The issue was resolved when I created a different VM on virutal box and used GNS3 to connect it to the BIGIP external network and tested the persistence again.

But the troubleshooting is still worth it!

The first thing to get out of the way is the time issue. We can do this using perl.

Download and install strawberry perl for windows and simply find the scaler time.

root@(big-ip-test)(cfg-sync Standalone)(Active)(/Common)(tmos)# run /util bash
[root@big-ip-test:Standalone] # perl -le 'print scalar time()'
1495179814
root@big-ip-test:Standalone] # exit

[root@big-ip-test:Active:Standalone] config # perl -le 'print scalar time()'
1495183038

C:\Users\allwyn>perl -le "print scalar time"
1495183035

That looks good, so no issues here.

Also the timezone for the cookie is always recommended to be in the GMT timezone since a website has to serve an global audience, I need to do more reading on this though. For next time.

So the packet in the above wireshark pcap is the HTTP response packet which has the cookie inserted by the BIGIP after the initial load balancing. This cookie is then saved by the browser and presented to the BIGIP for the remainder of the session or the cookie timeout as configured on the BIGIP.

Now we know that the BIGIP is inserting the cookie but whether it's getting back needs to be verified, and the following iRule helps to log this.

when HTTP_REQUEST {
    if { [HTTP::header exists Cookie] } {
        log local0. "Client: [IP::client_addr] : Incoming Cookie header: [HTTP::header values Cookie]"
    } else {
        log local0. "Client: [IP::client_addr] : Incoming Cookie header: None"
    }
}
when LB_SELECTED {
    log local0. "client addr : [client_addr] : Selected pool member: [LB::server addr]"
}

Then to view the logs use this guide. You have to enter the tmsh utility and filter the log events with a pipe |.

[root@big-ip-test:Active:Standalone] config # tmsh
root@(big-ip-test)(cfg-sync Standalone)(Active)(/Common)(tmos)# show /sys log ltm | grep cookie

Test-iRule <lb_selected>: client addr : 192.168.1.5 : Selected pool member: 10.2.0.22
Fri May 19 15:28:00 GST 2017    info    big-ip-test     tmm[10349]      Rule /Common/Cookie-Test-iRule <http_request>: Client: 192.168.1.5 : Incoming Cookie header: None
Fri May 19 15:28:02 GST 2017    info    big-ip-test     tmm[10349]      Rule /Common/Cookie-Test-iRule <lb_selected>: client addr : 192.168.1.5 : Selected pool member: 10.2.0.33</lb_selected></http_request></lb_selected>

You can also view the same logs from in GUI at system - logs - LTM and filter the events.


We see here clearly that the incoming (from client to BIGIP) http_request does not have the cookie set and hence the BIGIP keeps load balancing across the servers.

At this stage, as I already mentioned I just created a new VM and used GNS3 to connect it to the VMware network and tested the persistence.

Here's the log which then shows the incoming cookie.

ltm 05-19 18:43:13 info big-ip-test tmm[10349]: Rule /Common/Cookie-Test-iRule <HTTP_REQUEST>: Client: 192.168.1.192 : Incoming Cookie header: BIGipServerour-http-pool=184549898.20480.0000
ltm 05-19 18:43:13 info big-ip-test tmm[10349]: Rule /Common/Cookie-Test-iRule <LB_SELECTED>: client addr : 192.168.1.192 : Selected pool member: 10.2.0.11

ltm 05-19 18:43:13 info big-ip-test tmm[10349]: Rule /Common/Cookie-Test-iRule <HTTP_REQUEST>: Client: 192.168.1.192 : Incoming Cookie header: BIGipServerour-http-pool=184549898.20480.0000

ltm 05-19 18:52:05 info big-ip-test tmm[10349]: Rule /Common/Cookie-Test-iRule <LB_SELECTED>: client addr : 192.168.1.192 : Selected pool member: 10.2.0.22

ltm 05-19 18:52:05 info big-ip-test tmm[10349]: Rule /Common/Cookie-Test-iRule <HTTP_REQUEST>: Client: 192.168.1.192 : Incoming Cookie header: BIGipServerour-http-pool=369099274.20480.0000

ltm 05-19 18:52:06 info big-ip-test tmm[10349]: Rule /Common/Cookie-Test-iRule <LB_SELECTED>: client addr : 192.168.1.192 : Selected pool member: 10.2.0.22

The BIGIP then halts the load balancing and sends all requests to just one back-end server.

These are some posts I wrote while preparing for the JNCIA. They'll help you setup a lab and work with it and prepare for the certification or just learn juniper - it's fun!

• GNS3 Juniper SRX Lab And CLI Commands - Part 1 
• GNS3 Juniper SRX Lab And CLI Commands - Part 2
• Juniper CLI Modes and Hierarchies 

To be updated. . 

Part-1 is here.

We will continue with our network diagram, just putting it here for ref.



In part-1 we created policies to allow traffic from the trusted to the untrusted zone without NAT. Let's do NAT and confirm it on the destination test router Outside-R as well.

We will start with Source NAT using the egress interface, then do it using a pool of IP addresses and also see a weird situation I came across.

Just jump to the config mode and then go to the nat hierarchy:

[edit]
admin@SRX1# edit security nat source rule-set IN-OUT

#"IN-OUT is the rule-set name

[edit security nat source rule-set IN-OUT]
admin@SRX1# set from zone trust

[edit security nat source rule-set IN-OUT]
admin@SRX1# set to zone untrust

[edit security nat source rule-set IN-OUT]
admin@SRX1# edit rule IN-OUT

#the rule name can be same or different, comes under the rule-set

[edit security nat source rule-set IN-OUT rule IN-OUT] #now under "rule" not "rule-set"
admin@SRX1# set match source-address 192.168.3.0/24

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# set match destination-address all

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# set then source-nat interface

#the interface is chosen based on the "to zone" - we're using "untrusted"

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# commit check
configuration check succeeds

The same can be as below, you can copy this by just pasting to notepad and making your changes and then paste to the CLI

[edit]
admin@SRX1# edit security nat source

[edit security nat source] #make sure you are here in the hierarchy
set rule-set IN-OUT from zone trust
set rule-set IN-OUT to zone untrust
set rule-set IN-OUT rule IN-OUT match source-address 192.168.3.0/24
set rule-set IN-OUT rule IN-OUT match destination-address 0.0.0.0/0
set rule-set IN-OUT rule IN-OUT then source-nat interface

Now goto the Inside-R router to confirm this.

Inside-R#ssh -l bob 192.168.2.2

Password:

Outside-R#who
    Line       User       Host(s)              Idle       Location
* 99 vty 1     bob        idle                 00:00:00 192.168.2.1 #the egress interface IP

  Interface    User               Mode         Idle     Peer Address

We see our incoming connection on the destination router. This is one reason why GNS3 is so much fun, allows you instant confirmation of your config.

Source NAT Using A Pool

Now instead of using the egress interface we will NAT the source IP address using a per-defined pool of  addresses.

We just change the NAT rule on top for this, but first create the pool.

[edit security nat] #in the security NAT hierarchy
admin@SRX1# set source pool IN-OUT-POOL address 192.168.2.50 to 192.168.2.100 

Now go to the above NAT rules and just add pool instead of the interface. It automatically replaces it in the config.

[edit security nat source]
admin@SRX1# edit rule-set IN-OUT
                
[edit security nat source rule-set IN-OUT]
admin@SRX1# edit rule IN-OUT

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# set then source-nat pool IN-OUT-POOL

#using pool instead of the interface in the last line

[edit security nat source rule-set IN-OUT rule IN-OUT]
admin@SRX1# commit
commit complete

Always, always remember to commit!

Doing the SSH test from Inside-R to the Outside-R again.

IT DOESN'T WORK!

Then I had to troubleshoot and found a post on Juniper forums. It said proxy-arp is not required if the IP pool range is the same as the range of the egress interface, but a different NAT troubleshooting guide yet recommends configuring proxy arp for the pool. In our case 192.168.2.50 to 192.168.2.100.

As below.

[edit]
admin@SRX1# edit security nat proxy-arp

[edit security nat proxy-arp]
admin@SRX1# set interface ge-0/0/0 address 192.168.2.50 to 192.168.2.100 #our egress

And then testing again from the Inside-R

Inside-R#ssh -l bob 192.168.2.2

Password:

Outside-R#who
    Line       User       Host(s)              Idle       Location
* 99 vty 1     bob        idle                 00:00:00 192.168.2.62

  Interface    User               Mode         Idle     Peer Address

And the weird situation I saw here, which I don't yet have a reason for is SSH worked but ping doesn't work!

Inside-R#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

This only happens with source NAT using a pool and not when using the egress interface. 

I will definitely get to this and update in the future. Do leave a comment if you have an answer.

This could very be a GNS3 issue because of the proxy-arp or something and have nothing to do with anything else but still SSH has worked, so it's worth figuring out.

This is too long now and we will do destination NAT in a new post.

The Juniper CLI architecture is indeed really nicely done. No wonder it is the primary method of managing and configuring the Juniper devices. If you are coming from a Cisco background which most of start with then this way of doing things is indeed new, but just spend a few hours and get a GNS3 lab going and it will grow on you in no time.

Here's the architecture at a glance.


Of course this is not what you see when you login into a new JunOS device.

What we see there is the different modes a user can get into and a hierarchical division in which the configuration can be performed.

The two modes are:

1. The operator mode
2. The configuration mode

Unix Shell

This is NOT really a mode and hence I want to get it out of the way quickly.

Since the Juniper kernel is based on FreeBSD, this is the root shell aka the c shell. On a new device, which only has the root user with no password, this is the prompt (shown by the %) the root user is dropped too.

Of course it's never recommended t o use this account for anything but the initial setup.

login as: root
Using keyboard-interactive authentication.
--- JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC

root@SRX1%

The Operator Mode

This mode provides only means to monitoring, troubleshooting and displaying the current status of the device with show commands.

On a new device the root user must use the "cli" command to jump to the operator mode from the c shell. And immediately create admin accounts for the future device configuration.

Any custom user accounts created fall straight to the operator mode prompt which is show my the '>' prompt.

login as: admin
Using keyboard-interactive authentication.
Password:
--- JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1>

The Configuration Mode

This is the mode where an admin would live and breathe. All configuration and changes to the system are done here. As show below, you must use the "configure" or the "edit" command to jump to this mode. Hence for some admins this is also the "edit mode".

login as: admin
Using keyboard-interactive authentication.
Password:
--- JUNOS 12.1X47-D15.4 built 2014-11-12 02:13:59 UTC
admin@SRX1> configure
Entering configuration mode

[edit]
admin@SRX1#

The edit command is also a amazing feature which sets JunOS CLI apart from other CLIs. It can be used as an "cd" command (as in windows cmd) to jump across and into the various configuration hierarchies. This really brings the CLI to life giving you a complete view of where and what is to be configured.

The above figure is a good reference here. Here are some config examples using the edit command and the same config without it.

Here we are setting the host-name for the SRX from the config mode using the set command.

admin@SRX1> configure
Entering configuration mode

admin@SRX1# set system host-name ?
Possible completions:
  <host-name>          Hostname for this router

[edit]
admin@SRX1# set system host-name SRX2 #press enter to set the name to SRX2

We can do the same thing using edit to go under the system hierarchy

[edit] #this shows us our current level in the hierarchy which is global
admin@SRX1# edit system

#and here we are under the system hierarchy and only have access to those commands
[edit system]
admin@SRX1# set host-name SRX2

And when you do a show command here, it only shows you the config under that hierarchy which makes troubleshooting extremely smooth and easy!

[edit system]
admin@SRX1# show
host-name SRX1;
root-authentication {
    encrypted-password "$1$mEHemrS1$PZOVox.e6.YpxXFLiWZmA."; ## SECRET-DATA
}
login {
    user admin {
        uid 2000;
        class super-user;
        authentication {
            encrypted-password "$1$G28me91/$HfoIQrKZBBAMJM3hFfBNE."; ## SECRET-DATA
        }
    }
}
services {
    ssh;
    telnet;
    web-management {
        http {
            interface ge-0/0/0.0;
        }
        https {
            system-generated-certificate;
        }
    }

Similarly we can go into different levels of the hierarchy and configure just those parameters.

Let's look at one more example with interfaces. This is using the set command in the global hierarchy.

[edit] #just edit means the global hierarchy
admin@SRX1# set interfaces ge-0/0/0 unit 0 family inet address 192.168.2.1/24

And the same thing can be done with the edit command. Then you do the show command and see the settings just under that interface.

admin@SRX1# edit interfaces ge-0/0/0

[edit interfaces ge-0/0/0] #the interfaces hierarchy
admin@SRX1# show
unit 0 {
    family inet {
        address 192.168.2.1/24;
    }
}

Juniper provides a nice document for further reference on the CLI.

I have always been a proponent of HTTPS everywhere, hence some friends in the industry have brought up why I have not used HTTPS yet to secure this blog.

Firstly the blog did have a secure connection when hosted on the .blogspot domain. Google offered it for free and automatically for all .blogspot hosted blogs. You just had to flick a switch in the settings!

Recently I bought this custom domain which is still hosted for free by google's blogger service, and the situation is google does not allow an HTTPS connection setup on custom domains yet.

While I do see some tricks out there using cloudflare, I'm a little skeptical about the approach and afraid it might break something, especially with a comment like this.


Looks like an interesting experiment with Wireshark to me.

And in case you are wondering why a simple static blog with no login screen needs HTTPS like most people still think, you should give a read to Still think you don't need HTTPS?.

He puts rest to myths of "TLS causing CPU overhead" to rest and shows you how HTTPS makes your site faster. And more over google loves HTTPS more than HTTP sites now.

So now that I am on a job hunt, I have some time to figure how to go HTTPS on this blog. Let's get on it.