The NTP or Network Time Protocol is a KEY function of all of your network equipment. If I have said it once and you’re annoyed that I’m saying it again then be annoyed because trust me, if you don’t do this then one day you will regret your decision. Find an NTP host, point at it, synchronise yourself and make sure you keep it going.

So lets start from the beginning here.

NTP is a protocol running on UDP port 123....easy to remember that yeah? 123 easy like...123...also it remind me of the time 1 o’clock, 2 o’clock 3 o’clock. You know, the NTP port number feels to me like one of the obvious exam questions. Anyway NTP, lets think about it.

Imagine you have a system and it has a problem. Maybe you are logging the issue locally on the device and are also capturing logs from other devices on a syslog server. So you want to find out what happened across all of this kit to see if there are any common starting points but they don’t match. Crucially you have forgotten to synchronise their times so the logs don’t match - you are hosed because you can’t see any commonality. NTP would be your answer here. The NTP protocol (and services which use it) would automatically synchronise the time between all of these devices...bliss.

Remember NTP updates use the UTC or Universal Time Constant which is disassociated with any world time-zone (but is the same as GMT). We will need to set the correct time-zone as a final step to make sure we’ve got the correct local time....we’ll do that last. First lets get NTP running.

So how do we enable this for JunOS? First of all login and go into configuration mode. The NTP configuration is all done under the ‘system > ntp’ subtree.

edit system ntp

Lets take a look at the available options

set system ntp ?

We are an NTP client and we are going to point at an NTP peer on the internet. A quick Google for ‘public ntp servers’ found this list for me - I’m in the UK but you want to choose a list of stratum 2 public NTP servers need you.

list of NTP sratum 2 servers in the UK

I’ve chosen two servers from this list for me and I’l have a primary (the most trusted) and a secondary NTP server in case the primary fails. Lets use and Do you notice that the list includes both the hostname and the IP address? Well I always like to use the hostname for the configuration in case they change the server IP address. We’ll need to setup the DNS lookup server on the Juniper router so we can resolve the IP address from the domain name.

enabled DNS lookup in JunOS

I’ve chosen to use the Google public DNS servers but you can use any.

Now lets check we can lookup the IP address by using ping.


Perfect - DNS lookups are working.

Right lets configure the NTP peers then. First mcc - notice the ‘prefer’ keyword so we like this one the most.

set system ntp peer

Now for sandvika - we don’t prefer this one.

set system ntp peer

Ouch - thats not worked - no such hostname. Right lets have a look at ExNet then.

Screen shot 2011-06-22 at 21.45.34set system ntp peer

Ok great that went in - lets commit the candidate configuration now

Screen shot 2011-06-22 at 21.46.14

Lets drop out of configuration now to run some ‘show’ commands to see it build the association and synchronise the time.

show ntp associations

We’re not sync’d yet - notice we see stratum 16? There are 15 strata but mostly you sit at 2 or 3. Personally I wouldn’t ever wish to sync myself to anything less than a stratum 3 time source. The higher the number the less trustworthy the source. Lets take a look where we are now...we’ve left it for another 30 seconds...

show ntp associations

Great, we see we have sync’d to three stratum 2 time sources. Why three I hear you cry...well honestly I think the mcc time sources run a round-robin DNS so we got two different IP end hosts. Well thats it, we’re sync’d now. A few other ‘options’ you may wish to explore. What about if the remote time source is expecting you to be coming in from say your loopback address. This is normally for security reasons. Imagine each of your routers has two resilient links to the network and you are running an IGP so ca reach the NTP source from multiple links. If that source is trying to restrict the hosts talking to it you may wish to allow connectivity only form one remote IP address. If you have two links to it then there are two we use the loopback address.

Lets go through that now.

First we create the loopback address. We’ll use (remember JunOS uses CIDR notation).

confgure junos loopback interface

Now we set the source for our NTP packets to the loopback IP address. Now the remote server only needs one line in it’s security filter rather than two...nice.

set junos NTP source

There are way more things we can do including setting ourselves up as an NTP time source but thats for another time.

One final thing for me though, living in the UK means that I have to consider my time-zone and more specifically British Summer Time (Dayiight Savings Time). At two times int eh year we all put our clocks forwards one hour and then backwards again. Historically this is meant to allow our farmers to do more work...not that they don’t already huh.

To set the timezone we type ‘set system time-zone’. If you wish to know what time-zone choices you have then just use the ‘?’ or context sensitive help. Here is the output for the first few lines:

set junos NTP time-zone

I already said I’m in the UK and we run on GMT or Greenwich Mean Time but more specifically I wish to support BST or British Summer Time which operates a ‘Daylights Savings Time’ +1 hour and -1 hour at two points in the calendar. Now I’ve looked and looked and cannot find any command to support this. In IOS you would use the ‘clock’ command to set a recurring adjustment (see NTP post). In this case we could maybe go for GMT+1 which would do the same sort of thing but I fear that when the clock goes back again I’d have to change this again to GMT.

