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]> 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]> 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] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> > > >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
