Configuring OSPF

Problem

Your want to configure OSPF on a JUNOS router.

Solution

You enable OSPF by defining the interfaces on which it will run and the area to which the interfaces will be attached:

	[edit protocols]
	aviva@RouterG# set ospf area 0.0.0.0 interface fe-0/0/1.0
	aviva@RouterG# set ospf area 0.0.0.0 interface fe-1/0/1.0

Discussion

The basic setup for configuring a single OSPF area is straightforward. Enable the protocol on all router interfaces that will participate in the OSPF domain and specify which area the interfaces are in. In this recipe, area 0 has three routers (see Figure 12-1).

In this recipe, we configure OSPF on two interfaces of a router that is in the backbone area, which has an area identifier of 0.0.0.0. In addition, the router must have a router ID to identify the router from which OSPF packets originate. In this recipe, we don set one explicitly because we have configured a unicast IP address on the routers lo0 interface and this address is used as the router ID:

	aviva@RouterG> show configuration interfaces lo0
	unit 0 {
	 family inet {
	 address 192.168.19.1/32;
	 }
	}

Figure 12-1. OSPF single-area topology


You do not need to explicitly configure OSPF to run on lo0, because the JUNOS software automatically configures lo0 as a stub network if the router ID is the same as the address on the lo0 interface (which is what is recommended). Use the following command to set the router ID:

	[edit routing-options]
	aviva@RouterG# set router-id 192.168.19.1

In this recipe, using the lo0 as the router ID is implicit. Having the router ID be the same as the lo0 address provides a way for OSPF packets to get to the Routing Engine. If the router ID is different from the lo0 address, OSPF does not automatically run on the routers lo0 interface. The result is that LSAs will use the router ID as the originator, but the routing table will have a route to the lo0 address but not to the router ID.

However, it is good practice to configure the lo0 interface as a passive interface:

	[edit protocols]
	aviva@RouterG# set ospf area 0.0.0.0 interface lo0.0 passive

Passive interfaces advertise their addresses but do not form adjacencies.

With this simple configuration, the OSPF protocol takes over. You do not have to configure neighbors; OSPF automatically discovers them. (The exception to this is running OSPF on multipoint nonbroadcast, multiaccess [ NBMA] networks, such as ATM and Frame Relay. For these, you must explicitly configure neighbors.) OSPF then establishes adjacencies with its neighbors, first sending OSPF Hello packets to ensure that the two ends of the link can communicate. All point-to-point neighbors become adjacent to each other, and, on LANs, all interfaces become adjacent to the DR and BDR. In the process of establishing adjacencies, the routers synchronize their link-state databases. Once the adjacencies are established, OSPF floods LSAs to establish consistent routing databases.

To check that OSPF is running on the router interfaces, use the show ospf interface command:

	aviva@RouterG> show 
ospf interface
	Interface State Area DR ID BDR ID Nbrs
	fe-0/0/1.0 DR 0.0.0.0 192.168.19.1 192.168.18.1 1
	fe-1/0/1.0 BDR 0.0.0.0 192.168.17.1 192.168.19.1 1

This output shows the two interfaces we configured, fe-0/0/1 and fe-1/0/1. Both interfaces are in the backbone area, Area 0.0.0.0, and each has one neighbor. The State field indicates that interface fe-/0/0/1 is the DR for this network and interface fe-1/0/1 is the BDR, which is used if the DR becomes unavailable. The DR-ID and BDR-ID fields show the router ID of the DR and BDR. With this configuration, OSPF chooses as the designated router the interface with the highest router ID because all routers are using the default priority (which you see with the show ospf neighbor command, described below). If the router has not yet determined which router is the DR, the state is Waiting:

	aviva@RouterJ>  
show ospf interface
	Interface State Area DR ID BDR ID Nbrs
	fe-1/0/0.0 BDR 0.0.0.0 192.168.18.1 192.168.17.1 1
	fe-1/0/1.0 Waiting 0.0.0.0 0.0.0.0 0.0.0.0 0

