ServerIron ADX Switch and Router Guide
12.0.00
June 10, 2009

Table of Contents Previous Next Print


Configuring OSPF > Configuring OSPF

Configuring OSPF
To begin using OSPF on the router, perform the steps outlined below:
1.
2.
3.
4.
5.
6.
7.
NOTE: OSPF is automatically enabled without a system reset.
Configuration Rules
All router ports must be assigned to one of the defined areas on an OSPF router. When a port is assigned to an area, all corresponding subnets on that port are automatically included in the assignment.
OSPF Parameters
You can modify or set the following global and interface OSPF parameters.
Global Parameters
Interface Parameters
NOTE: When using the CLI, you set global level parameters at the OSPF CONFIG Level of the CLI. To reach that level, enter router ospf… at the global CONFIG Level. Interface parameters for OSPF are set at the interface CONFIG Level using the CLI command, ip ospf…

When using the Web management interface, you set OSPF global parameters using the OSPF configuration panel. All other parameters are accessed through links accessed from the OSPF configuration sheet.
Enable OSPF on the Router
When you enable OSPF on the router, the protocol is automatically activated. To enable OSPF on the router, use the following method:
ServerIron(config)# router ospf
This command launches you into the OSPF router level where you can assign areas and modify OSPF global parameters.
Note Regarding Disabling OSPF
If you disable OSPF, the Layer 3 Switch removes all the configuration information for the disabled protocol from the running-config. Moreover, when you save the configuration to the startup-config file after disabling one of these protocols, all the configuration information for the disabled protocol is removed from the startup-config file.
The CLI displays a warning message such as the following:
ServerIron(config-ospf-router)# no router ospf
router ospf mode now disabled. All ospf config data will be lost when writing to flash!
If you have disabled the protocol but have not yet saved the configuration to the startup-config file and reloaded the software, you can restore the configuration information by re-entering the command to enable the protocol (ex: router ospf), or by selecting the Web management option to enable the protocol. If you have already saved the configuration to the startup-config file and reloaded the software, the information is gone.
If you are testing an OSPF configuration and are likely to disable and re-enable the protocol, you might want to make a backup copy of the startup-config file containing the protocol’s configuration information. This way, if you remove the configuration information by saving the configuration after disabling the protocol, you can restore the configuration by copying the backup copy of the startup-config file onto the flash memory.
Assign OSPF Areas
Once OSPF is enabled on the system, you can assign areas. Assign an IP address or number as the area ID for each area. The area ID is representative of all IP addresses (subnets) on a router port. Each port on a router can support one area.
An area can be normal, a stub, or a Not-So-Stubby Area (NSSA).
Normal – OSPF routers within a normal area can send and receive External Link State Advertisements (LSAs).
Stub – OSPF routers within a stub area cannot send or receive External LSAs. In addition, OSPF routers in a stub area must use a default route to the area’s Area Border Router (ABR) or Autonomous System Boundary Router (ASBR) to send traffic out of the area.
NSSA – The ASBR of an NSSA can import external route information into the area.
ASBRs redistribute (import) external routes into the NSSA as type 7 LSAs. Type-7 External LSAs are a special type of LSA generated only by ASBRs within an NSSA, and are flooded to all the routers within only that NSSA.
ABRs translate type 7 LSAs into type 5 External LSAs, which can then be flooded throughout the AS. You can configure address ranges on the ABR of an NSSA so that the ABR converts multiple type-7 External LSAs received from the NSSA into a single type-5 External LSA.

When an NSSA contains more than one ABR, OSPF elects one of the ABRs to perform the LSA translation for NSSA. OSPF elects the ABR with the highest router ID. If the elected ABR becomes unavailable, OSPF automatically elects the ABR with the next highest router ID to take over translation of LSAs for the NSSA. The election process for NSSA ABRs is automatic.
EXAMPLE: 
To set up the OSPF areas shown in Figure 11.1, use the following method.
ServerIron(config-ospf-router)# area 192.5.1.0
ServerIron(config-ospf-router)# area 200.5.0.0
ServerIron(config-ospf-router)# area 195.5.0.0
ServerIron(config-ospf-router)# area 0.0.0.0
ServerIron(config-ospf-router) write memory
Syntax: area <num> | <ip-addr>
The <num> | <ip-addr> parameter specifies the area number, which can be a number or in IP address format. If you specify an number, the number can be from 0 – 2,147,483,647.
NOTE: You can assign one area on a router interface. For example, if the system or chassis module has 16 ports, 16 areas are supported on the chassis or module.
Assign a Totally Stubby Area
By default, the Layer 3 Switch sends summary LSAs (LSA type 3) into stub areas. You can further reduce the number of link state advertisements (LSA) sent into a stub area by configuring the Layer 3 Switch to stop sending summary LSAs (type 3 LSAs) into the area. You can disable the summary LSAs when you are configuring the stub area or later after you have configured the area.
This feature disables origination of summary LSAs, but the Layer 3 Switch still accepts summary LSAs from OSPF neighbors and floods them to other neighbors. The Layer 3 Switch can form adjacencies with other routers regardless of whether summarization is enabled or disabled for areas on each router.
When you enter a command or apply a Web management option to disable the summary LSAs, the change takes effect immediately. If you apply the option to a previously configured area, the Layer 3 Switch flushes all of the summary LSAs it has generated (as an ABR) from the area.
NOTE: This feature applies only when the Layer 3 Switch is configured as an Area Border Router (ABR) for the area. To completely prevent summary LSAs from being sent to the area, disable the summary LSAs on each OSPF router that is an ABR for the area.

