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