Well when I was doing it on my own (might have been part of a micro-lab at
GNS3Vault or somewhere), I tested pretty much the exact inverse requirement,
that WWW traffic would be marked DE (that's how I found this caveat). To
test that, used two routers that were each a hop "out" from the router with
the DE list, so in this topology:
R1----R2--{FR}--R3
R2 would have the DE-list. I set up an HTTP server on R3 using the 'http
path' command (pointed to a file on flash, like the IOS image) and did a
'copy http://url flash:' from R1. Mind the HTTP authentication requirements,
but otherwise lets you emulate Web traffic pretty easily.
What I noticed in that case was when I pulled the file from R2, the DE-list
applied, but when I pulled it from R1 the DE-list did not apply. After much
research I found that the MQC method ('set fr-de') applies to CEF traffic,
but DE-list only apples to process-switched.
So you have to find a way to test through the box if that's the requirement.
Any packets to or from the router's control/management plane will be process
switched and are a red herring for testing through-the-box behavior.
On Thu, Oct 13, 2011 at 9:52 AM, Brian Stajkowski <
[email protected]> wrote:
> Yes,
>
> Tested correctly as you have stated and it even states this under the
> command reference for 'frame-relay de-group' in the DocCD. Good catch!
> This goes along with verifying your work but how could we verify this in
> the lab?
>
> Brian
> CCIE#Whatever they give out in November
>
> On Thu, Oct 13, 2011 at 12:07 AM, Bob McCouch <[email protected]> wrote:
>
>> V1, 6.16 is a task about Frame Relay DE. The task indicates that HTTP
>> traffic should be the least likely to be dropped when entering the FR
>> cloud
>> (but constrains you from using FRTS, GTS, or any MQC to make it happen).
>> My
>> solution matched the DSG, essentially building an ACL that matches
>> everything other than WWW traffic, assigning that to a DE-list and
>> applying
>> the DE-group to the appropriate DLCIs.
>>
>> I went a step further and disabled IP CEF for those frame-relay
>> interfaces,
>> because I knew that the de-group/de-list function only works on process
>> switched traffic, per this note from the command reference:
>>
>> Frame Relay DE group functionality is supported on process-switched
>> packets
>> > only.
>>
>>
>> I know this to be true because I once spent about 2 hours trying to figure
>> out the seemingly inconsistent behavior of this feature before I found
>> that
>> little note.
>>
>> The DSG skips this and just applies the de-group, and then does a test by
>> sending packets from the router interface to which the de-group is
>> applied,
>> and declares the task complete. Problem is, testing form the router's
>> interface results in process-switched packets that hit the de-group. But
>> transit packets through the router that are normally CEF switched would
>> definitely not be marked by this feature.
>>
>> Was I right to disable CEF processing in order to ensure the de-group
>> would
>> actually mark the supposed WWW traffic that was going to come through it?
>>
>> Appreciate any insight or recommendations.
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>> Are you a CCNP or CCIE and looking for a job? Check out
>> www.PlatinumPlacement.com
>>
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check out
www.PlatinumPlacement.com
