OSPF host routes with network type point-to-multipoint

What's their purpose?

The best I've manage to come up with is this post by Brian Dennis:

OSPF Point-to-Multipoint Network Type and /32 Routes

...
Point-to-multipoint advertises the end points to overcome possible reachability issues between devices that are on the same logical subnet but do not have direct communication (i.e. spoke to spoke communication in a hub and spoke environment).
...

His post seems kind of vague to me.

Consider these two statements:

1) In a point-to-multipoint network the next-hops of routes are changed to the ip address of the interface that sent the route, regardless of what router originally advertised the route on to the segment. This in contrast to a broadcast network where the next-hop is maintained due to the assumption that a broadcast segment supports direct communication between all routers.

2) OSPF can only exchange information between routers if there is a direct layer 2 connection. This could be an Ethernet segment, a gre tunnel, a frame-relay pvc, etc.

If we put 1 and 2 together, we get that on a point-to-multipoint segment, the nexthop can only be a router where you have a direct layer 2 connection, and thus have some kind of mapping, be it a frame-relay map statement, a static tunnel or an nhrp mapping.

If we always have a mapping for the next hop, why do we need the host routes? It seems to me that if you just remove these from the routing table with a distribute-list, it won't affect reachability.

Find more posts tagged with

Comments

reaper81

Hi Fredrik,

I setup a simple network hub and spoke frame-relay with 10.0.0.0/24 as the network. R1 is the hub and has IP 10.0.0.1, R2 and R3 are spokes at .2 and .3.

I set the hub to become the DR for obvious reasons. R3 is advertising a loopback 3.3.3.3.

R3#sh ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 3.3.3.3/32 1 LOOP 0/0
Se1/0 1 0 10.0.0.3/24 64 BDR 1/1

When using non broadcast we get this LSA from the Hub.

R3#sh ip ospf data router 10.0.0.1

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

Router Link States (Area 0)

LS age: 204
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.0.0.1
Advertising Router: 10.0.0.1
LS Seq Number: 80000002
Checksum: 0x3C8A
Length: 36
Number of Links: 1

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

It also generates a network LSA.

R3#sh ip ospf data network

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

Net Link States (Area 0)

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

The problem now is that R2 sees 3.3.3.3 with a next-hop of 10.0.0.3.

R2#sh ip route ospf
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/65] via 10.0.0.3, 00:00:51, Serial1/0

However there is no frame-relay mapping for 10.0.0.3 at R2.

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

This means that R3 does not know how to encapsulate the frame when going to 10.0.0.3. If we debug frame-relay packet we will see the encapsulation failed message.

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

R2#
Serial1/0:Encaps failed--no map entry link 7(IP)

Basicly the problem here is that at layer 3 we are saying that all routers are connected at 10.0.0.0/24 and they all belong to the same segment. But at layer two we have a hub and spoke network.

This is what R3 router LSA looks like.

R2#sh ip ospf data router 10.0.0.3

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

Router Link States (Area 0)

LS age: 634
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.0.0.3
Advertising Router: 10.0.0.3
LS Seq Number: 80000003
Checksum: 0x366C
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

Advertising router and Link state ID is 10.0.0.3.

One way of solving this is to put additional mappings on the spokes.

R2(config)#int s1/0
R2(config-if)#frame-relay map ip 10.0.0.3 201

R3(config)#int s1/0
R3(config-if)#frame-relay map ip 10.0.0.2 301

The ping now goes through.

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 = 40/56/108 ms

If we compare this with Ethernet you can imagine these hosts being on the same subnet but they don't know which destination MAC to send the frame to. Like the ARP process was broken somehow and they didn't know how to resolve the MAC, you could put in a static mapping to overcome it.

Now if we remove the mappings and change to point to multipoint which was created to overcome these issues.

R2(config)#int s1/0
R2(config-if)#no frame-relay map ip 10.0.0.3 201
R2(config-if)#ip ospf net point-to-multipoint

R1(config)#int s1/0
R1(config-if)#ip ospf net point-to-multipoint
R1(config-router)#no nei 10.0.0.2
R1(config-router)#no nei 10.0.0.3

R3(config)#int s1/0
R3(config-if)#no frame-relay map ip 10.0.0.2 301
R3(config-if)#ip ospf net point-to-multipoint

