Subject: Re: (usr-tc) Continuing OSPF problems

From: Brian <[email-masked]>
Date: Tue, 16 Nov 1999 16:42:43 +0000

> 
> This popped up today when I needed to add an NM-4T to our Cisco 3620,
> which is set to the highest OSPF priority so that it normally becomes the
> DR, and our 2611 becomes the BDR.  Power cycling to add the NM-4T made
> this swap, of course, so right now the 2611 is the DR and the 3620 is the
> BDR.  Normal enough...

If I remember right it doesn't work like that.  When you have a DR and a
BDR, and you reboot the DR, yes the BDR becomes the DR.  But then when the
"old" DR comes back up it does not become BDR.  You have to reboot your
other box (the original BDR , now DR) for this too happen.  In other
words, the cluenote I remember is "2 reboots are necessary for a
re-election of OSPF DR/BDR".

This may be Ciscocentric, I don't remember.

> 
> However, both the ARCs on the subnet suddenly stopped advertising their IP
> pools, and stopped listening to advertisements from the other routers...
> basically quit exchange OSPF routes entirely.  Naturally, our dialup
> customers weren't real happy about this.  Rebooting the ARCs got things
> back into shape - a bit drastic of a solution.

I wonder if somehow the ospf database got fscked.  I think OSPF does a
"flood" every 30 minutes or so, and rebooting the 3com box would have
forced at least an initial flood.

> 
> I may have narrowed this down a bit more this time though.  
> 
> Cranking out a listing of OSPF neighbors indicates that maybe the ARC is
> having trouble talking to the new DR at all.
> 
> Here is the current DR (206.240.130.3):
> 
> fra2>show ip ospf nei
> 
> Neighbor ID     Pri   State           Dead Time   Address
> Interface
> fra-ts1.dcr.net   0   FULL/DROTHER    00:00:35    206.240.130.12  Ethernet0/0
> fra1-e0-0.dcr.n  50   FULL/BDR        00:00:31    206.240.130.1   Ethernet0/0
> dusty.dcr.net     0   FULL/DROTHER    00:00:32    206.240.130.7   Ethernet0/0
> fra3-e0.dcr.net  20   FULL/DROTHER    00:00:33    206.240.130.4   Ethernet0/0
> fra-ts2.dcr.net   0   EXSTART/DROTHER 00:00:32    206.240.130.14  Ethernet0/0
> andrew.dcr.net    0   FULL/DROTHER    00:00:35    206.240.130.2   Ethernet0/0

Yes, it would appear that fra-ts2 is not establishing adjacency with the
DR.......

> 
> The BDR (206.240.130.1):
> 
> fra1>show ip ospf nei
> 
> Neighbor ID     Pri   State           Dead Time   Address         Interface
> fra-ts1.dcr.net   0   FULL/DROTHER    00:00:33    206.240.130.12  Ethernet0/0
> fra2-e0-0.dcr.n  40   FULL/DR         00:00:38    206.240.130.3   Ethernet0/0
> fra3-e0.dcr.net  20   FULL/DROTHER    00:00:32    206.240.130.4   Ethernet0/0
> fra-ts2.dcr.net   0   FULL/DROTHER    00:00:30    206.240.130.14  Ethernet0/0
> andrew.dcr.net    0   FULL/DROTHER    00:00:34    206.240.130.2   Ethernet0/0
> dusty.dcr.net     0   FULL/DROTHER    00:00:30    206.240.130.7   Ethernet0/0
> office1.dcr.net  15   FULL/  -        00:00:32    199.77.100.18   Serial1/0
> law1-e0.dcr.net  20   FULL/  -        00:00:39    199.77.100.26   Serial1/1
> 
> fra-ts1 (206.240.130.12) is an ARC that was sick and was rebooted to fix
> the problem:
> 
> fra-ts1> list ospf nei
> OSPF NEIGHBORS
> IfIpAddr/IfInd  RouterId        Area    Prior.  State    Event QLen  Status
> 206.240.130.1   206.240.130.1   TRANSIT 50      Full/BDR 6     0     dynamic
> 206.240.130.2   128.167.1.69    TRANSIT 0       TwoWay   2     0     dynamic
> 206.240.130.3   206.240.130.3   TRANSIT 40      Full/DR  6     0     dynamic
> 206.240.130.4   206.240.130.4   TRANSIT 20      TwoWay   4     0     dynamic
> 206.240.130.7   206.240.130.7   TRANSIT 0       TwoWay   2     0     dynamic
> 206.240.130.14  206.240.130.14  TRANSIT 0       TwoWay   4     0     dynamic
> 
> fra-ts2 (206.240.130.14) is an ARC that was and still is sick right now
> (it won't advertise its IP pool, and its routing table has only default,
> itself, loopback, and the LAN).  Fortunately it has no live modems at the
> moment, so I can leave it this way for testing:
> 
> fra-ts2> list ospf nei
> OSPF NEIGHBORS
> IfIpAddr/IfInd  RouterId        Area    Prior.  State    Event QLen  Status
> 206.240.130.1   206.240.130.1   TRANSIT 50      Full/BDR 6     0     dynamic
> 206.240.130.2   128.167.1.69    TRANSIT 0       TwoWay   2     0     dynamic
> 206.240.130.3   206.240.130.3   TRANSIT 40      ExStart  3     0     dynamic
> 206.240.130.4   206.240.130.4   TRANSIT 20      TwoWay   2     0     dynamic
> 206.240.130.7   206.240.130.7   TRANSIT 0       TwoWay   2     0     dynamic
> 206.240.130.12  206.240.130.12  TRANSIT 0       TwoWay   2     0     dynamic
> 
> Basically the newly appointed DR is stuck in "exstart" state with the sick
> ARC.  Any pointers as to which debug flags I should turn on to figure out
> why?  I'm still not quite to the OSPF Guru state yet.

