Posts Tagged ‘ junos ’

For the Love of Networking or How I Learned to Stop Worrying and Love the Bomb

People usually tell you to do what you love. What they may not tell you is that you probably shouldn’t do something unless you love it.

There are obviously exceptions to this. If you need the work and can’t get anything else, you have to do what you have to do. However, with IT, the rule of “do what you love” seems particularly harsh.

I realize more and more that, with IT in general, if you don’t love what you do, you won’t get very far. You’ll probably work at a Tier I help desk for the rest of your life. While someone has to do it (and while it can be an art itself), I think most people aspire for more. Unfortunately, if you don’t love it, you won’t get any further.

As I study for my JNCIS, I have realized more and more that if I didn’t really want this, there’s no way I could pass it honestly. Sure, I could use a brain dump (read here for why not to) and pass, but that wouldn’t get me very far. I would either bomb every interview or get lucky, get hired, and then get fired within 30 days as my employer realizes I cheated on the test.

This stuff isn’t extremely simple. It’s not overly difficult, but you’re going to hate it if you don’t crave it. And if you hate it, how far do you realistically expect to get?

If you love it, don’t worry. It will all come with perseverance and dedication. Just study, ask questions, and delve deeper and deeper.

Advertisements

JNCIA Question of the Week #6 – Commit Requirements

Q:

With a clean Juniper router (one that is using the factory default configuration), what must be set before the router will allow you to commit configuration changes? How is this option set?

A:

Chris got it right, of course. Root passwords are required to save configuration changes in Junos. The command to do so is:
set system root-authentication plain-text-password

If you’re reading this and preparing for JNCIA-Junos, be sure you know this. Even if it’s not on the exam, it’s a pretty basic skill. Don’t use Brain Dumps!

Building a Juniper Lab with Remote Access – The Access Gateway

GNS3 is a great tool that can help us in many ways. One thing that may not be very evident, however, is how we can set up our GNS3 lab for remote access so we can practice when we’re not at home. The aim of this article is to show you how to do that.

This is part one in a series. This article describes how to install OpenBSD in a virtual machine (using VirtualBox). We go through the initial installation as well as assigning IP addresses to our interfaces. In part 2, we install Python and write a Python script that controls access to our gateway server.

This article assumes that you have already created virtual machines in VirtualBox before. If you have not, it is extremely intuitive. If you still need help, please see the VirtualBox website (here) or search Google.

Before we get started, here is our finished product in GNS3:

10 routers connected to a switch.  Two interfaces on a server connected to same switch.  Cloud connected to same switch

GNS 3 Topology

First, please create a new Virtual Machine with the OS type of BSD and OpenBSD. You can use the defaults throughout the wizard. Now open up the settings for the VM. Go to the storage tab and set the CD/DVD image to be the install50.iso you obtained from the OpenBSD website (here). Next, go to the Network tab. We need two interfaces. One will be bridged while the other will be internal.

The bridged adapter will be the one that is on our physical LAN. It is what will let us into the box. The internal adapter will get us to the actual GNS3 lab, but it will not automatically pass traffic between the GNS3 lab and our LAN (and thus the internet). In this way, although we have given ourselves remote access to the GNS3 lab (through this OpenBSD server), we have also isolated the GNS3 lab because there are no routes on the OpenBSD box. We will later use hostnames on the OpenBSD box to simplify accessing equipment, but there still will be no routes.

Next, start your VM. Press enter at the “boot>” prompt. The system will run through some internal loading and present you with the following screen:

Installation screen for OpenBSD 5.0

Installation Screen

Please accept the defaults until you get to the network configuration. For em0, we will want to use DHCP. This is our first adapter–the one that is bridged. When that is finished, you should see it ask you if you wish to configure any additional interfaces. We do. Type “em1.”

The screen for if em1

Interface em1 Configuration

