Archive for the ‘ OSPF ’ Category

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]

Add Interface to an OSPF Area in Junos

Just a quick update showing how easy it is to add an interface to an OSPF area. We’re going to start by navigating from a root login up to the OSPF Area 0 config level. Then, we’ll add the interface to Area 0. Please note that this assumes you have already configured an interface with the appropriate settings.

Continue reading