From: Jay Greenberg (groupstudylist@execulink.com)
Date: Tue Jul 27 2004 - 11:33:39 GMT-3
I guess you're SOL then. Once you're subscribed to a mailing list, you
can NEVER get off. Sorry!
On Tue, 2004-07-27 at 10:27, Veerman, Leigh wrote:
> 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
>
> _______________________________________________________________________
> 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
>
>
> Lynx Technology Ltd is a Cisco Systems Gold Certified Partner, Microsoft Gold Certified Partner and HP Business Partner Select / Authorised Warranty Delivery Partner.
> Sales Offices: Sheffield, London City, High Wycombe
>
> DISCLAIMER:
>
> This message is intended only for the use of the person(s) ('Intended Recipient') to whom it is addressed. It may contain information, which is privileged and confidential. Accordingly any dissemination, distribution, copying or other use of this message or any of its content by any person other than the Intended Recipient may constitute a breach of civil or criminal law and is strictly prohibited. If you are not the Intended Recipient, please contact the sender as soon as possible. Neither Lynx Technology Ltd or the sender accept any responsibility for viruses and its is your responsibility to scan the email and attachments. Any liability arising from any third party acting on any information contained in this email is hereby excluded. Lynx Technology Ltd will hold data provided by you for marketing and promotional purposes unless otherwise advised. Please see our Statement of Privacy at www.lynxtec.com.
>
> _______________________________________________________________________
> 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
-- Jay Greenberg, CCIE #11021http://www.free-tests.com - Free Practice Tests http://www.free-labs.com - Free Router Pods http://www.expert-labs.com - CCIE Router Pods
AcceliNetworks Online Resources
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:04 GMT-3