Now we need to enter some information. I use the following to match the requirements of my GNS3 lab:

  • IP Address – 10.0.0.1
  • Subnet Mask – 255.255.255.240 – This mask accommodates 14 interfaces total. My lab example has 11.

The installation will ask you to set a root password. Do this. Also create a new user with a password. Enable sshd by default. Disable root login for sshd.

Enter defaults until the system asks if you want to use a graphical environment, XWindows. Say no here. We don’t need a GUI.

No GUI option

Removing X Windows

Again, accept defaults until it asks you if you would like to create a new add or remove packages. YES! We want to remove all of the XWindows packages and the games package. Prepend the package name with a hyphen to remove it. So, enter the following commands:


-xserv50.tgz
-xfont50.tgz
-xshare50.tgz
-xetc50.tgz
-xbase50.tgz
-games50.tgz

Removing X WIndows and Games

Remove Packages

If there are more prompts, accept defaults. Finally, type reboot to restart the system. Remove the installation media.

At this point, we have a working OpenBSD system and gateway to the GNS3 network. We could stop here, but we are going to go farther in future articles because we might want to have access to this system for more than one person.

To access your network, be sure you open your firewall to the IP of your OpenBSD system. SSH to your public IP. You will be directed to your OpenBSD server. From here, ssh or telnet to your GNS3 routers.

Please ask if you have questions!

JNCIA Question of the Week #5 – Benefits of Class of Service

Q:

Class of Service offers a number of benefits. From the list below, select 3.

  • Quicker Network Convergence
  • Eliminates Congestion
  • Prioritizes Latency-Sensitive Network Traffic, Such as VoIP
  • Allocates Bandwidth According to Service Type
  • Forces Packets Through, Eliminating Packet Loss
  • Alleviates Congestion, but Does Not Eliminate it

[edit]

A:

  • Prioritizes Latency-Sensitive Network Traffic, Such as VoIP
  • Allocates Bandwidth According to Service Type
  • Alleviates Congestion, but Does Not Eliminate it

Feature Lab Friday #3 – Securing Telnet Access

Feature Lab Friday #3 – Securing Telnet Access

This coincides with the previous JNCIA Question of the Week regarding how to secure access via telnet. Our objective here is to limit telnet access to a router to only a specific subnet. We want to allow telnet access only from the router’s loopback address. To test this, we will make use of advanced pinging techniques available in the Junos software.

First, we will assume that you have two routers configured in the following way:

  • R1 – em0.0 172.16.0.1/30
  • R1 – em1.0 192.168.1.1/24
  • R1 – lo0.0 10.1.1.1
  • R2 – em0.0 172.16.0.2/30
  • R2 – em1.0 192.168.2.1/24
  • R2 – lo0.0 10.2.2.2

We will assume that you have the em0.0 interfaces directly connected to each other. We will also assume that we have routes to all subnets, whether they are statically or dynamically configured.

First, log into R2 and issue the following command:
telnet source 192.168.2.1 10.1.1.1
It should succeed. Now issue this command:
telnet source 10.2.2.2 10.1.1.1
This should also succeed. Right now, we can telnet to this device from anywhere in the world. We’re going to apply a firewall filter that allows us to restrict telnet access to R1 to only the 10.2.2.2 address. Obviously this isn’t very practical in the real world since you would only be able to access R1 by first being in R2, but this will give you an idea as to how to configure for a more practical situation.

The following commands will restrict telnet access to R1. Only the 10.2.2.2 IP address will be able to access the router remotely.

[edit]
root# edit firewall filter restrict-telnet term accept-telnet

[edit firewall filter restrict-telnet term accept-telnet]
root# set from source-prefix-list trusted-subnets

[edit firewall filter restrict-telnet term accept-telnet]
root# set from protocol tcp

[edit firewall filter restrict-telnet term accept-telnet]
root# set from destination-port telnet

[edit firewall filter restrict-telnet term accept-telnet]
root# set then accept