set junos NTP time-zone

So thats it for this time.

Thanks for reading and good luck with your studies.
View Comments
So we've got to secure our Juniper router from un-authorised access attempts. There are a couple of ways we can access the device for configuration; console, telnet, SSH, HTTP(s) and NMS to name the main ones. Each of these however *needs* a username and password to permit access before we get in, we need it for authentication.

So lets go ahead and configure a username and password for our router. We've decided to be totally cliche and use the name 'admin' for our administrator account. First we need to get into configuration edit mode by entering the configure keyword from 'exec' mode.

root@R1> configure

Now lets enter the 'system' command tree (which contains the login 'features') by entering:

root@R1# edit system

Now we can add the user:


Whoa! What went wrong here? Well it's simple really, JunOS saved my arse. The password I chose to input here was 'junos'. Sure it wasn't a very secure password but I figured it was for a demo so who cares? Well JunOS cares. It is very kindly reminding you that the password you put in was poor and didn't pass the restriction guidelines of minimum password length of 6 characters (junos is 5 of course) AND that it didn't contain a mixture of either case, numbers or punctuation. So lets do that again and choose the password JunOS1!


All good. Now you know what - our company guidelines are more strict than that. We need to have a minimum of 8 characters and we need to also make sure that the new passwords being set have at least 3 characters of difference from the last. That is to say if my current password if PassW0rd! then my new password cannot be PaSSW0rd! because I only changed two of the letters to uppercase.

So lets put in the configuration to get the company policy met:


OK, so user set, password right, now lets put our user into the right security group. Admin is clearly an administrator and so we'll put that user into the highest security group with the most rights. Note that this command has been entered from the 'top' of the configuration tree rather than from inside the 'system' branch:


Right now we need to enable the services themselves. Out of the box a fresh JunOS configuration has no services enabled. Lets turn on Telnet and SSH.


Now we look back at our company security policy and notice that we are told to exclude 'root' user access from SSH enabled devices. We can do this in JunOS...well done eh...


So now the only user configured outside of 'root' is 'admin' so we'll be using admin to access the device. All good so far. But hey, we've got a router here on the network...anyone can access it. What we really need to do now is restrict access to it. Now on a Cisco IOS device we'd be talking about an access-list. We'd write the list and then apply it to an interface (vty for telnet/ssh). Well JunOS is just the same except, like always, JunOS does things a little differently.

Lets start be creating a firewall filter (comparable to Cisco access-list). First enter the 'firewall' edit mode, notice we first skip back to the top of the configuration tree:


Lets setup our filter to allow access from hosts in the network. Forgive the screenshot the syntax goes thus (remember we are already at [edit firewall] level:


root@R1# set filter ssh-and-telnet-only term source-hosts from source-address

So thats the network access limited, and now we'll make sure this filter is matching traffic destined for telnet and ssh ports only. Remember SSH runs on port TCP/22 and Telnet on TCP/23 but we can match those using the application name. Again, the screen host has truncated and the beginning is 'set filter ssh-and-telnet-only term sour.....'


Finally we need to 'accept' this traffic. This is like the IOS 'permit' keyword.


So what do we do with the access which is denied? Well those sessions are dropped but wouldn't it be nice to see how many we're dropping? Lets add to our filter now with the 'count' keyword followed by a 'reject'. Both of these statements are called last in the filter. In IOS the reject would be implicit as a 'deny' at the end but like IOS if we want to log access attempts we need to add the 'deny log' statement at the end not too dissimilar eh?


Right, access-list done now but we need to bind it to an interface. Just like in IOS where you would use an access-group or access-class for VTY ports in JunOS we simply add the 'filter' to the interface. Again, the screenshot it truncated:

root@R1# set interfaces em0.0 family inet filter...


OK, lets try a telnet now. 


Now lets try an SSH. First attempt causes my unix based host to prompt to add the SSH key signature to my known_hosts file...the second attempt has no such issue...we login...done.



Thanks for reading
View Comments
GRE (Generic Routing Encapsulation) is an industry standard for encapsulating data within an IP packet. Unlike IP protocol 7 (IPv4) GRE runs over IP protocol 47. It is often used to manipulate routing over non-broadcast networks or for sending multicast over IPSEC tunnels. This tech note was setup between a Juniper EX 4200 switch cluster and a Cisco 2621XM router. One of the issues with GRE traffic is its extra header which means payloads are reduced when you use it by an extra 4bytes (minimum).

So here is our basic topology. Remember we’re just using this to prove out the connectivity NOT to delve deeply into GRE itself or how we could use this to fix a ‘situation’. We’ll be bringing more of these technical guides as soon as we can write them using another 24 bit subnet From here we’ll have two loopback interfaces (one on each device) and we’ll setup the routing to divert traffic between each of these loopback interfaces across the tunnel.

.Screen shot 2011-05-28 at 22.19.00

First lets configure the EX switch ge-0/0/0 interface which is connected directly to the Cisco 2600. Notice the bit-wise mask at the end. Cisco’s recent NEXUS platform running the NX-OS also now uses the bitwise pattern for netmask...interesting ;-)