Use the show ospf neighbor command to see who the OSPF neighbors are:

	aviva@RouterG> show ospf neighbor
	 Address Interface State ID Pri Dead
	10.0.1.1 fe-0/0/1.0 Full 192.168.18.1 128 34
	10.0.0.2 fe-1/0/1.0 Full 192.168.17.1 128 34

The Interface column lists the two interfaces we configured. Interface fe-0/0/1 connects to the neighbors interface address 10.0.1.1, and this neighbor has a router ID of 192.168.18.1. The other interface, fe-1/0/1, goes to the neighbors interface at IP address 10.0.0.2, and this neighbor has a router ID of 192.168.17.1. You see from this output that both neighbors have a router priority of 128, which is the default OSPF priority. OSPF uses this value to select the DR, choosing the router with the highest priority to be the DR. In the event of a tie, OSPF chooses the router with the highest router ID.

The State column shows the state of each OSPF neighbor. When OSPF network connectivity has established and the network is up and running, the state is Full. As OSPF connectivity is establishing, you may see Attempt, Init, or 2way in this field. (If either end of an adjacency on a LAN is not a DR or a BDR, the final state is 2Way.) If the state does not show as Full after about 30 seconds, check that the OSPF connectivity between the two neighbors is working correctly. Use the show interfaces command to make sure that the interface is operational. On the neighboring router, use the show configuration protocols ospf command to make sure that OSPF is configured, properly, and use the show ospf neighbor and show ospf interface commands to verify that OSPF is running on the interfaces.

Another common problem in establishing adjacencies is an MTU mismatch between the end points of the adjacency. This causes the adjacency to get stuck in the ExState state. The show interfaces command shows the MTU sizes for the physical and logical interfaces.

The last column of the output shows the OSPF dead interval, which is the amount of time remaining before the router closes the adjacency with its neighbor. OSPF sends Hello packets, which act as adjacency keepalives, every 10 seconds (this is the default). If there are no problems with the connection or the routers, the dead interval never drops below 31 seconds. The default dead time is four times the hello interval, or 40 seconds.

In the show ospf interface output, you can see that OSPF has automatically chosen DRs and a BDR:

	aviva@RouterG> show 
ospf interface
	Interface State Area DR ID BDR ID Nbrs
	fe-0/0/1.0 DR 0.0.0.0 192.168.19.1 192.168.18.1 1
	fe-1/0/1.0 BDR 0.0.0.0 192.168.17.1 192.168.19.1 1

How does OSPF elect the DR? It chooses the DR based on the priority. However, the default priority value (128) is the same for all OSPF interfaces, and we haven changed it in the configuration:

	aviva@RouterG>  
show ospf neighbor
	 Address Interface State ID Pri Dead
	10.0.1.1 fe-0/0/1.0 Full 192.168.18.1 128 34
	10.0.0.2 fe-1/0/1.0 Full 192.168.17.1 128 34

When an OSPF interface comes up, one of the things it checks is whether the network already has a DR. If it does, the interface simply accepts that DR regardless of its own router priority. In other words, the assignment of the DR is sticky. This is done by design because its relatively traumatic for the network to switch DRs (except to promote the BDR). So, even if you were to configure a DR priority (the priority can be a value from 1 to 255, with a higher number taking priority), it is effectively ignored once a DR is elected. Typically, there is no reason to care which router is the DR, because all JUNOS routers are powerful enough to handle the LSA load.


Router Configuration and File Management

Basic Router Security and Access Control

IPSec

SNMP

Logging

NTP

Router Interfaces

IP Routing

Routing Policy and Firewall Filters

RIP

IS-IS

OSPF

BGP

MPLS

VPNs

IP Multicast



JUNOS Cookbook
Junos Cookbook (Cookbooks (OReilly))
ISBN: 0596100140
EAN: 2147483647
Year: 2007
Pages: 290
Authors: Aviva Garrett

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net