From: secondie (secondie@gmail.com)
Date: Fri Aug 11 2006 - 13:28:07 ART
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
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:56 ART