Screen shot 2011-05-28 at 22.31.29

Lets configure the loopback interface

Screen shot 2011-05-28 at 22.31.37

Right now we’ll configure the GRE interface itself. It doesn’t matter in the order of the next three configuration lines but you DO need them all ;-)

The source is the beginning of the tunnel from ‘this routers’ point of view’. As an analogy think of you in your car. You are driving toward a tunnel going under a river from Coolville to Duddberg. As far as you are concerned the start (source) the tunnel is in Coolville. When you return however the start of the tunnel is in Duddsberg. Same thing for traffic going into and out of your tunnel here.

Screen shot 2011-05-28 at 22.31.44

Now the destination. Remeber this is all relative and the other side will look the opposite.

Screen shot 2011-05-28 at 22.32.04

OK, now thats the tunnel built we need to ‘load it up’ with loely IPv4 traffic. So, just like a normal interface we’ll give it an IP address and a mask.

Screen shot 2011-05-28 at 22.42.19

Right JunOS side done now, lets nip over to the Cisco box and do the same.

Lets configure the Fast Ethernet 0/0 interface which is connected to the Juniper switch.

Screen shot 2011-05-28 at 22.47.14

Now we’ll configure the tunnel interface. For brevity I’ve taken a pumped all of the configuration in here but it follows EXACTLY the same sort of configuration as JunOS. Source IP of tunnel, desitination IP, IP address of the tunnel...done.

Screen shot 2011-05-28 at 23.03.44

Right so now thats up lets see if we can ping either side of the tunnel.

Cisco side first...

Screen shot 2011-05-28 at 22.38.30

Cool, now the Juniper side

Screen shot 2011-05-28 at 22.49.52

Awesome. Right but we’re pinging the sides of a point to point interface here which isn’t exactly right is it. So if we’re going to be ‘routing’ traffic through this tunnel and not just having a secondary route (whats the point in our topology anyway) we’ll need to give each side routes to one another. We’re going to route traffic for each sides Loopback interface through the tunnel.

Juniper side first

Screen shot 2011-05-28 at 22.53.06

...don’t forget the commit in JunOS. You know it never fails to impress me how Juniper got JunOS so right for administrators. If we screwed this up and the router happened to be 1000 miles away we’ve got options. Auto rollback is the best thing ever.

Now the Cisco side

Screen shot 2011-05-28 at 22.53.41

...if we screwed up IOS we’d be gone ;-) Of course we could always issue that great ‘reload in 10’ shortcut to save our ass.

Ok lets ping out over the tunnel interface.

Screen shot 2011-05-28 at 23.04.19

Now form Cisco side...just because we can

Screen shot 2011-05-28 at 23.05.23

What about some statistics to back that up man?! OK, here we go.

Right Juniper side first again. We got 6 in and out here...

Screen shot 2011-05-28 at 23.07.03

Cisco side...

Screen shot 2011-05-28 at 23.05.59

Job Done.

Thanks for Reading
View Comments
Hi all,

I know you're all desperate to find out how we configure Q-in-Q between IOS and JunOS and here we have it. You know, when we did this the effort required to get the Juniper EX part done was worrying. The Juniper documentation was pretty good and the Cisco Q-in-Q part is very well documented of course. This techguide will hopefully help some of you out there desperate to join these two great platforms as one.

First I guess we should provide a little background to Q-in-Q services. The idea is pretty simple, Q-in-Q is a process whereby a normal 802.1q frame is attached to another 802.1q header, hence the name. You will most likely use this is you have a requirement to say connect two layer 3 networks together which are separated by a layer 2 network. The layer 3 networks at each end may be in the same subnet and each of these geographically disparate networks can act as one.

Here is our challenge:


The laptop at the top of the diagram is connected to a Cisco 6509E and is in VLAN 186 with layer 3 network We have another laptop at the bottom of the diagram connected to a Juniper EX cluster again in VLAN 186 with network We need to get both of these laptops to operate within the same network despite being separated by a number of switches and hops. That is to say when I ping from one side to the other I want one hop to the destination.

Lets begin.

