Re: Stubborn router.

I was not referring to something in particular.
I do teach classes, and courses tend to have features that are bug prone:
-new features are exercised
-bad configurations are usually made, cause people are just learning them

But it used to be the case that a reload was not one of the tools you
would resort to for fixing things. Not a common one at least.
Last week, it fixed 5 issues!
And... it is kind of stressfull, cause you look ate the config and you
think "it should be working" but it is not :(
When you tell someone "try reloading", it's not the best message about
quality of product, so to say :(

We are getting accustomed to "it's a new feature, bugs may be there".
Imagine something like "it's a new building, some floor may fall" :)
Or, "it's a new plane, it may dive ocasionally 5000 feet".
Wait! I saw that one somewhere :)

-Carlos

Paul Cosgrove @ 19/04/2009 10:16 -0200 dixit:
> Hi Carlos,
>
> What kind of issues are you referring to? Are you using FFF (flaky
> fancy features)?
>
> To be honest I do not think I have seen another (accidental) problem
> which required a reload, so thought this one quite unusual. I do reload
> sometimes to remove frame relay inverse arp entries, but have also found
> that removing the commands deletes those, at least in new IOS versions.
> My guess is that removing OSPF would have fixed the problem in this case
> as well, but a reload was slightly less effort. :-)
>
> Bugs are inevitable in complex software, but I've always found the
> mature releases of IOS solid enough. Where significant changes are
> introduced, bugs are likely to be more frequent - and as you would
> expect that seems to be the case with some of the newer code rewrites
> (e.g. early modular releases).
> Paul.
>
> Carlos G Mendioroz wrote:
>> Anyone noticing a "tendency" here ?
>> I very seldom resort to reload for fixing things, but latelly it IS
>> working more and more. This is a pitty.
>>
>> MS$ has made us so accustomed to fix by reloading that we care less and
>> less about this. We even have jokes about that (fixing a non functioning
>> MS car by stepping out and back in :)
>>
>> -Carlos
>>
>> Narbik Kocharians @ 18/04/2009 13:24 -0200 dixit:
>>
>>> Were you running Vista or NT?
>>>
>>> hahahaha just joking man. It has happened to me once on 12.4(19), i
>>> had to
>>> reload to get things going.
>>>
>>> On Sat, Apr 18, 2009 at 8:35 AM, Paul Cosgrove
>>> <paul.cosgrove_at_gmail.com>wrote:
>>>
>>>
>>>> Yes only on the hub router. Entered the commands and checked with
>>>> "show ip
>>>> ospf nei" but it showed no neighbor entries (no lines, regardless of
>>>> adj
>>>> state). Deleted the two neighbor config lines (or at least tried
>>>> to) and
>>>> re-entered the same commands and the neighbors are then recognised,
>>>> forming
>>>> full adjacencies. I then had duplicate lines in the config for each
>>>> neighbor.
>>>>
>>>> The router allowed me to remove the duplicate entries, but the
>>>> original two
>>>> lines could not be removed. I reloaded a few minutes after it
>>>> happened and
>>>> it has been fine since, but just thought it was an interesting bug.
>>>>
>>>> Paul.
>>>>
>>>>
>>>> Narbik Kocharians wrote:
>>>>
>>>>
>>>>> Paul,
>>>>>
>>>>> Are you configuring the neighbor commands on the HUB?
>>>>>
>>>>> On Sat, Apr 18, 2009 at 6:53 AM, Ahsan Mohiuddin
>>>>> <ahsan.mohiuddin_at_gmail.com>wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Yes we have seen this. Try rebooting the router; do the neighbor
>>>>>> commands
>>>>>> disappear? And while rebooting you see an error like "OSPF neighbor
>>>>>> command
>>>>>> is allowed only on non-broadcast interfaces". I think I saw it on
>>>>>> 12.4(17)
>>>>>>
>>>>>> On Fri, Apr 17, 2009 at 10:54 PM, Paul Cosgrove
>>>>>> <paul.cosgrove_at_gmail.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>> wrote:
>>>>>>> Just tried a simple topology with a hub and spoke non-broadcast
>>>>>>> ospf
>>>>>>> network. The neighbor commands did not take effect the first time
>>>>>>> around
>>>>>>> (no neighbors listed) and clearing ospf had no effect. To fix it I
>>>>>>> tried
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> to
>>>>>>
>>>>>>
>>>>>>
>>>>>>> remove and reapply the neighbor commands. Neighbor relationships
>>>>>>> are
>>>>>>> now
>>>>>>> formed, but it has left me with an interesting configuration. I
>>>>>>> guess
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> my
>>>>>>
>>>>>>
>>>>>>
>>>>>>> router is being a little stubborn today. :-)
>>>>>>>
>>>>>>> router ospf 1
>>>>>>> log-adjacency-changes
>>>>>>> network 141.1.0.0 0.0.0.255 area 1
>>>>>>> network 141.1.123.0 0.0.0.255 area 0
>>>>>>> network 150.1.2.0 0.0.0.255 area 0
>>>>>>> neighbor 141.1.123.3
>>>>>>> neighbor 141.1.123.1
>>>>>>> neighbor 141.1.123.1
>>>>>>> neighbor 141.1.123.3
>>>>>>> !
>>>>>>>
>>>>>>> Anyone else see this in 12.4(23) or other releases?
>>>>>>>
>>>>>>> Paul.
>>>>>>>
>>>>>>>
>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>
>>>>>>> _______________________________________________________________________
>>>>>>>
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>
>>>>>> _______________________________________________________________________
>>>>>>
>>>>>> Subscription information may be found at:
>>>>>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net