Archive for November, 2011

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]

JNCIA Question of the Week #3 – Routing Protocols

JNCIA Question of the Week #3

This week’s question is on common routing protocols and why they should be used. It’s pretty basic, but it’s something you have to know for the JNCIA. We’ll post the answers tomorrow.

Q:

What are two dynamic interior gateway protocols, and why would you use them over static (manual) routing? Additionally, list the current Exterior Gateway Protocol. Version numbers are optional, and listing more than two IGP’s is encouraged. Please be aware that we’re looking for modern, non-proprietary answers.

[edit]

A:

Dynamic Interior Gateway Routing Protocols include, but are not limited to, the following:

  • OSPFv2 – For IPv4
  • OSPFv3 – For IPv6
  • IS-IS – For IPv4 or IPv6
  • RIPv2 – For IPv4
  • RIPng – For IPv6

The Exterior Gateway Protocol currently in use is BGPv4.
[/edit]

Feature Lab Friday #2 – Single Area OSPF

Welcome back to Feature Lab Friday. Today, we’ll be discussing single-area OSPF, which is actually very simple to configure. We’re going to start off with our base config from here, which sets different subnets to the em0 (or if you have a live router, any interface). In addition, we’re going to set the following as well:

  • R1 em1.0 – 10.10.10.1/30
  • R2 em1.0 – 10.10.10.2/30
  • R3 em1.0 – 10.10.10.5/30
  • R4 em1.0 – 10.10.10.6/30
  • R1 em2.0 – 10.10.10.9/30
  • R2 em2.0 – 10.10.10.13/30
  • R3 em2.0 – 10.10.10.14/30
  • R4 em2.0 – 10.10.10.10/30

If you can’t tell from the above design, here’s how the routers connect:

  • R1 em1.0 <-> R2 em1.0
  • R3 em1.0 <-> R4 em1.0
  • R1 em2.0 <-> R4 em2.0
  • R2 em2.0 <-> R3 em2.0

We’re going to be using OSPF Area 0 for our configuration since this is single-area. This is also known as the backbone area or Area 0.0.0.0. We’re also going to use the passive option on all of the em0 interfaces. This will advertise the network attached to those interfaces without running OSPF on those interfaces. That is, OSPF will include those routes, but OSPF will not send or recieve OSPF information on those interfaces. To accomplish this, on all routers, enter the following from configuration mode:

[edit]
root@J1# edit protocols ospf area 0

[edit protocols ospf area 0.0.0.0]
root@J1# set interface em0.0 passive

[edit protocols ospf area 0.0.0.0]
root@J1# set interface em1.0

[edit protocols ospf area 0.0.0.0]
root@J1# set interface em2.0

After this, you should get a configuration similar to the following on each router, with IP addresses being different.

root@J1> show configuration 
## Last commit: 2011-11-25 02:33:18 UTC by root
version 9.6R1.13;
system {
    root-authentication {
        encrypted-password "$1$kEApDJMK$jfRY5ubo7CiiZ17HiaXSE."; ## SECRET-DATA
    }
    services {
        ssh;
    }
}
interfaces {
    em0 {
        unit 0 {
            family inet {
                address 192.168.0.1/24;
            }
        }
    }
    em1 {
        unit 0 {
            family inet {
                address 10.10.10.1/30;
            }
        }
    }
    em2 {
        unit 0 {
            family inet {
                address 10.10.10.9/30;
            }
        }
    }
    em3 {
        unit 0 {
            description "MANAGEMENT - DO NOT DELETE";
            family inet {
                address 172.16.1.1/29;
            }
        }
    }
}
protocols {         
    ospf {
        area 0.0.0.0 {
            interface em0.0 {
                passive;
            }
            interface em1.0;
            interface em2.0;
        }
    }
}

You probably won’t have the configuration that’s on em3.0. This exists specifically for me to be able to SSH into the boxes. You’ll also notice that I don’t have the user or class from the previous posts. This is intentional, as I am the only person administering this network. There is no real need for users or login classes.

Go back up to operational and run the command:

root@J1> show ospf neighbor

You should get output similar to the following (we show all four routers here, so pay attention to each):

root@J1> show ospf neighbor
Address Interface State ID Pri Dead
10.10.10.2 em1.0 Full 10.10.10.2 128 36
10.10.10.10 em2.0 Full 10.10.10.6 128 36

root@J2> show ospf neighbor
Address Interface State ID Pri Dead
10.10.10.1 em1.0 Full 10.10.10.1 128 36
10.10.10.14 em2.0 Full 10.10.10.5 128 34

root@J3> show ospf neighbor
Address Interface State ID Pri Dead
10.10.10.6 em1.0 Full 10.10.10.6 128 39
10.10.10.13 em2.0 Full 10.10.10.2 128 36