You can debug ospf adjacency information on the Cisco.  The last time I
had adjacency problems it was a bad PtP t1 circuit.  check for any wierd
ping/packet loss between fra-ts2 and the DR.

> 
> 
> Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
> VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
> Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
> "With sufficient thrust, pigs fly just fine." -- RFC 1925
> 
> 
> -
>  To unsubscribe to usr-tc, send an email to "[email-masked]"
>  with "unsubscribe usr-tc" in the body of the message.
>  For information on digests or retrieving files and old messages send
>  "help" to the same address.  Do not use quotes in your message.
> 

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 16 Nov 1999 16:59:24 +0000

Thus spake Brian

>This may be Ciscocentric, I don't remember.

No, this is standard OSPF, but I think you're violently agreeing with
Mike here.  :)  Originally the 3620 was DR, the 2611 was BDR, rebooting
the 3620 should advance the 2611 to DR, and since I believe those two
are the only two eligible DR's on this network for him, for the time
the 3620 is down, there would be no BDR, when the 3620 comes back up,
and "election" would occur for BDR, which the 3620 would "win" (running
unopposed :).  So they are swapped from the original.  To get back to
the 3620 being DR and 2611 being BDR, then, yes, the 2611 would have to
be brought down.

>forced at least an initial flood.

To my knowledge (and I'd have to go back and check the RFC to be sure)
once the databases are sync'ed, there are no periodic floods.

>Yes, it would appear that fra-ts2 is not establishing adjacency with the

Which is rather interesting since it should have had an adjacency
established long before that (when the thing was still just a BDR, the
adjacency shouldn't be affected when a router gets advanced from BDR to
DR), unless I misread the posting.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Wronski <[email-masked]>
Date: Tue, 16 Nov 1999 17:45:10 +0000

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Jeff Mcadams
|Sent: Tuesday, November 16, 1999 8:55 AM
|To: [email-masked]
|Subject: Re: (usr-tc) Continuing OSPF problems
|
|
|Thus spake Brian
|>I wonder if somehow the ospf database got fscked.  I think OSPF does a
|>"flood" every 30 minutes or so, and rebooting the 3com box would have
|>forced at least an initial flood.
|
|To my knowledge (and I'd have to go back and check the RFC to be sure)
|once the databases are sync'ed, there are no periodic floods.
|

Actually an OSPF route must be readvertised/flooded every MaxAge minutes or
it is removed from the active table. MaxAge is usually 30 minutes but may be
vendor specific. See section 14 of the RFC..

-M

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 16 Nov 1999 17:48:34 +0000

Thus spake Mike Wronski
>vendor specific. See section 14 of the RFC..

Ah...indeed...that's true...I was thinking flooding more in the terms of
RIP, where the whole database of the router was flooded out, rather than
an individual LS entry.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Brian <[email-masked]>
Date: Tue, 16 Nov 1999 18:48:56 +0000

> once the databases are sync'ed, there are no periodic floods.

Their is, I am not sure what the timer is though.  When an LSA is sent, it
could get missed by a router, and if that happens, since LSA's are not
ACK'ed, you have an unsyncronized database.....bad thing.  But the floods
take care of that.  I mean, I may be wrong too, I am just going off what I
have been taught, I never actually debugged and watched the flood.

-

---

From: Brian <[email-masked]>
Date: Tue, 16 Nov 1999 18:50:00 +0000

> RIP, where the whole database of the router was flooded out, rather than

Well, it is very flood like, because when you first boot an OSPF router,
all the LSA's come in to that router.  So all the LSA's (intial anyways),
will be re-flooded in 30 minutes.

So, what I am hearing, is that each LSA has its own MaxAge?  Thats pretty
cool, but on 30 minute intervals from the time you established adjacency,
you will probably get "floods" since that would be the bulk of the
database.......

Brian

-

---

From: Mike Wronski <[email-masked]>
Date: Tue, 16 Nov 1999 18:56:54 +0000

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Brian
|Sent: Tuesday, November 16, 1999 10:43 AM
|To: [email-masked]
|Subject: Re: (usr-tc) Continuing OSPF problems
|
|
|On Tue, 16 Nov 1999, Jeff Mcadams wrote:
|
|> Thus spake Mike Wronski
|> >Actually an OSPF route must be readvertised/flooded every 
|MaxAge minutes or
|> >it is removed from the active table. MaxAge is usually 30 
|minutes but may be
|> >vendor specific. See section 14 of the RFC..
|> 
|> Ah...indeed...that's true...I was thinking flooding more in the terms of
|> RIP, where the whole database of the router was flooded out, rather than
|> an individual LS entry.
|
|Well, it is very flood like, because when you first boot an OSPF router,
|all the LSA's come in to that router.  So all the LSA's (intial anyways),
|will be re-flooded in 30 minutes.
|
|So, what I am hearing, is that each LSA has its own MaxAge?  Thats pretty
|cool, but on 30 minute intervals from the time you established adjacency,
|you will probably get "floods" since that would be the bulk of the
|database.......
|
|Brian

YOU are correct sir..

-M

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 16 Nov 1999 19:32:55 +0000

Thus spake Brian

>Their is, I am not sure what the timer is though.  

Having now gone back and check the RFC a bit.  :)

MaxAge is 1 hour.

>When an LSA is sent, it could get missed by a router, and if that
>happens, since LSA's are not ACK'ed, 

Eh?  LSA's are indeed ack'ed.  LSA's are sent in Link State Update
packets, and acknowledged (individually...but can be grouped into a
single packet) in Link State Acknowledgement packets, or possibly in
another Link State Update packet.

>you have an unsyncronized database.....bad thing.  But the floods take
>care of that.  

If re-flooding were needed to ensure consistency, the convergence time
of OSPF would royally suck...would be best measured in hours based on
MaxAge.

>I mean, I may be wrong too, I am just going off what I have been
>taught, I never actually debugged and watched the flood.

Read the RFC...best way really to understand it.  As a warning
though...it may take a while to slog your way through it...they're
defintely not light reading.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Tue, 16 Nov 1999 19:50:26 +0000

> re-election of OSPF DR/BDR".

Turns out that it really doesn't matter who the DR/BDR is, or what the RFC
says about LSAs or floods :)

