Re: OSPF redistribute connected issue

From: Bob Sinclair (bob@bobsinclair.net)
Date: Sun Sep 25 2005 - 20:48:24 GMT-3


Blake,

There is an article called "
Why Are Some OSPF Routes in the Database but Not in the Routing Table?"

I am sure everyone on this list will want to be familiar with the seven
reasons it provides.

See:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009481a.
shtml

HTH,

Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net

  ----- Original Message -----
  From: Blake Silvester
  To: ccielab@groupstudy.com
  Sent: Sunday, September 25, 2005 7:36 PM
  Subject: RE: OSPF redistribute connected issue

  I got stuck with the same issue a week ago, took several hours before I
  worked out what was going wrong. And couldn't see anything enlightening
  in any debug, in the end I just started changing things until it came
  right.

  Anyone know of any other situations where the ospf peerings will come
  up, but no routes will be accepted into the route table despite being
  seen in the ospf database?

  Blake S.

  -----Original Message-----
  From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
  Scott Morris
  Sent: Sunday, 25 September 2005 01:26
  To: 'Schulz, Dave'; 'Brian Dennis '; ccielab@groupstudy.com
  Subject: RE: OSPF redistribute connected issue

  The adjacency will come up nicely, but your routes won't propogate
  properly.

  As a simple way to look at it, think of it like childish politics! The
  side
  that believes there's supposed to be a DR generally ends up being the DR
  (nobody else applies). And when you are the DR, you believe that you
  are
  the only one who is allowed to give authoratative announcements to the
  network. Then, all of a sudden there's this other router that start
  spouting things off and not playing by the rules ('cause it didn't have
  the
  same rule list).

  You'll get information announced, but believe it's not valid.

  Just confuses everyone. :) Unfortunately, this wasn't part of the spec
  for
  "will not peer" rules.

  Go figure.

  Scott

  -----Original Message-----
  From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
  Schulz, Dave
  Sent: Saturday, September 24, 2005 6:27 PM
  To: Brian Dennis ; ccielab@groupstudy.com
  Subject: RE: OSPF redistribute connected issue

  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 map 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-adjacency-changes
   redistribute connected metric 20 metric-type 1 subnets network
  192.168.5.0
  0.0.0.255 area 1

  Dave

  _______________________________________________________________________
  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 communication, including any attachments, is confidential.
  If you are not the intended recipient, you should not read
  it - please contact me immediately, destroy it, and do not
  copy or use any part of this communication or disclose
  anything about it. Thank you. Please note that this
  communication does not designate an information system for
   the purposes of the Electronic Transactions Act 2002."

  _______________________________________________________________________
  Subscription information may be found at:
  http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:16 GMT-3