From: Abidin Kahraman (abidin.kahraman@gmail.com)
Date: Tue Aug 15 2006 - 18:44:28 ART
Hello Rado,
They can discover each other but there is no guarantee that all attached
routers will receive the Hellos of all other routers. Therefore, all routers
might not automatically learn about all its neighbors. The main point is DR
election here, your HUB must be DR. The IEsolution seems wrong, R1 (
150.1.1.1) can not be DR here.
HTH,
Abidin.
On 8/11/06, Radoslav Vasilev <deckland@gmail.com> 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:57 ART