From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Mon Aug 21 2006 - 19:52:16 ART
Scott as many ppl in this list, we do not speak English very good.
How can you approximate to the proctor and ask for stupid question?
Yes I know that sound little weird, but for example, say you know 3 ways of
solving a particular Task, but in the Lab Wording none of the 3 ways you
know to resolve the problem is allowed, is the Proctor there to tell you a
tip or I just have to resign and loose those points?
I know that we have the DocCD, but I would like to read your opinion on how
to ask questions to this person, that for sure It would receive strange
questions everyday (for example this one - G.S. Please no flames )
Thanks
Victor.-
-----Mensaje original-----
De: Scott Morris [mailto:swm@emanon.com]
Enviado el: Lunes, 21 de Agosto de 2006 06:42 p.m.
Para: 'Victor Cappuccio'; 'Udo Konstantin'
CC: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
Asunto: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
My assumption would be that there would be more information provided in that
(or closeby) tasks to indicate a bandwidth to be used. Or, ask the proctor!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
IPExpert VP - Curriculum Development
IPExpert Sr. Technical Instructor
smorris@ipexpert.com
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Victor Cappuccio
Sent: Monday, August 21, 2006 10:32 AM
To: 'Scott Morris'; 'Udo Konstantin'
Cc: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Hi Scott,
Thinking in those lines, suppose that he meant to say 120 bytes from the
frame-relay fragment, what would be the needed BW used in ip rtp priority or
LLQ?
Any good formula for this, I know this depends on the Codec used, and how
many call are allowed. But I would love to hear your opinion about this...
Thanks
Victor.-
-----Mensaje original-----
De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de Scott
Morris Enviado el: Lunes, 21 de Agosto de 2006 09:46 a.m.
Para: 'Udo Konstantin'
CC: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
Asunto: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Two different things there... Your frame-relay map-class isn't JUST active
for the service-policy called there. It's active for everything (violating
your requirements). You just happen to be enacting a policy as an output
queuing strategy for that PVC only (instead of the whole interface).
And since your policy isn't doing anything, class class-default picks up the
voice packets anyway, and you just have two queues working the same way to
dump fragmented traffic onto frame-relay.
So, IMHO, the solution listed there would not accomplish what was asked in
the task. And I still go back to trying to figure out what the "120kb" part
is supposed to mean. Fragmentation is based on individual packet size, and
a single packet won't be that big! (Even if we're getting into semantics of
120kb (lower-case) may represent 120,000 bits or 15,000 bytes in length, it
still makes no sense)
120 bytes packet length makes sense. In which case you would use
"frame-relay fragment 120". I'm not sure where 40 came from.
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
IPExpert VP - Curriculum Development
IPExpert Sr. Technical Instructor
smorris@ipexpert.com
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Udo
Konstantin
Sent: Sunday, August 20, 2006 1:30 AM
To: Scott Morris
Cc: 'Sidalo'; 'Paul Dardinski'; 'Cisco certification'
Subject: RE: frame-relay fragment & exclude voice pakkets from being
fragmented
Hi Scott,
the primary challenge was ....
traffic over 120kb lemgth should be fragmented and voice traffic should
never fragmented even if the packet length over 120 Did you also have a
solution for this ?I think this shoul be the solution :
class-map match-all NO_VOICE
match not ip rtp 16384 16383
!
!
policy-map FRAGMENT
class NO_VOICE
!
!
interface Serial0/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
no ip split-horizon eigrp 100
frame-relay map ip 192.168.1.1 102
frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip
192.168.1.3 103 broadcast frame-relay interface-dlci 102
class FRAG
no frame-relay inverse-arp
!
!
!
map-class frame-relay FRAG
service-policy output FRAGMENT
frame-relay fragment 40
Udo
> So, to answer the question below, it's really quite simple:
>
> class-map Voice
> match access-list 101
> access-list 101 permit udp any any range 16384 32767 prec 5 policy-map
> GoodVoice class Voice
> priority (some number here, which may be guessing, or information
> given other places!)
>
> map-class frame-relay FragMe
> frame-relay fragment 120
> service-policy output GoodVoice
>
> int s0/1/0
> frame-relay interface-dlci 204
> class FragMe
>
> Or the map-class and service-policy could be applied per interface
> depending on what the exact scenario was. In the end, the handling
> should be what we desire.
>
> Obviously, pay attention to the scenario itself, but based on the
> generic information below this would be my approach. (which, by the
> way,
the "kb"
> part wouldn't be there!)
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
> JNCIE #153, CISSP, et al.
> CCSI/JNCI-M/JNCI-J
> IPExpert VP - Curriculum Development
> IPExpert Sr. Technical Instructor
> smorris@ipexpert.com
> http://www.ipexpert.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of Sidalo
> Sent: Saturday, August 19, 2006 1:01 PM
> To: Paul Dardinski
> Cc: Cisco certification
> Subject: Re: frame-relay fragment & exclude voice pakkets from being
> fragmented
>
> Obviously there is a reason this keep coming up, even though we havent
> see it in the big vendors lab workbooks. (unless it has since been
> added)
>
> I know for me, I would certainly figure this out before I go in for my
> next lab attempt.
>
> On 8/19/06, Paul Dardinski <pauld@marshallcomm.com> wrote:
> >
> > I am confused. How does one apply frame fragmentation within the mqc?
> > Required for within map-class, correct? If within map-class, how
> > would differentiate between packet sizes for selective fragmentation?
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Udo Konstantin
> > Sent: Saturday, August 19, 2006 10:54 AM
> > To: ccielab@groupstudy.com
> > Subject: frame-relay fragment & exclude voice pakkets from being
> > fragmented
> >
> > Hi group,
> >
> > I read this thread but right now I don't had a answer about the
> > following requirements
> >
> > Traffic over 120 kb length should be fragmented, voice traffic
> > should never fragmented, even if the packet length over 120 kb
> >
> > All other traff < 120 kb should not be fragmented
> >
> > My solution
> >
> > class-map DATA
> > match packet length max 120000
> >
> > policy-map FRAG
> > class DATA
> > frame-relay fragment ?? <not sure about the size>
> >
> > interface Serial0/0
> > ip address 192.168.1.1 255.255.255.0 ip rtp header-compression
> > encapsulation frame-relay frame-relay interface-dlci xxx
> > class FRAG
> >
> > or should I configure
> > service-policy output FRAG (Interface Config Mode)
> >
> > Thanks...
> >
> > Udo
> >
> >
> >
> >
> >
> >
> >
> >
> > ___________________________________________________________
> > Der fr|he Vogel fdngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
> > http://mail.yahoo.de
> >
> > ____________________________________________________________________
> > __ _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > ____________________________________________________________________
> > __ _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:58 ART