This feature does not apply to Not So Stubby Areas (NSSAs).
To disable summary LSAs for a stub area, enter commands such as the following:
ServerIron(config-ospf-router)# area 40 stub 99 no-summary
Syntax: area <num> | <ip-addr> stub <cost> [no-summary]
The <num> | <ip-addr> parameter specifies the area number, which can be a number or in IP address format. If you specify a number, the number can be from 0 – 2,147,483,647.
The stub <cost> parameter specifies an additional cost for using a route to or from this area and can be from 1 – 16777215. There is no default. Normal areas do not use the cost parameter.
The no-summary parameter applies only to stub areas and disables summary LSAs from being sent into the area.
NOTE: You can assign one area on a router interface. For example, if the system or chassis module has 16 ports, 16 areas are supported on the chassis or module.
Assign a Not-So-Stubby Area (NSSA)
The OSPF Not So Stubby Area (NSSA) feature enables you to configure OSPF areas that provide the benefits of stub areas, but that also are capable of importing external route information. OSPF does not flood external routes from other areas into an NSSA, but does translate and flood route information from the NSSA into other areas such as the backbone.
NSSAs are especially useful when you want to summarize Type-5 External LSAs (external routes) before forwarding them into an OSPF area. The OSPF specification (RFC 2328) prohibits summarization of Type-5 LSAs and requires OSPF to flood Type-5 LSAs throughout a routing domain. When you configure an NSSA, you can specify an address range for aggregating the external routes that the NSSA's ABR exports into other areas.
The Brocade implementation of NSSA is based on RFC 1587.
Figure 11.5 shows an example of an OSPF network containing an NSSA.
Figure 11.5
This example shows two routing domains, a RIP domain and an OSPF domain. The ASBR inside the NSSA imports external routes from RIP into the NSSA as Type-7 LSAs, which the ASBR floods throughout the NSSA.
The ABR translates the Type-7 LSAs into Type-5 LSAs. If an area range is configured for the NSSA, the ABR also summarizes the LSAs into an aggregate LSA before flooding the Type-5 LSA(s) into the backbone.
Since the NSSA is partially “stubby” the ABR does not flood external LSAs from the backbone into the NSSA. To provide access to the rest of the Autonomous System (AS), the ABR generates a default Type-7 LSA into the NSSA.
Configuring an NSSA
To configure OSPF area 1.1.1.1 as an NSSA, enter the following commands.
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# area 1.1.1.1 nssa 1
ServerIron(config-ospf-router)# write memory
Syntax: area <num> | <ip-addr> nssa <cost> | default-information-originate
The <num> | <ip-addr> parameter specifies the area number, which can be a number or in IP address format. If you specify an number, the number can be from 0 – 2,147,483,647.
The nssa <cost> | default-information-originate parameter specifies that this is a Not-So-Stubby-Area (NSSA). The <cost> specifies an additional cost for using a route to or from this NSSA and can be from 1 – 16777215. There is no default. Normal areas do not use the cost parameter. Alternatively, you can use the default-information-originate parameter causes the Layer 3 Switch to inject the default route into the NSSA.
NOTE: The Layer 3 Switch does not inject the default route into an NSSA by default.
NOTE: You can assign one area on a router interface. For example, if the system or chassis module has 16 ports, 16 areas are supported on the chassis or module.
To configure additional parameters for OSPF interfaces in the NSSA, use the ip ospf area… command at the interface level of the CLI.
Configuring an Address Range for the NSSA
If you want the ABR that connects the NSSA to other areas to summarize the routes in the NSSA before translating them into Type-5 LSAs and flooding them into the other areas, configure an address range. The ABR creates an aggregate value based on the address range. The aggregate value becomes the address that the ABR advertises instead of advertising the individual addresses represented by the aggregate. You can configure up to 32 ranges in an OSPF area.
To configure an address range in NSSA 1.1.1.1, enter the following commands. This example assumes that you have already configured NSSA 1.1.1.1.
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# area 1.1.1.1 range 209.157.22.1 255.255.0.0
ServerIron(config-ospf-router)# write memory
Syntax: [no] area <num> | <ip-addr> range <ip-addr> <ip-mask> [advertise | not-advertise]
The <num> | <ip-addr> parameter specifies the area number, which can be in IP address format. If you specify a number, the number can be from 0 – 2,147,483,647.
The range <ip-addr> parameter specifies the IP address portion of the range. The software compares the address with the significant bits in the mask. All network addresses that match this comparison are summarized in a single route advertised by the router.
The <ip-mask> parameter specifies the portions of the IP address that a route must contain to be summarized in the summary route. In the example above, all networks that begin with 209.157 are summarized into a single route.
The advertise | not-advertise parameter specifies whether you want the Layer 3 Switch to send type 3 LSAs for the specified range in this area. The default is advertise.
Assigning an Area Range (optional)
You can assign a range for an area, but it is not required. Ranges allow a specific IP address and mask to represent a range of IP addresses within an area, so that only that reference range address is advertised to the network, instead of all the addresses within that range. Each area can have up to 32 range addresses.
EXAMPLE: 
To define an area range for subnets on 193.45.5.1 and 193.45.6.2, enter the following command:
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# area 192.45.5.1 range 193.45.0.0 255.255.0.0
ServerIron(config-ospf-router)# area 193.45.6.2 range 193.45.0.0 255.255.0.0
Syntax: area <num> | <ip-addr> range <ip-addr> <ip-mask>
The <num> | <ip-addr> parameter specifies the area number, which can be in IP address format.
The range <ip-addr> parameter specifies the IP address portion of the range. The software compares the address with the significant bits in the mask. All network addresses that match this comparison are summarized in a single route advertised by the router.
The <ip-mask> parameter specifies the portions of the IP address that a route must contain to be summarized in the summary route. In the example above, all networks that begin with 193.45 are summarized into a single route.
Assigning Interfaces to an Area
Once you define OSPF areas, you can assign interfaces the areas. All router ports must be assigned to one of the defined areas on an OSPF router. When a port is assigned to an area, all corresponding subnets on that port are automatically included in the assignment.
To assign interface 1/8 of Router A to area 192.5.0.0 and then save the changes, enter the following commands:
RouterA(config-ospf-router)# interface e 1/8
RouterA(config-if-1/8)# ip ospf area 192.5.0.0
RouterA(config-if-1/8)# write memory
Modify Interface Defaults
OSPF has interface parameters that you can configure. For simplicity, each of these parameters has a default value. No change to these default values is required except as needed for specific network configurations.
Port default values can be modified using the following CLI commands at the interface configuration level of the CLI:
For a complete description of these parameters, see the summary of OSPF port parameters in the next section.
OSPF Interface Parameters
The following parameters apply to OSPF interfaces.
Area: Assigns an interface to a specific area. You can assign either an IP address or number to represent an OSPF Area ID. If you assign a number, it can be any value from 0 – 2,147,483,647.
Auth-change-wait-time: OSPF gracefully implements authentication changes to allow all routers to implement the change and thus prevent disruption to neighbor adjacencies. During the authentication-change interval, both the old and new authentication information is supported. The default authentication-change interval is 300 seconds (5 minutes). You change the interval to a value from 0 – 14400 seconds.
Authentication-key: OSPF supports three methods of authentication for each interface—none, simple password, and MD5. Only one method of authentication can be active on an interface at a time. The default authentication value is none, meaning no authentication is performed.
The simple password method of authentication requires you to configure an alphanumeric password on an interface. The simple password setting takes effect immediately. All OSPF packets transmitted on the interface contain this password. Any OSPF packet received on the interface is checked for this password. If the password is not present, then the packet is dropped. The password can be up to eight characters long.
The MD5 method of authentication requires you to configure a key ID and an MD5 Key. The key ID is a number from 1 – 255 and identifies the MD5 key that is being used. The MD5 key can be up to sixteen alphanumeric characters long.
Cost: Indicates the overhead required to send a packet across an interface. You can modify the cost to differentiate between 100 Mbps and 1000 Mbps (1 Gbps) links. The default cost is calculated by dividing 100 million by the bandwidth. For 10 Mbps links, the cost is 10. The cost for both 100 Mbps and 1000 Mbps links is 1, because the speed of 1000 Mbps was not in use at the time the OSPF cost formula was devised.
Dead-interval: Indicates the number of seconds that a neighbor router waits for a hello packet from the current router before declaring the router down. The value can be from 1 – 65535 seconds. The default is 40 seconds.
Hello-interval: Represents the length of time between the transmission of hello packets. The value can be
from 1 – 65535 seconds. The default is 10 seconds.
MD5-authentication activation wait time: The number of seconds the Layer 3 Switch waits until placing a new MD5 key into effect. The wait time provides a way to gracefully transition from one MD5 key to another without disturbing the network. The wait time can be from 0 – 14400 seconds. The default is 300 seconds (5 minutes).
MD5-authentication key ID and key: A method of authentication that requires you to configure a key ID and an MD5 key. The key ID is a number from 1 – 255 and identifies the MD5 key that is being used. The MD5 key consists of up to 16 alphanumeric characters. The MD5 is encrypted and included in each OSPF packet transmitted.
Passive: When you configure an OSPF interface to be passive, that interface does not send or receive OSPF route updates. By default, all OSPF interfaces are active and thus can send and receive OSPF route information. Since a passive interface does not send or receive route information, the interface is in effect a stub network. OSPF interfaces are active by default.
NOTE: This option affects all IP subnets configured on the interface. If you want to disable OSPF updates only on some of the IP subnets on the interface, use the ospf-ignore or ospf-passive parameter with the ip address command. See “Assigning an IP Address to an Ethernet Port”.
Priority: Allows you to modify the priority of an OSPF router. The priority is used when selecting the designated router (DR) and backup designated routers (BDRs). The value can be from 0 – 255. The default is 1. If you set the priority to 0, the Layer 3 Switch does not participate in DR and BDR election.
Retransmit-interval: The time between retransmissions of link-state advertisements (LSAs) to adjacent routers for this interface. The value can be from 0 – 3600 seconds. The default is 5 seconds.
Transit-delay: The time it takes to transmit Link State Update packets on this interface. The value can be from
0 – 3600 seconds. The default is 1 second.
Encrypted Display of the Authentication String or MD5 Authentication Key
The optional 0 | 1 parameter with the authentication-key and md5-authentication key-id parameters affects encryption.
For added security display of the password or authentication string is encrypted. Encryption is enabled by default. The software also provides an optional parameter to disable encryption of a password or authentication string, on an individual OSPF area or OSPF interface basis.
When encryption of the passwords or authentication strings is enabled, they are encrypted in the CLI regardless of the access level you are using. In the Web management interface, the passwords or authentication strings are encrypted at the read-only access level but are visible at the read-write access level.
The encryption option can be omitted (the default) or can be one of the following.
0 – Disables encryption for the password or authentication string you specify with the command. The password or string is shown as clear text in the running-config and the startup-config file. Use this option of you do not want display of the password or string to be encrypted.
1 – Assumes that the password or authentication string you enter is the encrypted form, and decrypts the value before using it.
NOTE: If you want the software to assume that the value you enter is the clear-text form, and to encrypt display of that form, do not enter 0 or 1. Instead, omit the encryption option and allow the software to use the default behavior.