With point-to-multipoint the links are advertised as being a collection of point to point links.

R2#sh ip ospf data router 10.0.0.1

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

Router Link States (Area 0)

LS age: 42
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.0.0.1
Advertising Router: 10.0.0.1
LS Seq Number: 8000000A
Checksum: 0xD666
Length: 60
Number of Links: 3

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.0.0.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: 10.0.0.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

The hub advertises a LSA saying it has point to point links to R2 and R3.

The spokes advertise that they are connected to the hub and any stub networks.

R2#sh ip ospf data router 10.0.0.3

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

Router Link States (Area 0)

LS age: 81
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.0.0.3
Advertising Router: 10.0.0.3
LS Seq Number: 80000007
Checksum: 0x443E
Length: 60
Number of Links: 3

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: another Router (point-to-point)
(Link ID) Neighboring Router ID: 10.0.0.1
(Link Data) Router Interface address: 10.0.0.3
Number of TOS metrics: 0
TOS 0 Metrics: 64

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

If we look in the OSPF RIB we see that 3.3.3.3 is reachable via 10.0.0.3.

R2#show ip ospf rib 3.3.3.3

OSPF local RIB for Process 1
Codes: * - Best, > - Installed in global RIB

*> 3.3.3.3/32, Intra, cost 129, area 0
flags 0x11, SPF Instance 10, age 00:01:47
via 10.0.0.1, Serial1/0
flags 0x4, LSA: 1/10.0.0.3/10.0.0.3

If we look in the routing table though we see that 3.3.3.3 is reachable via 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:02:28 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 10.0.0.3, 00:02:28 ago, via Serial1/0
Route metric is 129, traffic share count is 1

This is because 10.0.0.3 is reachable via 10.0.0.1.

R2#sh 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:03:14 ago
Routing Descriptor Blocks:
* 10.0.0.1, from 10.0.0.3, 00:03:14 ago, via Serial1/0
Route metric is 128, traffic share count is 1

The router does a recursive lookup to find the exit point for the route.

So the point-to-multipoint network type repairs at layer 3 the inconsistency at layer 2 keeping us from putting additional mappings. It does this by advertising /32 routes for each of the endpoints.

R2#sh ip route ospf
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/129] via 10.0.0.1, 00:05:47, Serial1/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.0.0.3/32 [110/128] via 10.0.0.1, 00:05:47, Serial1/0
O 10.0.0.1/32 [110/64] via 10.0.0.1, 00:06:45, Serial1/0

There is also a point-to-multipoint non-broadcast network type in case there is no support for multicast on the segment.

fredrikjj

Thanks for the reply.

I'm not going to comment on the broadcast type setup because that doesn't seem particularly strange. To me this is the key sentence on point-to-multipoint:

reaper81 wrote:

The router does a recursive lookup to find the exit point for the route.

So the point-to-multipoint network type repairs at layer 3 the inconsistency at layer 2 keeping us from putting additional mappings. It does this by advertising /32 routes for each of the endpoints.

I set up what I think is the same network as you (hub/spoke FR) running p2m. Loopback from R3 is 3.3.3.3/24.

I remove the host routes from R2's routing table with a prefix list:

R2#show run | inc prefix
ip prefix-list DENY_R1_R3_HOST seq 5 deny 10.0.0.1/32
ip prefix-list DENY_R1_R3_HOST seq 10 deny 10.0.0.3/32
ip prefix-list DENY_R1_R3_HOST seq 15 permit 0.0.0.0/0 le 32

R2#show run | s router ospf 1
router ospf 1
 router-id 0.0.0.2
 distribute-list prefix DENY_R1_R3_HOST in

R2's routing table now looks like this. The houst routes have been removed.

R2#show ip route
      2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        2.2.2.0/24 is directly connected, Loopback0
L        2.2.2.2/32 is directly connected, Loopback0
      3.0.0.0/24 is subnetted, 1 subnets
O        3.3.3.0 [110/129] via 10.0.0.1, 00:05:15, Serial1/0
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.0.0/24 is directly connected, Serial1/0
L        10.0.0.2/32 is directly connected, Serial1/0

I can still ping 3.3.3.3

R2#ping 3.3.3.3 source 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 = 4/8/12 ms

My argument is basically that it's not a recursive lookup but that the next-hop of the route itself is changed to the IP address of the hub. Maybe I'm not interpreting the routing table correctly, but it says via 10.0.0.1 right there.