The real problem is that the ARC is letting less specific routes override
more specific routes, and thus confusing itself about its own netmask.  
That's apparently why communication fails with the new DR:

> > fra-ts2> list ip route
> >
> > IP ROUTES
> > Destination        Prot   NextHop         Metric  Interface
> >         0.0.0.0/0  NetMgr 206.240.130.1   1       eth:1
> >       127.0.0.1/H  LOCAL  127.0.0.1       1       loopback
> >   206.240.130.0/23 LOCAL  206.240.130.1   1       eth:1
> >  206.240.130.14/H  LOCAL  206.240.130.14  1       eth:1
> >
> > This points out a problem I've brought up before.  The subnet mask on this
> > LAN should be /25, not /23.  There is a /23 route being advertised by the
> > Cisco that points at fra1's Null0 though (for BGP4 purposes) and this is
> > somehow getting confused with the local netmask set on the eth:1
> > interface, which is set correctly:
>
> Ok, fra1 is that your border?  Are you injecting static routes into the
> IGP at all?  I use tiedowns for my BGP routes as well.........you want to
> set these with a HIGH administrative weight, of like 250 though, so they
> don't get used.  Do you have a weight set on them?

Yeah, fra1 is the border (3620).  The null0 tiedown routes have a "250"
distance metric on the end (used to be 10 til last night), and those
routes are getting injected into OSPF.  The ARC still uses them whether
the metric is 10 or 250... it seems to ignore the metric.

