From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Jan 11 2005 - 16:40:01 GMT-3
Yep, that makes alot of sense.
Before my next lab attempt, any chance I can borrow your brain? :-)
----- Original Message -----
From: "marvin greenlee" <marvin@ccbootcamp.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Tuesday, January 11, 2005 2:25 PM
Subject: RE: ospf over isdn using unicasts - Problem almost solved
> I have it working (able to establish the adjacency) with the neighbor
> statement on one side, but is isn't stable.
>
> Think about the two topics conceptually.
>
> With a demand circuit configured, both sides need to be able to initiate
the
> connection in the event of a topology change.
>
> If one side is missing the neighbor statement, it won't be able to
initiate
> the connection (using that network type).
>
> - Marvin Greenlee, CCIE#12237, CCSI# 30483
> Network Learning Inc
> marvin@ccbootcamp.com
> www.ccbootcamp.com (Cisco Training)
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Tuesday, January 11, 2005 10:56 AM
> To: marvin greenlee
> Cc: Group Study
> Subject: Re: ospf over isdn using unicasts - Problem almost solved
>
> Thanks Marvin,
>
> If there's a way to get this config to work with a neighbor statement on
>
> just one side, I couldn't find it although I spent alot of time trying.
>
> If someone comes up with a working config, hopefully, they'll share it on
> GS.
>
> Thanks alot for taking the time to look into this.
>
> Tim
>
>
> ----- Original Message -----
> From: "marvin greenlee" <marvin@ccbootcamp.com>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
> Sent: Tuesday, January 11, 2005 1:36 PM
> Subject: RE: ospf over isdn using unicasts - Problem almost solved
>
>
> > If you are using a demand circuit, I would recommend having the neighbor
> > statement on both sides.
> >
> > - Marvin Greenlee, CCIE#12237, CCSI# 30483
> > Network Learning Inc
> > marvin@ccbootcamp.com
> > www.ccbootcamp.com (Cisco Training)
> >
> >
> > -----Original Message-----
> > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > Sent: Tuesday, January 11, 2005 9:37 AM
> > To: marvin greenlee; ccielab@groupstudy.com
> > Subject: Re: ospf over isdn using unicasts - Problem almost solved
> >
> > Hi Marvin,
> >
> > Thanks for getting back to me on this.
> >
> > Yes, I'm running the ospf demand-circuit on R4:
> >
> > interface BRI0/0
> > ip address 130.1.45.4 255.255.255.0
> > encapsulation ppp
> > ip ospf message-digest-key 1 md5 CISCO
> > ip ospf network point-to-multipoint non-broadcast
> > ip ospf demand-circuit
> > dialer idle-timeout 30
> > dialer enable-timeout 2
> > dialer map ip 130.1.45.5 name ROUTER5 2221
> > dialer-group 1
> > isdn switch-type basic-ni
> > isdn spid1 40811111
> > isdn caller 222x
> > ppp authentication chap
> > ppp chap hostname ROUTER4
> >
> > router ospf 1
> > router-id 150.1.4.4
> > log-adjacency-changes
> > area 345 authentication message-digest
> > redistribute eigrp 100 subnets route-map ei2os
> > network 130.1.45.0 0.0.0.255 area 345
> > network 150.1.4.4 0.0.0.0 area 0
> > neighbor 130.1.45.5
> >
> > R5
> > interface BRI0/0
> > ip address 130.1.45.5 255.255.255.0
> > encapsulation ppp
> > ip ospf message-digest-key 1 md5 CISCO
> > ip ospf network point-to-multipoint non-broadcast
> > dialer enable-timeout 2
> > dialer map ip 130.1.45.4 name ROUTER4 1111
> > dialer-group 1
> > isdn switch-type basic-ni
> > isdn spid1 40822221
> > isdn caller 111x
> > ppp chap hostname ROUTER5
> > end
> >
> > router ospf 1
> > router-id 150.1.5.5
> > log-adjacency-changes
> > area 345 authentication message-digest
> > network 130.1.5.0 0.0.0.255 area 345
> > network 130.1.35.0 0.0.0.255 area 345
> > network 130.1.45.0 0.0.0.255 area 345 <--- ISDN link
> > network 150.1.5.5 0.0.0.0 area 345
> > network 192.10.1.0 0.0.0.255 area 345
> > neighbor 130.1.45.4
> >
> > The above are the relevant config's of R4 and R5.
> >
> > Even though I tried removing the neighbor statement from
> > each side in turn - to see if it needed to be on one particular side -
> >
> > the results were the same. No adjacency!!!
> >
> > Are you suggesting there's a way R4 and R5 can
> >
> > become adjacent using the neighbor statement on only one side?
> >
> > And, if so, which side? The one with the demand circuit or the other
> side?
> >
> > Thanks alot, Tim
> >
> > ----- Original Message -----
> > From: "marvin greenlee" <marvin@ccbootcamp.com>
> > To: "'ccie2be'" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
> > Sent: Tuesday, January 11, 2005 12:15 PM
> > Subject: RE: ospf over isdn using unicasts - Problem solved
> >
> >
> > > Lee,
> > > Having the wrong name in the dialer map doesn't necessarily prevent
the
> > > connection from coming up.
> > >
> > > Tim,
> > > Your dead time shows as '-'. Are you also running an OSPF demand
> circuit?
> > > The neighbor statement will INITIATE the connection. If the side
> WITHOUT
> > > the neighbor statement had it's process cleared, it would not initiate
> > > traffic (with that network type for OSPF). The side with the neighbor
> > > statement may think that everything is fine because of the demand
> circuit,
> > > and show a 'full' adjacency.
> > >
> > > I don't have that workbook, so I don't know if the demand circuit is
> part
> > of
> > > a requirement for the same section, or a different section.
> > >
> > > - Marvin Greenlee, CCIE#12237, CCSI# 30483
> > > Network Learning Inc
> > > marvin@ccbootcamp.com
> > > www.ccbootcamp.com (Cisco Training)
> > >
> > >
> > > -----Original Message-----
> > > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > > Sent: Tuesday, January 11, 2005 4:41 AM
> > > To: marvin greenlee; ccielab@groupstudy.com
> > > Subject: Re: osfp over isdn using unicasts - Problem solved
> > >
> > > Hi Marvin,
> > >
> > > This morning I discovered some strange but interesting things.
> > >
> > > Last night, after I gave up on this, I left the configs as they were,
> ie,
> > >
> > > no adjacency between R4 and R5 and with the isdn link flapping up &
> down.
> > >
> > > This morning, when I checked, R4 and R5 had become adjacent.
> > >
> > > So, I wondered if maybe the problem was that I had set the
idle-timeouts
> > too
> > >
> > > short at 25 seconds. After removing the idle-timeouts from both sides
> and
> > >
> > > shutting and then no shutting the bri interface, the adjacency came
up.
> > >
> > > Then I did an experiment.
> > >
> > > I changed the config which had the neighbor command on both sides
> > >
> > > so that the neighbor command was on only one side - R5.
> > >
> > > On the side without the neighbor command, on R4, it showed no
neighbors:
> > >
> > > Rack1R4#sh ip os n
> > >
> > > Rack1R4#
> > >
> > > While at the same time, R5 showed R4 as a neighbor:
> > > Rack1R5#sh ip os n
> > >
> > > Neighbor ID Pri State Dead Time Address
> > Interface
> > > 150.1.4.4 0 FULL/ - - 130.1.45.4
BRI0/0
> > > 150.1.3.3 0 FULL/ - 00:00:36 130.1.35.3
> > Serial0/0
> > > Rack1R5#
> > >
> > > After about 10 minutes, R5 stilled showed R4 as adjacent and had R4
> routes
> > >
> > > in it's route table while R4 showed no ospf adjacencies and didn't
have
> > any
> > > ospf routes:
> > >
> > > Rack1R5#sir os
> > > 130.1.0.0/16 is variably subnetted, 5 subnets, 3 masks
> > > O IA 130.1.33.0/24 [110/74] via 130.1.35.3, 00:17:10, Serial0/0
> > > O 130.1.45.4/32 [110/1562] via 130.1.45.4, 00:16:47, BRI0/0
> > > 150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
> > > O IA 150.1.4.4/32 [110/2562] via 130.1.45.4, 00:17:10, BRI0/0 <--
> R4's
> > > Lo0
> > > O IA 150.1.3.3/32 [110/65] via 130.1.35.3, 00:17:10, Serial0/0
> > > Rack1R5#sh ip os n
> > >
> > > Neighbor ID Pri State Dead Time Address
> > Interface
> > > 150.1.4.4 0 FULL/ - - 130.1.45.4
BRI0/0
> > > 150.1.3.3 0 FULL/ - 00:00:39 130.1.35.3
> > Serial0/0
> > > Rack1R5#
> > >
> > >
> > > Rack1R4#sh ip os n
> > >
> > > Rack1R4#sir os
> > >
> > > Rack1R4#sh ip rout ospf
> > >
> > > Rack1R4#
> > >
> > > How is it that R5 can think it's adjacent with R4 while R4
> > >
> > > is NOT adjacent to R5?
> > >
> > > After reconfiguring the neighbor on R4, the adjacency from R4's
> > >
> > > point of view comes back.
> > >
> > > Rack1R4#c
> > > Enter configuration commands, one per line. End with CNTL/Z.
> > > Rack1R4(config)#router os 1
> > > Rack1R4(config-router)#nei 130.1.45.5
> > > Rack1R4(config-router)#
> > > Rack1R4#
> > > *Mar 6 11:07:04.251: %SYS-5-CONFIG_I: Configured from console by
> console
> > > Rack1R4#sh ip os n
> > >
> > > Neighbor ID Pri State Dead Time Address
> > Interface
> > > N/A 0 DOWN/ - - 130.1.45.5
BRI0/0
> > > Rack1R4#
> > > *Mar 6 11:07:21.515: %LINK-3-UPDOWN: Interface BRI0/0:1, changed
state
> to
> > > up
> > > Rack1R4#
> > > *Mar 6 11:07:22.555: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> > > BRI0/0:1,
> > > changed state to up
> > > Rack1R4#
> > > *Mar 6 11:07:27.519: %ISDN-6-CONNECT: Interface BRI0/0:1 is now
> connected
> > > to 22
> > > 21 ROUTER5
> > > Rack1R4#sh ip os n
> > >
> > > Neighbor ID Pri State Dead Time Address
> > Interface
> > > N/A 0 DOWN/ - - 130.1.45.5
BRI0/0
> > > Rack1R4#
> > > *Mar 6 11:08:11.003: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.5.5 on
BRI0/0
> > > from LO
> > > ADING to FULL, Loading Done
> > > Rack1R4#sh ip os n
> > >
> > > Neighbor ID Pri State Dead Time Address
> > Interface
> > > 150.1.5.5 0 FULL/ - 00:01:52 130.1.45.5
BRI0/0
> > > Rack1R4#
> > >
> > > Strange, isn't it?
> > >
> > > My conclusion: the neighbor statement is required on both sides of the
> > link.
> > > Do you agree?
> > >
> > >
> > > Thanks, Tim
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "marvin greenlee" <marvin@ccbootcamp.com>
> > > To: "'ccie2be'" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
> > > Sent: Tuesday, January 11, 2005 12:16 AM
> > > Subject: RE: osfp over isdn using unicasts [bcc][faked-from][bayes]
> > >
> > >
> > > > Works fine for me. What do 'debug ip ospf adj' and 'debug ip packet
> > > detail'
> > > > show you? Did you try saving configs and reloading your routers?
> > > >
> > > > - Marvin Greenlee, CCIE#12237, CCSI# 30483
> > > > Network Learning Inc
> > > > marvin@ccbootcamp.com
> > > > www.ccbootcamp.com (Cisco Training)
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > > > ccie2be
> > > > Sent: Monday, January 10, 2005 8:14 PM
> > > > To: Group Study
> > > > Subject: osfp over isdn using unicasts [bcc][faked-from][bayes]
> > > > Importance: Low
> > > >
> > > > Hi guys,
> > > >
> > > > Has anyone gotten this to work?
> > > >
> > > > This is from IEWB lab 15, task 5.21.
> > > >
> > > > According to IE, the config should be fairly simple and like this:
> > > >
> > > >
> > > > R4
> > > > int bri 0/0
> > > > ip ospf network point-to-multipoint non-broadcast
> > > > dialer map ip 130.1.45.5 name ROUTER5 5555
> > > >
> > > > ROUTER OSPF 1
> > > > net 130.1.45.0 0.0.0.255 area 345
> > > > neighbor 130.1.45.5
> > > >
> > > > R5
> > > >
> > > > int bri 0/0
> > > > ip ospf network point-to-multipoint non-broadcast
> > > > dialer map ip 130.1.45.4 name ROUTER5 4444
> > > >
> > > > ROUTER OSPF 1
> > > > net 130.1.45.0 0.0.0.255 area 345
> > > >
> > > >
> > > > Before changing to the above the config, I had established an ospf
> > > adjacency
> > > >
> > > > between R4 and R5. But, once I changed the config to the above,
> > > >
> > > > the ospf adjacency flapped between down and init.
> > > >
> > > > Any one have any ideas on what is needed to make this work.
> > > >
> > > > TIA, Tim
> > > >
> > > >
> _______________________________________________________________________
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:21 GMT-3