From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Sun Jul 31 2005 - 12:22:20 GMT-3
San,
Below is a config that is part of a QoS seminar Cisco delivers to
service provider audiences across the globe. These configurations, or
very similar have been deployed on some of the largest MPLS VPN
networks in the globe for the PE to CE link. This config is used as
frame relay is a common access technology to MPLS VPNs. Priority
queueing is supported on frame interfaces in these configurations, with
the caveat that to get the latency required for voice, cir equals mincir
meaning there is no shaping or drop actions taken within the frame
network. You want the frame part to be lossless and queue-less as it is
not IP aware and cannot differentiate a voice packet fom a best effort
packet.
Classification:
access-list 100 permit ip protocol rtp 16384 16383
access-list 101 permit <business traffic>
access-list 103 permit host 192.10.10.1 host 200.1.1.1
access-list 104 permit udp any eq rip any eq rip
access-list 104 permit ospf any any
access-list 104 permit tcp any eq bgp any
access-list 104 permit tcp any any eq bgp
!
class-map match-all voip
match ip access-group 100
class-map match-all bus
match ip access-group 101
class-map match-all mgt
match ip access-group 103
class-map match-all rp
match ip access-group 104
class-map match-all be
match any
Policy
policy-map pcwe
class voip
priority 64 1600
set ip dscp 40
class rp
bandwidth 8
queue-limit 40
class mgt
bandwidth 8
set ip dscp 24
queue-limit 40
class bus
bandwidth 154
set ip dscp 32
random-detect
class be
bandwidth 22
random-detect
Applying to the interface, setting F/R parameters and enabling interface
level traffic shaping so the class settingsa take effect.
interface serial1/0
encap frame-relay IETF
frame relay traffic-shaping
!
interface serial1/0.1 point-to-point
ip address 192.168.48.4 255.255.255.0
frame-relay class frts-pcwe
frame-relay interface-dlci 100 IETF
!
map-class frame-relay frts-pcwe
no frame-relay adaptive-shaping
frame-relay cir 256000
frame-relay mincir 256000
frame-relay bc 2560
service-policy output pcwe
frame-relay fragment 160
The Tx-ring (set on the interface with the is normally left to the self
tuning IOS process to meet latency requirements for voice, according to
the following table
Line rate <2 10 20 30
Tx-ring-limit 2 4 8 16
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
san
Sent: Saturday, July 30, 2005 11:17 PM
To: Yash Bajpai
Cc: ccielab@groupstudy.com
Subject: LLQ not supported on FR ?
Thanks Yash for sharing your notes.
your point "
* LLQ is not supported for FR interface." may not be valid. Can you /
anyone validate ?
I have seen an example IE WB 7 (vol 1) uses priority command (non
class-default) & assign to map-class & then to p-t-p subinterface.
May be you are trying to express some other point.
Thanks
SAN
On 7/29/05, Yash Bajpai <ccieyash@yahoo.com> wrote:
> Hello Friends!
>
> ...and say HELLO to the newest CCIE on the block...ME!!! heh heh
> heh....I passed CCIE R&S yesterday in san jose. This was my 3rd
> attempt.
>
> Before i begin with my viewpoints and suggestions, i would like to
> take this time and thank all of you in this groupstudy! YOu are a
> strong motivating force that every CCIE candidate should use ("Use the
> force, Luke"). I would especially like to thank NMC for their
> excellent Checkit labs. I took 5 of them mostly back to back in
> may-june2005 before my 2nd attempt. They are much more challenging
> than the real thing and they have an excellent feedback/verification
> system. Being in 'customer support' myself, i would really like to
> give my kudos to Indy and Bruce for their great service and support. I
> also used Internetwork expert labs and i really liked the lab content
> and material they cover in their labs.
>
> OK, now for my personal suggestions/comments about the lab prep. For
> maximum benefits, I would break this down into three cateogories
>
> 1) For the absolute newbies to Lab prep and this group study.
>
> * You would have heard this before, read about it, discussed it with
> friends and colleagues and it doesnt hurt to repeat: CCIE Lab is
> unlike any other exam! Its a different beast that require a different
> strategy than what we might be accustomed to for any 'paper exam'.
>
> * Having said that, its definitely an achievable goal given that you
> are seriously focussed, determined and commited towards the goal. (say
> goodbye to those weekly parties)
>
> * I started with Jeff Doyle vol1 vol2 which really enforced my
> fundarmentals on core topics. After that, Practical studies volumes
> were virtually a breeze. In between all this, ofcourse there were
> generous CCO readings for topics not covered in books (or atleast in
> the books i had access to).
>
> * Don't get disheartened by some of the posts in this groupstudy. Take
> whatever positive you can out of it.
> I remember when i first enrolled, i would not log in to check my mails
> because i would be 'terrified' of the level of questions some people
> would ask or when i heard that someone failed inspite of their
> enormous efforts! Just be optimistic and take only good points from
> here!
>
> * I started with the 'technology lab' in Jan-Feb2005.
> These were focussed on a particular technology and gave me the
> requisite comfort level on a particular topic.
>
> * Then i progressed to 8 hour labs. I would admit having access to a
> CCIE rack was the greatest 'enabler' in my pursuit.
>
> * Finally take the challenge labs from the top
> vendor(s) of your choice.
>
>
> 2) For people ready to take their labs very soon
>
> * At this point, you probably know so much already that you are
> already a CCIE! really!!! Believe in that and believe in yourself.
>
> * I failed my 2nd attempt *not* because of lack of preparation but due
> to my inferior "exam taking skills" (i still get mad thinking about
> it). Granted there were topics on which iam still amazed as to how i
> got so few points in my 2nd failed attempt. But overall, i realized i
> didn't do some basic verification of my work and all the things that i
> would do so diligently in my mock labs, i didnt do in the REAL lab.
> Can you belive that...aaarghhh!!! Long story short, don't take
> anything for granted when you see the actual lab much more simpler
> than the mock labs you have been practising! you can still pay a heavy
> price for that...This is a very very easy exam to FAIL :(
>
> * Keep it simple. Know the basics. if there is anything that i learnt
> from my 3 attempts then it was this. At this stage in your prep, you
> may know the intricacies of all the protocols out there, you may know
> complex/obscure technology in great
>
> detail and you may still find your concepts tested only on the more
> basic aspects of routing and switching! That is not to say that you
> don't need to prepare as hard as you are right now. As a future CCIE,
> you have a reputation to live up to and ofcourse "anything is fair
> game in the lab".
>
>
> 3) For the "rest" out there midway in their lab prep.
>
> You can do it! dont give up on it!!! I have some points/tips in
> general that i made in the last month of my prep. They are not in any
> particular order and perhaps may not make complete sense too. Its more
> of a scribble pad on points that i felt were easy to forget and i have
> pretty much put them as-is with no special interest in its order or
> lucidity. But iam sure they would help you even without you knowing
> them...Here are those 'precious' (please recheck its validity and
> accurate-ness)
>
>
> * eigrp would not advertise secondary addressess on an interface
> unless split horizon is disabled
>
> * you cannot change the AD of a specific external EIGRP route.
>
> * isis would not redistribute its 'connected'
> interfaces running isis into other protocols. Perhaps, the same is
> true for all IPv6 IGP routing protocols too.
>
> * For ISIS on ATM, remember to map clns protocol by "protocol clns 00
> broadcast"
>
> * for ISIS on ISDN, remember that interesting traffic is mapped by
> (hidden) clns_is protocol and not clns.
>
> * some ways to stop distance vector IGP to *not* advertise a
> route/interface:
> > distribute list
> > offset list
> > distance
> > make the interface metric infinity (delay,
> bandwidth)
>
> * For ATM to pass DHCP requests, do the following under pvc x/y
> "protocol ip 255.255.255.255 broadcast"
> (and enable "protocol ip inarp" for multipoint interfaces).
>
> * "ip msdp redistribute list" is nothing but
> (logically) msdp sa-originate-filter
>
> * "dlsw remote-peer 0 tcp x.x.x.x backup-peer y.y.y.y linger 20"
> should be interpreted as x.x.x.x IS the backup-peer OF y.y.y.y
> (implies y.y.y.y is already configured separately as a primary remote
> peer)
>
> * dlsw timer explorer-wait-time 100 should be used when there is 'dlsw
> load-balance' involved to give the peer enough time to listen to all
> explorer traffic.
>
> * in dlsw remote-peer encapulations: TCP and dlsw-lite
> (llc2) do reliable delivery and local acknowlwdgement.
> llc2 shuould be mapped in FR multipoint. FST and Direct are NOT
> reliable and have no local acknowlwdgement. dlsw should be mapped in
> FR multipoint.
>
> * OSPF will generate host routes instead of subnet/network route when
> the interface is configured for point-to-multipoint network type.
>
> * Under router rip, use "no validate-update source" to disable source
> address validation
>
> * user "no peer neighbor-route" under ISDN for dis-allowing the
> host-route creation. (best practice)
>
> * when using dialer watch on ISDN, set idle-timeout on the *other* end
> as '0' so that ISDN does not flap.
>
> * in ISIS route leaking, 'distribute-list' keyword is required even if
> no existing ACL is referenced by it.
>
> * dlsw transparent ethernet redundancy may also needs a "dlsw
> transparent switch-support" command. (best
> practice)
>
> * If ISIS needs to redistribute static routes then remember to use the
> 'IP' keyword and also prefer to use the "metric-type external" option
> in the redistribute static command.
>
> * In IPv6 across FR, remember to map the link local addresses ALSO.
>
> * Shaping: Token bucket is filled with Bc *bits* at the start of
> interval. Be is simply a 'larger space'
> in the same token bucket.
>
> * Policing: Tokens are prorated in the time interval to match Bc and
> are measured in 'BYTES'. Be is another token bucket which is filled
> either thru splill-over i.e. single rate or filled at Peak rate (PIR)
> i.e.
> dual rate Policing
>
> * Use "log" as the first command as a best practice when defining
> router isis.
>
> * Rate-limiting or Policing: normal rate = CIR Normal Burst Bc =
> CIR*1.5/8 (in bytes) and Be = 2 Bc (where burst is allowed) or Bc = Be
> (no burst allowed)
>
> * Leasked ISIS routes (from L2 into L1) cannot be then redistributed
> out from a L1 router.
>
> * CBWFQ percent (bandwidth percent) on FR is the percent of BW of the
> MINCIR
>
> * Be = (AR-CIR)*Tc/1000
>
> * 4 lines of IOS commands for NTP authentication!
> ntp authentication-key 1 md5 CISCO
> ntp authenticate
> ntp trusted-key
> ntp server IP address key 1
>
> * dont forget dot1x system-auth-control and keep a "aaa authentication
> login default none" as a backup in the lab.
>
> * Dialer callback is based on PPP and requires some form of PPP
> authentication to work (dialer callback-server username)
>
> * Multiple Dialer profiles using the same pool of BRi interface need
> either PPP authentication (preferred) or isdn caller screening to map
> the profile to the incoming call.
>
> * "ip ospf database-filter all out" interface command would give
> "passive interface" like features on RIP.
> It will form adjacencies but not send out LSA on that interface.
>
> * NSSA ABR does *not* automatically generate the default route in the
> nssa area unless area nssa default-originate is given.
>
> * Adjusting OSPF hello interval automatically adjusts its dead
> interval (to 4 time hello time) but *not* vice verca.
>
> * passive ftp acl e.g.
> access-list 101 permit tcp any any eq ftp access-list 101 permit tcp
> any any gt 1023 established
>
> * rate-limit has a 'continue' option to keep the packet in question go
> thru other rate-limi lists configured on the interface.
>
> * LLQ is not supported for FR interface.
>
>
> Thank you!!!
> Yash Bajpai
> CCIE # 14964
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:32 GMT-3