First we're hopefully all up to speed on VLANs and what they mean. If you need to read up on VLANs then take at look at our other techguides for a reminder. Lets create VLAN 186 on the first 6500 connected to the laptop and then place the port connected to the laptop into that vlan:

6500_FRONT(config#) vlan 186
6500_FRONT(config-vlan)# name X_SITE_INTERNET
6500_FRONT(config-vlan)# exit
6500_FRONT(config)# int g0/0
6500_FRONT(config-if)# switchport mode access
6500_FRONT(config-if)# switchport access vlan 186
6500_FRONT(config-if)# no shutdown
6500_FRONT(config-if)# end

So now lets take a look at the port connected between the FRONT and BACK 6500's. We need to configure this as an 802.1q port. Remember the Q-in-Q takes our 802.1q frames first.


So we take the VLAN 186 and only allow it on this port. Untagged traffic is also placed into VLAN 186 but this is necessary. We've forced the port to not use DTP (switchport nonegotiate) and we're manually configuring it as a trunk port. Forcing the port as a trunk is not required but is good practice.

Lets have a look at the 6500_BACK configuration for the port connected to the 6500_FRONT G4/11.


OK, looks like a lot of configuration here so lets go through the main lines. Now on a trunk port if you have a configuration for an access vlan (switchport access vlan) but configure 'switchport mode trunk' then the port os a trunk port and the acces vlan configuration is ignored. In our case we're configuring a dot1q tunnel port and therefore the access vlan IS IMPORTANT. So what are we saying here? Basically the 802.1q tagged traffic ingress into the port is left tagged (as if it were an access port with no tagging). The next line switchport mode dot1q-tunnel no performs the double tagging - we're going to be ramming tagged VLAN 186 traffic into VLAN 3043. The MTU is set to 9216 to accommodate for the double 802.1Q tag and should not be missed. 

We're disabling CDP so that we can tunnel CDP. What?! Well to help to explain this here is an example. When you have two directly connected cisco devices and CDP is running and enabled on these ports then you can 'see' the other device by issuing a 'show cdp neighbors'. This process is true also for Q-in-Q neighbors but we must turn off CDP between the two endpoints for the tunnel or else it would stomp all over the tunnel start points (in our example CDP would be tunnelled from 6500_FRONT but since the other startpoint is a Juniper device which doesn't undertsand CDP this step is unnecessary).

The l2ptotocol-tunnel allows us to send spanning-tree BPDU's down the Q-in-Q tunnel and CDP...we don't need them in our example but maybe you are creating a spanning-tree loop in your deployment so I think these lines are useful...just in case.

So now we are going to configure a normal run of the mill ordinary 802.1Q trunk link between the 6500_BACK and 3560 switches.

6500_BACK# configure terminal
6500_BACK(config)# interface g4/12
6500_BACK(config-if) switchport trunk encapsulation dot1q
6500_BACK(config-if) switchport mode trunk
6500_BACK(config-if) switchport trunk allowed vlan 1559,2127,3043,3738
6500_BACK(config-if) mtu 9216

So here we're just creating a normal trunk as we said. We're going to be trunking the Q-in-Q vlan 3043 we already created. Don't forget the jumbo frame MTU requirement. The other VLANs allowed on the trunk are for other things.

Right, at the other end of the link between the 6500 and 3560 we're going to again configure a normal bog standard trunk. 


On the 3560 there is one requirement to enable jumbo frames before this will work. In global configuration mode we issue:

3560(config)# system mtu jumbo

Then we need a reboot. Without this line the switch will not be able to support the minimum 1504 bytes required to transport the Q-in-Q frames. So when we're back we can move on - all should be fine so's just trunking.

Here is the configuration for the port connected to the Juniper EX stack.


So we're still trunking 3043...and some others but ignore those.

Now onto the Juniper EX stack dot1q-tunnel configuration.

First enable the protocol frame support.


Now lets create the VLAN - this took some time to get right int he Juniper documentation.


So we have created two vlans here. The first called X_SITE_INTERNET0 is carrying the Q-in-Q trunk traffic. Vlan XSITE_BACKBONE is carrying the untagged vlan 186 traffic.

Lets configure the port connected to the Cisco 3560. Again we need a dot1q trunk port and we'll restrict it to carrying only VLAN 3043.


So the last port configuration part if for the laptop port...


A quick 'show vlans XSITE_INTERNET_0 extensive'?


We see here that the 'Customer VLANs' are 186-186...or just 186 ;-) the ports ge-1/1/0.0 and ge-2/1/1.0 are the trunk ports connected to upstream Cisco switches (we've only looked at one of them...why do you think I had the STP stuff listed earlier ;-) ). The access ports are connected to host devices and are each in VLAN 186.

So there we go, IOS to JunOS using dot1q tunnelling. IT works, it's great tech, have fu.

View Comments
© 2011

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.