OSPF


The Open Shortest Path First (OSPF) protocol is an IGP that routes packets within a single AS. OSPF uses link-state information to make routing decisions, making route calculations using the shortest- path -first (SPF) algorithm (also referred to as the Dijkstra algorithm). Each router running OSPF floods link-state advertisements (LSAs) throughout the AS that contain information about that router's attached interfaces and routing metrics. Each router takes the information in these link-state advertisements and creates a complete routing table for the network.

The JUNOS software supports OSPF Version 2, including virtual links, stub areas, and authentication. It does not support type-of-service (ToS) routing.

In OSPF, a single AS can be divided into smaller groups called areas. This reduces the number of LSAs and other OSPF overhead traffic sent on the network, and it reduces the size of the topological database that each router must maintain. An area is a set of networks and hosts within an AS that have been administratively grouped together. Juniper Networks recommends that you configure an area as a collection of contiguous IP subnetted networks. Routers that are wholly within an area are called internal routers. All interfaces on internal routers are directly connected to networks within the area. The topology of an area is hidden from the rest of the AS, thus significantly reducing routing traffic in the AS. Also, routing within the area is determined only by the area's topology, providing the area with some protection from bad routing data. All routers within an area have identical topological databases.

Routers that belong to more than one area are called area border routers. They maintain a separate topological database for each area to which they are connected.

An OSPF backbone area consists of all networks in area ID 0.0.0.0 , their attached routers, and all area border routers. The backbone itself does not have any area border routers. The backbone distributes routing information between areas. The backbone is simply another area, so the terminology and rules of areas apply: a router that is directly connected to the backbone is an internal router on the backbone, and the backbone's topology is hidden from the other areas in the AS. The routers that make up the backbone must be physically contiguous. If they are not, you must configure virtual links to create the appearance of backbone connectivity. You can create virtual links between any two area border routers that have an interface to a common nonbackbone area. OSPF treats two routers joined by a virtual link as if they were connected to an unnumbered point-to-point network.

Routers that exchange routing information with routers in other ASs are called AS boundary routers. They advertise externally learned routes throughout the AS. Any router in the ASan internal router, an area border router, or a backbone routercan be an AS boundary router. Every router within the AS knows the path to the AS boundary routers.

Stub areas are areas through which or into which AS external advertisements are not flooded. You might want to create stub areas when much of the topological database consists of AS external advertisements. Doing so reduces the size of the topological databases and therefore the amount of memory required on the internal routers in the stub area. When an area border router is configured for a stub area, the router automatically advertises a default route in place of the external routes that are not being advertised within the stub area so that routers in the stub area can reach destinations outside the area. The following restrictions apply to stub areas: you cannot create a virtual link through a stub area, and a stub area cannot contain an AS boundary router.

An OSPF stub area has no external routes in it, so you cannot redistribute from another protocol into a stub area. A not-so-stubby area (NSSA) allows external routes to be flooded within the area. These routes are then leaked into other areas. However, external routes from other areas still do not enter the NSSA.

Transit areas are used to pass traffic from one adjacent area to the backbone (or to another area if the backbone is more than two hops away from an area). The traffic does not originate in, nor is it destined for, the transit area.

When OSPF exports route information from external ASs, it includes a cost, or external metric , in the route. There are two types of external metric: Type 1 and Type 2. Type 1 external metrics are equivalent to the link-state metric; that is, the cost of the route used in the internal AS. Type 2 external metrics are greater than the cost of any path internal to the AS.