If you specify encryption option 1, the software assumes that you are entering the encrypted form of the password or authentication string. In this case, the software decrypts the password or string you enter before using the value for authentication. If you accidentally enter option 1 followed by the clear-text version of the password or string, authentication will fail because the value used by the software will not match the value you intended to use.
Change the Timer for OSPF Authentication Changes
When you make an OSPF authentication change, the software uses the authentication-change timer to gracefully implement the change. The software implements the change in the following ways:
Outgoing OSPF packets – After you make the change, the software continues to use the old authentication to send packets, during the remainder of the current authentication-change interval. After this, the software uses the new authentication for sending packets.
Inbound OSPF packets – The software accepts packets containing the new authentication and continues to accept packets containing the older authentication for two authentication-change intervals. After the second interval ends, the software accepts packets only if they contain the new authentication key.
The default authentication-change interval is 300 seconds (5 minutes). You change the interval to a value from 0 – 14400 seconds.
OSPF provides graceful authentication change for all the following types of authentication changes in OSPF:
To change the authentication-change interval, enter a command such as the following at the interface configuration level of the CLI:
ServerIron(config-if-2/5)# ip ospf auth-change-wait-time 400
Syntax: [no] ip ospf auth-change-wait-time <secs>
The <secs> parameter specifies the interval and can be from 0 – 14400 seconds. The default is 300 seconds (5 minutes).
NOTE: For backward compatibility, the ip ospf md5-authentication key-activation-wait-time <seconds> command is still supported.
Block Flooding of Outbound LSAs on Specific OSPF Interfaces
By default, the Layer 3 Switch floods all outbound LSAs on all the OSPF interfaces within an area. You can configure a filter to block outbound LSAs on an OSPF interface. This feature is particularly useful when you want to block LSAs from some, but not all, of the interfaces attached to the area.
After you apply filters to block the outbound LSAs, the filtering occurs during the database synchronization and flooding.
If you remove the filters, the blocked LSAs are automatically re-flooded. You do not need to reset OSPF to re-flood the LSAs.
NOTE: You cannot block LSAs on virtual links.
To apply a filter to an OSPF interface to block flooding of outbound LSAs on the interface, enter the following command at the Interface configuration level for that interface.
ServerIron(config-if-1/1)# ip ospf database-filter all out
The command in this example blocks all outbound LSAs on the OSPF interface configured on port 1/1.
Syntax: [no] ip ospf database-filter all out
To remove the filter, enter a command such as the following:
ServerIron(config-if-1/1)# no ip ospf database-filter all out
Assign Virtual Links
All ABRs (area border routers) must have either a direct or indirect link to the OSPF backbone area (0.0.0.0 or 0). If an ABR does not have a physical link to the area backbone, the ABR can configure a virtual link to another router within the same area, which has a physical connection to the area backbone.
The path for a virtual link is through an area shared by the neighbor ABR (router with a physical backbone connection), and the ABR requiring a logical connection to the backbone.
Two parameters fields must be defined for all virtual links—transit area ID and neighbor router.
The transit area ID represents the shared area of the two ABRs and serves as the connection point between the two routers. This number should match the area ID value.
The neighbor router field is the router ID (IP address) of the router that is physically connected to the backbone, when assigned from the router interface requiring a logical connection. When assigning the parameters from the router with the physical connection, the router ID is the IP address of the router requiring a logical connection to the backbone.
NOTE: By default, the Brocade router ID is the IP address configured on the lowest numbered loopback interface. If the Layer 3 Switch does not have a loopback interface, the default router ID is the lowest numbered IP address configured on the device. For more information or to change the router ID, see “Changing the Router ID”.
NOTE: When you establish an area virtual link, you must configure it on both of the routers (both ends of the virtual link).
Figure 11.6
EXAMPLE: 
Figure 11.6 shows an OSPF area border router, RouterA, that is cut off from the backbone area (area 0). To provide backbone access to RouterA, you can add a virtual link between RouterA and RouterC using area 1 as a transit area. To configure the virtual link, you define the link on the router that is at each end of the link. No configuration for the virtual link is required on the routers in the transit area.
To define the virtual link on RouterA, enter the following commands:
RouterA(config-ospf-router)# area 1 virtual-link 209.157.22.1
RouterA(config-ospf-router)# write memory
Enter the following commands to configure the virtual link on RouterC:
RouterC(config-ospf-router)# area 1 virtual-link 10.0.0.1
RouterC(config-ospf-router)# write memory
Syntax: area <ip-addr> | <num> virtual-link <router-id>
[authentication-key | dead-interval | hello-interval | retransmit-interval | transmit-delay <value>]
The area <ip-addr> | <num> parameter specifies the transit area.
The <router-id> parameter specifies the router ID of the OSPF router at the remote end of the virtual link. To display the router ID on a Brocade Layer 3 Switch, enter the show ip command.
See “Modify Virtual Link Parameters” for descriptions of the optional parameters.
Modify Virtual Link Parameters
OSPF has some parameters that you can modify for virtual links. Notice that these are the same parameters as the ones you can modify for physical interfaces.
You can modify default values for virtual links using the following CLI command at the OSPF router level of the CLI, as shown in the following syntax:
Syntax: area <num> | <ip-addr> virtual-link <ip-addr> [authentication-key [0 | 1] <string>] [dead-interval <num>]
[hello-interval <num>] [md5-authentication key-activation-wait-time <num> | key-id <num> [0 | 1] key <string>]
[retransmit-interval <num>] [transmit-delay <num>]
Virtual Link Parameter Descriptions
You can modify the following virtual link interface parameters:
Authentication Key: This parameter allows you to assign different authentication methods on a port-by-port basis. OSPF supports three methods of authentication for each interface—none, simple password, and MD5. Only one method of authentication can be active on an interface at a time.
The simple password method of authentication requires you to configure an alphanumeric password on an interface. The password can be up to eight characters long. The simple password setting takes effect immediately. All OSPF packets transmitted on the interface contain this password. All OSPF packets received on the interface are checked for this password. If the password is not present, then the packet is dropped.
The MD5 method of authentication encrypts the authentication key you define. The authentication is included in each OSPF packet transmitted.
MD5 Authentication Key: When simple authentication is enabled, the key is an alphanumeric password of up to eight characters. When MD5 is enabled, the key is an alphanumeric password of up to 16 characters that is later encrypted and included in each OSPF packet transmitted. You must enter a password in this field when the system is configured to operate with either simple or MD5 authentication.
MD5 Authentication Key ID: The Key ID is a number from 1 – 255 and identifies the MD5 key that is being used. This parameter is required to differentiate among multiple keys defined on a router.
MD5 Authentication Wait Time: This parameter determines when a newly configured MD5 authentication key is valid. This parameter provides a graceful transition from one MD5 key to another without disturbing the network. All new packets transmitted after the key activation wait time interval use the newly configured MD5 Key. OSPF packets that contain the old MD5 key are accepted for up to five minutes after the new MD5 key is in operation.
The range for the key activation wait time is from 0 – 14400 seconds. The default value is 300 seconds.
Hello Interval: The length of time between the transmission of hello packets. The range is 1 – 65535 seconds. The default is 10 seconds.
Retransmit Interval: The interval between the re-transmission of link state advertisements to router adjacencies for this interface. The range is 0 – 3600 seconds. The default is 5 seconds.
Transmit Delay: The period of time it takes to transmit Link State Update packets on the interface. The range is 0 – 3600 seconds. The default is 1 second.
Dead Interval: The number of seconds that a neighbor router waits for a hello packet from the current router before declaring the router down. The range is 1 – 65535 seconds. The default is 40 seconds.
Encrypted Display of the Authentication String or MD5 Authentication Key
The optional 0 | 1 parameter with the authentication-key and md5-authentication key-id parameters affects encryption.
For added security, the display of the password or authentication string is encrypted. Encryption is enabled by default. The software also provides an optional parameter to disable encryption of a password or authentication string, on an individual OSPF area or OSPF interface basis.
When encryption of the passwords or authentication strings is enabled, they are encrypted in the CLI regardless of the access level you are using. In the Web management interface, the passwords or authentication strings are encrypted at the read-only access level but are visible at the read-write access level.
The encryption option can be omitted (the default) or can be one of the following.
0 – Disables encryption for the password or authentication string you specify with the command. The password or string is shown as clear text in the running-config and the startup-config file. Use this option of you do not want display of the password or string to be encrypted.
1 – Assumes that the password or authentication string you enter is the encrypted form, and decrypts the value before using it.
NOTE: If you want the software to assume that the value you enter is the clear-text form, and to encrypt display of that form, do not enter 0 or 1. Instead, omit the encryption option and allow the software to use the default behavior.

