From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Mar 02 2005 - 19:12:51 GMT-3
It's been a while so the config I showed may have been a bit different from
what I actually used.
The actual config I used definitely didn't bring down the interface because
I would have lost my ospf adjacencies and that didn't happen.
Maybe the config was like this:
Class-map OSPF
Match prot ospf
Policy-map SET-DE
class OSPF
class class-default
set fr-de
int s0/0
service-policy output SET-DE
After my last failed lab attempt where I lost most of the points in the QoS
section even though I felt I knew QoS pretty well, I went back and did
extensive testing - probably over 100 hours worth and I learned that some
MQC config's don't work as they should.
As a result of all this testing I concluded a few things:
1) Knowing QoS thoroughly is a son-of-a-bitch because it's such a huge
topic - even if you know everything in the DQoS book by Odom it's not
enough.
2) Occasionally, the only way do some things is by using the legacy
commands
3) Occasionally, even though the config is correct and should work, it
doesn't. So, it's imperative to know how to verify your results and know
different ways of doing the same thing.
Like it or not, QoS might be in the lab in a very big way and at a high
level of difficulty. Therefore, it can make the difference between passing
or failing the lab. So, even though many might not think of QoS as a "core"
topic, I think all ccie candidates should know and practice QoS as much as
they do other lab topics like f/r, ospf and bgp.
-----Original Message-----
From: marvin greenlee [mailto:marvin@ccbootcamp.com]
Sent: Wednesday, March 02, 2005 4:42 PM
To: 'ccie2be'; ccielab@groupstudy.com
Subject: RE: RE: Setting the DE bit in frame relay [bcc][faked-from]
Tim,
Not sure what your results were when using the policy below, but when I
tried it, the policy took down the line protocol on the interface, as it
seemed to interfere with the keepalives. With keepalives off, or with the
addition of "match protocol ip" to the "match not protocol ospf", with the
class set to 'match-all' it seemed to work fine.
Marvin Greenlee, CCIE#12237, CCSI# 30483
Network Learning Inc
marvin@ccbootcamp.com
www.ccbootcamp.com (Cisco Training)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Wednesday, March 02, 2005 1:22 PM
To: gladston@br.ibm.com; ccielab@groupstudy.com
Subject: RE: RE: Setting the DE bit in frame relay [bcc][faked-from]
Importance: Low
The idea in that code is to set the DE bit on all traffic except ospf.
As I recall, the config below didn't work as expected - not because the
config is incorrect but because of how IOS works or sometimes doesn't.
So, my point is to make sure the config is working as expected by knowing
how to verify the operations that are suppose to be taking place.
It's virtually impossible to test every possible configuration variation
prior to the lab to see what works and what doesn't. So, the only recourse
you have is to know how to verify your results and if you don't get the
results you were expecting, knowing how to alter your config until you do
get the results you need.
HTH, Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
gladston@br.ibm.com
Sent: Wednesday, March 02, 2005 3:15 PM
To: ccielab@groupstudy.com
Subject: Re: RE: Setting the DE bit in frame relay
==============
quoted
Class-map NOT-OSPF
Match not prot ospf
Policy-map SET-DE
Class NOT-OSPF
set fr-de
int s0/0
service-policy output SET-DE
==================
Tim,
Would "match not prot ospf" match any other packets?
Once I used "match access-group name..." and it did not worked until I
change it to numbered access-list. The platform was 6509, native mode.
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:39 GMT-3