From: alissitz@cisco.com
Date: Sat Sep 24 2005 - 20:45:50 GMT-3
Great question Dustin. I highly recommend doing the tests written
below. You may need to clear the OSPF process (in case OSPF does not
take the change quickly...) in between tests. Whenever possible, undo
your current test after you have observed the debugs and new / lost
routes on adjacent RTR.
Create a simple link between two peers over Ethernet, serial, ...
whatever. Configure OSPF between these two and share routes from
loopback interfaces so you see OSPF routes in the forwarding table.
RTR --- RTR --> very complex drawing ... ;--)
Clear the OSPF process and watch the activities and various states (this
is after you have a exchanged routes and have the debugs turned on)
Change the area id on one peer
Change the MTU on one peer
Make one peer have a stub
Change the network type on one
Change the hello timers
Change Authentication types on one
Configure another loop on either router to be in another area - See this
get advertised to the other RTR
Summarize this additional loop
Turn on debugs for OSPF events, adjacencies, hellos, and use the show ip
route command. For many of these tests there is a knob / command to
adjust and will fix the situation you created.
Question for all the folk out there (yes, all of us are kind of out
there... ) what are you favorite debug commands for OSPF or any other
router operation? I would like to try these in my lab :--). Kindest
regards everyone,
Andrew
________________________________
From: dusth@comcast.net [mailto:dusth@comcast.net]
Sent: Saturday, September 24, 2005 6:58 PM
To: Andrew Lissitz [alissitz@cisco.com]; Schulz, Dave; Brian Dennis ;
ccielab@groupstudy.com
Subject: RE: OSPF redistribute connected issue
Problem is hello-internal mismatch. Then, what if change the hello and
dead interval on r5 to match with hello interval on r2. Should ospf
exchange routing table then?
Regards,Dustin
-------------- Original message --------------
> debug ip ospf adj - will show any problems with advances
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf Of
> dusth@comcast.net
> Sent: Saturday, September 24, 2005 6:39 PM
> To: Schulz, Dave; Brian Dennis ; ccielab@groupstudy.com
> Subject: RE: OSPF redistribute connected issue
>
> What if both r2 and r5 are using physical frame-relay but r2
is
> configured with ip ospf p2p and r5 is configure with ip os
p2m? Since
> they are both physciall frame, should they are adjacence and
exchange
> routing?
>
> Regards, Dustin
>
> -------------- Original message --------------
>
> > Interesting! I thought that if you adjusted the hello/dead
timers to
> > agree at both ends of the circuit....that the adjacency
would come up
> > and everyone would be happy. Also, I did a debug ip ospf
events at
> > both R2 and R5 and nothing appeared out of the ordinary.
What is best
> > way to debug this if you run into such an issue (I like to
create
> > these "networks that should never happen" labesque type
scenarios)?
> >
> > Dave
> >
> > -----Original Message-----
> > From: Brian Dennis
> > To: Schulz, Dave; ccielab@groupstudy.com
> > Sent: 9/24/2005 3:32 PM
> > Subject: RE: OSPF redistribute connected issue
> >
> > Dave,
> > You have an OSPF network type mismatch. OSPF network types
that do not
>
> > use a DR (point-to-point and point-to-multipoint) can not
neighbor
> > with OSPF network types that do use a DR (broadcast and
> > non-broadcast). They will become "adjacent" with each other
if you
! > > ; adjust the hello timers but they won't become true
neighbors.
> >
> > HTH,
> >
> > Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> > bdennis@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987
> > Direct: 775-745-6404 (Outside the US and Canada)
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]
On Behalf
> Of
> > Schulz, Dave
> > Sent: Saturday, September 24, 2005 12:09 PM
> > To: ccielab@groupstudy.com
> > Subject: OSPF redistribute connected issue
> >
> > Group -
> >
> > Here is an issue that I am having under OSPF....
> >
> > R2 is connected R5 through a pt-pt frame. R2 is the ABR,
which has the
>
> > area 0
> > connection. The connection to R5 and R5 in in area 1. I have
a number
> > of
> > loopbacks set up on R5 (50.50.x.0)....and, when I
redistribute into
> > OSPF, I
> > can see them at R2 in the ospf database, but they are not
showing up
> in
> > the
> > routing table. And, because of this, the loopbacks are not
reachable
> at
> > the
> > spokes (other links out on the network connected to R2). Any
thoughts
> > on this
> > one?
> >
> >
> > R2 config.....
> >
> > interface Serial0
> > no ip address
> > encapsulation frame-relay
> > no frame-relay inverse-arp
> > frame-relay lmi-type cisco
> > !
> > interface Serial0.1 multipoint
> > ip address 192.168.3.2 255.255.255.0
> > ip ospf priority 255
> > frame-relay map ip 192.168.3.2 203
> > frame! -relay m ap ip 192.168.3.3 203 broadcast
> > frame-relay map ip 192.168.3.4 204 broadcast
> > no frame-relay inverse-arp
> > !
> > interface Serial0.2 point-to-point
> > ip address 192.168.5.2 255.255.255.0
> > ip ospf hello-interval 30
> > frame-relay interface-dlci 205
> > !
> > router ospf 1
> > log-adjacency-changes
> > network 192.168.3.0 0.0.0.255 area 0
> > network 192.168.5.0 0.0.0.255 area 1
> > neighbor 192.168.3.4
> > neighbor 192.168.3.3
> >
> >
> > On R5 the config is.....
> >
> > interface Loopback0
> > ip address 50.50.50.5 255.255.255.0
> > !
> > interface Loopback10
> > ip address 50.50.60.5 255.255.255.0
> > !
> > interface Loopback11
> > ip address 50.50.61.5 255.255.255.0
> > !
> > interface Loopback12
> > ip address 50.50.62.5 255.255.255.0
> > !
> > interface Loopback13
> > ip address 50.50.63.5 255.255.255.0
> > !
> > interface Loopback14
> > ip address 50.50.64.5 255.255.255.0
> > !
> > interface Loopback15
> > ip address 50.50.65.5 255.255.255.0
> > !
> > interface Loopback16
> > ip address 50.50.66.5 255.255.255.0
> > !
> > interface Loopback17
> > ip address 50.50.67.5 255.255.255.0
> > !
> > interface Loopback18
> > ip address 50.50.68.5 255.255.255.0
> > !
> > interface Serial0
> > ip address 192.168.5.5 255.255.255.0
> > encapsulation frame-relay
> > frame-relay map ip 192.168.5.2 502 broadcast
> > no frame-relay inverse-arp
> > frame-relay lmi-type cisco
> > !
> > router ospf 1
> > router-id 50.50.50.5
> > log-adj! acency-c hanges
> > redistribute connected metric 20 metric-type 1 subnets
> > network 192.168.5.0 0.0.0.255 area 1
> >
> > Dave
> >
> >
>
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:16 GMT-3