If you specify encryption option 1, the software assumes that you are entering the encrypted form of the password or authentication string. In this case, the software decrypts the password or string you enter before using the value for authentication. If you accidentally enter option 1 followed by the clear-text version of the password or string, authentication will fail because the value used by the software will not match the value you intended to use.
Changing the Reference Bandwidth for the Cost on OSPF Interfaces
Each interface on which OSPF is enabled has a cost associated with it. The Layer 3 Switch advertises its interfaces and their costs to OSPF neighbors. For example, if an interface has an OSPF cost of ten, the Layer 3 Switch advertises the interface with a cost of ten to other OSPF routers.
By default, an interface’s OSPF cost is based on the port speed of the interface. The cost is calculated by dividing the reference bandwidth by the port speed. The default reference bandwidth is 100 Mbps, which results in the following default costs:
You can change the reference bandwidth, to change the costs calculated by the software.
The software uses the following formula to calculate the cost:
Cost = reference-bandwidth/interface-speed
If the resulting cost is less than 1, the software rounds the cost up to 1. The default reference bandwidth results in the following costs:
The bandwidth for interfaces that consist of more than one physical port is calculated as follows:
Trunk group – The combined bandwidth of all the ports.
Virtual interface – The combined bandwidth of all the ports in the port-based VLAN that contains the virtual interface.
The default reference bandwidth is 100 Mbps. You can change the reference bandwidth to a value from 1 – 4294967.
If a change to the reference bandwidth results in a cost change to an interface, the Layer 3 Switch sends a link-state update to update the costs of interfaces advertised by the Layer 3 Switch.
NOTE: If you specify the cost for an individual interface, the cost you specify overrides the cost calculated by the software.
Interface Types To Which the Reference Bandwidth Does Not Apply
Some interface types are not affected by the reference bandwidth and always have the same cost regardless of the reference bandwidth in use:
Changing the Reference Bandwidth
To change reference bandwidth, use the following CLI method.
To change the reference bandwidth, enter a command such as the following at the OSPF configuration level of the CLI:
ServerIron(config-ospf-router)# auto-cost reference-bandwidth 500
The reference bandwidth specified in this example results in the following costs:
The costs for 10 Mbps, 100 Mbps, and 155 Mbps ports change as a result of the changed reference bandwidth. Costs for higher-speed interfaces remain the same.
Syntax: [no] auto-cost reference-bandwidth <num>
The <num> parameter specifies the reference bandwidth and can be a value from 1 – 4294967. The default is 100, which results in the same costs as previous software releases.
To restore the reference bandwidth to its default value and thus restore the default costs of interfaces to their default values, enter the following command:
ServerIron(config-ospf-router)# no auto-cost reference-bandwidth
Define Redistribution Filters
Route redistribution imports and translates different protocol routes into a specified protocol type. On Brocade routers, redistribution is supported for static routes, OSPF, RIP, and BGP4. When you configure redistribution for RIP, you can specify that static, OSPF, or BGP4 routes are imported into RIP routes. Likewise, OSPF redistribution supports the import of static, RIP, and BGP4 routes into OSPF routes. BGP4 supports redistribution of static, RIP, and OSPF routes into BGP4.
NOTE: The Layer 3 Switch advertises the default route into OSPF even if redistribution is not enabled, and even if the default route is learned through an IBGP neighbor. IBGP routes (including the default route) are not redistributed into OSPF by OSPF redistribution (for example, by the OSPF redistribute command).
In Figure 11.7, an administrator wants to configure the Layer 3 Switch acting as the ASBR (Autonomous System Boundary Router) between the RIP domain and the OSPF domain to redistribute routes between the two domains.
NOTE: The ASBR must be running both RIP and OSPF protocols to support this activity.
To configure for redistribution, define the redistribution tables with deny and permit redistribution filters.
If you are using the CLI, use the deny and permit redistribute commands for OSPF at the OSPF router level.
If you are using the Web management interface, click on the plus sign next to Configure in the tree view, click on the plus sign next to OSPF, then select the Redistribution Filter link from the OSPF configuration sheet.
NOTE: Do not enable redistribution until you have configured the redistribution filters. If you enable redistribution before you configure the redistribution filters, the filters will not take affect and all routes will be distributed.
Figure 11.7
EXAMPLE: 
To configure the Layer 3 Switch acting as an ASBR in Figure 11.7 to redistribute OSPF, BGP4, and static routes into RIP, enter the following commands:
ServerIronASBR(config)# router rip
ServerIronASBR(config-rip-router)# permit redistribute 1 all
ServerIronASBR(config-rip-router)# write memory
NOTE: Redistribution is permitted for all routes by default, so the permit redistribute 1 all command in the example above is shown for clarity but is not required.
You also have the option of specifying import of just OSPF, BGP4, or static routes, as well as specifying that only routes for a specific network or with a specific cost (metric) be imported, as shown in the command syntax below:
Syntax: deny | permit redistribute <filter-num> all | bgp | connected | rip | static
[address <ip-addr> <ip-mask> [match-metric <value> [set-metric <value>]]]
EXAMPLE: 
To redistribute RIP and static routes into OSPF, enter the following commands on the Layer 3 Switch acting as an ASBR:
ServerIronASBR(config)# router ospf
ServerIronASBR(config-ospf-router)# permit redistribute 1 all
ServerIronASBR(config-ospf-router)# write memory
Syntax: deny | permit redistribute <filter-num> all | connected | rip | static
address <ip-addr> <ip-mask>
[match-metric <value> | set-metric <value>]
NOTE: Redistribution is permitted for all routes by default, so the permit redistribute 1 all command in the example above is shown for clarity but is not required.
You also have the option of specifying import of just OSPF or static routes, as well as specifying that only routes for a specific network or with a specific cost (metric) be imported, as shown in the command syntax below:
Syntax: [no] redistribution connected | rip | static [route-map <map-name>]
For example, to enable redistribution of RIP and static IP routes into OSPF, enter the following commands.
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# redistribution rip
ServerIron(config-ospf-router)# redistribution static
ServerIron(config-ospf-router)# write memory
NOTE: The redistribution command does not perform the same function as the permit redistribute and deny redistribute commands. The redistribute commands allow you to control redistribution of routes by filtering on the IP address and network mask of a route. The redistribution commands enable redistribution for routes of specific types (static, directly connected, and so on). Configure all your redistribution filters before enabling redistribution.
NOTE: Do not enable redistribution until you have configured the redistribution filters. If you enable redistribution before you configure the redistribution filters, the filters will not take affect and all routes will be distributed.
Prevent Specific OSPF Routes from Being Installed in the IP Route Table
By default, all OSPF routes in the OSPF route table are eligible for installation in the IP route table. You can configure a distribution list to explicitly deny specific routes from being eligible for installation in the IP route table.
NOTE: This feature does not block receipt of LSAs for the denied routes. The Layer 3 Switch still receives the routes and installs them in the OSPF database. The feature only prevents the software from installing the denied OSPF routes into the IP route table.
To configure an OSPF distribution list:
Configure a standard or extended ACL that identifies the routes you want to deny. Using a standard ACL lets you deny routes based on the destination network, but does not filter based on the network mask. To also filter based on the destination network’s network mask, use an extended ACL.
NOTE: If you change the ACL after you configure the OSPF distribution list, you must clear the IP route table to place the changed ACL into effect. To clear the IP route table, enter the clear ip route command at the Privileged EXEC level of the CLI.
The following sections show how to use the CLI to configure an OSPF distribution list. Separate examples are provided for standard and extended ACLs.
NOTE: The examples show named ACLs. However, you also can use a numbered ACL as input to the OSPF distribution list.
Using a Standard ACL as Input to the Distribution List
To use a standard ACL to configure an OSPF distribution list for denying specific routes, enter commands such as the following:
ServerIron(config)# ip access-list standard no_ip
ServerIron(config-std-nacl)# deny 4.0.0.0 0.255.255.255
ServerIron(config-std-nacl)# permit any any
ServerIron(config-std-nacl)# exit
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# distribute-list no_ip in
The first three commands configure a standard ACL that denies routes to any 4.x.x.x destination network and allows all other routes for eligibility to be installed in the IP route table. The last three commands change the CLI to the OSPF configuration level and configure an OSPF distribution list that uses the ACL as input. The distribution list prevents routes to any 4.x.x.x destination network from entering the IP route table. The distribution list does not prevent the routes from entering the OSPF database.
Syntax: [no] distribute-list <acl-name> | <acl-id> in [<interface type>] [<interface number>]
Syntax: [no] ip access-list standard <acl-name> | <acl-id>
Syntax: deny | permit <source-ip> <wildcard>
The <acl-name> | <acl-id> parameter specifies the ACL name or ID.
The in command applies the ACL to incoming route updates.
The <interface type> parameter identifies the interface type (i.e., e (ethernet) or ve (virtual)) on which to apply the ACL.
The <interface number> parameter specifies the interface number on which to apply the ACL. Enter only one valid interface number. If necessary, use the show interface brief command to display a list of valid interfaces. If you do not specify an interface, the Brocade device applies the ACL to all incoming route updates.
If you do not specify an interface type and interface number, the device applies the OSPF distribution list to all incoming route updates.
The deny | permit parameter indicates whether packets that match the policy are dropped or forwarded.
The <source-ip> parameter specifies the source address for the policy. Since this ACL is input to an OSPF distribution list, the <source-ip> parameter actually is specifying the destination network of the route.
The <wildcard> parameter specifies the portion of the source address to match against. The <wildcard> is a four-part value in dotted-decimal notation (IP address format) consisting of ones and zeros. Zeros in the mask mean the packet’s source address must match the <source-ip>. Ones mean any value matches. For example, the <source-ip> and <wildcard> values 4.0.0.0 0.255.255.255 mean that all 4.x.x.x networks match the ACL.
If you want the policy to match on all destination networks, enter any any.
If you prefer to specify the wildcard (mask value) in Classless Interdomain Routing (CIDR) format, you can enter a forward slash after the IP address, then enter the number of significant bits in the mask. For example, you can enter the CIDR equivalent of “4.0.0.0 0.255.255.255” as “4.0.0.0/8”. The CLI automatically converts the CIDR number into the appropriate ACL mask (where zeros instead of ones are the significant bits) and changes the non-significant portion of the IP address into zeros.
NOTE: If you enable the software to display IP subnet masks in CIDR format, the mask is saved in the file in
“/<mask-bits>” format. To enable the software to display the CIDR masks, enter the ip show-subnet-length command at the global CONFIG level of the CLI. You can use the CIDR format to configure the ACL entry regardless of whether the software is configured to display the masks in CIDR format.

