You are correct Donald, retransmission is happening only when you don't
receive ack. And that's our situation at the beginning now. We BOTH
simultaneously send hello, and right after that NULL INIT with Ack 0 (we
are not aware at this moment about anything to ack) and we both wait for
ack from other side. After the retransmit timer, Cisco sends that same
NULL INIT again, but now with correct Ack number (now he already is
aware about my INIT) and initialization sequence can proceed.
This is the point. In Cisco<->Cisco topology they somehow decide, who
will start the INIT process. Only that one router sends NULL INIT with
Ack 0. Second router is in the moment of sending his NULL INIT aware,
that he needs to acknowledge previous first INIT. They skip this waiting
and retransmissions, etc. Just like it should be according to RFC.
And the way, how do they do that, is probably in a little random delay
before first INIT. This way, one of the routers will send his NULL INIT
always first, second one will receive it and Ack in his own NULL INIT.
Jan Janovic
On 1/15/2015 1:41 PM, Donald Sharp wrote:
Jan -
If a retransmission is happening then the ack for a packet was not
received. Are you sending the NULL update with the ACK seq # in it or not?
When a Hello is received for a new peer in EIGRP, it immediately sends
a HELLO packet and then immediately a NULL packet. The above sequence
of events does not state that. Are you doing that in the code?
donald
On Thu, Jan 15, 2015 at 5:23 AM, Jan Janovic <[email protected]
<mailto:[email protected]>> wrote:
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
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