[edit firewall filter restrict-telnet term accept-telnet]
root# up

[edit firewall filter restrict-telnet]
root# edit term reject-telnet

[edit firewall filter restrict-telnet term reject-telnet]
root# set from protocol tcp

[edit firewall filter restrict-telnet term reject-telnet]
root# set from destination-port telnet

[edit firewall filter restrict-telnet term reject-telnet]
root# set then discard

[edit firewall filter restrict-telnet term reject-telnet]
root# up

[edit firewall filter restrict-telnet]
root# set term accept-other-traffic then accept

[edit firewall filter restrict-telnet]
root# top

[edit]
root# set policy-options prefix-list trusted-subnets 10.2.2.2

Now, if we try to telnet from our 192.168.2.0/24 subnet, telnet will simply hang.

root> telnet source 192.168.2.1 10.1.1.1
Trying 10.1.1.1…
^C
root>

But if we telnet from the 10.2.2.2 address, we will get our login prompt:

root> telnet source 10.2.2.2 10.1.1.1
Trying 10.1.1.1…
Connected to 10.1.1.1.
Escape character is ‘^]’.

(ttyp0)

login:

JNCIA Question of the Week #4 – Securing Remote Access

JNCIA Question of the Week #4

After several weeks off due to heavy work load and vacation, we’re back with the JNCIA Question of the Week. And to start the week off, we’re going to be asking a more complicated question than has been customary.

Q:

This week, we want to allow telnet access only from a specific subnet.

Assume we have the following scenario:

  • Two routers directly connected through their em0 interfaces on the 172.16.0.0/30 subnet
  • R1’s lo0.0 address is 10.1.1.1
  • R2’s lo0.0 address is 10.2.2.2
  • R1 has the 192.168.1.0/24 network attached to its em1 interface
  • R2 has the 192.168.2.0/24 network attached to its em1 interface
  • We only want to allow telnet access to R1 from R2 from the 10.2.2.2/32 address.

What firewall filter(s) need to be created, to which device(s) and interface(s) must it/they be applied to and in which direction (ingress/egress), and how can we verify the firewall filter(s) work as intended?

This is a very open-ended question. Substitute IP addresses as you want. These were provided strictly as guidelines.

The answer to this week’s question will not be provided until Friday due to its complexity relative to previous questions. Also on Friday will be a Feature Lab Friday detailing how this can be accomplished and why we would want to accomplish such a thing.

[edit]

A:

Please refer to the post here for details on how to answer this question.
[/edit]

JNCIA and Network Fundamentals

There is a very fundamental concept behind the Juniper JNCIA-Junos exams: they expect you to have an understanding of networks before you ever take the exam.

The exam itself expects you to understand concepts such as subnetting and other networking basics. If you are not familiar with subnetting, how it’s done, why it’s done, what it means, etc., please consider taking the CompTIA Network+ exam. The official materials for the JNCIA-Junos exam do not really go over the fundamentals of data networking. (please see the note at the end of this post)

If you need to study or brush up on your networking fundamentals, I can recommend Michael Meyers’ CompTIA Network+ Guide to Managing and Troubleshooting Networks, Second Edition. It is several years old now, but it is still an excellent book.

If you’re looking for something more up-to-date, or if you prefer videos to books, check out Professor Messer’s N10-004 CompTIA Network+ Training Course. They’re free, too!

I don’t think that anyone could stress enough how important the fundamentals are. Although subnetting seemed to be the only fundamental stressed on the JNCIA-Junos exam that wasn’t covered in the official materials, everything on the Network+ exam is important to a career as a network technician, analyst, or engineer.

[note]
When I say “official materials,” I am talking about the materials offered via FastTrack. I don’t have the funds to purchase the JNCIA-Junos handbooks or attend the JNCIA-Junos classes. While the FastTrack video does talk about several fundamental concepts, I feel that it does not touch on them enough.
[/note]