Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Example: Configuring OSPF Overload Mode

    Understanding OSPF Overload Function

    If the time elapsed after the OSPF instance is enabled is less than the specified timeout, overload mode is set.

    You can configure the local routing device so that it appears to be overloaded. An overloaded routing device determines it is unable to handle any more OSPF transit traffic, which results in sending OSPF transit traffic to other routing devices. OSPF traffic to directly attached interfaces continues to reach the routing device. You might configure overload mode for many reasons, including:

    • If you want the routing device to participate in OSPF routing, but do not want it to be used for transit traffic. This could include a routing device that is connected to the network for analysis purposes, but is not considered part of the production network, such as network management routing devices.
    • If you are performing maintenance on a routing device in a production network. You can move traffic off that routing device so network services are not interrupted during your maintenance window.

    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 link-state advertisement (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 routing device and to take paths around the routing device. However, the overloaded routing device’s own links are still accessible.


    The routing device can also dynamically enter the overload state, regardless of configuring the device to appear overloaded. For example, if the routing device exceeds the configured OSPF prefix limit, the routing device purges the external prefixes and enters into an overload state.

    In cases of incorrect configurations, the huge number of routes might enter OSPF, which can hamper the network performance. To prevent this, prefix-export-limit should be configured which will purge externals and prevent the network from the bad impact.

    By allowing any number of routes to be exported into OSPF, the routing device can become overwhelmed and potentially flood an excessive number of routes into an area. You can limit the number of routes exported into OSPF to minimize the load on the routing device and prevent this potential problem.

    By default, there is no limit to the number of prefixes (routes) that can be exported into OSPF. To prevent this, prefix-export-limit should be configured which will purge externals and prevent the network.

    To limit the number of prefixes exported to OSPF:

    [edit]set protocols ospf prefix-export-limit number

    The prefix export limit number can be a value from 0 through 4,294,967,295.

    Example: Configuring OSPF to Make Routing Devices Appear Overloaded

    This example shows how to configure a routing device running OSPF to appear to be overloaded.

    Requirements

    Before you begin:

    Overview

    You can configure a local routing device running OSPF to appear to be overloaded, which allows the local routing device to participate in OSPF routing, but not for transit traffic. When configured, the transit interface metrics are set to the maximum value of 65535.

    This example includes the following settings:

    • overload—Configures the local routing device so it appears to be overloaded. You might configure this if you want the routing device to participate in OSPF routing, but do not want it to be used for transit traffic, or you are performing maintenance on a routing device in a production network.
    • timeout seconds—(Optional) Specifies the number of seconds at which the overload is reset. If no timeout interval is specified, the routing device remains in the overload state until the overload statement is deleted or a timeout is set. In this example, you configure 60 seconds as the amount of time the routing device remains in the overload state. By default, the timeout interval is 0 seconds (this value is not configured). The range is from 60 through 1800 seconds.

    Configuration

    CLI Quick Configuration

    To quickly configure a local routing device to appear as overloaded, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    [edit]set protocols ospf overload timeout 60

    Step-by-Step Procedure

    To configure a local routing device to appear overloaded:

    1. Enter OSPF configuration mode.

      Note: To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

      [edit]user@host# edit protocols ospf
    2. Configure the local routing device to be overloaded.
      [edit protocols ospf]user@host# set overload
    3. (Optional) Configure the number of seconds at which overload is reset.
      [edit protocols ospf]user@host# set overload timeout 60
    4. (Optional) Configure the limit on the number prefixes exported to OSPF, to minimise the load on the routing device and prevent the device from entering the overload mode.
      [edit protocols ospf]user@host# set prefix-export-limit 50
    5. If you are done configuring the device, commit the configuration.
      [edit protocols ospf]user@host# commit

    Results

    Confirm your configuration by entering the show protocols ospf command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration. The output includes the optional timeout and prefix-export-limit statements.

    user@host# show protocols ospf
    prefix-export-limit 50;
    overload timeout 60;

    To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.

    Verification

    Confirm that the configuration is working properly.

    Verifying Traffic Has Moved Off Devices

    Purpose

    Verify that the traffic has moved off the upstream devices.

    Action

    From operational mode, enter the show interfaces detail command.

    Verifying Transit Interface Metrics

    Purpose

    Verify that the transit interface metrics are set to the maximum value of 65535 on the downstream neighboring device.

    Action

    From operational mode, enter the show ospf database router detail advertising-router address command for OSPFv2, and enter the show ospf3 database router detail advertising-router address command for OSPFv3.

    Verifying the Overload Configuration

    Purpose

    Verify that overload is configured by reviewing the Configured overload field. If the overload timer is also configured, this field also displays the time that remains before it is set to expire.

    Action

    From operational mode, enter the show ospf overview command for OSPFv2, and the show ospf3 overview command for OSPFv3.

    Verifying the Viable Next Hop

    Purpose

    Verify the viable next hop configuration on the upstream neighboring device. If the neighboring device is overloaded, it is not used for transit traffic and is not displayed in the output.

    Action

    From operational mode, enter the show route address command.

    Modified: 2016-12-06