OSPF – Non Broadcast and Point to Multipoint

Introduction

There was a discussion on a forum about the point to multipoint network type in
OSPF. What is the purpose of it and why are /32 endpoints advertised? To understand
the solution we must first understand the problem. This topology has a NBMA network
where R1 is the hub. R1 has been elected the hub due to having the highest priority.

NBMA Networks

When using the network type non broadcast, which is the default for main interfaces
with frame relay enabled, a DR and BDR is elected. When using a hub and spoke
topology it is important that the hub is elected the DR. Why is this? If a
spoke is elected the DR the flooding process will fail. On broadcast and non broadcast
segments the DROTHERs flood the LSAs to the DR/BDR and then the DR floods them to
the other DROTHERs on the segment.

The routing has already been setup, R2 and R3 are advertising a loopback each, they
are 2.2.2.2/32 and 3.3.3.3/32 respectively. First we will have a look at the router
LSAs that are generated.

R2#sh ip ospf data router 3.3.3.3

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

                Router Link States (Area 0)

  LS age: 118
  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: 80000006
  Checksum: 0x5849
  Length: 48
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 3.3.3.3
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.0.0.1
     (Link Data) Router Interface address: 10.0.0.3
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

Interfaces that are connected and don’t have an OSPF adjacency are considered
stub networks. These are advertised with the network and the mask. There is
also a transit network that contains the IP of the DR and the local routers IP
for that network. Note that there is no network mask within this LSA.

If we have a look at the routing table of R2, the next-hop to reach 3.3.3.3/32
is 10.0.0.3.

R2#sh ip route 3.3.3.3                
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 65, type intra area
  Last update from 10.0.0.3 on Serial1/0, 00:34:24 ago
  Routing Descriptor Blocks:
  * 10.0.0.3, from 3.3.3.3, 00:34:24 ago, via Serial1/0
      Route metric is 65, traffic share count is 1

On broadcast and non broadcast segments all routers are assumed to be fully
meshed but here we have a hub and spoke topology. When R2 needs to send traffic
to R3 it will try to encapsulate the frame but it does not know which DLCI to
use for 10.0.0.3 because there is no frame mapping for that.

R2#sh frame map
Serial1/0 (up): ip 10.0.0.1 dlci 201(0xC9,0x3090), dynamic,
              broadcast,, status defined, active

If we debug the sending of frame relay frames we will see that the encapsulation
is failing.

R2#debug frame-relay packet
Frame Relay packet debugging is on
R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:

*Mar  1 00:42:30.495: Serial1/0(o): dlci 201(0x3091), pkt type 0x800(IP), datagramsize 84
*Mar  1 00:42:32.303: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:34.299: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:36.299: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:38.299: Serial1/0:Encaps failed--no map entry link 7(IP).
*Mar  1 00:42:40.299: Serial1/0:Encaps failed--no map entry link 7(IP).
Success rate is 0 percent (0/5)

The layer 3 topology is not consistent with the layer 2 topology. The layer 3 is
assumed to be fully meshed but our layer 2 is in fact hub and spoke.

The next-hop is not changed on broadcast and non broadcast segments because
all routers are assumed to be fully meshed.

Solving the Inconsistency

One way of solving the inconsistency is by adding static mappings for
the IP of R2 and R3 respectively to the correct DLCI.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s1/0
R2(config-if)#frame map ip 10.0.0.3 201

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s1/0
R3(config-if)#frame map ip 10.0.0.2 301

R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/51/76 ms

This solved our problem but requires manual intervention and if new routers are
added then new mappings would have to be added as well. Before we leave the
network type non-broadcast there is one more thing I would like to point out.

Network LSA

What is the role of the network LSA? It is twofold, it conveys both topology
information and reachability information. If we look at the network LSA that R1
generates.

R2#sh ip ospf data net 10.0.0.1

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

                Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 634
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 10.0.0.1 (address of Designated Router)
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000003
  Checksum: 0x46C6
  Length: 36
  Network Mask: /24
        Attached Router: 1.1.1.1
        Attached Router: 2.2.2.2
        Attached Router: 3.3.3.3

We see all of the attached routers and also the network mask for the segment.
This network LSA will be converted by R4 into a type3 summary LSA. If we look
from R5’s perspective we can see this prefix.

R5#sh ip route 10.0.0.0
Routing entry for 10.0.0.0/24, 1 known subnets

O IA    10.0.0.0 [110/84] via 45.45.45.45, 00:45:27, FastEthernet0/0
R5#sh ip ospf data sum 10.0.0.0

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

                Summary Net Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 831
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.0.0.0 (summary Network Number)
  Advertising Router: 4.4.4.4
  LS Seq Number: 80000002
  Checksum: 0x7364
  Length: 28
  Network Mask: /24
        TOS: 0  Metric: 74 

R5 can reach this network which is demonstrated by the ping.

R5#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/64/72 ms