reaper81

I see what you mean. You might be on to something here, so the next-hop is set to the IP of the neighbor on the interface that the LSA was received. So that is what is fixing the topology.

However the host routes need to be there for routers outside of the area to get reachability to the network to where these routers are connected. Because no DR/BDR is used there is no type2 LSA advertised for the network.

fredrikjj

I think that I just got it. The host routes are required to have reachability to the other interfaces in the point-to-multipoint subnet under certain circumstances. The loopbacks we've been looking at, and other external prefixes, can have their next hops changed by OSPF based on what the OSPF network is doing because they are OSPF routes. However, this directly connected route,

C 10.0.0.0/24 is directly connected, Serial1/0

,is kind of stuck in this state and unable to respond to changes in the layer 2 or layer 3 topology.

Now for example, if our network is frame-relay with static mappings and we don't map every endpoint on this subnet to the correct pvc and we don't have the host routes, encapsulation will fail when we try to reach any endpoint where we don't have a mapping. However, we will still be able to reach any external prefixes because OSPF has changed the next-hop for us to an address that we can reach (if we couldn't reach it, we wouldn't have an OSPF adjacency with that neighbor). This "next hop management" is done dynamically by OSPF on a point-to-multipoint network.

So what the host routes do is point any ip address on the subnet (that is in use) to a next-hop that we can reach. What's the point of this one might ask. Couldn't you just statically map every ip in the subnet to the correct pvc? Yes, you could, but what the host routes allow you to do is add a new router to the network without having to go around modifying the L3-L2 mappings on ever router on the subnet. A new host route will simply appear in the routing table of every router. Also, the cool thing is that unlike static mappings, the next hops of the host routes will change depending on what ospf neighbor adjacencies you have. this means that you will always reach all interfaces on the network as long as you have at least one adjacency.

Hopefully not too convoluted of an explanation.

EdTheLad

I think the host routes are just to keep full connectivity between routers on the multipoint segment. With R1,R2 and R3 in a partial mesh setup over FR, each spoke will have a mapping to the hub. The spokes will only know how to reach each other via the host routes.

Imagine R1 is the hub, R2 and R3 are the spokes. The network is 10.0.0.0/24; interfaces .1 .2 .3 respectfully. Let's say there way no /32's being advertised, instead each router advertise a /24 for the network. R2 will receive the /24 from R1, this /24 will have a next-hop 10.0.0.1, the 10.0.0.1 is mapped to a FR pvc. So with this /24 we could reach R3? wrong! Since R2 has a directly connected interface with the 10.0.0.0/24 it will prefer this. In this case forwarding is broken as there is no fr map for the /24. To over come the directly connected interface a /32 is used.

Removing the /32's from the rib will cause connectivity issues locally on routers R1,R2 and R3. When you execute a ping from R2 to an advertised network on R3, R3 will not have a route to for the src address used by R2. So you would need to src the ping from an interface other than the multipoint.

fredrikjj

reaper81 wrote:

However the host routes need to be there for routers outside of the area to get reachability to the network to where these routers are connected. Because no DR/BDR is used there is no type2 LSA advertised for the network.

The type 2 isn't required to advertise a prefix/mask. There's no type 2 in a network with just point-to-point links for example. For a prefix to show up in the routing table there just needs to be a "stub network" entry in the router LSA. This stub entry list both the prefix and the mask. However, all these hosts routes would give you more optimal routing to the specific interfaces in the point-to-multipoint segment I guess?

reaper81

The type2 advertised the network mask. This is not contained in the router LSA.

The /32 host routes on P2MP are for the spokes to be able to reach each other. Otherwise any traffic sourced by the IP connecting to the P2MP segment will fail.

I decided to write a blog on it:

OSPF – Non Broadcast and Point to Multipoint | Daniels networking blog

fredrikjj

reaper81 wrote: »

The type2 advertised the network mask. This is not contained in the router LSA.

Indeed, when using broadcast, the prefix length information is removed from the router LSA. When using the point-to-point network type you have the 'stub network' entries in the router LSA, but using point-to-multipoint that entry is removed and the entire network is just a collection of point-to-point entries. It's quite interesting and it means that p2p, p2m and broadcast all represent prefixes differently in the LSDB.