This is normal and expected behavior. You can't have two processes using the same interface. Which one will be active on the interface is "semi-random". However, interface level command is more specific than the network command and that is why your OSPF 2 took over from the first one. When you removed it, it simply kept on running, because it was still covered by the network command.
"Semi" random part comes because what you see as the order of operation at the moment you configure OSPF< may not be the same order you see after the reboot (where processes are sorted in decreasing fashion by process ID). To avoid this situation, you should avoid having two processes active on the interfaces, which is explicitly not supported by Cisco. -- Marko Milivojevic - CCIE #18427 Senior Technical Instructor - IPexpert FREE CCIE training: http://bit.ly/vLecture Mailto: [email protected] Telephone: +1.810.326.1444 Web: http://www.ipexpert.com/ On Tue, Sep 21, 2010 at 17:34, Bojan Zivancevic <[email protected]> wrote: > Just had a mental wrecking event. :) I am wondering if there is any logic > behind this, or just “one of those things.” > > > > Vol.1 Lab 10. OSPF. Task 10.14, entering the second process ID on R8. It has > the first process ID already running on F0/1 interface, enabled with the > network command. And, because it was a stub network at the beggining, I did > passive F0/1. > > > > Now, it is time to add the second process, and it will run on that F0/1 > interface. So, I put the network command – and nothing happened. OSPF showed > that no process is running on that interface. So, debugging, looking, > searching, you how it goes – I managed to do nothing. > > > > And it popped into my mind to try interface level command, to see what will > happen. And the moment I entered the ip ospf 2 area 0 command, OSPF got > started and formed a neighbor, like it should before. > > > > But then I removed that interface level command – and it continued to work, > but with different router ID value... That is to say, it proves that the “ip > ospf” process got killed, and then the new one from “network” command took > over. So, the network command now works. > > > > So, now everything is ok. But it is interesting how this happened. Like this > passive F0/1 from the first process killed any chance of running other OSPF > processes... Temporarely. :) > > > > Best Regards, > > > > Bojan Zivancevic > > Network Engineer > > ---- > > Comutel d.o.o. > > Omladinskih brigada 65v > > 11070 Belgrade > > SERBIA > > > > Tel: +381 11 217 8000 Ext.109 > > Mob: +381 64 646 8401 > > Fax: +381 11 6164641 > > > > http://www.comutel.co.rs > > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
