RE: OSPF/FR: why spoke-spoke relationships try to form?

From: Brian Dennis (brian@5g.net)
Date: Sun Dec 22 2002 - 20:35:12 GMT-3


Have you checked to see if you have a dynamic frame-relay mapping
between the two spokes? It looks like R4 has a frame-relay mapping to
R3. This could happen if you disabled inverse-arp after the interface
was up/up with an IP address applied.

Brian Dennis, CCIE #2210 (R&S/ISP Dial/Security)

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Marshall Stacks
Sent: Sunday, December 22, 2002 5:25 AM
To: ccielab@groupstudy.com
Subject: OSPF/FR: why spoke-spoke relationships try to form?

Problem: 3-router hub-spoke FR/OSPF network using physical interfaces,
frame
map statements, ip ospf point-to-multipoint. There is a "live" but
unused
PVC between the two spokes. Why do spokes constantly try to create an
OSPF
neighbor relationship over "unused" PVC & how to prevent other than by
shutting down the unused PVC between them? It doesn't seem right for
this
waste of CPU and bandwidth to be occurring. Thanks.

R1 (hub):
interface Serial0/0
ip address 130.10.134.1 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 130.10.134.3 102 broadcast
frame-relay map ip 130.10.134.4 101 broadcast
no frame-relay inverse-arp

R3:
interface Serial1/0
ip address 130.10.134.3 255.255.255.0
ip access-group 103 in
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 130.10.134.1 100 broadcast
no frame-relay inverse-arp

R4:
interface Serial1/0
ip address 130.10.134.4 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 130.10.134.1 110 broadcast
no frame-relay inverse-arp

Neighbor ID Pri State Dead Time Address
Interface
130.10.13.5 1 INIT/ - 00:00:00 130.10.134.4
Serial1/0
130.10.134.1 1 FULL/ - 00:01:52 130.10.134.1
Serial1/0



This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:51 GMT-3