From: simon hart (simon.hart@btinternet.com)
Date: Mon Mar 07 2005 - 15:56:20 GMT-3
Hi Tim,
No I do not think that is a reasonable assumption. The peering will be
established irrespective of traffic traversing the link. So each end will
peer, but if the IOS does not support Ethernet encapsulation then the
Ethernet traffic will not be encapsulated on the link.
Having said all that, I would assume for the lab that all encapsulation
types support Ethernet.
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
ccie2be
Sent: 07 March 2005 18:48
To: 'simon hart'; 'Group Study'
Subject: RE: Eliminating "unnecessary overhead"
Hi Simon,
Although it certainly would be wonderful if the elimination of token ring
also meant the elimination of certain encap types with dlsw, my assumption
is that all encap types are on the table.
I recall hearing a while back that cisco updated the dlsw code so that what
Solie said is no longer completely true.
Unfortunately, I don't know which, if any, encap types are NOT supported
with ethernet, so I figure it's best to just assume that now all encap types
are supported.
Now, I don't have access to a rack today, but my other assumption is this:
If a certain encap type isn't supported for ethernet but is configured just
the same, I'll be able to see the problem with a show dlsw peers showing the
peering isn't working. Do you think that's a reasonable assumption? If
that doesn't show a problem, is there some other way I can verify that the
encap I'm using is working or not working?
Ahh, so many details to know and there's still a small chance that dlsw
won't even be on the lab.
What's a candidate to do?
thanks, Tim
-----Original Message-----
From: simon hart [mailto:simon.hart@btinternet.com]
Sent: Monday, March 07, 2005 1:30 PM
To: ccie2be; Group Study
Subject: RE: Eliminating "unnecessary overhead"
I would suggest that this means to minimize the overhead on the WAN link,
therefore tcp would not be the choice. I really do not think such a
question would relate to local acknowledgment (however I understand your
question as it can seem a little ambiguous)
Therefore you would look for either FST (36bytes), Direct encapsulation
(16bytes) or LLC2 (DLSWlite)(20bytes) so as to provide the lowest overhead
on the WAN.
The problem, however, with FST and Direct Encapsulation is that the under
certain IOS they will only support Token Ring (Karl Solie actually states
that they will only ever support Token Ring).
So in summary I would go for
1. DLSWlite for low overhead
If you want non-disruptive re-routing then TCP
Just my two penny worth
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
ccie2be
Sent: 07 March 2005 17:47
To: Group Study
Subject: Eliminating "unnecessary overhead"
Hi guys,
With dlsw, if you're told to reduce or eliminate or minimize "unnecessary
overhead", what does that refer to?
To me, that can mean 2 different things:
1) use a encap type that does local acknowledgement which keeps those types
of frames off the wan
2) or use an encap type that has the smallest headers
Option 1 allows tcp or dlsw lite, while option 2 allows everything except
tcp depending on the topology.
I'd appreciate hearing what you all think.
TIA, Tim
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:42 GMT-3