OSPF won't share this ONE route

Answered Question
Nov 25th, 2008

Router G is connected out its Tok0 interface to the 10.4.4.0/24 subnet (its interface IP is 10.4.4.7).

Router A is connected to Router G via a 30-bit Serial link. Each has each other in its OSPF neighbor table in the full state.

The 10.4.4.0 link is up and active, is declared in the OSPF process (evident under both show ip prot and show running), yet it WILL NOT APPEAR in Router A's routing table.

Router A's info:

Sethtek-A#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface

215.0.0.13 1 FULL/ - 00:01:57 215.0.0.13 Serial0

Sethtek-A#show run

interface Serial0

ip address 215.0.0.14 255.255.255.252

no ip directed-broadcast

encapsulation ppp

no ip route-cache

ip ospf hello-interval 30

no ip mroute-cache

no fair-queue

clockrate 1000000

!!!!!output omitted!!!!!

!

interface Serial1

ip address 215.0.0.6 255.255.255.252

no ip directed-broadcast

encapsulation ppp

no ip route-cache

no ip mroute-cache

no fair-queue

!

router ospf 100

network 215.0.0.12 0.0.0.3 area 0

!

ip default-gateway 215.0.0.14

ip classless

!

tftp-server flash:c2500-i-l.120-8.bin

I have this problem too.
0 votes
Correct Answer by Harold Ritter about 8 years 2 weeks ago

Seth,

The issue is that there is an ospf network type mismatch. This will not prevent the adjacency from forming but will prevent the routes learned from this neighbor to be used by ospf. Remove the "ip ospf network non-broadcast" under serial0 of router G and it should fix the issue you are seeing.

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
CriscoSystems Tue, 11/25/2008 - 11:51

And Router G's info:

Sethtek-G#sh ip pro

Routing Protocol is "ospf 100"

Invalid after 0 seconds, hold down 0, flushed after 0

Outgoing update filter list for all interfaces is

Incoming update filter list for all interfaces is

Routing for Networks:

10.4.4.0/24

215.0.0.12/30

Routing Information Sources:

Gateway Distance Last Update

Distance: (default is 110)

Sethtek-G>sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface

205.1.3.1 1 FULL/BDR 00:01:55 215.0.0.14 Serial0

Sethtek-G# sh run

!!!output omitted!!!

!

interface Serial0

ip address 215.0.0.13 255.255.255.252

encapsulation ppp

ip ospf network non-broadcast

no ip mroute-cache

no fair-queue

!

interface Serial1

no ip address

encapsulation ppp

!

interface TokenRing0

ip address 10.4.4.7 255.255.255.0

ip ospf priority 200

ip policy route-map word

ring-speed 16

!

router ospf 100

log-adjacency-changes

network 10.4.4.0 0.0.0.255 area 0

network 215.0.0.12 0.0.0.3 area 0

!

router bgp 50

bgp log-neighbor-changes

network 10.4.4.0

neighbor 10.4.4.8 remote-as 50

neighbor 215.0.0.14 remote-as 100

!

ip kerberos source-interface any

ip classless

ip route 10.2.2.0 255.255.255.0 10.5.5.1

no ip http server

!

access-list 1 permit 172.16.0.2

route-map Toby permit 10

match ip next-hop 1

set weight 100

!

!

tftp-server flash:aaa0850.bin

As indicated, these are partial clippings from the running config; but I think all the relevant stuff is here.

10.4.4.0 is up and running on Router G, it's declared in the OSPF process, and Router G has full neighborship with Router A so WHY is Router A not getting the route to 10.4.4.0?

CriscoSystems Tue, 11/25/2008 - 11:55

Sethtek-A#sh ip route

Codes: C - connected, S - static, I - IGRP, 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, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

C 205.1.1.0/24 is directly connected, Loopback1

C 205.1.0.0/24 is directly connected, Loopback0

C 205.1.3.0/24 is directly connected, Loopback3

C 205.1.2.0/24 is directly connected, Loopback2

215.0.0.0/24 is variably subnetted, 2 subnets, 2 masks

C 215.0.0.13/32 is directly connected, Serial0

C 215.0.0.12/30 is directly connected, Serial0

Sethtek-A#

PLUS

Sethtek-G#sh ip route

Codes: C - connected, S - static, I - IGRP, 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, E - EGP

i - IS-IS, 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

215.0.0.0/24 is variably subnetted, 2 subnets, 2 masks

C 215.0.0.14/32 is directly connected, Serial0

C 215.0.0.12/30 is directly connected, Serial0

10.0.0.0/24 is subnetted, 1 subnets

C 10.4.4.0 is directly connected, TokenRing0

Sethtek-G#

Correct Answer
Harold Ritter Tue, 11/25/2008 - 12:40

Seth,

The issue is that there is an ospf network type mismatch. This will not prevent the adjacency from forming but will prevent the routes learned from this neighbor to be used by ospf. Remove the "ip ospf network non-broadcast" under serial0 of router G and it should fix the issue you are seeing.

Regards

CriscoSystems Tue, 11/25/2008 - 12:44

WOW! I will try that, but before I do - what the heck is Cisco's (or the RFC 2328 authors') logic behind allowing adjacencies to form over mismatched network types; if that's going to prevent good routes from gettin in?

Harold Ritter Tue, 11/25/2008 - 13:28

Seth,

This is not a Cisco issue but rather an RFC2328 issue. Unlike some other attibutes (i.e. MTU, network address, capabilities, etc), the network type is not negotiated. I suppose the reason for it is that in certain cases it would be normal to have different network types on either side of the adjacency (point-to-multipoint vs point-to-point for instance).

Regards

Actions

This Discussion