EIGRP SIA

d.hodgson · ‎09-10-2009

hi guru's,

I'm studying for my BSCI and trying to get to grips with EIGRP Stuck in Active. I understand the theory (I think) and according to the book "Cisco Press BSCI Third Edition" if you have a remote site with a FS pointing back to the core then an SIA condition will occur. I wanted to see this with my own eyes and so built a lab reflecting the books topology on page 122 (I used 1 remote site (R3) instead of 3). Yet when I disable a route (2.2.2.2) that route doesn't go SIA, it works immediatly, SIAQueries or SIA replies aren't even being used.

I've attached a drawing of the topology along with capture of "debug ip eigrp packets" and all router and L3 switch configs.

R3 is the remote site, SW2 and SW3 are in the data centre.

I've changed the bandwidth and delay on the links between the data centre and the remote site so the FS is chosen correctly.

On the attached drawing I've tried to visual each step, from query to reply along all the paths in sequence as they occur using EIGRP sequence numbers. I've not added the "received" packets apart from the first one in the sequence.

What I don't understand is how can SW2 send a reply (Step 15) about a route that's active and awaiting a reply from R3? According to the book it states that no route can send a query down the interface on which it received the query, yet this is exactly whats heppening at step 12.

Am I looking at this backward or something? I've used the sequence numbers to make sure the steps are in sequence but yet it just doesn't make sense to me.

Has Cisco used some new functionailty in EIGRP that has made it to the latest version of code?

on R3 I'm using c2600-adventerprisek9-mz.124-15.T8.bin

on SW2 I'm using c3560-ipservicesk9-mz.122-50.SE3.bin

On SW3 I'm using c3550-ipbasek9-mz.122-44.SE2.bin

thanks

Dave

simontibbitts · ‎09-10-2009

Hi Dave.

Yes there are 2 new messages, SIA Query and SIA Reply are in 12.2.

So now when a router goes active on a route and sends out queries, it also now sets a SIA-retransmit timer to half the active timer (90seconds). When this timer expires it now sends a SIA Query message to the neighbor it is waiting to hear a reply from. That neighbor replies with a SIA reply and the router resets its active timer and SIA-retransmit timer.

The originating router will attempt a total of three SIA Queries.

Why this is better is because it gives more of a chance for the SIA to complete as there are more queries sent out. It also has one very good advantage of only resetting the neighbor relationship between the two routers that have the problem and not all the neighbors in the query path.

SIA Query has an EIGRP opcode header value of 10 and SIA Replay has an EIGRP opcode header value of 11.

Simon

Peter Paluch · ‎09-10-2009

Hello Dave,

Regarding the step 15: Note that if the SW2 had not responded to R3, there would be a deadlock because the R3 would never receive a reply for its query so it would not ever be able to terminate the diffusing computation for itself. As I understand it, if an EIGRP router receives a query from anybody while being active, it just responds with its current (increased) distance from the destination. The article by Dr. Garcia describing the DUAL internals at

http://ccrg.soe.ucsc.edu/publications/jj.dual.ton93.pdf

suggests that it is completely normal (see the page 136 with the example where the node 'a' responds to multiple queries from its neighbors despite having them queried first).

The SIA state should be created only by transmission problems on the links or by some bug in the EIGRP code. The DUAL algorithm itself is proved to converge - there should be no deadlocks.

Best regards,

Peter

d.hodgson · ‎09-10-2009

Hi Peter,

so EIGRP is working as designed, so this shows the books descritpion maybe wrong. I've attached the pages from the book, can you please confirm? Or can you at least help me make sense of this?

many thanks

Dave

Peter Paluch · ‎09-11-2009

Hello Dave,

To me it seems that the book is incorrect on the subject. The SIA is not an issue in that network. If the RouterB receives queries from the spoke routers it just replies immediately with its present information about the rechability of the network after the topology change (which is 'unreachable' in the presented example). Note that by doing it, the RouterB only duplicates what it already has told its neighbors. The Query from the RouterB contained the information about the metric of the destination network 10.1.8.0/24, which was, after disconnecting, infinity. If any of those routers asks again using its own Query, the RouterB just responds with what it already told them - it sends a Reply with the inifite metric again. That's quite a logical thing to do, isn't it?

The EIGRP is a mystic protocol indeed. The articles of Dr. Garcia who authored the DUAL are indeed difficult to read and understand. Moreover, Cisco seems to implement some things differently or it at least describes some things differently in comparison to the original DUAL description by Dr. Garcia - have a look here:

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml#queryrange

This table describes actions that do not completely align with the description of the DUAL by Dr. Garcia - some of them are quite contrary. It seems to me that there is quite a lot of confusion about EIGRP even inside Cisco, as indicated by that document about EIGRP and as also pointed out by Ivan Pepelnjak's blog at http://blog.ioshints.info/2008/07/why-im-no-longer-active-ccie.html :

...the [certification] tests were not exactly accurate over the years I had to take them. When I was developing (the then only) EIGRP training for internal Cisco audiences, I lost most points on EIGRP questions simply because I knew too much about the protocol.

While I can't say anything about my EIGRP knowledge correctness I can say that I had a couple of EIGRP questions on my CCIE R&S Written Exam that to my best knowledge had no correct answer at all. Concidence?

Best regards,

Peter