The only way I was able to make things sane was to stop the tiedowns from
getting injected into OSPF at all.  I haven't yet figured out how to stop
just those routes from getting injected without shutting down
redistribution of ALL static routes.  (Fortunately there aren't many other
static routes, so for now, this is what I've done.)  I had tried various
combinations of distribute-list on the Cisco, as well as receivepolicy on
the ARC, and didn't have much luck.  I'm sure there's a better way to do
it though. :)

The screwed up netmask caused by this is *definitely* what's making it
stick in ExStart.  I did find a workaround that did NOT require rebooting,
finally:

   reconfig ip network ip addr 206.240.130.14/25  (to fix the mask)
   disable ospf
   enable ospf

and voila, things start working again.  Of course the netmask goes back to
the wrong thing immediately after this, if you haven't stopped the
tiedowns from getting injected into OSPF...

> Also, using null0 as a tiedown used to be slow switched, so people used
> loopbacks, but I think now in later ios's this is not the case, and both
> can be used, but if you are running an older version you may want to
> consider that.

It's 11.3(11a)T1... about 2 months old.

-

---

From: Mike Wronski <[email-masked]>
Date: Tue, 16 Nov 1999 20:00:57 +0000

I opened the Bug (MR) today.. Hope to have some resolution soon.. Good
catch..

-M

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Mike Andrews
|Sent: Tuesday, November 16, 1999 11:43 AM
|To: [email-masked]
|Subject: Re: (usr-tc) Continuing OSPF problems
|
|
|On Tue, 16 Nov 1999, Brian wrote:
|
|> If I remember right it doesn't work like that.  When you have a DR and a
|> BDR, and you reboot the DR, yes the BDR becomes the DR.  But
|then when the
|> "old" DR comes back up it does not become BDR.  You have to reboot your
|> other box (the original BDR , now DR) for this too happen.  In other
|> words, the cluenote I remember is "2 reboots are necessary for a
|> re-election of OSPF DR/BDR".
|
|Turns out that it really doesn't matter who the DR/BDR is, or what the RFC
|says about LSAs or floods :)
|
|The real problem is that the ARC is letting less specific routes override
|more specific routes, and thus confusing itself about its own netmask.
|That's apparently why communication fails with the new DR:
|
|
|> > fra-ts2> list ip route
|> >
|> > IP ROUTES
|> > Destination        Prot   NextHop         Metric  Interface
|> >         0.0.0.0/0  NetMgr 206.240.130.1   1       eth:1
|> >       127.0.0.1/H  LOCAL  127.0.0.1       1       loopback
|> >   206.240.130.0/23 LOCAL  206.240.130.1   1       eth:1
|> >  206.240.130.14/H  LOCAL  206.240.130.14  1       eth:1
|> >
|> > This points out a problem I've brought up before.  The subnet
|mask on this
|> > LAN should be /25, not /23.  There is a /23 route being
|advertised by the
|> > Cisco that points at fra1's Null0 though (for BGP4 purposes)
|and this is
|> > somehow getting confused with the local netmask set on the eth:1
|> > interface, which is set correctly:
|>
|> Ok, fra1 is that your border?  Are you injecting static routes into the
|> IGP at all?  I use tiedowns for my BGP routes as well.........you want to
|> set these with a HIGH administrative weight, of like 250 though, so they
|> don't get used.  Do you have a weight set on them?
|
|Yeah, fra1 is the border (3620).  The null0 tiedown routes have a "250"
|distance metric on the end (used to be 10 til last night), and those
|routes are getting injected into OSPF.  The ARC still uses them whether
|the metric is 10 or 250... it seems to ignore the metric.
|
|The only way I was able to make things sane was to stop the tiedowns from
|getting injected into OSPF at all.  I haven't yet figured out how to stop
|just those routes from getting injected without shutting down
|redistribution of ALL static routes.  (Fortunately there aren't many other
|static routes, so for now, this is what I've done.)  I had tried various
|combinations of distribute-list on the Cisco, as well as receivepolicy on
|the ARC, and didn't have much luck.  I'm sure there's a better way to do
|it though. :)
|
|The screwed up netmask caused by this is *definitely* what's making it
|stick in ExStart.  I did find a workaround that did NOT require rebooting,
|finally:
|
|   reconfig ip network ip addr 206.240.130.14/25  (to fix the mask)
|   disable ospf
|   enable ospf
|
|and voila, things start working again.  Of course the netmask goes back to
|the wrong thing immediately after this, if you haven't stopped the
|tiedowns from getting injected into OSPF...
|
|
|> Also, using null0 as a tiedown used to be slow switched, so people used
|> loopbacks, but I think now in later ios's this is not the case, and both
|> can be used, but if you are running an older version you may want to
|> consider that.
|
|It's 11.3(11a)T1... about 2 months old.
|
|
|Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
|VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
|Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville
|"With sufficient thrust, pigs fly just fine." -- RFC 1925
|
|
|
|
|-
| To unsubscribe to usr-tc, send an email to "[email-masked]"
| with "unsubscribe usr-tc" in the body of the message.
| For information on digests or retrieving files and old messages send
| "help" to the same address.  Do not use quotes in your message.
|

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 16 Nov 1999 20:19:02 +0000

