A Non-Broadcast Multi-Access (NBMA) network is a network type that allows multiple hosts to connect to the same network; however, an NMBA does not natively support Broadcast and Multicast packets. One of the most commonly implemented NBMA technologies is Frame Relay. The implementation of OSPF on NBMA networks requires a great deal of thought and planning. OSPF can be implemented in three modes on NBMA networks. These modes are:
- Simulated Broadcast Mode
- Point-to-Point Mode
- Point-to-Multipoint Mode
Each mode has its advantages and disadvantages. It is therefore important to weigh them accordingly based on the network in which you want to implement OSPF. The following sections describe these three modes, their advantages and their disadvantages.
Simulated Broadcast Mode
Simulated Broadcast mode simulates a traditional Broadcast model by electing a Designated Router and Backup Designated Router on the NBMA network. There are two ways in which OSPF can be implemented in simulated Broadcast mode for NBMA network types:
- Using the default network type and the neighbor router configuration command
- By changing the default network type to the broadcast network type
When OSPF is enabled on a Frame Relay network, the default network type is Non-Broadcast. Unlike on Broadcast network types, Multicast Hello packets are not used for dynamic neighbor discovery on NBMA networks. Instead, because OSPF assumes that the underlying infrastructure is incapable of sending and receiving Broadcast and Multicast packets, static neighbor configuration is required to allow the routers on the NBMA network to communicate using Unicast packets instead of Multicast packets.
This requirement is mandatory even if the broadcast keyword has been added to the end of the frame-relay map command or that Inverse ARP has been used to dynamically map remote IP addresses to local DLCIs. In Cisco IOS software, static OSPF neighbors are defined using the neighbor [address] [priority <number>] [poll-interval <seconds>] [cost <number>] [database-filter all] router configuration command for each directly connected neighbor router.
The [address] keyword specifies the IP address of the neighbor router. It is important to remember that the specified address is the interface address connected to the non-Broadcast network, and not the router ID. If the router ID is specified, the adjacency will not be established.
NOTE: If the router ID and interface IP address are the same, the adjacency will be established.
The priority <number> keyword is specifies the router priority of the neighbor associated with the IP address specified. A router priority value between 0-255 can be specified for the neighbor. By default, the neighbor priority value is set to 1. Assigning a priority value of 0 indicates that the neighbor will not participate in DR/BDR election. The router with the lowest priority value will be elected DR. If the priority values are the same, the RID will be used.
The poll-interval <seconds>keyword is used to configure the poll interval time based on RFC 1247 recommendations. This is not the Hello interval. The poll interval can be any integer between 0 and 4294967295. The default value is 120 seconds. The cost <number> keyword specifies the neighbor router cost. This keyword is applicable only to point-to-multipoint configuration. And finally, the database-filter all keyword is used to filter all outgoing Link State Advertisements to the specified OSPF neighbor router(s). Figure 3-31 illustrates a typical full mesh Frame Relay network topology wherein all routers are connected to each other via a permanent virtual circuit (DLCI):
Fig. 3-31. A Full Mesh Frame Relay WAN
Referencing Figure 3-31, by default, when OSPF is enabled over Frame Relay, the interface defaults to a Non-Broadcast network type as shown in the output of the show ip ospf interface command below:
| R1#show ip ospf interface serial 0/0 Serial0/0 is up, line protocol is up Internet Address 10.99.99.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64[Truncated Output] |
Because of the default network type, OSPF neighbors must be statically configured in Cisco IOS software in order for adjacencies to be established between the neighbor routers. Although the neighbors use Unicast packets to communicate, the election of the DR and BDR routers follows the same rules as are applicable in Broadcast network types.
Again referencing Figure 3-31, OSPF would be configured and implemented as follows on the network the network topology illustrated in the diagram:
| R1(config)#interface fastethernet 0/0 R1(config-if)#ip ospf 3 area 0 R1(config-if)#exit R1(config)#interface serial 0/0 R1(config-if)#ip ospf 3 area 0 R1(config-if)#exit R1(config)#router ospf 1 R1(config-router)#neighbor 10.99.99.2 R1(config-router)#neighbor 10.99.99.3 R1(config-router)#neighbor 10.99.99.4 R1(config-router)#exit |
| R2(config)#router ospf 2 R2(config-router)#router-id 2.2.2.2 R2(config-router)#network 10.22.22.0 0.0.0.255 area 0 R2(config-router)#network 10.99.99.0 0.0.0.255 area 0 R2(config-router)#neighbor 10.99.99.1 R2(config-router)#neighbor 10.99.99.3 R2(config-router)#neighbor 10.99.99.4 R2(config-router)#exit |
| R3(config)#interface fastethernet 0/0 R3(config-if)#ip ospf 3 area 0 R3(config-if)#exit R3(config)#interface serial 0/0 R3(config-if)#ip ospf 3 area 0 R3(config-if)#exit R3(config)#router ospf 3 R3(config-router)#neighbor 10.99.99.1 R3(config-router)#neighbor 10.99.99.2 R3(config-router)#neighbor 10.99.99.4 R3(config-router)#exit |
| R4(config)#router ospf 4 R4(config-router)#router-id 4.4.4.4 R4(config-router)#network 10.44.44.0 0.0.0.255 area 0 R4(config-router)#network 10.99.99.0 0.0.0.255 area 0 R4(config-router)#neighbor 10.99.99.1 R4(config-router)#neighbor 10.99.99.2 R4(config-router)#neighbor 10.99.99.3 R4(config-router)#exit |
NOTE: The ip ospf and the network commands are used in the configurations above to reinforce the statement that either method of configuration is valid and acceptable.
Following the configuration of OSPF, the show ip ospf neighbor command is used to validate the configuration and verify the adjacencies and DR/BDR election:
| R1#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 2WAY/DROTHER 00:01:31 10.99.99.2 Serial0/0 3.3.3.3 1 FULL/BDR 00:01:37 10.99.99.3 Serial0/0 4.4.4.4 1 FULL/DR 00:01:56 10.99.99.4 Serial0/0 |
| R2#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 3.3.3.3 1 FULL/BDR 00:01:52 10.99.99.3 Serial0/0 1.1.1.1 1 2WAY/DROTHER 00:01:37 10.99.99.1 Serial0/0 4.4.4.4 1 FULL/DR 00:01:56 10.99.99.4 Serial0/0 |
| R3#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DROTHER 00:01:56 10.99.99.2 Serial0/0 1.1.1.1 1 FULL/DROTHER 00:01:32 10.99.99.1 Serial0/0 4.4.4.4 1 FULL/DR 00:01:50 10.99.99.4 Serial0/0 |
| R4#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DROTHER 00:01:50 10.99.99.2 Serial0/0 3.3.3.3 1 FULL/BDR 00:01:50 10.99.99.3 Serial0/0 1.1.1.1 1 FULL/DROTHER 00:01:48 10.99.99.1 Serial0/0 |
From the output above, R4 has been elected DR (based on the RID) and R3 has been elected BDR (also based on the RID). Routers R1 and R2 are DROther routers. These two routers establish an adjacency with the DR and BDR, but not with each other. If the DR fails, the BDR assumes the role of DR and a new BDR would then be elected as would be the case on a traditional Broadcast network.
The second method of implementing OSPF in simulated Broadcast mode entails the changing of the default OSPF network type for the NBMA network using the ip ospf network broadcast interface configuration command on all routers. This configuration allows for DR/BDR election, but negates the need to manually configure static neighbors. This is because a Broadcast network is one that natively supports both Broadcast and Multicast traffic. This lifts the restriction imposed by the Non-Broadcast network type and OSPF can use Multicast Hello packets to dynamically discover neighbors.
NOTE: When implementing OSPF in simulated Broadcast mode by changing the default OSPF network type, it is important to ensure that the Frame Relay network has been configured to support Broadcast and Multicast packets either via Inverse ARP (dynamic mappings) or by the addition of the broadcast keyword to frame-relay map statements.
Following the configuration of the ip ospf network broadcast interface configuration command on all WAN interfaces of R1, R2, R3, and R4, the show ip ospf neighbor command is used to validate the configuration and verify the adjacencies as shown for R4:
| R3#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DROTHER 00:00:32 10.99.99.2 Serial0/0 1.1.1.1 1 FULL/DROTHER 00:00:35 10.99.99.1 Serial0/0 4.4.4.4 1 FULL/DR 00:00:33 10.99.99.4 Serial0/0 |
The show ip ospf interface command is used to verify the non-default network type:
| R3#show ip ospf interface serial 0/0 Serial0/0 is up, line protocol is up Internet Address 10.99.99.3/24, Area 0 Process ID 3, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 64 Enabled by interface config, including secondary ip addresses Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 4.4.4.4, Interface address 10.99.99.4 Backup Designated router (ID) 3.3.3.3, Interface address 10.99.99.3 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:08 Supports Link-local Signaling (LLS) Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 1 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 3, Adjacent neighbor count is 3 Adjacent with neighbor 2.2.2.2 Adjacent with neighbor 1.1.1.1 Adjacent with neighbor 4.4.4.4 (Designated Router) Suppress hello for 0 neighbor(s) |
While the previous configuration examples have illustrated the implementation of OSPF in simulated Broadcast mode over a fully meshed Frame Relay network, it is important to understand that the same solution can also be applied to a partially meshed Frame Relay network. However, it is imperative to ensure the following when doing so:
- The DR must have a direct connection (virtual circuit) to every other router
- The DR must have a direct connection (virtual circuit) to the BDR
- The BDR must have a direct connection (virtual circuit) to every other router
Figure 3-32 illustrates a topology that meets these specifications:
Fig. 3-32. A Redundant Partial Mesh Frame Relay WAN
Referencing Figure 3-32, both the DR and BDR are connected to each other and all other routers connecting across the Frame Relay network. The spoke routers, R1, R2, R3, and R4, need not have a direct connection between themselves. When implementing OSPF is simulated Broadcast mode over such a topology, it is important to ensure that none of the spoke router is ever elected DR or BDR inadvertently. The recommended solution in this network would be to issue the ip ospf priority 0 interface configuration command on each of the spoke routers, or alternatively, use a network type that does not require or elect a DR or a BDR router.
The primary advantage gained by using simulated Broadcast mode is the use of the Designated Router. The DR (and BDR) reduces the amount of traffic and updates required between individual routers by acting as a central point of contact for all routers connected to the multi-access network. In addition to this, the number of adjacencies required on the multi-access network is also reduced as DROther routers only establish adjacencies with the DR and BDR routers. The disadvantages of using simulated Broadcast mode is that all routers must have a direct connection between them (full mesh) or additional configuration is required to ensure that spoke routers do not become the DR or BDR (partial mesh).
Point-to-Point Mode
Point-to-point mode is perhaps the simplest method of implementing OSPF on NBMA network types. By default, OSPF uses Multicast on point-to-point network types for dynamic neighbor discovery, even on Frame Relay subinterfaces. When configuring point-to-point Frame Relay subinterfaces, the frame-relay interface-dlcisubinterface configuration command must be used instead of the frame-relay map command. The following configuration shows how to configure a point-to-point connection between two routers:
| R1(config)#interface serial 0/0 R1(config-if)#no ip address R1(config-if)#encapsulation frame-relay R1(config-if)#exit R1(config)#interface serial 0/0.1 point-to-point R1(config-subif)#ip address 10.99.99.1 255.255.255.252 R1(config-subif)#frame-relay interface-dlci 102 R1(config-fr-dlci)#exit R1(config-subif)#exit R1(config)#router ospf 1 R1(config-router)#network 10.99.99.1 255.255.255.252 area 0 R1(config-router)#exit |
| R2(config)#interface serial 0/0 R2(config-if)#no ip address R2(config-if)#encapsulation frame-relay R2(config-if)#exit R2(config)#interface serial 0/0.2 point-to-point R2(config-subif)#ip address 10.99.99.2 255.255.255.252 R2(config-subif)#ip ospf 2 area 0 R2(config-subif)#frame-relay interface-dlci 201 R2(config-fr-dlci)#exit |
Following this configuration, the show ip ospf interface command is used to validate the network type as well as adjacency formed with the remote router as shown below:
| R2#show ip ospf interface serial 0/0.2 Serial0/0.2 is up, line protocol is up Internet Address 10.99.99.2/30, Area 0 Process ID 2, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64 Enabled by interface config, including secondary ip addresses Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:03 Supports Link-local Signaling (LLS) Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 1.1.1.1 Suppress hello for 0 neighbor(s) |
The primary advantage of using OSPF point-to-point mode is that it is easy to configure and implement. However, there are certain factors which should be taken into consideration. The first factor pertains to IP address space. If IP address space is plentiful, this is not an issue. However, if IP address space is scarce, or almost depleted, it may not be feasible to allocate a subnet for each individual point-to-point connection, especially in a large deployment.
Another factor that should be taken into consideration is the size of the Link State Database. Although Type 2 LSAs are not generated for the point-to-point subnets, a Type 3 LSA is still generated by the ABR for each one. In a large deployment, this will increase the size of the LSBD on routers in adjacent areas, which could lead to performance issues. However, if the IP address space is contiguous, the area…range command can be used to mitigate this.
Point-to-Multipoint Mode
Point-to-multipoint mode is a non-default OSPF mode. In Cisco IOS software, this configuration is used to treat the NBMA network as a collection of point-to-point connections or links. This mode allows all routers connected to each other to establish an adjacency without the need to elect a DR or BDR. Point-to-point mode can be configured to allow OSPF to use either Multicast (default) or Unicast packets to establish adjacencies with other routers.
In Cisco IOS software, the ip ospf network point-to-multipoint [broadcast] interface configuration command is used to configure point-to-multipoint mode. When this command is issued, a host route is created for all routers that reside on the multi-access network. This negates the need to configure multiple frame-relay mapstatements for all of the routers connected to the Frame Relay network. Figure 3-33 illustrates a typical hub and spoke network wherein the spoke routers, routers R2 and R3, have a single virtual circuit provisioned to the hub router (R1). All routers, however, are part of the same logical Layer 3 network 10.99.99.0/24 as shown in the diagram:
Fig. 3-33. A Traditional Hub-and-Spoke Network
Referencing Figure 3-33, the two spoke routers are connected to the hub router via a single virtual circuit (DLCI). While both simulated Broadcast and point-to-point mode could be implemented in the same network, the additional configuration required to implement both methods makes point-to-multipoint mode the best possible option as it accommodates the current network design and requires the least amount of additional configuration. The following illustrates how to implement OSPF point-to-multipoint mode on the three routers illustrated in Figure 3-33:
| R1(config)#router ospf 1 R1(config-router)#router-id 1.1.1.1 R1(config-router)#network 10.99.99.0 255.255.255.0 area 0 R1(config-router)#network 10.11.11.0 255.255.255.0 area 0 R1(config-router)#exit R1(config)#interface serial 0/0 R1(config-if)#ip ospf network point-to-multipoint R1(config-if)#exit R1(config)# |
| R2(config)#interface fastethernet 0/0 R2(config-if)#ip ospf 2 area 0 R2(config-if)#exit R2(config)#interface serial 0/0 R2(config-if)#ip ospf 2 area 0 R2(config-if)#ip ospf network point-to-multipoint R2(config-if)#exit R2(config)#router ospf 2 R2(config-router)#router-id 2.2.2.2 R2(config-router)#exit |
| R3(config)#interface fastethernet 0/0 R3(config-if)#ip ospf 3 area 0 R3(config-if)#exit R3(config)#interface serial 0/0 R3(config-if)#ip ospf network point-to-multipoint R3(config-if)#ip ospf 3 area 0 R3(config-if)#exit R3(config)#router ospf 3 R3(config-router)#router-id 3.3.3.3 R3(config-router)#exit |
To validate this configuration, either the show ip ospf interface or the show ip ospf neighbor commands can be used. Following is the output of the show ip ospf interface command on R1, the hub router, and the output of the show ip ospf neighbor command on spoke routers R2 and R3:
| R1#show ip ospf interface serial 0/0 Serial0/0 is up, line protocol is up Internet Address 10.99.99.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 oob-resync timeout 120 Hello due in 00:00:24 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 2.2.2.2 Adjacent with neighbor 3.3.3.3 Suppress hello for 0 neighbor(s) |
| R2#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/ – 00:01:38 10.99.99.1 Serial0/0 |
| R3#show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/ – 00:01:51 10.99.99.1 Serial0/0 |
While the implementation of point-to-multipoint mode is very simple and straightforward, it is important to remember that a host route is generated for each of the interfaces connected to the NBMA network. This is illustrated on R1:
| R1#show ip route ospf 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks O 10.99.99.2/32 [110/64] via 10.99.99.2, 00:08:35, Serial0/0 O 10.99.99.3/32 [110/64] via 10.99.99.3, 00:08:35, Serial0/0 O 10.33.33.0/24 [110/65] via 10.99.99.3, 00:08:35, Serial0/0 O 10.22.22.0/24 [110/65] via 10.99.99.2, 00:08:35, Serial0/0 |
In a small network such as the one illustrated in Figure 3-33, this is typically not even an issue. However, if, for example, R1 was connected to additional OSPF areas, as the ABR, the router would also generate a Type 3 LSA for each host route and flood it to all of the adjacent areas as is illustrated in the following output:
| R1#show ip ospf databaseOSPF Router with ID (1.1.1.1) (Process ID 1)Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum Router Link States (Area 1) Link ID ADV Router Age Seq# Checksum Link count Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum |
In the output above, R1 has been configured as an ABR by connecting it to area 1. Following the expected operation of an ABR, R1 generates a Type 3 LSA for each of the individual hosts and floods it into area 1. In large networks, this may result in a large number of LSAs being flooded into adjacent areas. Again, it is important to remember that one of the core principles when implementing OSPF is to attempt to keep the database as lean as possible as this reduces OSPF convergence time and results in better protocol performance in the network.
OSPF Routing and Metric Calculation over Frame Relay Networks
One of the most common errors engineers make when implementing OSPF in Frame Relay networks is forgetting to look at the underlying technology. In most Frame Relay implementations, DLCIs typically have different Committed Information Rate (CIR) values, especially in situations where two routers are used to back each other up at the same site. Consider the topology illustrated in Figure 3-34:
Fig. 3-34. A Basic Redundant Site
Figure 3-34 illustrates a basic network topology wherein two individual routers are connected to the 150.254.254.0/24 subnet are redundantly connected across the Frame Relay WAN to the hub router (R1). The CIR for the DLCI provisioned between R1 and the primary router at the site (R2) is 768Kbps. The CIR for the DLCI provisioned between R1 and the secondary (backup) router at the site is 384Kbps.
From a network engineer’s perspective, OSPF point-to-multipoint mode would arguably be the simplest solution when implementing OSPF in this network. The issue, however, arises with the way that OSPF calculates its metric. By default, OSPF will use the cost value assigned to the interface to determine the metric to the destination network. Assuming that both R2 and R3 are using similar cost interfaces, R1 calculates the cost to the 150.254.254.0/24 subnet as being the same for the paths between both R2 and R3 as illustrated in the following output:
| R1#show ip route 150.254.254.0 255.255.255.0 Routing entry for 150.254.254.0/24 Known via “ospf 1”, distance 110, metric 65, type inter area Last update from 10.99.99.3 on Serial0/0, 00:00:28 ago Routing Descriptor Blocks: * 10.99.99.2, from 2.2.2.2, 00:00:28 ago, via Serial0/0 Route metric is 65, traffic share count is 1 10.99.99.3, from 3.3.3.3, 00:00:28 ago, via Serial0/0 Route metric is 65, traffic share count is 1 |
Based on the output above, OSPF will perform equal-cost load balancing to the 150.254.254.0/24 subnet using both R2 and R3. However, the issue is that because the DLCIs are provisioned with different CIR values. It is therefore important to look at the underlying infrastructure before deciding on which OSPF mode to implement on the NBMA network.
Referencing the topology in Figure 3-34, while the first option that comes to mind would be the use of the ip ospf cost interface configuration command, it is important to understand that this would only result in a different equal cost metric for both paths and would not ensure that the path via R2 is preferred over the path via R3.
In Cisco IOS software, the recommended solution would be to use the neighbor [address] cost <value> router configuration command. This command allows administrators to manually specify a unique cost value for each OSPF neighbor and can be used only with point-to-multipoint (Non-Broadcast) mode. If you do not look at the overall picture, you will most likely find yourself having to reconfigure routers to accommodate such situations. The following configuration example demonstrates how to use point-to-multipoint (Non-Broadcast) mode to ensure that R1 prefers the path via R2 to reach the 150.254.254.0/24 subnet:
| R1(config)#interface serial 0/0 R1(config-if)#ip ospf network point-to-multipoint non-broadcast R1(config-if)#exit R1(config)#router ospf 1 R1(config-router)#neighbor 10.99.99.2 cost 1 R1(config-router)#neighbor 10.99.99.3 cost 2 R1(config-router)#exit |
| R2(config)#interface serial 0/0 R2(config-if)#ip ospf network point-to-multipoint non-broadcast R2(config-if)#router ospf 2 R2(config-router)#neighbor 10.99.99.1 R2(config-router)#exit |
| R3(config)#interface serial 0/0 R3(config-if)#ip ospf network point-to-multipoint non-broadcast R3(config-if)#exit R3(config)#router ospf 3 R3(config-router)#neighbor 10.99.99.1 R3(config-router)#exit |
This configuration is validated using the show ip ospf neighbor command as follows:
| R1#show ip ospf interface serial 0/0 Serial0/0 is up, line protocol is up Internet Address 10.99.99.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 oob-resync timeout 120 Hello due in 00:00:11 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 2, Adjacent neighbor count is 2 Adjacent with neighbor 3.3.3.3, cost is 2 Adjacent with neighbor 2.2.2.2, cost is 1 Suppress hello for 0 neighbor(s) |
Following this change, the routing table on R1 shows as follows for the 150.254.254.0/24 subnet:
| R1#show ip route 150.254.254.0 255.255.255.0 Routing entry for 150.254.254.0/24 Known via “ospf 1”, distance 110, metric 2, type inter area Last update from 10.99.99.2 on Serial0/0, 00:02:41 ago Routing Descriptor Blocks: * 10.99.99.2, from 2.2.2.2, 00:02:41 ago, via Serial0/0 Route metric is 2, traffic share count is 1 |
If you attempt to configure a cost value on the default network type, i.e. Non-Broadcast, the following error message will be printed on the console:
| R1(config-if)#router ospf 1 R1(config-router)#neighbor 10.99.99.2 cost 1 OSPF: Cost and database-filter option are allowed only for point-to-multipoint network |