From: firstie (secondie@gmail.com)
Date: Fri Aug 11 2006 - 15:34:09 ART
Can you shut all your interfaces and unshut to see if the neighbors
re-establishes. This is bizarre.
Radoslav Vasilev wrote:
> Hi again,
>
> My adjacencies are up for 6 hours now ;)
> I've already included the ospf/fr configuration, now check the debug ip
> packet on the hub:
>
> *Mar 1 06:19:22.666: IP: s=173.1.125.1 (Serial0/0.125), d=173.1.125.5, len
> 68, rcvd 0, proto=89
> Rack1R5#
> *Mar 1 06:19:24.582: IP: s=173.1.125.5 (local),
> d=173.1.125.1(Serial0/0.125), len 84, sending, proto=89
> *Mar 1 06:19:24.582: IP: s=173.1.125.5 (local),
> d=173.1.125.2(Serial0/0.125), len 84, sending, proto=89
> Rack1R5#
> Rack1R5#
> *Mar 1 06:19:30.270: IP: s=173.1.125.2 (Serial0/0.125), d=173.1.125.5, len
> 68, rcvd 0, proto=89
>
> they're using unicast for the hellos, and i don't have neighbor-command
> anywhere.
> So the question is - how do they discover each other?
>
> Rado
>
>
>
> On 8/11/06, secondie <secondie@gmail.com> wrote:
>> Is that right ????
>>
>> I know that Frame relay is allowing broadcast but I think that OSPF
>> still thinks that the network is NON-BROADCAST. So I am thinking
>> (agreeing with) what Rado is thinking; how did routers R2 and R3 become
>> neighbors to R5. All the routers are in OSPF NON-Broadcast mode
>> therefore it should not happen.
>>
>> I staged the scenario and there are no neighbors formed. I think this is
>> the expected behavior.
>>
>> Although, what can happen is that the network type was changed (from
>> broadcast to ptp) and clear IP ospf process was used to re-init the
>> ospf. In my lab, my interfaces were broadcast and I changed to NON. Even
>> though all interfaces were NON-BROADCAST, one of the spoke kept on
>> forming neighbor until I did a shut on all interfaces on Hub and Spoke.
>> After I unshut the interfaces, every thing started to behave the way it
>> should; i.e. no neighbors were established. Debugs verifies that hub and
>> spokes were not seeing any ospf data from each other.
>>
>> -secondie
>>
>>
>>
>> Shanky wrote:
>>> Hi Radoslav,
>>>
>>> The key is under interface config of the spokes ..
>>>
>>> frame-relay map ip 173.1.125.5 105 broadcast
>>>
>>> so broadcast is allowed on the PVC between spoke & Hub , why you need
>> the
>>> neighbor statements for ?
>>>
>>> Also, in my opinion , the solution should configure
>>> ip ospf priority 0 under interface configuration on the spokes ,
>> configuring
>>> the Hub with high priority doesnt guarantee that it will be elected as
>> DR.
>>> Hope it helps
>>>
>>> Shanky
>>>
>>>
>>>
>>>
>>> On 8/11/06, Radoslav Vasilev <deckland@gmail.com> wrote:
>>>> Hi Group,
>>>>
>>>> Can anyone shed some light of why the following setup actually works?
>>>>
>>>> The setup is from IEWBv3 lab 17, task 4.1 - basic ospf setup
>>>>
>>>> the underlying topology is frame-relay hub-and-spoke with R5 being the
>> hub
>>>> and R1 and R2 the spokes.
>>>> The spokes use physical interfaces with manual FR mapping to R5. The
>> hub
>>>> uses In-ARP to go to the spokes.
>>>>
>>>>
>>>> R5:
>>>>
>>>> interface Serial0/0.125 multipoint
>>>> ip address 173.1.125.5 255.255.255.0
>>>> ip ospf network non-broadcast
>>>> ip ospf priority 255
>>>> frame-relay interface-dlci 501
>>>> frame-relay interface-dlci 502
>>>>
>>>> router ospf 100
>>>> router-id 150.1.5.5
>>>> log-adjacency-changes
>>>> network 173.1.125.5 0.0.0.0 area 0
>>>>
>>>>
>>>>
>>>> R1:
>>>> interface Serial0/0
>>>> ip address 173.1.125.1 255.255.255.0
>>>> no ip directed-broadcast
>>>> encapsulation frame-relay
>>>> no ip mroute-cache
>>>> frame-relay map ip 173.1.125.2 105
>>>> frame-relay map ip 173.1.125.5 105 broadcast
>>>> no frame-relay inverse-arp
>>>>
>>>> router ospf 100
>>>> network 173.1.125.1 0.0.0.0 area 0
>>>>
>>>>
>>>> R2:
>>>>
>>>> interface Serial0/0
>>>> ip address 173.1.125.2 255.255.255.0
>>>> encapsulation frame-relay
>>>> clock rate 64000
>>>> frame-relay map ip 173.1.125.1 205
>>>> frame-relay map ip 173.1.125.5 205 broadcast
>>>> no frame-relay inverse-arp
>>>>
>>>> router ospf 100
>>>> router-id 150.1.2.2
>>>> log-adjacency-changes
>>>> network 173.1.125.2 0.0.0.0 area 0
>>>>
>>>>
>>>> Now the problem: area 0 has to be configured ove that FR segment - R1
>> and
>>>> R2
>>>> are not allowed any interface level commands to achieve that task.
>>>> As R1 and R2 use physical interfaces, their ospf interface type is by
>>>> default non-broadcast, so is the multipoint sub-iface of R5.
>>>> We're not allowed neighbor commands anywhere as well.
>>>>
>>>> The IEsolution, as visible above includes configuring `ip ospf network
>>>> non-broadcast` on R5.
>>>> No neighbor commands, nothing else.
>>>>
>>>> 150.1.1.1 1 FULL/DR 00:01:47 173.1.125.1
>>>> Serial0/0.125
>>>> 150.1.2.2 1 FULL/DROTHER 00:01:54 173.1.125.2
>>>> Serial0/0.125
>>>>
>>>> Any explenation what exactly happens so the non-broadcast neighbors
>>>> actually
>>>> become adjacent?
>>>>
>>>> Thanks in advance!
>>>> Rado
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:56 ART