Thus spake Mike Andrews
>That's apparently why communication fails with the new DR:

Hrmm...ok...so its sending the wrong netmask...the netmask in the
routing table in the Hello packets....

So...that means that someone isn't paying attention to the Hello packets
in the normal course of operation.  Theoretically, sending a Hello
packet with the wrong netmask (as the Arc is doing) should destroy the
adjacency, should it not?  OK...a check of the RFC shows that I'm not
quite right here.  A mismatch on the Netmask should cause the Hello
packet to be dropped, which, after RouterDeadInterval time of no Hello
packets, the router should be declared down and the adjacency destroyed.
It seems that the Cisco is not doing the checks that it should here
either though in that its not killing the adjacency.

Just out of curiosity, what does a list ip networks, or show ip network
<blah> show for the netmask on that network after picking up the new
OSPF routes?

>the metric is 10 or 250... it seems to ignore the metric.

I believe administrative distance is a Cisco proprietary thing and is
not transmitted via OSPF.  The Arc's don't seem to have nearly the
control over route redistribution and such that the Cisco's do.  :/

>the ARC, and didn't have much luck.  I'm sure there's a better way to do

Hrmm...Cisco's web site seems to be broken at the moment, but I think
you'll need to put a route-map on the "redistribute static" clause in
router ospf for this to work.  Not sure exactly what distribute-list
does...
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Wronski <[email-masked]>
Date: Tue, 16 Nov 1999 21:09:18 +0000

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Jeff Mcadams
|Sent: Tuesday, November 16, 1999 12:12 PM
|To: [email-masked]
|Subject: Re: (usr-tc) Continuing OSPF problems
|
|
|Thus spake Mike Andrews
|>The real problem is that the ARC is letting less specific routes override
|>more specific routes, and thus confusing itself about its own netmask.
|>That's apparently why communication fails with the new DR:
|
|Hrmm...ok...so its sending the wrong netmask...the netmask in the
|routing table in the Hello packets....
|
|So...that means that someone isn't paying attention to the Hello packets
|in the normal course of operation.  Theoretically, sending a Hello
|packet with the wrong netmask (as the Arc is doing) should destroy the

HARC is not sending anything wrong in this case. It is doing something wrong
based on information it receives from the DR.
The card should not be changing its netmask for any reason. But it obviosly
is doing this when it receives a less specific route from the DR.

|adjacency, should it not?  OK...a check of the RFC shows that I'm not
|quite right here.  A mismatch on the Netmask should cause the Hello
|packet to be dropped, which, after RouterDeadInterval time of no Hello
|packets, the router should be declared down and the adjacency destroyed.
|It seems that the Cisco is not doing the checks that it should here
|either though in that its not killing the adjacency.
|
|Just out of curiosity, what does a list ip networks, or show ip network
|<blah> show for the netmask on that network after picking up the new
|OSPF routes?
|
|>Yeah, fra1 is the border (3620).  The null0 tiedown routes have a "250"
|>distance metric on the end (used to be 10 til last night), and those
|>routes are getting injected into OSPF.  The ARC still uses them whether
|>the metric is 10 or 250... it seems to ignore the metric.
|
|I believe administrative distance is a Cisco proprietary thing and is
|not transmitted via OSPF.  The Arc's don't seem to have nearly the
|control over route redistribution and such that the Cisco's do.  :/

