OSPF Configuration
1. Single OSPF Area
2. Multiple OSPF Areas
3. Multipoint Network Types
4. NBMA Network Types
5. OSPF Authentication
6. Protocol Tracing
7. Stub Areas
8. Totally Stubby Areas
9. Not-So-Stubby Areas (NSSA)
10. Address Summarization
11. Virtual Links
12. OSPF Routing Policy
13. load-balance with metric
14. OSPF overload
15. OSPF transit-delay
Single OSPF Area
[edit protocols ospf]
user@Chablis# set area 0 interface all
user@Chablis# set area 0 interface fxp0 disable
Within the configuration of a protocol, any reference to a specific interface supersedes the parameters
of the interface all statement. The opposite approach of configuration is taken with the Chardonnay
router; each interface is referenced explicitly:
[edit protocols ospf]
user@Chardonnay# set area 0 interface so-0/0/1
user@Chardonnay# set area 0 interface at-0/1/0.100
Multiple OSPF Areas
[edit protocols ospf]
user@Chardonnay# set area 10 interface so-0/0/2
user@Chardonnay# set area 10 interface so-0/0/0
user@Chardonnay# set area 10 interface so-0/0/3
Area 1 Configuration
The following commands correctly configure r6 for operation as an internal area 1 router:
[edit protocols ospf]
lab@r6# set area 1 interface fe-0/1/0
[edit protocols ospf]
lab@r6# set area 1 interface fe-0/1/1
Multipoint Network Types
[edit]
lab@r3# set interfaces so-0/2/0 encapsulation frame-relay unit 0 multipoint family inet address 10.1.0.3/24
[edit interface so-0/2/0]
lab@r3# set multipoint-destination 10.1.0.4 dlci 400
[edit interface so-0/2/0]
lab@r3# set multipoint-destination 10.1.0.5 dlci 500
[edit protocol ospf]
lab@r3# set area 0.0.0.0 interfaces so-0/2/0.0 neighbor 10.1.0.4
[edit protocol ospf]
lab@r3# set area 0.0.0.0 interfaces so-0/2/0.0 neighbor 10.1.0.5
NBMA Network Types
[edit]
lab@r3# set protocols ospf area 0 interface so-0/2/0.0 interface-type nbma neighbor 10.1.0.4 eligible
[edit]
lab@r4# set protocols ospf area 0 interface so-0/1/0.0 interface-type nbma neighbor 10.1.0.3 eligible
OSPF Authentication
MD5 authentication requires that communicating stations share both the key value and a corresponding key-id.
Specifying the same secret with two different key-ids will result in authentication failures
The following commands correctly configure the authentication type for area 0 and area 1:
[edit protocols ospf]
lab@r5# set area 0 authentication-type md5
[edit protocols ospf]
lab@r5# set area 1 authentication-type simple
The next set of commands configures the MD5 specifics for all backbone area interfaces:
[edit protocols ospf area 0.0.0.0]
lab@r5# set interface at-0/2/1.35 authentication-key jni key-id 10
[edit protocols ospf area 0.0.0.0]
lab@r5# set interface as1.0 authentication-key jni key-id 10
Simple password
[edit protocols ospf area 0.0.0.1]
lab@r5# set authentication-type simple
[edit protocols ospf area 0.0.0.1]
lab@r5# set interface fe-0/0/0 authentication-key jnx
[edit protocols ospf area 0.0.0.1]
lab@r5# set interface fe-0/0/1.0 authentication-key jnx
Protocol Tracing
While monitoring traffic has the benefit of being “quick and dirty,” the more or less raw output pales in
comparison to the well-cooked information provided by JUNOS software protocol tracing. The following tracing
configuration has been added to r5, which is still the only router configured for authentication at this stage of the
configuration example:
[edit]
lab@r5# set protocols ospf traceoptions file ospf
[edit]
lab@r5# set protocols ospf traceoptions flag error detail
[edit]
lab@r5# set protocols ospf traceoptions flag hello detail
This tracing configuration produced the following output, which makes the nature of the problem obvious to even
a casual observer:
[edit]
lab@r5# run monitor start ospf
Stub Areas
Note
Juniper Networks routers do not automatically generate a default route when operating as an ABR attached to a
stub or not-so-stubby area. With JUNOS software, you must configure a default metric before a default route will
be advertised!
The following commands correctly configure area 10 as a stub area, beginning with the configuration changes
required on r3.
[edit protocols ospf]
lab@r3# set area 10 stub default-metric 10
[edit protocols ospf]
lab@r3# set area 10 interface fe-0/0/0.200
[edit protocols ospf]
lab@r3# set area 10 interface fe-0/0/1
Totally Stubby Areas
Note
By their very nature, Totally Stubby Areas are black holes looking for a place to happen. You should always be on
guard when configuring a TSA because achieving connectivity to inter-area destinations from within a TSA can be
tricky, and the loss of inter-area connectivity could be overlooked in the heat of battle—resulting in major
problems in your network’s operation down the road.
[edit protocols ospf area 0.0.0.10]
lab@r4# set stub no-summaries
Not-So-Stubby Area Configuration
[edit protocols ospf area 0.0.0.10]
lab@r1# set nssa
The following commands, entered on both r3 and r4, correctly configure the NSSA’s ABRs:
[edit protocols ospf area 0.0.0.10]
lab@r4# set nssa no-summaries default-lsa type-7 metric-type 2
[edit protocols ospf area 0.0.0.10]
lab@r4# set nssa default-lsa default-metric 10
Address Summarization
The proposed summarization prefix and mask pair of 10.0.8/23 is first used to filter the routing table contents of
r5. This allows the candidate to accurately gauge the summarization effect that will result when the same
prefix/mask is configured as part of an area range statement:
lab@r3# run show route protocol ospf 10.0.8/23
inet.0: 29 destinations, 31 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.8.0/30 *[OSPF/10] 00:04:38, metric 3
> via at-0/1/0.35
10.0.8.4/30 *[OSPF/10] 00:04:38, metric 2
> via at-0/1/0.35
10.0.8.8/30 *[OSPF/10] 00:04:38, metric 2
> via at-0/1/0.35
10.0.9.6/32 *[OSPF/10] 00:04:38, metric 2
> via at-0/1/0.35
10.0.9.7/32 *[OSPF/10] 00:04:38, metric 2
> via at-0/1/0.35
These results demonstrate that all of area 1’s internal prefixes can be correctly summarized with a 10.0.8.0/23
prefix and mask. Knowing that the summarization mask is valid, the following command is now used to configure
the summarization of the prefixes in area 1:
[edit protocols ospf area 0.0.0.1]
lab@r5# set area-range 10.0.8/23
When performing summarization for an OSPF area, do not forget to also summarize the loopback addresses, unless
otherwise required by your lab scenario.
Virtual Links
The following commands configure a virtual link on r5 and display the resulting virtual link
configuration:
[edit protocols ospf area 0]
lab@r5# set virtual-link neighbor-id 10.0.3.3 transit-area 3
[edit protocols ospf area 0.0.0.0]
lab@r5# show | match virtual
virtual-link neighbor-id 10.0.3.3 transit-area 0.0.0.3;
The following command is now entered (and committed) on r3 to complete the definition of the virtual link:
[edit protocols ospf area 0.0.0.0]
lab@r3# set virtual-link neighbor-id 10.0.3.5 transit-area 3
Load-balance with metric
[edit protocols ospf]
lab@r3# set area 10 interface fe-0/0/0 metric 2
[edit protocols ospf]
lab@r3# set area 10 interface fe-0/0/1 metric 2
lab@r5> show route 10.0.4/22
inet.0: 28 destinations, 30 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.4.0/22 *[OSPF/10] 00:02:03, metric 4
> via as1.0
via at-0/2/1.35
OSPF overload
Now, you configure r6 to appear overloaded:
[edit]
lab@r6# set protocols ospf overload
lab@r5> show ospf database router detail advertising-router 10.0.9.6
OSPF link state database, area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
OSPF link state database, area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.0.9.6 10.0.9.6 0x80000192 28 0x2 0xf60a 60
bits 0x2, link count 3
id 10.0.8.5, data 10.0.8.5, type Transit (2)
TOS count 0, TOS 0 metric 65535
id 10.0.8.1, data 10.0.8.1, type Transit (2)
TOS count 0, TOS 0 metric 65535
OSPF transit-delay
The last configuration requirement in this section is to correctly set OSPF to factor in a 4-second propagation delay
between r4 and r5. This is accomplished by setting the OSPF transit-delay value at both ends of the aggregated
SONET interface that interconnects r4 and r5. The following setting causes the lifetime of all LSAs flooded over r4’s
aggregated link to be reduced by the alleged 4-second propagation delay of the interface. This transit-delay setting
must also be configured on r5:
[edit protocols ospf area 0.0.0.0 interface as0.0]
lab@r4# set transit-delay 4
[edit protocols ospf area 0.0.0.0 interface as0.0]
lab@r4# show
transit-delay 4;
authentication-key "$9$3.1g/A0vMX7-w" key-id 10; # SECRET-DATA
Reference Bandwidth
The automatic metric formula uses the numerator value of 10 ^ 8 as the default reference bandwidth. We’ve seen
that this equals the bandwidth of a Fast Ethernet interface. The JUNOS software allows you to alter the reference
bandwidth used in the formula by using the reference-bandwidth command at the global OSPF configuration
hierarchy level. Changing the reference bandwidth affects all OSPF interfaces on the router, except for those
configured with a manual metric value.
[edit protocols ospf]
user@Chardonnay# set reference-bandwidth 1g;
The Restart Operation
[edit routing-options]
user@Zinfandel> set graceful-restart;
Within the [edit protocols ospf] hierarchy, a graceful-restart directory exists as well:
[edit protocols ospf]
user@Zinfandel# set graceful-restart ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
disable Disable OSPF graceful-restart capability
helper-disable Disable graceful restart helper capability
notify-duration Time to send all max-aged grace LSAs (1..3600 seconds)
restart-duration Time for all neighbors to become full (1..3600 seconds)
