Let’s say we need to setup a quick DHCP server on IOS and JunOS.
We’ve been tasked with configuring DHCP to give out addresses in the subnet, but only from to
We’ve also been asked to not give out as this has been hardcoded in the local fileserver. The lease time should only be 1 hour, and the default gateway should be

This is how we do it on the IOS we know and love:

 >conf t
#ip dhcp pool
#lease 0 1
#ip dhcp excluded-address
#ip dhcp excluded-address
#ip dhcp excluded-address

Now on JunOS:

> configure
# edit system service dhcp
# set default-lease-time 3600
# set router
# set pool address-range low high
# set pool exclude-address

There are extra things you can add to both, like domain name and so on, but I wanted a quick and dirty comparison between the 2. Remember that you will need an interface in the scope on either router in order for DHCP to actually work.

Let’s now say that we do have a DHCP server. This server is on another subnet, and so DHCP requests won’t get through (as they are broadcasted). Consider the following topology:

Both IOS and JunOS allows you to configure the router as a DHCP relay agent. This is how it’s done.

On IOS it’s extremely simple. All you need to do is put the following command on the interface receiving the broadcast. In this topology it’ll be the interface connected to the switch and workstation the user is on

>conf t
# int fa0
# ip helper-address

On JunOS it’s just as simple. The configuration is not put on a particular interface, rather you specify which interface will be receiving the broadcast.

> configure
# set forwarding-options helpers bootp interface em1
# set forwarding-options helpers bootp server

Nice and easy :)

JunOS vs IOS – Basic OSPF

Let’s set up a basic OSPF adjacency between JunOS and IOS. I’ve got the following simple topology:

The good thing here is that the configs shown will show the difference between JunOS and IOS as the actual configuration goal is the same for both.

The Cisco config is as follows:

Router>conf t
#int fa0
#ip address
#int lo100
#ip address

#router ospf 1
#network area 0
#network area 0

Now onto JunOS:

# set interfaces em1 unit 0 family inet address
# set interfaces lo0 unit 100 family inet address

# edit protocols ospf area 0
# set interface
# set interface

Let’s see what we see on the Cisco:

Router#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface     128   FULL/BDR        00:00:34     FastEthernet0

Router#sh ip route is variably subnetted, 3 subnets, 2 masks
O [110/1] via, 00:00:25, FastEthernet0
O [110/1] via, 00:00:25, FastEthernet0
C is directly connected, Loopback100
C is directly connected, FastEthernet0

What about the Olive?

root@Olive> show ospf neighbor
Address         Interface   State           ID             Pri         Dead     em1.0       FULL      1           36

root@Olive>show route      *[OSPF/10]  00:09:05, metric 2
                     > to via em1.0

And yes, both routers can ping both loopbacks :)

JunOS – The basics

Right, it’s really time I get cracking on with my JNCIA. I’m going to do the EX track first, then maybe ER as well.

I’ve set up an Olive quickly and connected it to a 1721 via dynamips. I want to start off with the basics of getting around the cli of JunOS. Yes it’s different to IOS, but it’s really not that difficult.

When the Olive first boots up, it’ll be a blank slate. If you logged in as root, you’ll need to enter cli to actually get to the cli:


Right, now we are at the CLI. Let’s start configuring!

First go into configure mode:

root@O> configure
Entering configuration mode


Let’s start with a few basics. These few are all intuitive:

#set system host-name Olive
#set system time-zone Europe/London
#set system domain-name test.com
#set system name-server

Note that JunOS won’t make these changes live straight away. All changes go into a ‘candidate configuration’ – Only when you actually commit the changes will they actually happen. You can commit straight away or do a syntax check beforehand:

#commit check
configuration check succeeds

This means all looks good, so let’s commit the changes!

commit complete


There is something to note here. JunOS’s config mode is hierarchical. This means that if I was going to do a lot of commands in the same sub-section – I could go into that sub-section first.
For example, the above 4 commands were all in the system sub-section. Instead of the above, I could’ve done this:

root@O> configure
Entering configuration mode

