Hi Vipin,
Sorry for mis-reading the code.
I have started "router ospf" and "router ospf X" manually without
init.d/quagga script, and let them co-work correctly.
Would you please think of supporting the instance ID 0 in MI mode
again?
It would not be a big issue if no. But that will bring the users
a little trouble in switching from single-instance mode to multi-
instance mode if they are using vtysh.
One must be facing choices:
a) Either he must update his configuration files and all relative
management tools to add an instance ID now to change the original
"ospf" to "ospf 1" - this takes instant extra effort which he
may not want;
b) Or he must give up using vtysh, and develop a tool by himself.
From my point of view, it's important to keep the backward
compatibility in the way of configuration.
BTW: please don't forget to give an offset to the port for MI mode.
And is there a better way to show instance ID? (I have no yet,
sorry ;))
ubuntu# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, A - Babel, T - Table,
> - selected route, * - FIB route
K>* 0.0.0.0/0 via 10.0.2.2, eth0
C>* 10.0.2.0/24 is directly connected, eth0
C>* 10.1.0.1/32 is directly connected, loopback
O 100.2.0.0/24 [110/10] is directly connected, eth1, 00:10:38
C>* 100.2.0.0/24 is directly connected, eth1
O[1] 100.9.0.0/24 [110/10] is directly connected, eth2, 00:05:42
C>* 100.9.0.0/24 is directly connected, eth2
O>* 101.2.0.0/24 [110/20] via 100.2.0.1, eth1, 00:08:36
O[1]>* 101.9.0.0/24 [110/20] via 100.9.0.1, eth2, 00:00:22
Thanks and best regards,
Feng Lu
On 12/18/2014 07:05 AM, Vipin Kumar wrote:
Hi Feng,
On 12/15/14, 11:54 PM, "Feng Lu"<[email protected]> wrote:
Hi Vipin,
I see the single-daemon mode and multi-daemon mode are exclusive. Why?
I think this is not kind for users. For example:
Initially I started a single ospfd for my business. It was enough at
the time. But later my business grows. I need to start another one or
two ospfd for balance. How can I do it without stopping the original
one (that will break my running business)?
As such, adding a new ospfd without affecting the existing ones is handled
with the init.d/quagga script changes that Dinesh has posted.
Yes, user will have to move to the new code-base that has the MI support
(that restart cant be avoided in any case)
But once quagga comes up in MI mode (if we can use that term), then new
ospf daemons can be added without affecting the existing OSPF daemons or
zebra.
From my point of view, it should not be difficult to support the
original mode - just allowing the instance ID to grow from 0 instead
of the current 1. A little more code needs to be added to handle the
special instance ID 0, which means the original mode (use ospfd.conf,
ospfd.pid and ospfd.vty instead of ospf-X.yyy).
So, your point is specifically about the co-existence of ..
router ospf
And
router ospf x
Didn¹t think it would be needed. But yes, like you said, with some changes
in the posted patch it can be supported too.
One benefit of excluding Œrouter ospf¹ or Œinstance-id 0¹ from MI mode is
that show/debug commands could be made to work for all the instances when
no instance-id specification is given.
If we go with this co-existence, we will need to introduce some keyword in
all the commands to have a command for that purpose. I at that time
thought it was nice to see that without keyword it would work for all.
rtr# show ip ospf neighbor
OSPF Instance: 1
Neighbor ID Pri State Dead Time Address Interface
RXmtL RqstL DBsmL
0.0.2.1 1 Full/DR 2.624s 210.2.0.2
swp1:210.2.0.1 0 0 0
OSPF Instance: 2
Neighbor ID Pri State Dead Time Address Interface
RXmtL RqstL DBsmL
0.0.2.2 1 Full/DR 2.623s 210.2.1.2
swp2:210.2.1.1 0 0 0
OSPF Instance: 3
Neighbor ID Pri State Dead Time Address Interface
RXmtL RqstL DBsmL
0.0.2.3 1 Full/DR 2.622s 210.2.2.2
swp3:210.2.2.1 0 0 0
Regards,
Vipin
Best regards,
Feng Lu
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
