01-05-2012 06:24 AM - edited 03-04-2019 02:49 PM
I am attempting to examine load balancing, both equal and unequal cost. But equal cost has thrown me a monkey wrench.
All the interfaces are WIC-2a/s, with no special configuration.
What I get at R1, when examining the equi-distance paths to the 10.100.23.0/29 network via the EIGRP topology table, is a displayed FD that isn't what I would expect.
First, here is my own scratch at the math:
R1 to R3: (256 * (10,000,000/128)) + (2000 * 256)
R1 to R3: (256 * 78125= 20,000,000) + (2000 * 256= 512000)
R1 to R3 metric is 20512000
R3 to <network>: (256 * (10,000,000/128)) + (2000 * 256)
Same thing... 20512000
Now, the EIGRP metric for the total path is lowest BW + cumulative delay, so that means:
20,000,000 + 1024000, equaling 21024000. That would be the FD from R1, with the RD or AD from R2 and R3 equalling 20512000. That is validated in the routing table:
#sho ip rou 10.100.23.0
Routing entry for 10.100.23.0/29
Known via "eigrp 1", distance 90, metric 21024000, type internal
Redistributing via eigrp 1
Last update from 10.100.13.3 on Serial0/0/0, 00:28:48 ago
Routing Descriptor Blocks:
10.100.13.3, from 10.100.13.3, 00:28:48 ago, via Serial0/0/0
Route metric is 21024000, traffic share count is 1
Total delay is 40000 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
* 10.100.12.2, from 10.100.12.2, 00:28:48 ago, via Serial0/0/1
Route metric is 21024000, traffic share count is 1
Total delay is 40000 microseconds, minimum bandwidth is 128 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R1#sho ip rou ei
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.3.1.0/24 [90/20640000] via 10.100.13.3, 00:29:20, Serial0/0/0
D 10.2.1.0/24 [90/20640000] via 10.100.12.2, 00:29:20, Serial0/0/1
D 10.100.23.0/29 [90/21024000] via 10.100.13.3, 00:29:20, Serial0/0/0
[90/21024000] via 10.100.12.2, 00:29:20, Serial0/0/1
D 192.168.0.0/22 [90/20640000] via 10.100.13.3, 00:29:20, Serial0/0/0
R1#
Here is where it is strange.
R1#sho ip eigrp topo 10.100.23.0/29
IP-EIGRP (AS 1): Topology entry for 10.100.23.0/29
State is Passive, Query origin flag is 1, 2 Successor(s), FD is
20514560
Routing Descriptor Blocks:
10.100.12.2 (Serial0/0/1), from 10.100.12.2, Send flag is 0x0
Composite metric is (21024000/20512000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.100.13.3 (Serial0/0/0), from 10.100.13.3, Send flag is 0x0
Composite metric is (21024000/20512000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
R1#
For the life of me I can not figure out why in the topology table the FD is listed as 20514560, while the FD/RD numbers in each routing descriptor block match what is displayed in the routing table.
01-05-2012 07:18 AM
Hi,
could you try clear ip eigrp nei and look at the topology table again.
Regards.
Alain
01-05-2012 07:35 AM
Hello Alain,
That will most probably help but what we see here is not a bug - on the contrary, we are seeing a completely correct EIGRP operation. See my next post.
It is a widely spread misunderstanding that a route has several FDs, one through each neighbor. That is wrong. Only a single FD value is kept for each route - simply the value of the lowest metric since the last time the route went from Active to Passive state. The metrics through each neighbor do not have any special names - they are simply resulting total metrics via particular neighbors.
Quite many textbooks on the subject get this wrong - including Networking Academy curricula, unfortunately.
Best regards,
Peter
01-05-2012 07:31 AM
Hello,
The FD is not the current lowest distance to a destination - that is a common misunderstanding. In reality, the FD is the lowest metric of the route since the last time the route went from Active to Passive state. In other words, it is a record of a historical minimum to a destination, with the history starting anwe each time the route goes from Active to Passive state. FD may be lower than the actual distance if the current distance has increased (for example, by increasing the interface delay or by lowering its bandwidth) without losing the current successor.
So what you see here is completely normal - it is simply an indication that you once were closer to the destination than you are now, but the increase in the metric did not cause you to enter the Active mode, so the FD was not reset and simply stayed at the previous minimum.
While the route is in Passive state, the FD may only decrease which is simply a result of its definition as being a minimum (or an infimum, if you will) of the distance to a particular destination. If the FD needs to be increased because no other neighbor satisfies the feasibility condition, the route will need to enter the Active state.
Best regards,
Peter
01-05-2012 07:47 AM
Concur. This is exepected behavior..R3 is connected directly to R5.
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (20514560/20002560), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 20100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Simply by modifying the delay by 1990 we see the change in your routing table. As Peter stated modifying the bandwidth could also produce similiar results.
R5(config-if)#delay 10
R5(config-if)#delay 2000
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (21024000/20512000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
01-05-2012 07:49 AM
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (21024000/20512000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
I forced route to go from passive to active by resetting interface on R5..the FD updated.
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21024000
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (21024000/20512000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
01-05-2012 08:28 AM
Thanks for the great reply Peter. Let me see if I got this down correctly. Let's say we have a topology just like the one in the thread. Where A is the top of the trianle and B is left and C is right. Let's say B has an EIGRP Metric to route 3.3.3.3 which is on C. B's route to 3.3.3.3 from C is 500120, but when you look at the EIGRP topology table you notice that there is a route to the same destination but with a metric that has increased in value lets say 500500. Now, since the 500120 is the lowest metric since that specific route went from ACTIVE to PASSIVE, that's why you don't see the updated value of 500500? So in order to fix this I would have to cause the route to go from PASSIVE to ACTIVE and then ACTIVE to PASSIVE?
01-05-2012 10:23 AM
Yes, but there is another condition which can also change the the FD. As you know each time a metric is changed the update is forwarded to the neighbor. If the RD of this new route is lower then the "historically" FD then it will keep the current FD and update the toplogy entry. This is what is happening to the original poster. If the RD is higher then the current FD it will modify the route and add the new FD. The EIGRP event log reports this event as "FC not sat". Bear with me if will as I try to explain...
My test lab: R3 connected to R5. R5 with loopback network configured with 172.16.55.36/30. Using metrics similiar to original poster.
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (20514560/20002560), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 20100 microseconds
R5(config-if)#delay 2000
R3#
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20514560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (21024000/20512000), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40000 microseconds
*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 237 FC sat nh/ndbmet: 172.16.35.5 20514560
*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 238 FC sat rdbmet/succmet: 21024000 20512000
EIGRP event log also reports the FC is sat or in other words the RD of this new route 20512000 is lower than historical FD 20514560.
If we change the delay so the RD is equal to or greater the the "historical" FD it will update the FD.
R5(config-if)#delay 2010
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21026560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (21026560/20514560), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40100 microseconds
*Dec 12 02:08:37.250: %DUAL-6-EVENT: IP-EIGRP(0), 247 FC not sat Dmin/met: 21026560 21024000
The FC has not be meet because the RD 2051460 is equal to or greater than the FD. So the FD updates. Also as Peter noted and I have also tested, changing the route from passive to active by reseting the loopback interface will cause the FD to update.
01-05-2012 03:13 PM
Hi Ryan,
A nice experiment you have done. Please allow me a few comments.
You wrote:
As you know each time a metric is changed the update is forwarded to the neighbor. If the RD of this new route is lower then the "historically" FD then it will keep the current FD and update the toplogy entry. This is what is happening to the original poster. If the RD is higher then the current FD it will modify the route and add the new FD.
I must admit I do not fully understand this description. However, let me restate a few basic principles, perhaps this will clarify the doubts. Correct me whenever you feel I am incorrect.
As I already indicated, the Feasible Distance, or FD, is a record of the smallest total metric towards a destination since the last time the route went from Active to Passive state and a new successor has been chosen. It is incorrect to talk about a "historical FD" as there is no such thing - we would be talking about "historical historical minimum of a metric". The FD itself is a historical minimum of the metric towards a destination. The FD is recorded for each known destination, and there is exactly one FD for each known destination. Also, the FD is a local variable - it is never advertised or carried in any EIGRP packets. In other words, the FD is an internal parameter necessary in EIGRP operations but it is not necessarily the current lowest metric.
There is an immediate important fact to the FD: because it is a record of the smallest total metric towards a destination, it is always permitted to decrease the FD if the current metric to a destination falls below the current value of the FD - the FD will simply adopt the value of the current metric. Remember, we are always keeping a record of the minimal metric. If the current metric falls below the current record, we simply update the record, i.e. the FD. This also means that the FD absolutely does not need to be identical to the current lowest metric. Once again, the current metric to a destination and the FD are two independent values - they may be identical but they also may differ.
Also note that the FD is a record of the total minimal distance to a destination. It is not equal just to a historically lowest Reported Distance as received from a neighbor, rather, it is a record of the the lowest total distance from the local router to a particular destination.
The FD is a crucial component to the Feasibility Condition (FC). The FC says: "If the neighbor is closer to the destination than we have ever been, it is guaranteed to be not on a routing loop", or in short, a neighbor for which the relation RD < FD holds is a loop-free neighbor.
However, during network operation, a situation may arise when the FD has fallen so low that when a next topology change takes place and the RD of the current successor increases to or above the value of the current FD, the neighbor that provides the next lowest total metric to the destination does not meet the FC, or there is no neighbor at all that would satisfy the FC. That does not necessarily mean that there is no route to the destination - it just means that the local router has currently no guarantee that choosing any of its neighbors would provide a guaranteed loop-free route. This is the situation when the route needs to enter the Active state, the local router will send out queries, expect replies, and only after receiving all replies, the route will be put back to Passive state, the router will be allowed to choose the neighbor providing the lowest total distance as the new successor and reset the FD to this current lowest total distance, even if it is higher than the previous value. In other words, if a need arises to increase the FD, the only way to do it is to perform a diffusing computation using queries and replies. If a route stays in Passive state, it is not possible to increase the FD, and conversely, if the FD does not need to be increased, the route does not need to enter the Active state.
To sum it up - the FD is a record of the minimal metric to a destination. It can always decrease if the current distance to the destination falls below the current value of the FD. If, however, the current successor route fails and either the router providing the next lowest total distance does not meet the FC, or there is no router at all that would meet the FC, then the route will enter the Active state and a diffusing computation will take place. After receiving all replies, the route will be put back to Passive state and the FD will be reset (i.e. increased) to the new lowest total metric which is available.
Now, to the experiment Ryan performed:
*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 237 FC sat nh/ndbmet: 172.16.35.5 20514560
*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 238 FC sat rdbmet/succmet: 21024000 20512000
EIGRP event log also reports the FC is sat or in other words the RD of this new route 20512000 is lower than historical FD 20514560.
Once again, there is no concept of "historical FD". There is just the FD, or the historical minimum. What was demonstrated here is that when on R5 the metric was increased, the R3 noted this distance increase. However, the FC was not violated - while the RD increased, it did not increase to or above the value of FD. Therefore, although the metric worsened, the neighbor still passed the FC and was deemed as a feasible successor, and if it still provided the shortest path available, it was also deemed the successor. The route therefore remained in the Passive state, it never went into Active - we say that only a local computation on R3 took place.
If we change the delay so the RD is equal to or greater the the "historical" FD it will update the FD.
R5(config-if)#delay 2010
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21026560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (21026560/20514560), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40100 microseconds
*Dec 12 02:08:37.250: %DUAL-6-EVENT: IP-EIGRP(0), 247 FC not sat Dmin/met: 21026560 21024000
Here, the metric on R5 was increased so much that on R3, this increased metric reported from R5 no longer met the FC. However, in order for R3 to be allowed to increase the FD, it had to enter the Active state for this network and reset the FD only after receiving all replies and putting the network back to Passive state. The debug eigrp fsm should prove that.
This all may be quite confusing - please feel welcome to ask further!
Best regards,
Peter
01-05-2012 03:53 PM
Hi Paul,
Okay so my issue is I used some terms incorrectly and my logic at the end omiited a one step. Besides that I think we are saying the same thing and hopefully the EIGRP event messages told a clearer story than my botched explanation..at least I hope : ) I will work through your comments...
I must admit I do not fully understand this description. However, let me restate a few basic principles, perhaps this will clarify the doubts. Correct me whenever you feel I am incorrect.As I already indicated, the Feasible Distance, or FD, is a record of the smallest total metric towards a destination since the last time the route went from Active to Passive state and a new successor has been chosen. It is incorrect to talk about a "historical FD" as there is no such thing - we would be talking about "historical historical minimum of a metric". The FD itself is a historical minimum of the metric towards a destination. The FD is recorded for each known destination, and there is exactly one FD for each known destination. Also, the FD is a local variable - it is never advertised or carried in any EIGRP packets. In other words, the FD is an internal parameter necessary in EIGRP operations but it is not necessarily the current lowest metric.
I agree. I was using miscorrectly using the term "historical" FD to represent the fact the local router stores the lowest FD to a destination. Also agree with comment regarding FD not being advertised, as it is a local computation. The RD is advertised with the new route and this is the parameter used locally to check the FC of the new route. If the RD of the new route reported by R5 (in my example) meets FC then the FD previously recorded locally on R3 does not change. If the RD reported by the new route does not meet the FC then the FD on R3 is updated.
Once again, the current metric to a destination and the FD are two independent values - they may be identical but they also may differ.Also note that the FD is a record of the total minimal distance to a destination. It is not equal just to a historically lowest Reported Distance as received from a neighbor, rather, it is a record of the the lowest total distance from the local router to a particular destination.
No problem here!
The FD is a crucial component to the Feasibility Condition (FC). The FC says: "If the neighbor is closer to the destination than we have ever been, it is guaranteed to be not on a routing loop", or in short, a neighbor for which the relation RD < FD holds is a loop-free neighbor.
However, during network operation, a situation may arise when the FD has fallen so low that when a next topology change takes place and the RD of the current successor increases to or above the value of the current FD, the neighbor that provides the next lowest total metric to the destination does not meet the FC, or there is no neighbor at all that would satisfy the FC. That does not necessarily mean that there is no route to the destination - it just means that the local router has currently no guarantee that choosing any of its neighbors would provide a guaranteed loop-free route. This is the situation when the route needs to enter the Active state, the local router will send out queries, expect replies, and only after receiving all replies, the route will be put back to Passive state, the router will be allowed to choose the neighbor providing the lowest total distance as the new successor and reset the FD to this current lowest total distance, even if it is higher than the previous value. In other words, if a need arises to increase the FD, the only way to do it is to perform a diffusing computation using queries and replies. If a route stays in Passive state, it is not possible to increase the FD, and conversely, if the FD does not need to be increased, the route does not need to enter the Active state.
To sum it up - the FD is a record of the minimal metric to a destination. It can always decrease if the current distance to the destination falls below the current value of the FD. If, however, the current successor route fails and either the router providing the next lowest total distance does not meet the FC, or there is no router at all that would meet the FC, then the route will enter the Active state and a diffusing computation will take place. After receiving all replies, the route will be put back to Passive state and the FD will be reset (i.e. increased) to the new lowest total metric which is available.
Now, to the experiment Ryan performed:
*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 237 FC sat nh/ndbmet: 172.16.35.5 20514560
*Dec 12 02:03:49.102: %DUAL-6-EVENT: IP-EIGRP(0), 238 FC sat rdbmet/succmet: 21024000 20512000
EIGRP event log also reports the FC is sat or in other words the RD of this new route 20512000 is lower than historical FD 20514560.
Once again, there is no concept of "historical FD". There is just the FD, or the historical minimum. What was demonstrated here is that when on R5 the metric was increased, the R3 noted this distance increase. However, the FC was not violated - while the RD increased, it did not increase to or above the value of FD. Therefore, although the metric worsened, the neighbor still passed the FC and was deemed as a feasible successor, and if it still provided the shortest path available, it was also deemed the successor. The route therefore remained in the Passive state, it never went into Active - we say that only a local computation on R3 took place.
If we change the delay so the RD is equal to or greater the the "historical" FD it will update the FD.
R5(config-if)#delay 2010
R3#show ip eigrp topology 172.16.55.36/30
IP-EIGRP (AS 35): Topology entry for 172.16.55.36/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 21026560
Routing Descriptor Blocks:
172.16.35.5 (FastEthernet0/1), from 172.16.35.5, Send flag is 0x0
Composite metric is (21026560/20514560), Route is Internal
Vector metric:
Minimum bandwidth is 128 Kbit
Total delay is 40100 microseconds
*Dec 12 02:08:37.250: %DUAL-6-EVENT: IP-EIGRP(0), 247 FC not sat Dmin/met: 21026560 21024000
Here, the metric on R5 was increased so much that on R3, this increased metric reported from R5 no longer met the FC. However, in order for R3 to be allowed to increase the FD, it had to enter the Active state for this network and reset the FD only after receiving all replies and putting the network back to Passive state. The debug eigrp fsm should prove that.
This all may be quite confusing - please feel welcome to ask further!
Best regards,
Peter
Agree with your explanation. EIGRP event 237 and 238 show that the FC is meet and therefore the FD is not updated. As you state the router performed a local computation. My terms where wrong but my logic matched until your last paragraph. Where I went wrong was I incorrectly assumed R3 simply updated the FD. But as you stated what is really happening is the route went active because the RD of R5 no longer meet the FC. I will perform a debug eigrp fsm as you have suggested.
Thanks for your time!
Ryan
01-05-2012 04:13 PM
Hi Ryan,
Please allow me first to assure you that I am not catching for words or being a nitpicker just for the sake of it. It has just been my experience that using an imprecise or free terminology with EIGRP ultimately leads to misunderstanding of its operations, and as there are many misconceptions being spread about EIGRP even in semi-official or official materials, I am trying to put some things straight. Please consider also my further remarks just as being faithtful to that intention, and I honestly appreciate your knowledge of EIGRP operations!
I agree. I was using miscorrectly using the term "historical" FD to represent the fact the local router stores the lowest FD to a destination.
Again, it would be incorrect to talk about "the lowest FD", as for any destination, there is only a single FD. Correctly, we should say: "The local router stores the lowest known metric to a destination as the FD." It is often suggested that the FD is the total metric through a particular neighbor (i.e. the sum of RD of that neighbor plus the cost of the link towards it) and that there are multiple FDs for a particular destination, one for each neighbor. However, that suggestion is incorrect.
If the RD reported by the new route does not meet the FC then the FD on R3 is updated.
To be completely precise, this is not always true. Think of a route having a successor and a feasible successor, both obviously meeting the FC with the current value of FD. If the current successor sends an update whose RD does not meet the FC and the feasible successor provides a route with the next lowest metric, it will become the new successor - however, the FD will not be updated because it does not need to.
But as you stated what is really happening is the route went active because the RD of R5 no longer meet the FC.
... and the router that provides the next overall shortest route does not pass the FC check. Otherwise, only a local computation would take place.
Best regards,
Peter
01-05-2012 04:23 PM
Agree, only serves to make things more difficult when free terminology is used.
Again, it would be incorrect to talk about "the lowest FD", as for any destination, there is only a single FD. Correctly, we should say: "The local router stores the lowest known metric to a destination as the FD." It is often suggested that the FD is the total metric through a particular neighbor (i.e. the sum of RD of that neighbor plus the cost of the link towards it) and that there are multiple FDs for a particular destination, one for each neighbor. However, that suggestion is incorrect.
Concur.
To be completely precise, this is not always true. Think of a route having a successor and a feasible successor, both obviously meeting the FC with the current value of FD. If the current successor sends an update whose RD does not meet the FC and the feasible successor provides a route with the next lowest metric, it will become the new successor - however, the FD will not be updated because it does not need to.
Again concur. I was only speaking to the lab scenario but I appreciate your completeness.
Thanks again for your time! Your desire to not losely use terms and correctly state the facts has left a lasting impression.
Thanks,
Ryan
01-05-2012 04:26 PM
Hello Ryan,
Thanks again for your time! Your desire to not losely use terms and correctly state the facts has left a lasting impression.
I am honored! And about that lasting impression... uh-oh, I hope it's not a negative one
Once again, thank you for joining this thread. I hope you'll be able to join more often!
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide