This network type is useful in forcing traffic from multiple sites go via the HQ, or central location. In the example below, this means all traffic is going to flow through R3.

R1#
interface Serial0/0
ip address 10.0.0.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 10.0.0.3 103 broadcast
no frame-relay inverse-arp
!
router ospf 1
router-id 1.1.1.1
network 10.0.0.0 0.0.0.255 area 0
R2#
interface Loopback0
ip address 99.99.99.99 255.255.255.255
ip ospf network point-to-point
!
interface Serial0/0
ip address 10.0.0.2 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 10.0.0.3 203 broadcast
no frame-relay inverse-arp
!
router ospf 1
router-id 2.2.2.2
network 10.0.0.0 0.0.0.255 area 0
network 99.99.99.99 0.0.0.0 area 0
R3#
interface Serial1/0
ip address 10.0.0.3 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 10.0.0.1 301 broadcast
frame-relay map ip 10.0.0.2 302 broadcast
no frame-relay inverse-arp
!
router ospf 1
router-id 3.3.3.3
network 10.0.0.0 0.0.0.255 area 0
I highlighted some important stuff. In this network type, OSPF hello’s are sent as multicasts to 224.0.0.5. In order for multicasts to be transmitted, we have to enable the broadcast keyword on the frame-relay map statements (more info on the broadcast keyword here). The other important thing, is that their is no requirement for R1 to have a DLCI to R2. Instead, R3 will inject itself as the next hop for reachability between the two spokes. You can see this in R1’s routing table below.

R1#sh ip route ospf
99.0.0.0/32 is subnetted, 1 subnets
O 99.99.99.99 [110/846] via 10.0.0.3, 00:00:13, Serial0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.0.0.2/32 [110/845] via 10.0.0.3, 00:00:13, Serial0/0
O 10.0.0.3/32 [110/64] via 10.0.0.3, 00:00:13, Serial0/0
As you can see from R1’s point of view, the 99.99.99.99 network (on R2’s loopback) is accessible via R3’s IP address. Even R2 itself, is only accessible via R3. This is actually because R3 treats the connection to each spoke like a point-to-point link; meaning R3 is always gonna be the next hop between them. You can see this when you check the ospf database below.

R3#sh ip ospf database router 3.3.3.3

OSPF Router with ID (3.3.3.3) (Process ID 1)

Router Link States (Area 0)

LS age: 536
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xE1C9
Length: 60
Number of Links: 3

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 1.1.1.1
(Link Data) Router Interface address: 10.0.0.3
Number of TOS metrics: 0
TOS 0 Metrics: 781

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 2.2.2.2
(Link Data) Router Interface address: 10.0.0.3
Number of TOS metrics: 0
TOS 0 Metrics: 781

Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.0.3
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 0
The output shows that R3 is sending type 1 router LSA’s that describe R1 and R2 as being connected to it via a point-to-point network type.

One last cool feature I want to show is the neighbor cost command. So I’m gonna change the network a bit so we can have a play. See the new topology below.

The following commands have been added

R1#
//Advertise new network into OSPF
R1(config)#router ospf 1
R1(config-router)#passive-interface FastEthernet0/0
R1(config-router)#network 12.12.12.0 0.0.0.255 area 0

R2#
//Advertise new network into OSPF
R2(config)#router ospf 1
R2(config-router)#passive-interface FastEthernet0/0
R2(config-router)#network 12.12.12.0 0.0.0.255 area 0
You can see the significance of this when checking R3’s routing table. He now has two equal cost paths to the new network 12.12.12.0/24.

R3#sh ip route 12.12.12.0
Routing entry for 12.12.12.0/24
Known via “ospf 1”, distance 110, metric 782, type intra area
Last update from 10.0.0.1 on Serial1/0, 00:00:14 ago
Routing Descriptor Blocks:
* 10.0.0.2, from 2.2.2.2, 00:00:14 ago, via Serial1/0
Route metric is 782, traffic share count is 1
10.0.0.1, from 1.1.1.1, 00:00:14 ago, via Serial1/0
Route metric is 782, traffic share count is 1
If we want to influence R3 to choose the path via R1 as the best path to this network, we would normally assign a lower cost to the interface of the neighbor we want to prefer. However, we’re only using 1 interface to connect both neighbors here. So we can use the neighbor command to assign the cost instead. Let’s do that now on R3.

R3#
//Assign costs to each neighbor so that we prefer the link via R1
R3(config)#router ospf 1
R3(config-router)#neighbor 10.0.0.1 cost 5
R3(config-router)#neighbor 10.0.0.2 cost 10
You can see the impact of this when we now check the routing table on R3

R3#sh ip route 12.12.12.0
Routing entry for 12.12.12.0/24
Known via “ospf 1”, distance 110, metric 6, type intra area
Last update from 10.0.0.1 on Serial1/0, 00:00:01 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 1.1.1.1, 00:00:01 ago, via Serial1/0
Route metric is 6, traffic share count is 1
Cool, R3 now prefers the path via R1. Just incase you’re wondering how the cost is 6 and not 5, this is because R1 added a cost of 1 as the route was incoming via Fa0/0. R3 then added a cost of 5 as it came in via S1/0.

Quick Facts

– OSPF hellos are sent to the AllSPFRouters multicast address – 224.0.0.5

– Requires frame-relay broadcast keyword so that the OSPF multicast hello’s can be sent

– Default timers are Hello 30 secs, Dead 120 secs

– No DR/BDR election

– Routers will be on the same logical subnet

– This mode is RFC compliant

– Typical in a hub and spoke or partial mesh design.

– Can be used in a full mesh OSPF neighborship design (i.e. traffic does not always have to go via the hub).