RE: ATM and Frame Relay interworking [7:53414]
Yes indeed, you simply configure the frame and ATM as you normally would, and the provider will provide which vpi/vci maps to which DLCI. I think the traffic between the carrier's ATM cloud & frame relay cloud (& vice versa) translates via FRATM. Randall -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of MADMAN Sent: Monday, September 16, 2002 12:00 PM To: [EMAIL PROTECTED] Subject: Re: ATM and Frame Relay interworking [7:53414] Yes the service provider provides the magic, you simply configure the frame and ATM as you normally would, the provider will provide which vpi/vci maps to which DLCI. FRF8 provides a mechanism for relaying link status from frame to ATM and vis-versa but it not not always implemented by all vendors:( Dave Ben W wrote: > > We have a number of these ATM/Frame PVCs also. From what our vendor told > us, the packets are migrated from ATM to Frame, or vise versa, on the > vendors network. We have seen some latency that the vendor tells us is an > effect of the packets hopping from ATM to Frame or Frame to ATM. Otherwise > it works great. -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "You don't make the poor richer by making the rich poorer." --Winston Churchill Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=55250&t=53414 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ATM and Frame Relay interworking [7:53414]
No, OAM does not have a corresponding mechanism in frame relay and does not help in internetworking as far a interface up/down status. OAM is for ATM to ATM though there is, in FRF8 a spec for this functionality in internetworking though it is not always implemented:( Dave "[EMAIL PROTECTED]" wrote: > > Enabling ATM OAM (Operations and Maintenance?) cells on the > hub-site router lets you see when the remote Frame Relay > PVC/DLCI goes down. Here's a sample: > > interface ATM1/0.105 point-to-point > description ATM PVC to FrameRelaySite > mtu 1500 > bandwidth 256 > ip address 10.1.121.89 255.255.255.252 > pvc r-framesitec261 1/105 > vbr-nrt 512 512 100 > no ilmi manage > oam-pvc manage 3 > > It is pretty much that simple. I have @ 130 frame circuits internetworked > to > > an ATM DS3. The only "problem" is that it seems to make troubleshooting a > > little harder. There isn't much you can do to look at the other side > > (without a modem attached to the remote router). For instance, when a > remote > > frame site goes down, there is no notification to the hub ATM site because > > nothing changes on it's end. Everything always shows up/up. At least with > > frame/frame you can do a show frame pvc and look at the DLCI status, etc., > > > > Martin Reilly wrote: > > > > > > I have a question I'd appreciate some advice with regarding ATM > > > and > > > Frame Relay interworking. > > > > > > I'm deploying a WAN using a telco that is providing "typical" > > > frame > > > relay ports over E1 links at ten remote offices. At the central > > > site, > > > where PVCs from the remote offices all come in, the telco is > > > providing a > > > 34Mb circuit, using ATM, to support the aggregated bandwidth > > > that may be > > > required. > > > > > > Now, I'm pretty familiar with frame relay (most of this setup is > > > actually just migrating from one telco's frame service to > > > another) and > > > that part I have no problem with. But I'm a newbie to ATM > > > (reading up on > > > it at the moment). Looks like ATM to ATM isn't too dissimilar > > > to frame. > > > > > > The telco says that the interworking should be "seamless", but > > > are not > > > terribly specific on details. Could it be as simple as pointing > > > an ATM > > > VC to a Frame PVC and letting the telco deal with the > > > differences in the > > > middle somewhere? I've never heard of this before, which > > > worries me a > > > bit! -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "You don't make the poor richer by making the rich poorer." --Winston Churchill Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54338&t=53414 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ATM and Frame Relay interworking [7:53414]
Enabling ATM OAM (Operations and Maintenance?) cells on the hub-site router lets you see when the remote Frame Relay PVC/DLCI goes down. Here's a sample: interface ATM1/0.105 point-to-point description ATM PVC to FrameRelaySite mtu 1500 bandwidth 256 ip address 10.1.121.89 255.255.255.252 pvc r-framesitec261 1/105 vbr-nrt 512 512 100 no ilmi manage oam-pvc manage 3 It is pretty much that simple. I have @ 130 frame circuits internetworked to > an ATM DS3. The only "problem" is that it seems to make troubleshooting a > little harder. There isn't much you can do to look at the other side > (without a modem attached to the remote router). For instance, when a remote > frame site goes down, there is no notification to the hub ATM site because > nothing changes on it's end. Everything always shows up/up. At least with > frame/frame you can do a show frame pvc and look at the DLCI status, etc., Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54317&t=53414 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ATM and Frame Relay interworking [7:53414]
Enabling ATM OAM (Operations and Maintenance?) cells on the hub-site router lets you see when the remote Frame Relay PVC/DLCI goes down. Here's a sample: interface ATM1/0.105 point-to-point description ATM PVC to FrameRelaySite mtu 1500 bandwidth 256 ip address 10.1.121.89 255.255.255.252 pvc r-framesitec261 1/105 vbr-nrt 512 512 100 no ilmi manage oam-pvc manage 3 > It is pretty much that simple. I have @ 130 frame circuits internetworked to > an ATM DS3. The only "problem" is that it seems to make troubleshooting a > little harder. There isn't much you can do to look at the other side > (without a modem attached to the remote router). For instance, when a remote > frame site goes down, there is no notification to the hub ATM site because > nothing changes on it's end. Everything always shows up/up. At least with > frame/frame you can do a show frame pvc and look at the DLCI status, etc., > > Martin Reilly wrote: > > > > I have a question I'd appreciate some advice with regarding ATM > > and > > Frame Relay interworking. > > > > I'm deploying a WAN using a telco that is providing "typical" > > frame > > relay ports over E1 links at ten remote offices. At the central > > site, > > where PVCs from the remote offices all come in, the telco is > > providing a > > 34Mb circuit, using ATM, to support the aggregated bandwidth > > that may be > > required. > > > > Now, I'm pretty familiar with frame relay (most of this setup is > > actually just migrating from one telco's frame service to > > another) and > > that part I have no problem with. But I'm a newbie to ATM > > (reading up on > > it at the moment). Looks like ATM to ATM isn't too dissimilar > > to frame. > > > > The telco says that the interworking should be "seamless", but > > are not > > terribly specific on details. Could it be as simple as pointing > > an ATM > > VC to a Frame PVC and letting the telco deal with the > > differences in the > > middle somewhere? I've never heard of this before, which > > worries me a > > bit! Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54311&t=53414 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: ATM and Frame Relay interworking [7:53414]
Martin, The below is from a production router. Int ATM2/0 is a DS-3 ATM port with Service Inter-Working Translational (Frame to ATM) PVC's. Hope this helps. interface ATM2/0 description VPI/VCI 2/17 DNEC.XX.ATI (T-3) no ip address atm scrambling cell-payload no atm auto-configuration no atm ilmi-keepalive no atm address-registration no atm ilmi-enable ! interface ATM2/0.37 point-to-point description 192k PVC to XXX - Far end router mtu 1500 bandwidth 100 ip address 10.231.xxx.xxx 255.255.255.252 ip load-sharing per-packet ip summary-address eigrp 1 10.xxx.xxx.xxx 255.255.0.0 5 atm pvc 37 2 37 aal5snap oam 10 - The 2 is the VPI number and the 37 is the remote end PVC number. Or you can do it this way: - Same router, just a different interface to a different far end: interface ATM2/0.40 point-to-point description 384K PVC to XXX - Far end router mtu 1500 bandwidth 100 ip address 10.xxx.xxx.xxx 255.255.255.252 ip load-sharing per-packet ip summary-address eigrp 1 10.231.0.0 255.255.0.0 5 pvc 1/40 vbr-nrt 4608 4608 1 (4608 is far end b/w plus 10% for ATM overhead i.e. far end has 3 T1/5's, the 1 is for MBS - Maximum Burst Size) oam-pvc manage I'm traffic shaping the PCR/SCR/MBS in the above example. Martin Reilly wrote: > Morning all. I've been lurking on this list for a week or so to get a > flavour... seems there are some very knowledgeable people here. :) > > I have a question I'd appreciate some advice with regarding ATM and > Frame Relay interworking. > > I'm deploying a WAN using a telco that is providing "typical" frame > relay ports over E1 links at ten remote offices. At the central site, > where PVCs from the remote offices all come in, the telco is providing a > 34Mb circuit, using ATM, to support the aggregated bandwidth that may be > required. > > Now, I'm pretty familiar with frame relay (most of this setup is > actually just migrating from one telco's frame service to another) and > that part I have no problem with. But I'm a newbie to ATM (reading up on > it at the moment). Looks like ATM to ATM isn't too dissimilar to frame. > > The telco says that the interworking should be "seamless", but are not > terribly specific on details. Could it be as simple as pointing an ATM > VC to a Frame PVC and letting the telco deal with the differences in the > middle somewhere? I've never heard of this before, which worries me a > bit! > > You might ask why I didn't sort all this out before signing contracts... > but back then, we were planning for the 34Mb link to be provided as a > "normal" frame port which would have been nothing new to us (other than > the extra speed). Some "issues" came up later which necessitated the > change. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=53537&t=53414 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
