Thanks for reply,
I'll try to explain situation in more detail. It's simple but still a
little bit challenging.
When you create a new EIGRP neighbor adjacency, you need to do this
sequence:
Router A Router B
(just booted) (up and running)
(1)---------------->
HELLO (multicast) <---------------- (2)
Seq=0, Ack=0 HELLO (multicast)
Seq=0, Ack=0
<---------------- (3)
UPDATE (unicast)
Seq=10, Ack=0, INIT
(4)----------------> UPDATE 11 is queued
UPDATE (unicast)
Seq=100, Ack=10, INIT <---------------- (5)
UPDATE (unicast)
Seq=11, Ack=100, EOT
(6)--------------->
ACK (unicast)
Seq=0, Ack=11
Our sequence works correctly and reliably, but still I want to optimize
it to achieve state above. In Quagga, we send UPDATE INIT with Ack 0
immediately, after hearing new hello on the interface. First INIT should
be acknowledged in another INIT from other side (not in general Ack
packet), otherwise we cannot proceed in sequence. Second, remaining INIT
is then acknowledged in EOT UPDATE(step 5 in above diagram) . This is
optimal sequence from RFC.
In Quagga<->Cisco, we both send UPDATE INIT with Ack 0 to each other and
then wait for INIT Ack from other side. Cisco waits 2 seconds of
retransmission timer and sends the same INIT, but now with Ack correctly
set to Sequence No. of my INIT. Then I can continue to EOT packet and
ack his UPDATE INIT. This introduces a little delay and sometimes 1 or
more not needed packets sent.
In Cisco<->Cisco environment you will never see this. Especially in 15.x
version, where it works just like in RFC. They always somehow decide,
who should start with INIT process. Only starting router sends UPDATE
INIT with Ack 0. Not both like in our situation. No retransmissions,
only fast, optimized process without any not needed packets.
I remember from a meeting with Cisco's EIGRP developers, they've
mentioned something like random little delay before first INIT, which
ensures that one of the routers will go first and second can send his
optimized INIT with Ack. Now I would like to try something similar. To
delay sending of the first INIT UPDATE and if in a meanwhile I receive
INIT from other side, I would Acknowledge it in my delayed packet.
Hope it is sufficient and understandable explanation. I will appreciate
any help, or hint. Thanks in advance.
Best regards
Jan Janovic
On 15.01.2015 00:58, Donald Sharp wrote:
Why would you need to delay packet sending in EIGRP by a random amount?
Typically one stops another threads execution through an agreed upon
communication method. I'm not aware of a command to use to remotely
suspend another thread without using the agreed upon communication method.
In any event before any specific recommendations about what can be
done, it would be nice to have a more detailed description of the
problem that you are facing.
donald
On Wed, Jan 14, 2015 at 3:40 PM, Jan Janovic <[email protected]
<mailto:[email protected]>> wrote:
Hello community!
Is it possible to somehow pause specific thread in Quagga for
several miliseconds while not affecting work of other threads?
They would continue their jobs. I'm just thinking loudly. Maybe
it's stupid consideration.
I need to address one situation in our new EIGRP daemon, when it
would be best to delay packet sending for a little, but random
amount of time...and then decide what next. It's possible that in
a meanwhile, when thread is stopped, we will receive another
specific packet and the next step in previous stopped thread will
be slightly different.
I can provide you with more specific information if needed.
Thanks for info.
Best regards
Jan Janovic
_______________________________________________
Quagga-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