If you use the CIDR format, the ACL entries appear in this format in the running-config and startup-config files, but are shown with subnet mask in the display produced by the show ip access-list command.
Using an Extended ACL as Input to the Distribution List
To use an extended ACL to configure an OSPF distribution list for denying specific routes, enter commands such as the following:
The first three commands configure an extended ACL that denies routes to any 4.x.x.x destination network with a 255.255.0.0 network mask and allows all other routes for eligibility to be installed in the IP route table. The last three commands change the CLI to the OSPF configuration level and configure an OSPF distribution list that uses the ACL as input. The distribution list prevents routes to any 4.x.x.x destination network with network mask 255.255.0.0 from entering the IP route table. The distribution list does not prevent the routes from entering the OSPF database.
Syntax: [no] ip access-list extended <acl-name> | <acl-id>
Syntax: deny | permit <ip-protocol> <source-ip> <wildcard> <destination-ip> <wildcard>
The <acl-name> | <acl-id> parameter specifies the ACL name or ID.
The deny | permit parameter indicates whether packets that match the policy are dropped or forwarded.
The <ip-protocol> parameter indicates the type of IP packet you are filtering. When using an extended ACL as input for an OSPF distribution list, specify ip.
The <source-ip> <wildcard> parameter specifies the source address for the policy. Since this ACL is input to an OSPF distribution list, the <source-ip> parameter actually is specifying the destination network of the route.
The <wildcard> parameter specifies the portion of the source address to match against. The <wildcard> is a four-part value in dotted-decimal notation (IP address format) consisting of ones and zeros. Zeros in the mask mean the packet’s source address must match the <source-ip>. Ones mean any value matches. For example, the <source-ip> and <wildcard> values 4.0.0.0 0.255.255.255 mean that all 4.x.x.x networks match the ACL.
If you want the policy to match on all network addresses, enter any any.
If you prefer to specify the wildcard (mask value) in Classless Interdomain Routing (CIDR) format, you can enter a forward slash after the IP address, then enter the number of significant bits in the mask. For example, you can enter the CIDR equivalent of “4.0.0.0 0.255.255.255” as “4.0.0.0/8”. The CLI automatically converts the CIDR number into the appropriate ACL mask (where zeros instead of ones are the significant bits) and changes the non-significant portion of the IP address into zeros.
NOTE: If you enable the software to display IP subnet masks in CIDR format, the mask is saved in the file in
“/<mask-bits>” format. To enable the software to display the CIDR masks, enter the ip show-subnet-length command at the global CONFIG level of the CLI. You can use the CIDR format to configure the ACL entry regardless of whether the software is configured to display the masks in CIDR format.