Actually its not a Cisco thing. Its called Internal Distance in the RFC.
This information is used for tie breaking when equal cost routes are present
and the admin does have a preference.

-M
*

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 16 Nov 1999 21:30:17 +0000

Thus spake Mike Wronski

>based on information it receives from the DR.

Semantics.  :)

>is doing this when it receives a less specific route from the DR.

OK, the Arc is getting a less-specific route, accepting it and
installing it in the routing table instead of a more-specific one...a
no-no to begin with...then using that information in its Hello
information.  I guess its a matter of how its coded as to what the root
cause of the problem really is, but ultimately, the netmask value in the
Hello packets don't match what was configured on the interface...end
result, boo boo by the Arc.  :)

>and the admin does have a preference.

Uhm, no.  Administrative distance is used in Cisco's to determine which
route to use when multiple routes are present in different routing
protocols.  ie, connected routes have a lower admin distance (are
preferred) than statics, which are lower than eBGP, which is lower than
OSPF, which is lower than RIP, which is lower than iBGP.  There are
others in there of course (IS-IS, Hello, EGP, etc.), but those are the
main ones.  When you're putting in a static route, you can set it at a
specific administrative distance (ie, Mike was sticking them in at 250)
which means that the same route picked up by OSPF will be preferred over
the static one, when, by default, a static route will be used rather
than the OSPF.  Much the same type of thing can be done with routing
protocols...for example, I have two cisco's redistributing routes from
RIP into OSPF on one network...this causes problems based on the
administrative distance...the solution was to tell one router to deal
with OSPF at a higher administrative distance than RIP (so it preferred
the RIP routes over OSPF).  This prevented a nice loop in the routing
updates.  :)  This information is not transmitted in OSPF in any way.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Tue, 16 Nov 1999 21:38:56 +0000

> <blah> show for the netmask on that network after picking up the new

If you shut OSPF off and reboot, you get:

IP ROUTES
Destination        Prot   NextHop         Metric  Interface
        0.0.0.0/0  NetMgr 206.240.130.1   1       eth:1
      127.0.0.1/H  LOCAL  127.0.0.1       1       loopback
  206.240.130.0/25 LOCAL  206.240.130.14  1       eth:1
 206.240.130.14/H  LOCAL  206.240.130.14  1       eth:1
206.240.130.127/H  LOCAL  206.240.130.127 1       eth:1

Turn OSPF on (and static route redistribution on) and the third entry
becomes:

(Note LOCAL instead of OSPF.  Bad. :)  This is from memory as I don't
really want to reenable static route redistribution right now...)

This same thing happens on a different subnet -- a 208.6.168.0/22 and
208.6.168.0/25 route are both in the table, and it uses the /22 instead of
the /25.  Fortunately there are no ARCs on 208.6.168.0/25... but it's
still screwy.

What should probably happen is that it should probably put BOTH routes in
the table, rather than trying to pick between the two... then when making
routing decisions later, use the most specific.  I can see cases where
just throwing one of the two routes away would cause problems.  (Suppose
one of the routes goes down, for example.)

-

---

From: Mike Wronski <[email-masked]>
Date: Tue, 16 Nov 1999 21:45:06 +0000

|>|I believe administrative distance is a Cisco proprietary thing and is
|>|not transmitted via OSPF.  The Arc's don't seem to have nearly the
|>|control over route redistribution and such that the Cisco's do.  :/
|
|>Actually its not a Cisco thing. Its called Internal Distance in the RFC.
|>This information is used for tie breaking when equal cost routes
|are present
|>and the admin does have a preference.
|
|Uhm, no.  Administrative distance is used in Cisco's to determine which
|route to use when multiple routes are present in different routing
|protocols.  ie, connected routes have a lower admin distance (are
|preferred) than statics, which are lower than eBGP, which is lower than
|OSPF, which is lower than RIP, which is lower than iBGP.  There are
|others in there of course (IS-IS, Hello, EGP, etc.), but those are the
|main ones.  When you're putting in a static route, you can set it at a
|specific administrative distance (ie, Mike was sticking them in at 250)
|which means that the same route picked up by OSPF will be preferred over
|the static one, when, by default, a static route will be used rather
|than the OSPF.  Much the same type of thing can be done with routing
|protocols...for example, I have two cisco's redistributing routes from
|RIP into OSPF on one network...this causes problems based on the
|administrative distance...the solution was to tell one router to deal
|with OSPF at a higher administrative distance than RIP (so it preferred
|the RIP routes over OSPF).  This prevented a nice loop in the routing
|updates.  :)  This information is not transmitted in OSPF in any way.

