From: Veerman, Leigh (leigh.veerman@lynxtec.com)
Date: Tue Jul 27 2004 - 11:27:00 GMT-3
How do I unsubscribe from this email group????
I cannot handle the volume of mails
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: 27 July 2004 15:21
To: trouse@cisco.com; 'Yasser Aly'; ccielab@groupstudy.com
Subject: Re: VOIP over ATM or FR
Sorry, I can't answer that question. In the lab, if there's any
question about what you need to do, I would ask the proctor.
----- Original Message -----
From: "Terrence Rouse (trouse)" <trouse@cisco.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Yasser Aly'"
<yasser.aly@noorgroup.net>; <ccielab@groupstudy.com>
Sent: Tuesday, July 27, 2004 9:44 AM
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.
> >
> > ____________________________________________________________________
> > ___
> > Please help support GroupStudy by purchasing your study materials
> > from: http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials
> from: http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials
> from: http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:04 GMT-3