root@O#edit system

[edit system]
root@O#set host-name Olive
#set time-zone Europe/London
#set domain-name test.com
#set name-server

This would give me exactly the same configuration as the above. If I need to get out of a sub-section I just type ‘up’



If I’m in pretty deep, you can type ‘top’ to get right to the top of the tree

Now we need to set up an IP address on an interface. To see what interfaces you have, you can type:

 Olive> show interfaces terse 

This command is similar to show ip int brief on a Cisco

I want to configure the em1 interface and I do so like this:

Olive# set interfaces em1 unit 0 family inet address

So quite a bit longer than on a Cisco, but it’s really not that difficult. There is an important note here. When you assign an IP address to a Cisco, it becomes the ‘first’ IP. You can add secondary addresses on that interface but you need to specify secondary when entering the IP address. The same thing happens on JunOS, but you HAVE to specify a logical unit at all times, even if it is only EVER going to have 1 IP. Therefore Unit 0 is the first IP, unit 1 the second, unit 2 the third and so on. If I wanted to add a second IP to this interface, I’d do it like so:

Olive# set interfaces em1 unit 1 family inet address

To set up a default route, we do it like so:

Olive# set routing-options static route next-hop

There’ll be plenty more JunOS stuff coming very shortly!

Troubleshooting 101 – Can I get back?

Rule #1 – Just because Host 1 can get to Host 2, does NOT mean that Host 2 can get back to Host 1!

I can’t tell you how many times I’ve seen this out in the field. Here is a prime example.

This is quite a simply common topology. OfficeA and OfficeB have a WAN connection running between them. RouterA and RouterB are under control of the ISP and are running OSPF. RouterC is a customer-owned router, and so doesn’t run any OSPF with RouterA or RouterB.

OfficeB has an internet connection, and RouterB is injecting a default route to OfficeA via OSPF.

RouterB has a default route to RouterC. So let’s think about traffic flow now. A host connected to RouterA needs to send traffic to the internet. It will send it’s traffic to it’s default gateway, RouterA. RouterA has a default route injected into OSPF from RouterB and so sends traffic to RouterB.

RouterB has a default route and hence sends that traffic out to RouterC. Which then goes out to the internet.

Traffic then flows back from the internet to RouterC. The return address will be an IP that belongs in RouterA and RouterB’s routing table, however RouterC has no knowledge of that subnet (as it’s not participating in OSPF). RouterC will just use it’s default route and send that packet back out to the internet.  Eventually the TTL will kill that packet.

This can be fixed by putting a static route on RouterC to let it know that RouterA’s ip range needs to be sent off to RouterB instead.

A similar thing will happen if we add a server to SwitchA. That server’s default gateway will most likely be RouterC. If a host in OfficeA send a PING to that server, that server will then send traffic off to RouterC. If RouterC does not have the static route added above, it’ll send it out to the internet.

I’m well aware that the design in the picture is pretty bad, but I used it to illustrate a point. That point being that just because router’s know how to get from A to B, it does NOT mean they know how to route that traffic back. Make sure you understand this!


I was tasked without setting up some IP SLA’s over our network to check performance at various points in the network. I’m not going to go hardcore into how to configure it, as Cisco has an excellent guide right here: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsjitter.html

There is something I wanted to point out though. I installed a 3750 in the core running the actual tests. IP SLA requires another Cisco router to actually respond to those tests, basically an IP SLA Responder. It seemed to me that a lot of devices we had simply did not support IP SLA, or at least I though.
IP SLA used to be called something completely different. In IOS release 12.1 (4) they released a feature called SAA Monitor. The commands used to configure it were completely different to IP SLA. Basically instead of typing:

Cisco(config)#ip sla responder

The command was instead:

Cisco(config)#rtr responder
The beauty is they work together perfectly. i.e. Router1 could be running 12.4 with IP SLA while RouterB would be running 12.1 with RTR RESPONDER. Both will still function perfectly.
One more thing to remember, a lot of devices cannot be the primary SLA monitor, but most CAN be the responder.