Hrm.. I used it in a Cisco OSPF environment.. Further reading reveals that
you are correct. OSPF does have a similar feature in the internal distance.
This information is also NOT transmitted and is intended to help the
receiver make its final routing decision based on available information.

-M

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 16 Nov 1999 21:48:49 +0000

Thus spake Mike Andrews

>IP ROUTES

Yeah, but what about "list ip networks" or "show ip network <blah>"
rather than "list ip routes"?  ;)  I'm curious whether the actual
network definition changes or not.  :)

>routing decisions later, use the most specific.  

No "probably" to it.

>I can see cases where just throwing one of the two routes away would
>cause problems.  (Suppose one of the routes goes down, for example.)

Or even just look at the concept of classless routing...packets in the
more-specific route should be sent to the destination for the more
specific...that doesn't mean that there won't be packets destined for
the part of the less-specific route that isn't covered by the
more-specific...those packets should go to the less-specific (most
specific that it matches) next-hop.  To not keep both routes and pick
the most-specific for each packet is rather bogus routing behavior
actually.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 16 Nov 1999 21:51:52 +0000

Thus spake Mike Wronski
>receiver make its final routing decision based on available information.

Ya, for type 2 externals, if the external metric is equal, the internal
distance is considered to pick a preferred path...if *those* are equal,
I believe both paths are used with the normal equal-cost load-balancing
mechanism in OSPF.  You are correct that's it's not really transmitted
via OSPF, but the internal distance is built based on the information
transmitted in the OSPF protocol of course (basically the path cost from
the system in question to the ASBR that originated the LSA).  I suspect
you already knew all this though.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Tue, 16 Nov 1999 22:04:12 +0000

> network definition changes or not.  :)

Oh.  Duh. :)  (I'm not fully awake here... I was up reeeally late working
on this.)

"show ip network ip" does not change, from what I remember... the netmask
stays correct there.  So it's only screwing up the routing table, not the
network definition.  If I play around with it tonight I'll do a "list ip
networks" to see what happens there... but my guess is that it'll look
fine.

-

---

From: Mike Wronski <[email-masked]>
Date: Tue, 16 Nov 1999 22:12:26 +0000

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Mike Andrews
|Sent: Tuesday, November 16, 1999 1:57 PM
|To: [email-masked]
|Subject: Re: (usr-tc) Continuing OSPF problems
|
|
|On Tue, 16 Nov 1999, Jeff Mcadams wrote:
|
|> Thus spake Mike Andrews
|> >On Tue, 16 Nov 1999, Jeff Mcadams wrote:
|> >> Just out of curiosity, what does a list ip networks, or show
|ip network
|> >> <blah> show for the netmask on that network after picking up the new
|> >> OSPF routes?
|>
|> >If you shut OSPF off and reboot, you get:
|>
|> >IP ROUTES
|>
|> Yeah, but what about "list ip networks" or "show ip network <blah>"
|> rather than "list ip routes"?  ;)  I'm curious whether the actual
|> network definition changes or not.  :)
|
|Oh.  Duh. :)  (I'm not fully awake here... I was up reeeally late working
|on this.)
|
|"show ip network ip" does not change, from what I remember... the netmask
|stays correct there.  So it's only screwing up the routing table, not the
|network definition.  If I play around with it tonight I'll do a "list ip
|networks" to see what happens there... but my guess is that it'll look
|fine.

What about "list rtab prefered"? It is the "Routing Table". The "LIST IP
ROUTES" is the "Forwarding Table".

-M

-

---

From: Mike Andrews <[email-masked]>
Date: Wed, 17 Nov 1999 09:28:54 +0000

> ROUTES" is the "Forwarding Table".

Hm... didn't know that was there.  I went back and tried that (and Jeff's
'list ip networks') in three different states: one with OSPF shut off
entirely, one with the aggregate routes injected into OSPF (the broken
case) and one without them (the workaround case).

In all cases, "list ip networks" and "show ip network ip" show what they
ought to.

Rather than bore everyone else with this, I'll move this off list to you
two.

-