Re: Stubborn router.

Paul, definitely not "of course"...

Here I have a rotuer without any interfaces at all:

Router#sh ip int brie
Interface IP-Address OK? Method Status
Protocol
Router#

And I start all the routing protocols:

-----------------------------------------------------
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#router bgp 1
Router(config-router)#bgp router-id 1.1.1.1

Router(config)#router ospf 1
Router(config-router)#router-id 1.1.1.1

Router(config)#router eigrp 1
Router(config-router)#no auto

Router(config)#router odr
Router(config-router)#exit

Router(config)#router isis
Router(config-router)#exit

Router(config)#router iso-igrp SOMETAG
Router(config-router)#exit

Router(config)#router rip
Router(config-router)#no auto
-----------------------------------------------------

And after that:

Router#sh run | b router
router odr
!
router eigrp 1
 no auto-summary
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
!
router iso-igrp SOMETAG
!
router isis
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 no auto-summary
!
-----------------------------------------------------

So the conditions for all protocols are the same. Granted, they are quite
different. But in an interface and operational sense, ODR also functions by
sending out information every once in a while.
And look: ODR, EIGRP, OSPF, ISO-IGRP, ISIS, BGP are all seen in running
config, but not RIP.

And it's easy to trick RIP as well: apply network statement, create
interface, remove interface, remove network statement. And here is the
outcome:
-----------------------------------------------------
Router#sh run | section router rip
router rip
 version 2
 no auto-summary
Router#
Router#sh processes cpu | in RIP
 163 32 6 5333 0.00% 0.00% 0.00% 0 RIP Router
 164 4 3 1333 0.00% 0.00% 0.00% 0 RIP Send
 165 0 17 0 0.00% 0.00% 0.00% 0 RIP Timers
Router#
Router#sh ip int brie
Interface IP-Address OK? Method Status
Protocol
Router#
-----------------------------------------------------

So it sure as heck is running, and there are no interfaces. But it wasn't
the case at the beginning.

This is the phenomenon I was talking about

On Tue, Apr 21, 2009 at 5:56 PM, Paul Cosgrove <paul.cosgrove_at_gmail.com>wrote:

> If rip is not configured to run on any interfaces, then the other commands
> would be irrelevant of course. You do not have to format version 2
> messages if you do not have an interface to send them out, and you will not
> auto summarise routes if you don't have any routes. :-)
>
> In my case the router accepted commands, but ignored them. It was happy to
> show them to me, but not act on them or allow them to be removed from the
> config. Enter the exact same commands a second time and they are accepted
> and acted upon. All very rude if you ask me, I'll have to have words with
> that routers parents...
>
> Paul.
>
>
> Pavel Bykov wrote:
>
>> You're right, it should not.
>> But if you for example start RIP process, using the following commands:
>>
>> router rip
>> no auto summ
>> ver 2
>> redistribute connected
>>
>>
>> and then if you do a "show runn | s r r" (or "| b r r" if you're running
>> NON-T), you will not see a line regarding rip.
>> But once you go in the process configuration mode and add a network line,
>> like network 10.0.0.0
>> suddenly you'll see all the previous command appear in show runn.
>>
>>
>> On Tue, Apr 21, 2009 at 4:15 PM, Paul Cosgrove <paul.cosgrove_at_gmail.com
>> >wrote:
>>
>>
>>
>>> I'm missing a NOT in the last line....
>>>
>>>
>>> Paul Cosgrove wrote:
>>>
>>>
>>>
>>>> I did indeed confirm the network type, and also ran debugs which showed
>>>> that no hellos were sent out the interface. The problem was that the
>>>> router
>>>> configuration contained two neighbor commands which were not being
>>>> parsed.
>>>> The same two commands could be added a second time to the config (as
>>>> you
>>>> can see below). The router configuration should accept multiple copies
>>>> of
>>>> the same command, regardless of the ospf area type.
>>>>
>>>> Paul.
>>>>
>>>> Pavel Bykov wrote:
>>>>
>>>>
>>>>
>>>>> Just wondering, have you checked using "show ip ospf interface" for the
>>>>> operational network type?
>>>>>
>>>>> On Fri, Apr 17, 2009 at 7: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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>

-- 
Pavel Bykov
----------------
Don't forget to help stopping the braindumps, use of which reduces value of
your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net