root@J4> show ospf neighbor
Address Interface State ID Pri Dead
10.10.10.5 em1.0 Full 10.10.10.5 128 35
10.10.10.9 em2.0 Full 10.10.10.1 128 31

We can see that each router has 2 neighbors, which is our intention as shown at the top of this post. Now, let’s check to see if our routes are being advertised correctly. Use the command

root@J1> show route

You should get something similar to:

root@J1> show route protocol ospf

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both

10.10.10.4/30 *[OSPF/10] 00:07:17, metric 2
> to 10.10.10.10 via em2.0
10.10.10.12/30 *[OSPF/10] 00:07:22, metric 2
> to 10.10.10.2 via em1.0
192.168.1.0/24 *[OSPF/10] 00:07:22, metric 2
> to 10.10.10.2 via em1.0
192.168.2.0/24 *[OSPF/10] 00:07:17, metric 3
to 10.10.10.10 via em2.0
> to 10.10.10.2 via em1.0
192.168.3.0/24 *[OSPF/10] 00:07:17, metric 2
> to 10.10.10.10 via em2.0
224.0.0.5/32 *[OSPF/10] 00:07:32, metric 1
MultiRecv

You can see here that we have a route to each subnet. Remember from previous commands that we don’t have neighbor relationships with any of the 192.168.0.0/16 networks because we used the passive option–but we do have routes to them. Finally, to verify our routes, we’ll ping each of the remote 192.168.0.0/16 networks.

root@J1> ping rapid 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!
— 192.168.1.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.461/0.632/1.064/0.235 ms

root@J1> ping rapid 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!
— 192.168.2.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.486/0.676/1.011/0.190 ms

root@J1> ping rapid 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
!!!!!
— 192.168.3.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.185/0.299/0.545/0.130 ms

And now, as you can see, we have a fully functional single-area OSPF domain. If you have questions, feel free to ask!

[edit]
Well, that’s embarrassing. I left a personal edit in the post that was supposed to remind me to post a link. I have fixed that and added the link now.
[/edit]

JNCIA Question of the Week #2 – OSPF Area 0

JNCIA Question of the Week #2

Another simple question this week, but vital nonetheless. I’ll avoid asking for a configuration example, though if you would like to provide one, feel free.

Q:

In the dynamic routing protocol OSPF, what is the purpose and/or importance of Area 0?

[edit]

A:

In OSPF, Area 0 is also known as the backbone area. In single-area configurations, the single area must be area 0. In multi-area OSPF, Area 0 serves as the backbone. All traffic destined for non-Area-0 areas must pass through Area 0. Therefore, all areas must have a way to reach Area 0 in a multi-area OSPF configuration.

[/edit]

Apologies

I know I haven’t been keeping to my commitments lately. Things have been extremely crazy with work, real life, studying, and the holidays. I want you to know, though, that I am not abandoning this project/blog/site. I will continue on, and the next post will be today and it will be the scheduled Question of the Week.

Feature Lab Friday #1 – Static Routes

In our first Feature Lab Friday, we’re going to take a look at a JNCIA-level topic: static routes. These are very simple to set up. We’ll cover basic static routes. During a later Feature Lab Friday segment, we will cover the resolve option as well as default routes.

To get started, start up two of your routers using the baseline configuration from this post. This should give you a single interface with an IP address that you can SSH to for remote access. Here’s an outline of the rest of this lab:

  1. Configure em1 on each router with a /30 subnet mask
  2. Verify Connectivity
    1. Ping from R1 to em1 on R2.
    2. Ping from R2 to em1 on R1.
  3. Create a static route on R1 to the subnet on R2’s em0 interface.
  4. Create a static route on R2 to the subnet on R1’s em0 interface.
  5. Verify Connectivity
    1. Ping from R1 to em0 on R2.
    2. Ping from R2 to em0 on R1.

Configure em1 on Each Router

We’re going to configure each router’s em1 interface with a /30 subnet mask (because this will be a point-to-point link and we don’t want to waste IP addresses). We’re going to use a simple 192.168.100.0/30 subnet for this configuration.

pkttlk@Junos-Olive-1> show configuration interfaces em1 
unit 0 {
    family inet {
        address 192.168.100.1/30;
    }
}

pkttlk@Junos-Olive-2> show configuration interfaces em1 
unit 0 {
    family inet {
        address 192.168.100.2/30;
    }
}

Above, you can see our configured IP addresses. R1 has an IP address of 192.168.100.1/30 and R2 has an IP address of 192.168.100.2/30. This offers a point-to-point, physically connected link located within the same subnet. Therefore, it should be possible to pass traffic between these two interfaces (but not to any other interfaces or to another router).