Each multiaccess network has a designated router , which originates network link advertisements on behalf of the network and establishes adjacencies with all routers on the network, thus participating in the synchronizing of the link-state databases. The OSPF hello protocol elects a designated router for the network based on the priorities advertised by all the routers. In general, when an interface first becomes functional, it checks whether the network currently has a designated router. If there is one, the router accepts that designated router regardless of its own router priority. Otherwise , if the router has the highest priority on the network, it becomes the designated router. If router priorities tie, the router with the highest router ID (which is typically the router's IP address) is chosen as the designated router.

See Chapter 11, "MPLS Applications," on page 519.

To help provide traffic engineering and MPLS with information about network topology and loading, extensions have been added to the JUNOS implementation of OSPF. Specifically, OSPF generates opaque LSAs, which carry traffic engineering parameters. These parameters are used to populate the traffic engineering database (TED), which is used by the Constrained Shortest-Path First (CSPF) algorithm to compute the paths that MPLS LSPs take. This path information is used by RSVP to set up LSPs and reserve bandwidth for them. The JUNOS software also supports an LSP as the next hop as if it were a logical interface from the ingress router to the egress router. When used in this way, LSPs are no different than ATM and Frame Relay VCs, except that LSPs carry only IPv4 traffic.

Table 9.5 lists the OSPF standards and protocol extensions supported by the JUNOS software.

Table 9.5. OSPF Standards Supported by JUNOS Software
Standard Title
RFC 2328 OSPF Version 2
RFC 1587 The OSPF NSSA Option
RFC 2370 The OSPF Opaque LSA Option
draft-katz-yeung-ospf-traffic-06.txt Traffic Engineering Extension to OSPF

OSPF Routing Algorithm

OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra algorithm, to determine the route to reach each destination. All routers in an area run this algorithm in parallel, storing the results in their individual topological databases. Routers with interfaces to multiple areas run multiple copies of the algorithm. This section provides a brief summary of how the SPF algorithm works.

When a router starts, it initializes OSPF and waits for indications from lower-level protocols that the router interfaces are functional. The router then uses the OSPF hello protocol to acquire neighbors, doing this by sending hello packets to its neighbors and receiving their hello packets.

On broadcast or nonbroadcast multiaccess networks (physical networks that support the attachment of more than two routers), the OSPF hello protocol elects a designated router for the network. This router is responsible for sending LSAs that describe the network, which reduces the amount of network traffic and the size of the routers' topological databases.

The router then attempts to form adjacencies with some of its newly acquired neighbors. (On multiaccess networks, only the designated router and backup designated router form adjacencies with other routers.) Adjacencies determine the distribution of routing protocol packets: routing protocol packets are sent and received only on adjacencies, and topological database updates are sent only along adjacencies. When adjacencies have been established, pairs of adjacent routers synchronize their topological databases.

A router sends LSA packets to advertise its state periodically and when the router's state changes. These packets include information about the router's adjacencies, which allows detection of nonoperational routers.

Using a reliable algorithm, the router floods LSAs throughout the area, which ensures that all routers in an area have exactly the same topological database. Each router uses the information in its topological database to calculate a shortest-path tree, with itself as the root. The router then uses this tree to route network traffic.

The description of the SPF algorithm up to this point has explained how the algorithm works within a single area ( intra-area routing ). For internal routers to be able to route to destinations outside the area ( interarea routing ), the area border routers must inject additional routing information into the area. Because the area border routers are connected to the backbone, they have access to complete topological data about the backbone. They use this information to calculate paths to all destinations outside its area and then advertise these paths to the area's internal routers.

AS boundary routers flood information about external ASs throughout the AS, except to stub areas. Area border routers are responsible for advertising the paths to all AS boundary routers.

OSPF Packets

All OSPF packets have a common 24-byte header that contains all information necessary to determine whether OSPF should accept the packet. The header consists of the following fields:

  • Version numberThe current OSPF version number is 2.

  • TypeType of OSPF packet.

  • Packet lengthLength of the packet, in bytes, including the header.

  • Router IDIP address of the router from which the packet originated.

  • Area IDIdentifier of the area in which the packet is traveling. Each OSPF packet is associated with a single area. Packets traveling over a virtual link are labeled with the backbone area ID, 0.0.0.0 . You configure the area ID with the area statements.

  • ChecksumFletcher checksum.

  • Authentication typeAuthentication scheme to use for the packet. You configure the authentication type with the authentication-type statement.

  • AuthenticationThe authentication information itself.

Routers periodically send hello packets on all interfaces, including virtual links, to establish and maintain neighbor relationships. Hello packets are multicast on physical networks that have a multicast or broadcast capability, which enables dynamic discovery of neighboring routers. (On nonbroadcast networks, dynamic neighbor discovery is not possible, so you must configure all neighbors statically using the neighbor statement.)

Hello packets consist of the OSPF header plus the following fields:

  • Network maskNetwork mask associated with the interface.

  • Hello intervalHow often the router sends hello packets. All routers on a shared network must use the same hello interval. You configure this interval with the hello-interval statement.

  • OptionsOptional capabilities of the router.

  • Router priorityThe router's priority to become the designated router. You can configure this value with the priority statement.

  • Router dead intervalHow long the router waits without receiving any OSPF packets from a router before declaring that router to be down. All routers on a shared network must use the same router dead interval. You can configure this value with the dead-interval statement.

  • Designated routerIP address of the designated router.

  • Backup designated routerIP address of the backup designated router.

  • NeighborIP addresses of the routers from which valid hello packets have been received within the time specified by the router dead interval.

When initializing an adjacency , OSPF exchanges database description packets, which describe the contents of the topological database. These packets consist of the OSPF header, this packet's sequence number, and the link-state advertisement's header.

When a router detects that portions of its topological database are out of date, it sends a link-state request packet to a neighbor requesting a precise instance of the database. These packets consist of the OSPF header plus fields that uniquely identify the database information that the router is seeking.

Link-state update packets carry one or more LSAs one hop farther from their origin. The router multicasts (floods) these packets on physical networks that support multicast or broadcast mode. The router acknowledges all link-state update packets and, if retransmission is necessary, sends the retransmitted advertisements unicast.

Link-state update packets consist of the OSPF header plus the following fields:

  • Number of advertisementsNumber of LSAs included in this packet

  • Link-state advertisementsThe LSAs themselves

The router sends link-state acknowledgment packets in response to link-state update packets to verify that the update packets have been received successfully. A single acknowledgment packet can include responses to multiple update packets. Link-state acknowledgment packets consist of the OSPF header plus the LSA header.

Link-state request, link-state update, and link-state acknowledgment packets are used to reliably flood LSA packets. OSPF sends the following types of LSAs:

  • Router link advertisementsSent by all routers to describe the state and cost of the router's links to the area. These LSAs are flooded throughout a single area only.

  • Network link advertisementsSent by designated routers to describe all the routers attached to the network. These LSAs are flooded throughout a single area only.

  • Summary link advertisementsSent by area border routers to describe the routes that they know about in other areas. There are two types of summary link advertisements: those used when the destination is an IP network, and those used when the destination is an AS boundary router. Summary link advertisements describe interarea routes; that is, routes to destinations outside the area but within the AS. These LSAs are flooded throughout the advertisement's associated areas.

  • AS external link advertisementSent by AS boundary routers to describe external routes that they know about. These LSAs are flooded throughout the AS (except for stub areas).

Each LSA type describes a portion of the OSPF routing domain. All LSAs are flooded throughout the AS. Each LSA packet begins with a common 20-byte header.

Configuring OSPF

For OSPF to run on the router, you must configure a backbone area on at least one interface.

 [edit protocols] ospf {   disable;   domain-id  domain-id  ;   export [  policy-names  ];   external-preference  preference  ;   overload {     timeout  seconds  ;   }   preference  preference  ;   rib-group  group-name  ;   reference-bandwidth  reference-bandwidth  ;   traffic-engineering {     no-topology;     shortcuts;   }   traceoptions {     file  name  <replace> <size  size  > <files  number  > <no-stamp>       <(world-readable  no-world-readable)>;     flag  flag  <  flag-modifier  > <disable>;   }   area  area-id  {     area-range  network  /  mask-length  <restrict>;     authentication-type  authentication  ;     interface  interface-name  {       disable;       authentication-key  key  <key-id  identifier  >;       dead-interval  seconds  ;       hello-interval  seconds  ;       interface-type  type  ;       metric  metric  ;       neighbor  address  <eligible>;       passive;       poll-interval  seconds  ;       priority  number  ;       retransmit-interval  seconds  ;       transit-delay  seconds  ;       transmit-interval  seconds  ;     }     label-switched-path  name  metric  metric  ;     nssa {       area-range  network  /  mask-length  <restrict>;       default-lsa {         default-metric  metric  ;         metric-type  type  ;       }       (no-summaries  summaries)     }     stub <default-metric  metric  > <summaries  no-summaries>;     virtual-link neighbor-id  router-id  transit-area  area-id  {       disable;       authentication-key  key  <key-id identifier>;       dead-interval  seconds  ;       hello-interval  seconds  ;       retransmit-interval  seconds  ;       transit-delay  seconds  ;     }   } } 
Configuring the Backbone Area and Other Areas

You can group routers in a single AS into areas to reduce the amount of LSA traffic on the network and to reduce the size of the topological databases that OSPF routers must maintain. If you do this, the AS must contain a single backbone area and optionally can contain any number of nonbackbone areas. The routers that make up the backbone must be physically contiguous. If they are not, you must configure virtual links to create the appearance of connectivity. You also can configure stub areas, which are areas through which AS external advertisements are not flooded, and NSSAs, which allow external routes to be flooded within an area.

You must create a backbone area if your network consists of multiple areas. An area border router must have at least one interface in the backbone area, or it must have a virtual link to a router in the backbone area. The backbone comprises all area border routers and all routers that are not included in any other area. You configure all these routers by including the following area statement:

 [edit protocols ospf] area 0.0.0.0; 

Each OSPF area consists of routers configured with the same area number. To configure a router to be in an area, include the area statement. The area number can be any number except 0.0.0.0 , which is reserved for the backbone area.

 [edit protocols ospf] area  area-id  ; 

Stub areas are areas into which OSPF does not flood AS external advertisements. You might want to configure stub areas when much of the topological database consists of AS external advertisements and you want to minimize the size of the topological databases on an area's routers. You must include the stub statement when configuring all routers that are in the stub area. You cannot configure an area as being both a stub area and an NSSA. To configure a stub area, include the stub statement:

 [edit protocols ospf area  area-id  ] stub <default-metric  metric  > <(no-summaries  summaries)>; 

To inject a default route with a specified metric value into the area, include the default-metric option and a metric value. The default route matches any destination that is not explicitly reachable from within the area. To have the stub areas not advertise summary routes into the stub area, include the no-summaries option. Only the default route is advertised, and only if you include the default-metric option. The default route injected into the NSSA area is a Type 3 LSA.

An OSPF stub area has no external routes in it, so you cannot redistribute from another protocol into a stub area. An NSSA allows external routes to be flooded within the area. These routes are then leaked into other areas. However, external routes from other areas still do not enter the NSSA. You cannot configure an area to be both a stub area and an NSSA. To configure an NSSA, include the nssa statement:

 [edit protocols ospf area  area-id  ] nssa {   area-range  network/mask-length  <restrict>;   default-lsa {     default-metric  metric  ;     metric-type  type  ;   }   (no-summaries  summaries) } 

By default, a default route is not advertised. To advertise a default route with the specified metric within the area, include the default-metric statement. You can configure this option only on area border routers.

To prevent area border routers from advertising summary routes into an NSSA, include the no-summaries statement. If you include the default-metric option in addition to the no-summaries statement, only the default route is advertised. The default route is a Type 3 LSA injected into the NSSA. To flood summary (Type 7) LSAs into the NSSA area, include the summaries statement.

To aggregate external routes learned within the area when a route is advertised to other areas, include one or more area-range statements. If you also include the restrict option, the aggregate is not advertised, effectively creating a route filter. All external routes learned within the area that do not fall into the range of one of the prefixes are advertised individually to other areas.

If any router on the backbone is not physically connected to the backbone itself, you must establish a virtual connection, or virtual link, between that router and the backbone. You can establish virtual links between area border routers only. For the virtual link to work, you also must configure a virtual link to the backbone area on the remote area border router (the router at the other end of the virtual link). To configure a virtual link, include the virtual-link statement when configuring the backbone area (area 0):

 [edit protocols ospf area 0.0.0.0]  virtual-link neighbor-id  router-id  transit-area  area-id  ; 

Specify the IP address of the router at the other end of the virtual link. This router must be an area border router that is physically connected to the backbone. Also, specify the number of the area through which the virtual link transits.

Configuring OSPF on Router Interfaces

To enable OSPF on the router, you must configure OSPF on at least one of the router's interfaces. How you configure an interface depends on whether the interface is connected to a broadcast or point-to-point network, a point-to-multipoint network, or a nonbroadcast, multiaccess (NBMA) network.

When you configure OSPF on an interface, you must also include the family inet statement at the [edit interfaces interface-n ame unit l ogical-unit-number ] hierarchy level.

If the interface on which you are configuring OSPF supports broadcast mode (such as a LAN), or if the interface supports point-to-point mode (such as a PPP interface or a point-to-point logical interface on Frame Relay), include the following form of the interface statement, specifying the IP address or name of the interface:

 [edit protocols ospf area  area-id  ]  interface  interface-name  ; 

When you configure OSPF on an NBMA network, such as a multipoint ATM or Frame Relay logical interface, OSPF operates by default in point-to-multipoint mode. In this mode, OSPF treats the network as a set of point-to-point links. Because there is no autodiscovery mechanism, each neighbor must be configured. To configure OSPF in point-to-multipoint mode, include the following statements, specifying the IP address or name of the interface. To configure multiple neighbors, include a neighbor statement for each neighbor.

 [edit protocols ospf area 0.0.0.0]  interface  interface-name  {   neighbor  address  ; } 

When configuring OSPF on an NBMA network, you can use nonbroadcast mode rather than point-to-multipoint mode. Using this mode offers no advantages over point-to-multipoint mode, but it has more disadvantages than point-to-multipoint mode. Nevertheless, you might occasionally find it necessary to configure nonbroadcast mode to interoperate with other equipment. Nonbroadcast mode treats the NBMA network as a partially connected LAN, electing designated and backup designated routers. All routers must have a direct connection to both the designated and backup designated routers, or unpredictable results occur. To configure nonbroadcast mode, include the following statements, specifying the IP address of the interface. To configure multiple neighbors, include a neighbor statement for each neighbor.

 [edit protocols ospf area 0] interface  interface-name  {   interface-type nbma;   neighbor  address  <eligible>;   poll-interval  seconds  ; } 

OSPF routers normally discover their neighbors dynamically by listening to the broadcast or multicast hello packets on the network. Because an NBMA network does not support broadcast (or multicast), the router cannot discover its neighbors dynamically, so you must configure all the neighbors statically. Do this by including the neighbor statement and specifying the IP address of each neighboring router in the address option. To configure multiple neighbors, include multiple neighbor statements. If the neighbor is allowed to become the designated router, include the eligible keyword.

By default, the router sends hello packets out the interface every 120 seconds before it establishes adjacency with a neighbor. To modify the interval, include the poll-interval statement.

Configuring OSPF Authentication

All OSPF protocol exchanges can be authenticated to guarantee that only trusted routers participate in the AS's routing. By default, OSPF authentication is disabled. You can configure one of the following authentication methods . Each area must use the same method.

  • Simple authenticationUses a text password that is included in the transmitted packet. The receiving router uses an authentication key (password) to verify the packet.

  • MD5 algorithmCreates an encoded checksum that is included in the transmitted packet. The receiving router uses an authentication key (password) to verify the packet. For MD5 authentication to work, both the receiving and transmitting routers must have the same MD5 key. Define an MD5 key for each interface. If MD5 is enabled on an interface, that interface accepts routing updates only if MD5 authentication succeeded; otherwise, updates are rejected. The key ID for MD5 authentication is hard-coded to 1. If you use equipment from other vendors , you must configure the key ID for that equipment to 1 to interoperate with the access path.

To enable authentication and specify an authentication method, include the authentication-type statement. authentication can be none , simple , or md5 .

 [edit protocols ospf area  area-id  ] authentication-type  authentication  ; 

To configure a key (password) on each interface, include the authentication-key statement. The key (password) can be 1 to 8 characters long. Characters can include any text strings. If you include spaces, enclose all characters in quotation marks (" "). The key identifier, which is required for MD5 authentication, specifies the identifier associated with the MD5 key. You can define multiple keys, each with a different key identifier. OSPF uses the key with the highest number.

 [edit protocols ospf area  area-id  interface  interface-name  ] authentication-key  key  key-id  identifier  ; 
Configuring the Priority for Becoming the Designated Router

A router advertises its priority to become a designated router in its hello packets. On all multiaccess networks, the OSPF hello protocol uses the advertised priorities to elect a designated router for the network. This router is responsible for sending network link advertisements, which describe all the routers attached to the network. These advertisements are flooded throughout a single area. At least one router on each logical IP network or subnet must be eligible to be the designated router.

A router's priority for becoming the designated router is indicated by an arbitrary number from 0 through 255, with a higher value indicating a greater likelihood of becoming the designated router. By default, routers have a priority value of 128. A value of 1 means that the router has the least chance of becoming a designated router. A value of 0 marks the router as ineligible to become the designated router. To modify the router's priority value, include the priority statement:

 [edit protocols ospf area  area-id  interface  interface-name  ] priority  number  ; 
Configuring Route Summarization

Area border routers send summary link advertisements to describe the routes to other areas. To minimize the number of these advertisements that are flooded, you can configure the router to coalesce, or summarize, a range of IP addresses and send reachability information about these addresses in a single link-state advertisement. To summarize a range of IP addresses, include the area-range statement. To summarize multiple ranges, include multiple area-range statements.

 [edit protocols ospf area  area-id  ] area-range  network /mask-length  <restrict >; 

All routes that match the specified area range are filtered at the area boundary, and the summary is advertised in their place. If you specify the restrict option, the routes are filtered, but no summary is advertised.

Modifying the Interface Metric

All OSPF interfaces have a cost, which is a routing metric that is used in the OSPF link-state calculation. Routes with lower total path metrics are preferred over those with higher path metrics. When several equal-cost routes to a destination exist, traffic is distributed equally among them. The cost of a route is described by a single dimensionless metric that is determined using the following formula:

 cost = reference-bandwidth / bandwidth 

reference-bandwidth is the reference bandwidth. Its default value is 100 Mbps (which you specify as 100,000,000), which gives a metric of 1 for any bandwidth that is 100 Mbps or greater.

To modify the metric for routes advertised from an interface, include the metric statement:

 [edit protocols ospf area  area-id  interface  interface-name  ] metric  metric  ; 

To modify the reference bandwidth, include the reference-bandwidth statement:

 [edit protocols ospf] reference-bandwidth  reference-bandwidth  ; 

For example, if you set the reference bandwidth to 1 Gbps (that is, reference-bandwidth is set to 1,000,000,000), a 100-Mbps interface has a default metric of 10.

By default, the loopback interface ( lo0 ) metric is 0. No bandwidth is associated with the loopback interface.

Configuring Route Preferences

Route preferences are used to select which route is installed in the forwarding table when several protocols calculate routes to the same destination. The route with the lowest preference value is selected. By default, internal OSPF routes have a preference value of 10, and external OSPF routes have a value of 150. To change the preference values, include the preference statement (for internal routes) or the external-preference statement (for external routes). The preference value can range from 0 through 255.

For more information about route preferences, see Table 9.1 on page 379.

 [edit protocols ospf] external-preference  preference  ; preference  preference  ; 
Configuring OSPF Timers

OSPF routers constantly track the status of their neighbors, sending and receiving hello packets that indicate that the neighbor still is functioning, and sending and receiving LSA and acknowledgment packets. OSPF sends packets and expects to receive packets at specified intervals.

Routers send hello packets at a fixed interval on all interfaces, including virtual links, to establish and maintain neighbor relationships. This interval, which must be the same on all routers on a shared network, is advertised in the hello interval field in the hello packet. By default, the router sends hello packets every 10 seconds. To modify how often the router sends hello packets out of an interface, include the hello-interval statement:

 [edit protocols ospf area  area-id  interface  interface-name  ] 

or

 [edit protocols ospf area  area-id  virtual-link]  hello-interval  seconds  

On nonbroadcast networks, the router sends hello packets every 120 seconds until active neighbors are detected by default. This interval is long enough to minimize the bandwidth required on slow WAN links. After the router detects an active neighbor, the hello packet interval changes from the time specified in the poll-interval statement to the time specified in the hello-interval statement. To modify the hello interval on nonbroadcast networks, include the poll-interval statement.

 [edit protocols ospf area  area-id  interface  interface-name  ] poll-interval  seconds  ; 

The transmit interval specifies how often OSPF LSA packets are transmitted on an interface. This interval determines the maximum packet transmission rate on an interface, which affects network stability. Because packets are built at the instant of transmission, only the latest information is sent even if the transmission is delayed. The default transmit interval is 30 milliseconds . To modify the interval, include the transmit-interval statement:

 [edit protocols ospf area  area-id  interface  interface-name  ]  transmit-interval  milliseconds  ; 

When a router sends LSAs to its neighbors, the router expects to receive an acknowledgment packet from the neighbor within a certain amount of time. If the router does not receive an acknowledgment, it retransmits the advertisement. By default, the router waits 5 seconds for an acknowledgment before retransmitting the LSA. To modify this interval, include the retransmit-interval statement:

 [edit protocols ospf area  area-id  interface  interface-name  ] 

or

 [edit protocols ospf area  area-id  virtual-link] retransmit-interval  seconds  ; 

If a router does not receive a hello packet from a neighbor within a fixed amount of time, the router modifies its topological database to indicate that the neighbor is nonoperational. The time that the router waits is called the router dead interval. By default, this interval is 40 seconds (four times the default hello interval). To modify the router dead interval, include the dead-interval statement. This interval must be the same for all routers on a shared network.

 [edit protocols ospf area  area-id  interface  interface-name  ] 

or

 [edit protocols ospf area  area-id  virtual-link]  dead-interval  seconds  ; 

Before a link-state update packet is propagated out of an interface, the router must increase the age of the packet. If you have a very slow link (for example, one with an average propagation delay of multiple seconds), the age of the packet must be increased by a similar amount. Doing this ensures that you do not receive a packet back that is younger than the original copy. The default transit delay is 1 second. You should never have to modify the default value. However, if you need to specify the approximate transit delay to use to age update packets, include the transit-delay statement:

 [edit protocols ospf area  area-id  interface  interface-name  ] 

or

 [edit protocols ospf area  area-id  virtual-link] transit-delay  seconds  ; 
Advertising Interface Addresses without Running OSPF

By default, OSPF must be configured on an interface for direct interface addresses to be advertised as interior routes. To advertise the direct interface addresses without actually running OSPF on that interface, include the passive statement:

 [edit protocols ospf interface  interface-name  ] passive; 

Point-to-point interfaces are different than multipoint in that only one OSPF adjacency is possible. (A LAN, for instance, can have multiple addresses and can run OSPF on each subnet simultaneously .) As such, when you configure a numbered point-to-point interface to OSPF by name, multiple OSPF interfaces are created. One, which is unnumbered, is the one on which the protocol is run. An additional OSPF interface is created for each address configured on the interface, if any, which is automatically marked as passive.

Enabling OSPF on an interface (by including the interface statement at the [edit protocols ospf] hierarchy level), disabling it (by including the disable statement), and not actually having OSPF run on an interface (by including the passive statement) are mutually exclusive states.

Advertising Label-Switched Paths into OSPF

You can advertise label-switched paths (LSPs) into OSPF as point-to-point links so that all participating routers can take the LSP into account when performing SPF calculations. The advertisement contains a local address (the from address of the label-switched path), a remote address (the to address of the label-switched path), and a metric with the following precedence:

  1. Use the label-switched path metric defined under OSPF.

  2. Use the label-switched path metric configured for the label-switched path under MPLS.

  3. If you do not configure any of the above, use the default OSPF metric of 1.

To advertise label-switched paths, include the label-switched-path statement, with a specified name and metric :

 [edit protocols ospf area  area-id  ]  label-switched-path  name  metric  metric  ; 

For more information, see Chapter 11, "MPLS Applications," on page 519.

For a label-switched path that is announced into OSPF to be used in SPF calculations, a reverse link must exist (that is, a link from the egress router of the label-switched path to the ingress router). To establish a reverse link, configure a label-switched path in the reverse direction and announce it into OSPF.

Configuring the Router to Appear Overloaded

You can configure the local router so that it appears to be overloaded. You might do this when you want the router to participate in OSPF routing, but do not want it to be used for transit traffic. (Note that traffic to immediately attached interfaces continues to transit the router.) You configure or disable overload mode in OSPF with or without a timeout. Without a timeout, overload mode is set until it is explicitly deleted from the configuration. With a timeout, overload mode is set if the time elapsed since the OSPF instance started is less than the specified timeout. A timer is started for the difference between the timeout and the time elapsed since the instance started. When the timer expires , overload mode is cleared. In overload mode, the router LSA is originated with all the transit router links (except stub) set to a metric of 0xFFFF . The stub router links are advertised with the actual cost of the interfaces corresponding to the stub. This causes the transit traffic to avoid the overloaded router and take paths around the router. However, the overloaded router's own links are still accessible.

To mark the router as overloaded, include the overload statement:

 [edit protocols ospf] overload; 

To specify the number of seconds at which overload is reset, include the timeout statement. The time can range from 60 through 1,800 seconds.

 [edit protocols ospf overload]  timeout  seconds  ; 
Enabling OSPF Traffic Engineering Support

For more information, see Chapter 11, "MPLS Applications," on page 519.

When traffic engineering is enabled on the router, you can enable OSPF's traffic engineering support, which allows OSPF to generate LSAs that carry traffic engineering parameters. These parameters are used to create the traffic engineering database (TED), which is used by CSPF to compute MPLS label-switched paths (LSPs). By default, the traffic engineering support is disabled. To enable it, include the traffic-engineering statement:

 [edit protocols ospf] traffic-engineering {   no-topology;   shortcuts; } 
Configuring OSPF Routing Policy

For more information on routing policy, see Chapter 8, "Routing Policy and Firewall Filters," on page 301.

For OSPF, you can apply routing policies that affect how the routing table exports routes into OSPF. To do this, include the export statement at the [edit protocols ospf] hierarchy level:

 [edit protocols ospf] export [  policy-names  ]; 

For OSPF, you should not apply routing policies that affect how routes are imported into the routing table; doing so with a link-state protocol could easily lead to an inconsistent topology database.

Configuring OSPF Routing Table Groups

To install routes learned from OSPF routing instances into routing tables in the OSPF routing table group, include the rib-group statement:

 [edit protocols ospf] rib-group  group-name  ; 
Trace OSPF Protocol Traffic

To trace OSPF protocol traffic, specify OSPF-specific options by including the traceoptions statement:

 [edit protocols ospf] traceoptions {   file  name  <replace> <size  size  > <files  number  > <no-stamp>     <(world-readable  no-world-readable)>;   flag  flag  <  flag-modifier  > <disable>; } 

For more information about tracing and global tracing options, see the JUNOS technical documentation.

You can specify the following OSPF-specific flags in the OSPF traceoptions statement:

  • all All OSPF information

  • database-description All database description packets

  • error OSPF errored packets

  • event OSPF state transitions

  • flooding Link-state flooding packets

  • general General events

  • hello Hello packets

  • lsa-ack Link-state acknowledgment packets

  • lsa-request Link-state request packets

  • lsa-update Link-state updates packets

  • normal Normal events

  • packets All OSPF packets

  • packet-dump Contents of selected packet types

  • policy Policy processing

  • spf Shortest-path-first (SPF) calculations

  • state State transitions

  • task Routing protocol task processing

  • timer Routing protocol timer processing



Juniper Networks Field Guide and Reference
Juniper Networks Field Guide and Reference
ISBN: 0321122445
EAN: 2147483647
Year: 2002
Pages: 185

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