Close enough.... Let me work through it, as well, since that might help.
1. R1 will notice it has lost it's connection to 192.168.1.0/24. It will examine it's topology table, and find it has no feasible successor, so it will mark the route active, and make the current cost infinite.
2. Because the topology table entry for 192.168.1.0/24 is now active, R1 will send queries to both R2 and R3. Since networks are never "perfect" in their timing, one of them will receive it before the other. Lets assume R2 receives it first.
3. When R2 receives this query, it examines its local topology table, and sees the query is from its successor, and it contains an infinite metric (R2's successor can no longer reach the destination). R2 will examine its topology table, and find it has no other path to 192.168.1.0/24, so it marks the route active.
4. When R3 receives the query from R1, it processes it in the same way as R2 just did.
5. R2 now sends a query to R3. We'll assume R3 hasn't yet built it's query towards R3 (though it might have, but that doesn't make much difference in the end).
6. When R3 receives this query, it notes the local route is already in active state with an infinite metric. R3 will also clear R2 on the list of neighbors it needs to query. R3 now finds its list of neighbors to query is empty, so it builds a reply towards R1 and R2 with an infinite metric. This is going to tell R1 and R2 that R3 has no alternate path.
7. When R1 receives the reply from R3, it marks R3 off its list of neighbors it has queried about 192.168.1.0/24.
8. When R2 receives R3's reply, it marks R3 off its list of neighbors it has queried about 192.168.1.0/24. At this point, it isn't waiting on any other neighbors, so it will reply to R1 with an infinite metric, indicating it has no alternate path to 192.168.1.0/24.
9. When R1 receives R2's reply, it marks R2 off its list of neighbors it has queried about 192.168.1.0/24. R1 notes the list of queried neighbors is now empty, so it kills the SIA timers, and removes the route from the local routing table (which causes the routing table to check with the other routing protocols running locally for routes to the same destination).
Let's pause for a breath: At this point, the route is passive on all three routers. R2 and R3 have gone active, figured out they have no alternate route, and removed the route from their local tables. R1 still has the route in its local table, its just holding to send the update which normally follows a route moving from the active to the passive state.
10. R1 now sends an update for 192.168.1.0/24 with an infinite metric.
11. R2 and R3 don't do anything with this update, since they've already removed the route from their local tables.
Now, in reality, this last poison update isn't needed, because R2 and R3, the only neighbors R1 has, have already replied, and thus already know the state of things. Since R1 has already seen replies from R2 and R3, it will squash this last poison update, resulting in a log entry that says: "poison squash."
HTH
:-)
Russ
