Re: (usr-tc) Continuing OSPF problems
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) * mandrews@dcr.net * 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 "majordomo@xmission.com" 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) signal@shreve.net 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 "majordomo@xmission.com" 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.
Thus spake Brian
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.
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.
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.
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 DR.......
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Tuesday, November 16, 1999 8:55 AM |To: usr-tc@lists.xmission.com |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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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
-- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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) signal@shreve.net 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 "majordomo@xmission.com" 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.
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Tuesday, November 16, 1999 10:43 AM |To: usr-tc@lists.xmission.com |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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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.
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.
Yes, it would appear that fra-ts2 is not establishing adjacency with the DR.......
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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) signal@shreve.net 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 "majordomo@xmission.com" 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.
Thus spake Brian
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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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) * mandrews@dcr.net * 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 "majordomo@xmission.com" 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.
I opened the Bug (MR) today.. Hope to have some resolution soon.. Good catch.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, November 16, 1999 11:43 AM |To: usr-tc@lists.xmission.com |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) * mandrews@dcr.net * 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 "majordomo@xmission.com" | 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. | - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 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. :/
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. :)
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Tuesday, November 16, 1999 12:12 PM |To: usr-tc@lists.xmission.com |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 * - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Thus spake Mike Wronski
|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.
Semantics. :)
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.
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. :)
|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. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
|>|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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Thus spake Mike Wronski
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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 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: 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 (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.) Mike Andrews (MA12) * mandrews@dcr.net * 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 "majordomo@xmission.com" 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.
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. :)
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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, November 16, 1999 1:57 PM |To: usr-tc@lists.xmission.com |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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Tue, 16 Nov 1999, Mike Wronski wrote:
What about "list rtab prefered"? It is the "Routing Table". The "LIST IP 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. Mike Andrews (MA12) * mandrews@dcr.net * 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 "majordomo@xmission.com" 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.
participants (4)
-
Brian -
Jeff Mcadams -
Mike Andrews -
Mike Wronski