From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue Jul 27 2004 - 15:12:16 GMT-3
"if not stated in a CCIE lab task, should you still configure the L2 QOS
to support voice traffic."
No. The CCIE lab exam is not a design test. Many of the
configuration interactions typically will not make sense, and would not
actually work if you tried to use them, but that is not the point. The
exam is designed to test your problem solving skills based on a certain
set of restrictions and criteria. I.e. do only what is asked of you and
nothing more.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Terrence Rouse (trouse)
> Sent: Tuesday, July 27, 2004 8:45 AM
> To: 'ccie2be'; 'Yasser Aly'; ccielab@groupstudy.com
> Subject: RE: VOIP over ATM or FR
>
> CCIE2BE,
>
> Thanks for the insight. I guess my initial question is geared more
> specifically to a CCIE lab scenarios. We all know that "real world"
is
> different than practice and CCIE labs. So my question really was more
> of....."if not stated in a CCIE lab task, should you still configure
the
> L2
> QOS to support voice traffic." In other words is it mandatory to
avoid
> breaking data communication. For example in F/R: you have LLQ, FRTS
with
> tc=1/100, FRAGMENTS. If so what are the issues. This is important
> because
> in real lab things may appear to work just fine, but if they expect to
see
> the proper QOS and you don't configure it, then you get no points.
Know
> one
> knows how these are graded but little tidbits like this may help
someone
> be
> more thorough on the solution.
>
> Thanks again, great info. I will be reading over all those books
again.
> Its
> been a while, need to dust them off. :-)
>
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Tuesday, July 27, 2004 8:24 AM
> To: Yasser Aly; trouse@cisco.com; ccielab@groupstudy.com
> Subject: Re: VOIP over ATM or FR
>
>
> Yasser,
>
> You've got this all confused.
>
> For example, if you ping an ip address ( and get a response), do you
have
> do
> to anything special if the ping travels over a ATM or F/R circuit or
> ethernet or token ring or sonet or 802.11b wireless? The answer, of
> course,
> is no.
>
> The ping doesn't care what the layer 2 link technology is. Why is
that?
>
> Because at each link's interface, the router takes care of
encapsulating
> the
> icmp packet appropriately for the layer 2 technology used on the
> particular
> link needed to send the packet along it's way to the next hop.
>
> Now, suppose that instead of the packet carrying icmp info, it's
carrying
> voice data. Wouldn't the same thing be true?
>
> The answer is YES. Each router along the path will take the ip packet
> carrying voice samples (or call signaling info) and encapsulate it
with
> whatever layer 2 headers and trailers are appropriate for the type of
> layer
> 2 link over which the packet is traveling to it's next hop. And,
because
> of
> this, each hop's layer 2 link technology can be different. The first
hop
> might be ethernet, the 2nd hop could be f/r, the 3rd hop could be ATM,
the
> 4th hop could f/r again, the 5th hop could be wireless, and so on.
You
> get
> the idea.
>
> Put simply, when you configue voip, the layer 2 technology is
transparent
> to
> the voip traffic.
>
> Now, this transparency comes at a cost. In addition to the whatever
> headers
> and trailer are needed for the layer 2 link, the voice packet must
also
> have
> layer 3 headers and trailers and layer 4 headers and trailers as
> appropriate
> for layer 3 (IP) and layer 4 (usually or always UDP). This makes the
> voice
> packet bigger which means more network resource ( rtr cpu and network
> bandwidth) is needed to transport the voice packets to their
destinations.
>
> Now, suppose your network looks like this:
>
> phone A --> rtr A --> F/R --> rtr B --> phone B
>
> You have a choice: At rtr A and B you can encapsulate the voice
traffic in
> ip and let the network take care of the layer 2 stuff or you can save
> network resources by configuring your rtr's to encapsulate the voice
> traffic
> directly into frame relay. It's your choice (or the choice of those
> people
> creating the lab).
>
> The thing to notice is that there's only one hop. Now, voip and VoFR
> aren't
> mutually exclusive.
>
> Suppose, for example, that rtr 1 is also connected to rtr A by an ATM
link
> and that phone 1 is attached to rtr1. When phone 1 wants to call
phone B,
> rtr 1 must use voip (because phone B is 2 hops away). Now, also assume
> another phone is attached to rtr B. Let's call that phone B2.
>
> Now, phone A calls phone B and phone 1 calls phone B2. What happens?
>
> At rtr A when the voip traffic arrives from rtr 1, rtr A looks at the
dest
> ip addr of the voip packet and sees that this packet needs to go to
rtr B.
> So, just like any ip based traffic, rtr A encapsulates the voip packet
> appropriately for the f/r link and sends the packet on it's way. Now,
> when
> a voice packet arrives at rtr A from phone A, rtr A because it's
> configured
> to directly encapsulate voice traffic from phone A into f/r, does
that.
>
> So, rtr A because there are 2 calls taking place at the same time is
> forwarding both voice traffic streams to rtr B. However, you should
> realize
> at this point that rtr A doesn't even know that the voip traffic from
rtr
> 1
> is voip traffic. To rtr A, that traffic is just plain old ip traffic
and
> it
> forwards it just as it would any other ip traffic ( except, of course,
> probably someone has configured QoS so that voip traffic doesn't have
to
> wait too long behind FTP traffic or other less time critical traffic).
>
> So, based on this example, you can see that voip doesn't "override"
VoFR
> or
> VoATM. They are just different ways of carrying voice traffic.
>
> If you want to really understand this better, I would suggest you read
a
> couple of books:
>
> 1) Integrating Voice and Data Networks, Scott Keagy, ISBN 157870-196-1
>
> A truly excellent book which is well written, clear, full of config
> examples
> and comprehensive.
>
> 2) Cisco Voice over Frame Relay, ATM and IP, Steve McQuerry, ISBN
> 157870-227-5
>
> Not quite as well written as the first book but covers the basics very
> well
> and includes a number of topics that aren't covered in the first book.
>
> 3) DQoS, Wendell Odom
>
> Another truly excellent book. If you're planning on becoming a ccie,
you
> have to know the material in this book inside out. And, since QoS is
> critical for voice traffic, you need to understand this broad topic
very
> well to properly configure a network to handle voice traffic.
>
> All 3 books are available from Cisco Press.
>
> HTH a bit, Tim
>
>
> ----- Original Message -----
> From: "Yasser Aly" <yasser.aly@noorgroup.net>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; <trouse@cisco.com>;
> <ccielab@groupstudy.com>
> Sent: Tuesday, July 27, 2004 2:35 AM
> Subject: RE: VOIP over ATM or FR
>
>
> > Hello,
> >
> > Based on your reply it might mean that VOIP overrides Vofr and
VoATM
> > ? I just need to confirm this or otherwise define when Vofr or VoATM
> > would
> be
> > needed.
> >
> > Thanks,
> > Yasser
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of ccie2be
> > Sent: Monday, July 26, 2004 10:34 PM
> > To: trouse@cisco.com; ccielab@groupstudy.com
> > Subject: Re: VOIP over ATM or FR
> >
> > If you're configuring VOIP, then you don't need to be concerned
about
> > Vofr or voATM. The voice traffic flows based on the IP network and
> > doesn't care what the layer 2 link technology is.
> >
> > You still need to configure QoS, but mostly at the L3 level by
> prioritizing
> > precedence 5 packets or their dscp equivalent. How this is done
will
> vary
> > depending on the layer 2 technology.
> >
> > HTH a little.
> >
> >
> > ----- Original Message -----
> > From: <trouse@cisco.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Monday, July 26, 2004 11:13 AM
> > Subject: VOIP over ATM or FR
> >
> >
> > > He guys,
> > >
> > > I need some clarification. When configuring VOIP, but traveling
over
> a
> > ATM or FR medium, do you still have to address the issues with the
L2
> > technology. IF so what are the key issues for ATM and FR to keep in
> > mind. For example, with ATM do you still have to configure the
vbr-rt
> > and COS.
> Do
> > you have to ahve address the fragmenting of data. If a
> question/requirement
> > does not speak of this stuff do you still need to configure it.
What
> > is
> the
> > rule of thumb, when the call works and all is pingable but this L2
> > feature and issues are not addressed.
> > >
> > > Thanks Everyone.
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:04 GMT-3