If you use the CIDR format, the ACL entries appear in this format in the running-config and startup-config files, but are shown with subnet mask in the display produced by the show ip access-list commands.
The <destination-ip> <wildcard> parameter specifies the destination address for the policy. Since this ACL is input to an OSPF distribution list, the <destination-ip> parameter actually is specifying the network mask of the destination. The <wildcard> parameter specifies the portion of the destination address to match against. If you want the policy to match on all network masks, enter any any.
Modify Default Metric for Redistribution
The default metric is a global parameter that specifies the cost applied to all OSPF routes by default. The default value is 10. You can assign a cost from 1 – 15.
NOTE: You also can define the cost on individual interfaces. The interface cost overrides the default cost.
To assign a default metric of 4 to all routes imported into OSPF, enter the following commands:
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# default-metric 4
Syntax: default-metric <value>
The <value> can be from 1 – 16,777,215. The default is 10.
Enable Route Redistribution
To enable route redistribution, use one of the following methods.
NOTE: Do not enable redistribution until you have configured the redistribution filters. Otherwise, you might accidentally overload the network with routes you did not intend to redistribute.
To enable redistribution of RIP and static IP routes into OSPF, enter the following commands.
Example Using a Route Map
To configure a route map and use it for redistribution of routes into OSPF, enter commands such as the following:
The commands in this example configure some static IP routes, then configure a route map and use the route map for redistributing static IP routes into OSPF.
The ip route commands configure the static IP routes. The route-map command begins configuration of a route map called “abc”. The number indicates the route map entry (called the “instance”) you are configuring. A route map can contain multiple entries. The software compares packets to the route map entries in ascending numerical order and stops the comparison once a match is found.
The match command in the route map matches on routes that have 5 for their metric value (cost). The set command changes the metric in routes that match the route map to 8.
The redistribute static command enables redistribution of static IP routes into OSPF, and uses route map “abc“ to control the routes that are redistributed. In this example, the route map allows a static IP route to be redistributed into OSPF only if the route has a metric of 5, and changes the metric to 8 before placing the route into the OSPF route table.
The following command shows the result of the redistribution filter. Since only one of the static IP routes configured above matches the route map, only one route is redistributed. Notice that the route’s metric is 5 before redistribution but is 8 after redistribution.
Syntax: [no] redistribution connected | rip | static [route-map <map-name>]
The connected | rip | static parameter specifies the route source.
The route-map <map-name> parameter specifies the route map name. The following match parameters are valid for OSPF redistribution:
match tag <tag-value>
The following set parameters are valid for OSPF redistribution:
set ip next hop <ip-addr>
set tag <tag-value>
NOTE: You must configure the route map before you configure a redistribution filter that uses the route map.
NOTE: When you use a route map for route redistribution, the software disregards the permit or deny action of the route map.
NOTE: For an external route that is redistributed into OSPF through a route map, the metric value of the route remains the same unless the metric is set by a set metric command inside the route map. The default-metric <num> command has no effect on the route. This behavior is different from a route that is redistributed without using a route map. For a route redistributed without using a route map, the metric is set by the default-metric <num> command.
Disable or Re-enable Load Sharing
Brocade routers can load share among up to eight equal-cost IP routes to a destination. By default, IP load sharing is enabled. The default is 4 equal-cost paths but you can specify from 2 – 8 paths.
The router software can use the route information it learns through OSPF to determine the paths and costs. Figure 11.8 shows an example of an OSPF network containing multiple paths to a destination (in this case, R1).
Figure 11.8
In the example in Figure 11.8, the Brocade router has four paths to R1:
SI->R3
SI->R4
SI->R5
SI->R6
Normally, the Brocade router will choose the path to the R1 with the lower metric. For example, if R3’s metric is 1400 and R4’s metric is 600, the Brocade router will always choose R4.
However, suppose the metric is the same for all four routers in this example. If the costs are the same, the router now has four equal-cost paths to R1. To allow the router to load share among the equal cost routes, enable IP load sharing. The software supports four equal-cost OSPF paths by default when you enable load sharing. You can specify from 2 – 8 paths.
NOTE: The Brocade router is not source routing in these examples. The router is concerned only with the paths to the next-hop routers, not the entire paths to the destination hosts.
OSPF load sharing is enabled by default when IP load sharing is enabled. To configure IP load sharing parameters, see “Configuring IP Load Sharing”.
Configure External Route Summarization
When the Layer 3 Switch is an OSPF Autonomous System Boundary Router (ASBR), you can configure it to advertise one external route as an aggregate for all redistributed routes that are covered by a specified address range.
When you configure an address range, the range takes effect immediately. All the imported routes are summarized according to the configured address range. Imported routes that have already been advertised and that fall within the range are flushed out of the AS and a single route corresponding to the range is advertised.
If a route that falls within a configured address range is imported by the Layer 3 Switch, no action is taken if the Layer 3 Switch has already advertised the aggregate route; otherwise the Layer 3 Switch advertises the aggregate route. If an imported route that falls with in a configured address range is removed by the Layer 3 Switch, no action is taken if there are other imported route(s) that fall with in the same address range; otherwise the aggregate route is flushed.
You can configure up to 32 address ranges. The Layer 3 Switch sets the forwarding address of the aggregate route to zero and sets the tag to zero.
If you delete an address range, the advertised aggregate route is flushed and all imported routes that fall within the range are advertised individually.
If an external LSDB overflow condition occurs, all aggregate routes are flushed out of the AS, along with other external routes. When the Layer 3 Switch exits the external LSDB overflow condition, all the imported routes are summarized according to the configured address ranges.
NOTE: If you use redistribution filters in addition to address ranges, the Layer 3 Switch applies the redistribution filters to routes first, then applies them to the address ranges.
NOTE: If you disable redistribution, all the aggregate routes are flushed, along with other imported routes.
NOTE: This option affects only imported, type 5 external routes. A single type 5 LSA is generated and flooded throughout the AS for multiple external routes. Type 7-route redistribution is not affected by this feature. All type 7 routes will be imported (if redistribution is enabled). To summarize type 7 LSAs or exported routes, use NSSA address range summarization.
To configure a summary address for OSPF routes, enter commands such as the following:
ServerIron(config-ospf-router)# summary-address 10.1.0.0 255.255.0.0
The command in this example configures summary address 10.1.0.0, which includes addresses 10.1.1.0, 10.1.2.0, 10.1.3.0, and so on. For all of these networks, only the address 10.1.0.0 is advertised in external LSAs.
Syntax: summary-address <ip-addr> <ip-mask>
The <ip-addr> parameter specifies the network address.
The <ip-mask> parameter specifies the network mask.
To display the configured summary addresses, enter the following command at any level of the CLI:
ServerIron(config-ospf-router)# show ip ospf config
OSPF Redistribution Address Ranges currently defined:
Range-Address Subnetmask
1.0.0.0 255.0.0.0
1.0.1.0 255.255.255.0
1.0.2.0 255.255.255.0
Syntax: show ip ospf config
Configure Default Route Origination
When the Layer 3 Switch is an OSPF Autonomous System Boundary Router (ASBR), you can configure it to automatically generate a default external route into an OSPF routing domain. This feature is called “default route origination” or “default information origination”.
By default, Brocade Layer 3 Switches do not advertise the default route into the OSPF domain. If you want the Layer 3 Switch to advertise the OSPF default route, you must explicitly enable default route origination.
When you enable OSPF default route origination, the Layer 3 Switch advertises a type 5 default route that is flooded throughout the AS (except stub areas and NSSAs). In addition, internal NSSA ASBRs advertise their default routes as translatable type 7 default routes.
The Layer 3 Switch advertises the default route into OSPF even if OSPF route redistribution is not enabled, and even if the default route is learned through an IBGP neighbor.
NOTE: Brocade Layer 3 Switches never advertise the OSPF default route, regardless of other configuration parameters, unless you explicitly enable default route origination using the following method.
If the Layer 3 Switch is an ASBR, you can use the “always” option when you enable the default route origination. The always option causes the ASBR to create and advertise a default route if it does not already have one configured.
If default route origination is enabled and you disable it, the default route originated by the Layer 3 Switch is flushed. Default routes generated by other OSPF routers are not affected. If you re-enable the feature, the feature takes effect immediately and thus does not require you to reload the software.
NOTE: The ABR (Layer 3 Switch) will not inject the default route into an NSSA by default and the command described in this section will not cause the Layer 3 Switch to inject the default route into the NSSA. To inject the default route into an NSSA, use the area <num> | <ip-addr> nssa default-information-originate command. See “Assign a Not-So-Stubby Area (NSSA)”.
To enable default route origination, enter the following command:
ServerIron(config-ospf-router)# default-information-originate
To disable the feature, enter the following command:
ServerIron(config-ospf-router)# no default-information-originate
Syntax: [no] default-information-originate [always] [metric <value>] [metric-type <type>]
The always parameter advertises the default route regardless of whether the router has a default route. This option is disabled by default.
The metric <value> parameter specifies a metric for the default route. If this option is not used, the default metric is used for the route.
The metric-type <type> parameter specifies the external link type associated with the default route advertised into the OSPF routing domain. The <type> can be one of the following:
1 – Type 1 external route
2 – Type 2 external route
If you do not use this option, the default redistribution metric type is used for the route type.
NOTE: If you specify a metric and metric type, the values you specify are used even if you do not use the always option.
Modify SPF Timers
The Layer 3 Switch uses the following timers when calculating the shortest path for OSPF routes:
SPF delay – When the Layer 3 Switch receives a topology change, the software waits before it starts a Shortest Path First (SPF) calculation. By default, the software waits five seconds. You can configure the SPF delay to a value from 0 – 65535 seconds. If you set the SPF delay to 0 seconds, the software immediately begins the SPF calculation after receiving a topology change.
SPF hold time – The Layer 3 Switch waits for a specific amount of time between consecutive SPF calculations. By default, the Layer 3 Switch waits ten seconds. You can configure the SPF hold time to a value from 0 – 65535 seconds. If you set the SPF hold time to 0 seconds, the software does not wait between consecutive SPF calculations.
You can set the delay and hold time to lower values to cause the Layer 3 Switch to change to alternate paths more quickly in the event of a route failure. Note that lower values require more CPU processing time.
You can change one or both of the timers. To change the SPF delay and hold time, enter commands such as the following:
ServerIron(config-ospf-router)# timers spf 10 20
The command in this example changes the SPF delay to 10 seconds and changes the SPF hold time to 20 seconds.
Syntax: timers spf <delay> <hold-time>
The <delay> parameter specifies the SPF delay.
The <hold-time> parameter specifies the SPF hold time.
To set the timers back to their default values, enter a command such as the following:
ServerIron(config-ospf-router)# no timers spf 10 20
Modify Redistribution Metric Type
The redistribution metric type is used by default for all routes imported into OSPF unless you specify different metrics for individual routes using redistribution filters. Type 2 specifies a big metric (three bytes). Type 1 specifies a small metric (two bytes). The default value is type 2.
To modify the default value to type 1, enter the following command:
ServerIron(config-ospf-router)# metric-type type1
Syntax: metric-type type1 | type2
The default is type2.
Modify Administrative Distance
Brocade Layer 3 Switches can learn about networks from various protocols, including RIP, and OSPF. Consequently, the routes to a network may differ depending on the protocol from which the routes were learned. The default administrative distance for OSPF routes is 110.
The router selects one route over another based on the source of the route information. To do so, the router can use the administrative distances assigned to the sources. You can bias the Layer 3 Switch’s decision by changing the default administrative distance for RIP routes.
Configuring Administrative Distance Based on Route Type
You can configure a unique administrative distance for each type of OSPF route. For example, you can use this feature to prefer a static route over an OSPF inter-area route but you also want to prefer OSPF intra-area routes to static routes.
The distance you specify influences the choice of routes when the Layer 3 Switch has multiple routes for the same network from different protocols. The Layer 3 Switch prefers the route with the lower administrative distance.
You can specify unique default administrative distances for the following route types:
The default for all these OSPF route types is 110.
NOTE: This feature does not influence the choice of routes within OSPF. For example, an OSPF intra-area route is always preferred over an OSPF inter-area route, even if the intra-area route’s distance is greater than the inter-area route’s distance.
To change the default administrative distances for inter-area routes, intra-area routes, and external routes, enter the following command:
ServerIron(config-ospf-router)# distance external 100
ServerIron(config-ospf-router)# distance inter-area 90
ServerIron(config-ospf-router)# distance intra-area 80
Syntax: distance external | inter-area | intra-area <distance>
The external | inter-area | intra-area parameter specifies the route type for which you are changing the default administrative distance.
The <distance> parameter specifies the new distance for the specified route type. Unless you change the distance for one of the route types using commands such as those shown above, the default is 110.
To reset the administrative distance to its system default (110), enter a command such as the following:
ServerIron(config-ospf-router)# no distance external 100
Configure OSPF Group Link State Advertisement (LSA) Pacing
The Layer 3 Switch paces LSA refreshes by delaying the refreshes for a specified time interval instead of performing a refresh each time an individual LSA’s refresh timer expires. The accumulated LSAs constitute a group, which the Layer 3 Switch refreshes and sends out together in one or more packets.
The pacing interval, which is the interval at which the Layer 3 Switch refreshes an accumulated group of LSAs, is configurable to a range from 10 – 1800 seconds (30 minutes). The default is 240 seconds (four minutes). Thus, every four minutes, the Layer 3 Switch refreshes the group of accumulated LSAs and sends the group together in the same packet(s).
Usage Guidelines
The pacing interval is inversely proportional to the number of LSAs the Layer 3 Switch is refreshing and aging. For example, if you have approximately 10,000 LSAs, decreasing the pacing interval enhances performance. If you have a very small database (40 – 100 LSAs), increasing the pacing interval to 10 – 20 minutes might enhance performance slightly.
Changing the LSA Pacing Interval
To change the LSA pacing interval to two minutes (120 seconds), enter the following command:
ServerIron(config-ospf-router)# timers lsa-group-pacing 120
Syntax: [no] timers lsa-group-pacing <secs>
The <secs> parameter specifies the number of seconds and can be from 10 – 1800 (30 minutes). The default is 240 seconds (four minutes).
To restore the pacing interval to its default value, enter the following command:
ServerIron(config-ospf-router)# no timers lsa-group-pacing
Modify OSPF Traps Generated
OSPF traps as defined by RFC 1850 are supported on Brocade routers. OSPF trap generation is enabled on the router, by default.
When using the CLI, you can disable all or specific OSPF trap generation by entering the following CLI command:
ServerIron(config-ospf-router)# no snmp-server trap ospf
To later re-enable the trap feature, enter snmp-server trap ospf.
To disable a specific OSPF trap, enter the command as no snmp-server trap ospf <ospf-trap>.
These commands are at the OSPF router Level of the CLI.
Here is a summary of OSPF traps supported on Brocade routers, their corresponding CLI commands, and their associated MIB objects from RFC 1850:
interface-state-change-trap – [MIB object: OspfIfstateChange]
virtual-interface-state-change-trap – [MIB object: OspfVirtIfStateChange
neighbor-state-change-trap – [MIB object:ospfNbrStateChange]
virtual-neighbor-state-change-trap – [MIB object: ospfVirtNbrStateChange]
interface-config-error-trap – [MIB object: ospfIfConfigError]
virtual-interface-config-error-trap – [MIB object: ospfVirtIfConfigError]
interface-authentication-failure-trap – [MIB object: ospfIfAuthFailure]
virtual-interface-authentication-failure-trap – [MIB object: ospfVirtIfAuthFailure]
interface-receive-bad-packet-trap – [MIB object: ospfIfrxBadPacket]
virtual-interface-receive-bad-packet-trap – [MIB object: ospfVirtIfRxBadPacket]
interface-retransmit-packet-trap – [MIB object: ospfTxRetransmit]
virtual-interface-retransmit-packet-trap – [MIB object: ospfVirtIfTxRetransmit]
originate-lsa-trap – [MIB object: ospfOriginateLsa]
originate-maxage-lsa-trap – [MIB object: ospfMaxAgeLsa]
link-state-database-overflow-trap – [MIB object: ospfLsdbOverflow]
link-state-database-approaching-overflow-trap – [MIB object: ospfLsdbApproachingOverflow
EXAMPLE: 
To stop an OSPF trap from being collected, use the CLI command: no trap <ospf-trap>, at the Router OSPF level of the CLI. To disable reporting of the neighbor-state-change-trap, enter the following command:
ServerIron(config-ospf-router)# no trap neighbor-state-change-trap
EXAMPLE: 
To reinstate the trap, enter the following command:
ServerIron(config-ospf-router)# trap neighbor-state-change-trap
Syntax: [no] snmp-server trap ospf <ospf-trap>
Modify OSPF Standard Compliance Setting
Brocade routers are configured, by default, to be compliant with the RFC 1583 OSPF V2 specification.
To configure a router to operate with the latest OSPF standard, RFC 2178, enter the following commands:
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# no rfc1583-compatibility
Syntax: [no] rfc1583-compatibility
Modify Exit Overflow Interval
If a database overflow condition occurs on a router, the router eliminates the condition by removing entries that originated on the router. The exit overflow interval allows you to set how often a Layer 3 Switch checks to see if the overflow condition has been eliminated. The default value is 0. The range is 0 – 86400 seconds (24 hours). If the configured value of the database overflow interval is zero, then the router never leaves the database overflow condition.
To modify the exit overflow interval to 60 seconds, enter the following command:
ServerIron(config-ospf-router)# data-base-overflow-interval 60
Syntax: database-overflow-interval <value>
The <value> can be from 0 – 86400 seconds. The default is 0 seconds.
Specifying Types of OSPF Syslog Messages to Log
You can specify which kinds of OSPF-related Syslog messages are logged. In configurations with a large amount of OSPF activity, this can result in the Brocade device’s Syslog buffer and the Syslog server filling up with OSPF messages.
By default, the only OSPF messages that are logged are those indicating possible system errors. If you want other kinds of OSPF messages to be logged, you can configure the Brocade device to log them.
For example, to specify that all OSPF-related Syslog messages be logged, enter the following commands.
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# log all
Syntax: [no] log all | adjacency | bad_packet [checksum] | database | memory | retransmit
The log command has the following options:
The all option causes all OSPF-related Syslog messages to be logged. If you later disable this option with the no log all command, the OSPF logging options return to their default settings.
The adjacency option logs essential OSPF neighbor state changes, especially on error cases. This option is disabled by default.
The bad_packet checksum option logs all OSPF packets that have checksum errors. This option is enabled by default.
The bad_packet option logs all other bad OSPF packets. This option is disabled by default.
The database option logs OSPF LSA-related information. This option is disabled by default.
The memory option logs abnormal OSPF memory usage. This option is enabled by default.
The retransmit option logs OSPF retransmission activities. This option is disabled by default.

Configuring OSPF > Configuring OSPF

Table of Contents Previous Next Print
Copyright © 2009 Brocade Communications Systems, Inc.