What would happen if R2 or R3 became the DR instead of R1? Let’s try it out.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s1/0
R1(config-if)#ip ospf prio 1

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s1/0
R2(config-if)#ip ospf prio 100

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int s1/0
R3(config-if)#ip ospf prio 0

Then clear the process to see the effect.

The segment has now been split into two. R2 does not know about R3 so we have
a segment with R1 and R2 and then a segment with R1 and R3. This can be seen
from the neighbor table and from the network LSA that is generated.

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           1   FULL/DR         00:00:31    14.14.14.4      FastEthernet0/0
2.2.2.2         100   FULL/DR         00:01:44    10.0.0.2        Serial1/0
3.3.3.3           0   FULL/DROTHER    00:01:45    10.0.0.3        Serial1/0

R1#sh ip ospf data net 10.0.0.2

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

                Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 600
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 10.0.0.2 (address of Designated Router)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x43D6
  Length: 32
  Network Mask: /24
        Attached Router: 2.2.2.2
        Attached Router: 1.1.1.1

This also means that SPF can’t run properly because R3 is now not connected to
the topology because it’s not part of the network LSA for 10.0.0.0/24. This
means that R5 can’t ping R3.

R5#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

It can still reach R1 and R2 though.

R5#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/52/84 ms
R5#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/66/84 ms

So the network LSA is used both for building the SPF topology and for reachibility
information.

Point to Multipoint Network

There is a point to multipoint network type. This overcomes the limitations of
partially meshed networks by accomplishing two things. The first thing that happens
is that when a LSA is received on an interface, the next-hop is changed to IP of
the router LSA that the local router is connecting to. In our case this is 10.0.0.1.

R2#sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
  Known via "ospf 1", distance 110, metric 129, type intra area
  Last update from 10.0.0.1 on Serial1/0, 00:03:59 ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 3.3.3.3, 00:03:59 ago, via Serial1/0
      Route metric is 129, traffic share count is 1

R2#sh ip ospf data router 1.1.1.1

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

                Router Link States (Area 0)

  LS age: 483
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 1.1.1.1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000018
  Checksum: 0x6E61
  Length: 72
  Number of Links: 4

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 14.14.14.4
     (Link Data) Router Interface address: 14.14.14.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    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.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 3.3.3.3
     (Link Data) Router Interface address: 10.0.0.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.0.0.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

This is described in RFC 2328.

If the destination is a router which connects to the
calculating router via a Point-to-MultiPoint network, the
destination's next hop IP address(es) can be determined by
examining the destination's router-LSA: each link pointing
back to the calculating router and having a Link Data field
belonging to the Point-to-MultiPoint network provides an IP
address of the next hop router.

From the router LSA above you can see that each router in the point to multipoint
network advertises a stub network with a /32 mask. On point to multipoint segments
the network is described as a collection of point to point links. With a regular
point to point network the stub network is described with the actual mask of
the interface that is running OSPF. What is the use of these /32 routes?
First let’s test the reachability.

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/60/72 ms
R2#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/76 ms
R2#show ip route 10.0.0.3
Routing entry for 10.0.0.3/32
  Known via "ospf 1", distance 110, metric 128, type intra area
  Last update from 10.0.0.1 on Serial1/0, 00:12:41 ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 3.3.3.3, 00:12:41 ago, via Serial1/0
      Route metric is 128, traffic share count is 1

Full reachability. What happens if we filter the /32 route to R3 on R2?

R2(config)#ip prefix-list DENY_R3 deny 10.0.0.3/32         
R2(config)#ip prefix-list DENY_R3 permit 0.0.0.0/0 le 32   
R2(config)#router ospf 1
R2(config-router)#distribute-list prefix DENY_R3 in

The host route to R3 is now gone. The route to R3 is known via the connected
network.

R2#show ip route 10.0.0.3
Routing entry for 10.0.0.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Serial1/0
      Route metric is 0, traffic share count is 1

What about reachability?

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/57/84 ms
R2#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

The ping went through when we used the loopback as a source. That is because
R3 still has a host route to R2 in its routing table. We couldn’t ping 10.0.0.3
though? Why? Because without the host route pointing to a next-hop of 10.0.0.1,
R2 will try to see what DLCI to use when encapsulating the frame to 10.0.0.3
and there is no mapping for this. If we ping R2’s loopback from R3 sourcing
with the 10.0.0.3 IP, it will fail for the same reason.

R3#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Conclusion

OSPF has various network types that accomplish different things.
The point to multi point network type is used to overcome limitations at
layer 2. The network is described as a collection of point to point links
where each router advertises a stub network with a /32 mask. By doing this
the spokes can maintain connectivity between each other when sourcing traffic
from the interface connected to their common network.

The next-hop is also changed on incoming LSAs to the IP contained in the router
LSA from the router that originated the LSA. This solves the next hop issue
on non broadcast networks where the next hop is maintained because full mesh
connectivity is assumed.