OSPF over Frame Relay. ADJ is formed, LSA is recevied, but no entry in routing table

[Oak Ridge]

R13 is a HUB and R14, R15, R16 are spoke routers.  R13 is configured as

point-to-multipoint non-broadcast

R13#sh run inter s 2/0

Building configuration...

Current configuration : 183 bytes

!

interface Serial2/0

ip address 10.5.1.13 255.255.255.0

encapsulation frame-relay

ip ospf network point-to-multipoint non-broadcast

ip ospf 1 area 5

serial restart-delay 0

end

R13#

R14 is configured as 

point-to-multipoint non-broadcast too, and OSPF routing is running good in R14:

R14#sh run inter s 1/0

Building configuration...

Current configuration : 183 bytes

!

interface Serial1/0

ip address 10.5.1.14 255.255.255.0

encapsulation frame-relay

ip ospf network point-to-multipoint non-broadcast

ip ospf 1 area 5

serial restart-delay 0

end

R14#

R14#sh ip route ospf

     17.0.0.0/24 is subnetted, 1 subnets

O IA    17.0.0.0 [110/76] via 10.5.1.13, 00:39:13, Serial1/0

O IA 192.168.12.0/24 [110/66] via 10.5.1.13, 00:39:13, Serial1/0

....

However, I    R15's frame relay is using the default ospf type (non-broadcast), but no entry in it's routing table, even it has LSA. I know it should be the same OSPF network type in all the routers interfaces. I am just wondering how the things work:

R15#sh run inter s 1/0

Building configuration...

Current configuration : 132 bytes

!

interface Serial1/0

ip address 10.5.1.15 255.255.255.0

encapsulation frame-relay

ip ospf 1 area 5

serial restart-delay 0

end

R15#

R15#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.132.13    1   FULL/BDR        00:01:55    10.5.1.13       Serial1/0

R15#

R15#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets

C       10.5.1.0 is directly connected, Serial1/0

R15#

R15#sh ip os database

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

                Router Link States (Area 5)

Link ID         ADV Router      Age         Seq#       Checksum Link count

10.5.1.14       10.5.1.14       651         0x80000007 0x001E4D 2

10.5.1.15       10.5.1.15       931         0x80000003 0x00AEC6 1

10.5.1.16       10.5.1.16       357         0x80000003 0x0098DB 1

192.168.132.13  192.168.132.13  779         0x80000004 0x009CDF 4

                Net Link States (Area 5)

Link ID         ADV Router      Age         Seq#       Checksum

10.5.1.15       10.5.1.15       931         0x80000002 0x0009D7

                Summary Net Link States (Area 5)

Link ID         ADV Router      Age         Seq#       Checksum

10.1.1.0        192.168.132.13  1035        0x80000002 0x0062C7

10.2.18.0       192.168.132.13  1035        0x80000002 0x00A472

10.2.118.0      192.168.132.13  1035        0x80000002 0x005E53

10.3.49.0       192.168.132.13  1035        0x80000002 0x0038BF

--More--

[Jan Hrnko]

Hi,

Maybe I am wrong, but did you try to manually define neighbors with neighbor command?

It seems to me that it is a must when configuring OSPF as point-to-multipoint nonbroadcast.

The point-to-multipoint non-broadcast mode is a Cisco extension of the RFC-compliant point-to-multipoint mode and is used when the media does not support broadcast (such as classic IP over ATM: see “Configuring OSPF” white paper). You must statically define neighbors, and you can modify the cost of the link to the neighboring router to reflect the different bandwidths of each link. The RFC point-to-multipoint mode was developed to support underlying point-to-multipoint VCs that support multicast and broadcast; therefore, this mode allows dynamic neighboring router discovery. If multicast and broadcast are not enabled on the VCs, the RTFC-compliant point-to-multipoint mode cannot be used because the router cannot dynamically discover its neighboring routers using the hello multicast packets; this Cisco mode should be used instead.

Also, it is a good idea to configure the neighbor cost. Otherwise, the local router will assume equal cost to the configured neighbors. In the example, RTA is configured as a neighbor with a cost of 10 and RTC is configured as a neighbor with a cost of 20. These cost values are purely arbitrary and are only meant for demonstration purposes. You would, of course, configure an accurate cost value in a live network configuration.

RTB(config-if)#ip ospf network point-to-multipoint non-broadcast

--------

RTB(config-router)#network 3.1.1.0 0.0.0.255 area 0

RTB(config-router)#neighbor 3.1.1.1 cost 10

RTB(config-router)#neighbor 3.1.1.3 cost 20

Hope that helps!

Best regards,

Jan

[Oak Ridge]

yes I did the "neighbor x.x.x.x" in router R13, other wise the adjency will not be formed.

I just wonder how come  the OSPF LSDB is there, but no entry in routing table.

[John Blakley]

The problem, I believe, is that R15 is configured as a non-broadcast network type which expects a DR. The other types don't use DRs. You can tell this by the Network lsa that you have in your database. If you change your R15 to point-to-multipoint (make it consistent across routers), then you should be able to install the route into the routing table.

You can also see this evidence by doing a "sh ip ospf inter" on R15. You'll probably see that R15 sees itself as the DR.

HTH,

John

*** Please rate all useful posts ***

[Oak Ridge]

Yes I confirmed that R15 elected itself as DR, and elected R13 as BDR.   My understanding is every router in a  OSPF domain independly runs their shortest path first algorithm, so after R15 already has link state database (learnt from other ospf routers, since it forms the adjdency with them), it should install the best route into it's routing table. Why here R15 doesn't?

I know we should configured the same OSPF network type in all NBMA ends. I just want to check with the operation of OSPF.

R15#sh ip os nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.132.13    1   FULL/BDR        00:01:47    10.5.1.13       Serial1/0       <<<<<

R15#

R15#sh ip os da network

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

                Net Link States (Area 5)

  Routing Bit Set on this LSA

  LS age: 1661

  Options: (No TOS-capability, DC)

  LS Type: Network Links

  Link State ID: 10.5.1.15 (address of Designated Router)    <<<

  Advertising Router: 10.5.1.15

  LS Seq Number: 80000001

  Checksum: 0xBD6

  Length: 32

  Network Mask: /24

        Attached Router: 10.5.1.15

        Attached Router: 192.168.132.13

  LS age: 1663

  Options: (No TOS-capability, DC)

  LS Type: Network Links

  Link State ID: 10.5.1.16 (address of Designated Router)

  Advertising Router: 10.5.1.16

  LS Seq Number: 80000001

  Checksum: 0x5D9

  Length: 32

  Network Mask: /24

        Attached Router: 10.5.1.16

        Attached Router: 192.168.132.13

R15#

[Giuseppe Larosa · Accepted solution]

Hello Oak,

John is right the root cause of the behaviour you see is the mismatch in OSPF network type between R15 and the other routers in segment more specifically R13.

When R15 runs SPF it detects the mismatch or simply by examining the OSPF hello packets received by R13 not listing R15 as DR and R13 as BDR as it happens on OSPF hello generated by R15 itself.

After detecting the OSPF network type mismatch the local node does not use the LSAs received from the neighbor(s) with different network type. Let's see this as a safety measure of the protocol itself.

Hope to help

Giuseppe