Set Commands

Now, here are the commands we used to turn our interfaces up (also called configuring the interfaces). I’m going to assume you’ve logged in as the user configured in this post and will display the user@host information now.

pkttlk@Junos-Olive-1> set interfaces em1 unit 0 family inet address 192.168.100.1/30
pkttlk@Junos-Olive-2> set interfaces em1 unit 0 family inet address 192.168.100.2/30

Verifying Connectivity

Now we need to be sure we can pass traffic between these devices. We’ll start from R1 and ping the IP address we configured on R2’s em1 interface (192.168.100.2). After we’ve verified that we can reach em1 on R2, we’ll ssh into R2 (which itself will verify connectivity as well as verifying our ssh service and user are set up correctly). Finally, we’ll ping R1’s em1 interface by pinging 192.168.100.1.

pkttlk@Junos-Olive-1> ping rapid 192.168.100.2
PING 192.168.100.2 (192.168.100.2): 56 data bytes
!!!!!
— 192.168.100.2 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.443/0.624/1.065/0.230 ms

pkttlk@Junos-Olive-1> ssh 192.168.100.2
pkttlk@192.168.100.2’s password:
— JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
pkttlk@Junos-Olive-2> ping rapid 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
!!!!!
— 192.168.100.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.397/0.862/2.007/0.584 ms

It should be pretty clear from here that we have connectivity, so our next step is going to be to actually configure our static routes from R1 to R2’s em0, and from R2 to R1’s em0.

Configuring Static Routes

pkttlk@Junos-Olive-1# show routing-options   
static {
    route 192.168.1.0/24 next-hop 192.168.100.2;
}

root@Junos-Olive-2# show routing-options 
static {
    route 192.168.0.0/24 next-hop 192.168.100.1;
}

This is pretty straightforward. This config says that under the edit routing-options static hierarchy, we’re going to have a static route to the 192.168.1.0/24 subnet, and that we’re going to reach that subnet through the next-hop address of 192.168.100.2, which if you remember is the IP address we configured on interface em1 on R2. The second section is the same, except in reverse: it shows the route to the 192.168.0.0/24 subnet (em0 on R1) through the next-hop of 192.168.100.1, which is em1 on R1.

Set Commands

Configuring these routes is just as easy as it looks, and we’ll do it with only one set command per router:

pkttlk@Junos-Olive-1# set routing-options static route 192.168.1.0/24 next-hop 192.168.100.2
pkttlk@Junos-Olive-2# set routing-options static route 192.168.0.0/24 next-hop 192.168.100.1

Verify Static Route Connectivity

We’re pretty much finished. Our last step is to verify connectivity, which I would say is even more important than entering commands to configure the router! What good is it if you don’t know you’ve accomplished your goal, after all? So here’s how we’re going to test test this. We’ll start on R1 and ping to 192.168.1.1. Once we’ve verified we can reach that host, we’ll ssh to R2 (via 192.168.100.2) and ping to 192.168.0.1. Once we know that this process is successful, we will know that we can pass traffic between the 192.168.0.0/24 and 192.168.1.0/24 subnets. So let’s do that now!

pkttlk@Junos-Olive-1> ping rapid 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!
— 192.168.1.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.443/0.624/1.065/0.230 ms

pkttlk@Junos-Olive-1> ssh 192.168.100.2
pkttlk@192.168.100.2’s password:
— JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
pkttlk@Junos-Olive-2> ping rapid 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
!!!!!
— 192.168.0.1 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.397/0.862/2.007/0.584 ms

Conclusion

And that is it. Configuration complete and successful! Stay tuned for Part 2, which will cover default routes and add a third router to study resolve.

[edit]
Part 2 to come on Saturday. Stayed up studying instead of writing.
[/edit]

[edit 2]
Part 2 cancelled due to time. It is extensive enough to be featured by itself, so we will cover it at a later date.
[/edit]

JNCIA Question of the Week #1 – Rescue Config

JNCIA Question of the Week #1

For our first question, we’ll start off simple. This week’s question is actually two questions, but they are closely related.

Q:

What is the command required to generate a rescue configuration, and under which mode and/or hierarchy (if applicable) is the rescue configuration created? Additionally, how can you restore this rescue configuration?

[edit]
Looks like I had comments set to require moderator approval before posting. My apologies! I’ll change the settings so that comments get posted immediately.
[/edit]


Both maurips and Rakesh Mandava got the answer correct. The reference for the answer is here. So save a rescue configuration, enter operational mode and use the following command:
> request system configuration rescue save
And, for the second half of the question, to restore the rescue configuration, enter configuration mode and enter the following command:
# rollback rescue
# commit
Thanks for stopping by!