Frame Relay encap vis-a-vis point-to-point at UUNET
Hey all, We just got a third T1, this time through UUNet and when I looked at their router configuration I got a little surprise. We ordered a point-to-point circuit that is being terminated at their detroit POP. The configuration, however, sets up the line as a frame relay encap on a sub-interface (on a Cisco, of course :). When I talked to my UUNet rep he advised that this was the way "every large ISP did it" which I knew wasn't exactly true since our MCI and AT&T (just recently transitioned from the BBN backbone to the AT&T network) does not use this configuration. He insisted that it was still a point to point and that the frame relay encapsulation was used to enhance the connection. Well, I had him grab an engineer (he was an SE) that could possibly explain it better to me (since the SE said F/R was used to decrease RIP broadcasts across their backbone) and the engineer said this (basically): the circuit is terminated in a cascade 9000 f/r switch (used for port density) which went to a HSSI interface in a Cisco 7xxx series router which connected directly to their ATM network. Therefore, the f/r encaps were needed to speak with the cascade. The engineer advised we had a full CIR and would not suffer any bandwidth loss from using f/r encap. Now, I guess my question is: am I getting sold the brooklyn bridge here? I mean, not that I wouldn't like to *own* the brooklyn bridge (well, I'd rather have the triboro or the washington, but anyway...). Is this f/r encap going have any adverse affect on the quality of this connection (assuming that this is *NOT* a point-to-point into a frame cloud) or am I getting shoveled a load of copralite? Thanks! Barry Barry L James | Mikrotec Internet Services, Inc (AS3801) Director R & D | 1001 Winchester Rd bjames@mis.net | Lexington KY 40505 http://www.mis.net/ | 606/266.5925 800/875.5095 Member AAAI, IEEE # 40277528 --- Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on. -- Winston Churchill
Barry, The story that you were told jives with what I was told many moons ago by UUNet when I ordered lines for my previous employer. The need for frame relay encapsulation is not necessary since the Cascade (Ascend) 9000 supports PPP to frame relay translation. At Pacific Bell Internet we turned up all dedicated ports on PPP even though they terminated on our 9000 and the customer was never the wiser. I guess UUNet likes to explain to each and every customer why they are using FR encap instead of PPP. The short answer to your question is, no. There is basically no difference between FR and PPP as far as performance of your line goes. Mark Tripod Senior Backbone Engineer Exodus Communications Barry L James wrote:
Hey all,
We just got a third T1, this time through UUNet and when I looked at their router configuration I got a little surprise. We ordered a point-to-point circuit that is being terminated at their detroit POP. The configuration, however, sets up the line as a frame relay encap on a sub-interface (on a Cisco, of course :). When I talked to my UUNet rep he advised that this was the way "every large ISP did it" which I knew wasn't exactly true since our MCI and AT&T (just recently transitioned from the BBN backbone to the AT&T network) does not use this configuration. He insisted that it was still a point to point and that the frame relay encapsulation was used to enhance the connection.
Well, I had him grab an engineer (he was an SE) that could possibly explain it better to me (since the SE said F/R was used to decrease RIP broadcasts across their backbone) and the engineer said this (basically): the circuit is terminated in a cascade 9000 f/r switch (used for port density) which went to a HSSI interface in a Cisco 7xxx series router which connected directly to their ATM network. Therefore, the f/r encaps were needed to speak with the cascade. The engineer advised we had a full CIR and would not suffer any bandwidth loss from using f/r encap.
Now, I guess my question is: am I getting sold the brooklyn bridge here? I mean, not that I wouldn't like to *own* the brooklyn bridge (well, I'd rather have the triboro or the washington, but anyway...). Is this f/r encap going have any adverse affect on the quality of this connection (assuming that this is *NOT* a point-to-point into a frame cloud) or am I getting shoveled a load of copralite?
Thanks!
Barry
Barry L James | Mikrotec Internet Services, Inc (AS3801) Director R & D | 1001 Winchester Rd bjames@mis.net | Lexington KY 40505 http://www.mis.net/ | 606/266.5925 800/875.5095 Member AAAI, IEEE # 40277528 --- Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on. -- Winston Churchill
On Mon, 21 Sep 1998, Mark Tripod wrote:
The short answer to your question is, no. There is basically no difference between FR and PPP as far as performance of your line goes.
Except that with the FR encap, you can do a sh fr pv and see when the cascade is congested. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Mon, 21 Sep 1998, Barry L James wrote:
Hey all,
We just got a third T1, this time through UUNet and when I looked at their router configuration I got a little surprise. We ordered a point-to-point circuit that is being terminated at their detroit POP. The configuration, however, sets up the line as a frame relay encap on a sub-interface (on a Cisco, of course :). When I talked to my UUNet rep he advised that this was the way "every large ISP did it" which I knew wasn't exactly true since our MCI and AT&T (just recently transitioned from the BBN backbone to the AT&T network) does not use this configuration. He insisted that it was still a point to point and that the frame relay encapsulation was used to enhance the connection.
Well I don't know that this is the way every large ISP does it, but several do. That is at least how I did it with NetRail. You take all your T1 customers into CT3 cards on Cascade 9000s and then connect the 9000 to your routers.
Well, I had him grab an engineer (he was an SE) that could possibly explain it better to me (since the SE said F/R was used to decrease RIP broadcasts across their backbone) and the engineer said this (basically): the circuit is terminated in a cascade 9000 f/r switch (used for port density) which went to a HSSI interface in a Cisco 7xxx series router which connected directly to their ATM network. Therefore, the f/r encaps were needed to speak with the cascade. The engineer advised we had a full CIR and would not suffer any bandwidth loss from using f/r encap.
Correct.
Now, I guess my question is: am I getting sold the brooklyn bridge here?
Well no, but it does have some problems. A lot of the Cascades at UUNet are the old HSSI cards and have problems over 30 megs.
I mean, not that I wouldn't like to *own* the brooklyn bridge (well, I'd rather have the triboro or the washington, but anyway...). Is this f/r encap going have any adverse affect on the quality of this connection (assuming that this is *NOT* a point-to-point into a frame cloud) or am I getting shoveled a load of copralite?
Well you should be ok. Sure you MAY run into congestion issues, but you should be ok.
Thanks!
<> Nathan Stratton Telecom & ISP Consulting www.robotics.net nathan@robotics.net -- "No king is saved by the size of his army; no warrior escapes by his great strength." - Psalm 33:16
Barry
Barry L James | Mikrotec Internet Services, Inc (AS3801) Director R & D | 1001 Winchester Rd bjames@mis.net | Lexington KY 40505 http://www.mis.net/ | 606/266.5925 800/875.5095 Member AAAI, IEEE # 40277528 --- Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on. -- Winston Churchill
On Mon, Sep 21, 1998 at 08:33:27PM -0400, Nathan Stratton wrote:
On Mon, 21 Sep 1998, Barry L James wrote:
Now, I guess my question is: am I getting sold the brooklyn bridge here?
Well no, but it does have some problems. A lot of the Cascades at UUNet are the old HSSI cards and have problems over 30 megs.
Anybody done/doing this with Cisco/StrataCom BPX/etc? One of our providers attempted this with us about a year ago, without success. This was before CEF/CAR, and they wanted to perform rate limiting/ shaping on our T3 down to 10Mbit/Sec. The idea was to use frame-to-ATM translation (terminology?) and then ATM QoS tweaks in the BPX, before shipping it to a 7513 via HSSI. Cisco wasn't able to make the specific FR card involved work then, however. I don't remember the switch card P/N. Is CAR inexpensive enough processor-wise that this and the CT-3 card make the above obsolete/moot? -- David Carmean <dlc@avtel.net> Avtel Communications, Santa Barbara, CA +1-805-884-6300 also: <dlc@silcom.com>, <dlc@matrixinet.{net,com}>, <dave@west.net> PGP fingerprint = B1 57 EB A8 1D B9 87 86 5F 5C 51 A4 F2 5E ED FD
Barry, See http://info.uu.net/tv/unite/low/hubs.html. It depicts Cascade switches terminating 'customer leased lines'. They go so far as to draw the FR cloud(s) separately, so it looks like the UUNET engineer was giving it to you straight. However, the statement 'would not suffer any bandwidth loss from using f/r encap' is largely dependent on the overbooking of those aggregation ports. If it were me, I would a) make sure that 'full CIR' meant line speed & b) want an assurance that the aggregation ports were >= the sum of all line speeds mapped to them. Otherwise, one could very well argue that those connections are not pt-pt at all but FR clouds collapsed onto an on-site FR switch. If there is any overbooking going on on those aggregation connections, you are not getting your T1's worth and might as well have bought a FR connection in the first place. My 2c. Dan At 02:09 PM 9/21/98 -0400, Barry L James wrote:
Hey all,
We just got a third T1, this time through UUNet and when I looked at their router configuration I got a little surprise. We ordered a point-to-point circuit that is being terminated at their detroit POP. The configuration, however, sets up the line as a frame relay encap on a sub-interface (on a Cisco, of course :). When I talked to my UUNet rep he advised that this was the way "every large ISP did it" which I knew wasn't exactly true since our MCI and AT&T (just recently transitioned from the BBN backbone to the AT&T network) does not use this configuration. He insisted that it was still a point to point and that the frame relay encapsulation was used to enhance the connection.
Well, I had him grab an engineer (he was an SE) that could possibly explain it better to me (since the SE said F/R was used to decrease RIP broadcasts across their backbone) and the engineer said this (basically): the circuit is terminated in a cascade 9000 f/r switch (used for port density) which went to a HSSI interface in a Cisco 7xxx series router which connected directly to their ATM network. Therefore, the f/r encaps were needed to speak with the cascade. The engineer advised we had a full CIR and would not suffer any bandwidth loss from using f/r encap.
Now, I guess my question is: am I getting sold the brooklyn bridge here? I mean, not that I wouldn't like to *own* the brooklyn bridge (well, I'd rather have the triboro or the washington, but anyway...). Is this f/r encap going have any adverse affect on the quality of this connection (assuming that this is *NOT* a point-to-point into a frame cloud) or am I getting shoveled a load of copralite?
Thanks!
Barry
Barry L James | Mikrotec Internet Services, Inc (AS3801) Director R & D | 1001 Winchester Rd bjames@mis.net | Lexington KY 40505 http://www.mis.net/ | 606/266.5925 800/875.5095 Member AAAI, IEEE # 40277528 --- Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on. -- Winston Churchill
On Mon, 21 Sep 1998, Dan Jones wrote:
However, the statement 'would not suffer any bandwidth loss from using f/r encap' is largely dependent on the overbooking of those aggregation ports. If it were me, I would a) make sure that 'full CIR' meant line speed & b) want an assurance that the aggregation ports were
= the sum of all line speeds mapped to them. Otherwise, one could very well argue that those connections are not pt-pt at all but FR clouds
collapsed onto an on-site FR switch.
If there is any overbooking going on on those aggregation connections, you are not getting your T1's worth and might as well have bought a FR connection in the first place.
The point where the congestion and overbooking takes place might be anywhere along the source/destination pair. Assuming provider A was aggregating customers directly onto CT3 cards instead of frame relay switches. The customer is now happy with his "point to point link." Now, further assuming the uplink from the customer aggregation equipment, to the backbone transist system is worth X Mbps, then directly terminating a number of connections onto the gateway with an aggregate _peak_ bandwidth of greater than X Mbps just moves the choke point up further, to the transist <--> Customer aggregation equipment link. This can be moved up to any point in the network. This is where aggresive monitoring and proactive retermination and/or addition of more resources come in. -- Vijay Gill |The (paying) customer is always right. wrath@cs.umbc.edu, vijay@umbc.edu | - Piercarlo Grandi http://www.gl.umbc.edu/~vijay | Eagles may soar, but weasels don't get These are my opinions only. | sucked into jet engines.
On Mon, 21 Sep 1998, Barry L James wrote:
We just got a third T1, this time through UUNet and when I looked at their router configuration I got a little surprise. We ordered a point-to-point circuit that is being terminated at their detroit POP. The configuration, however, sets up the line as a frame relay encap on a sub-interface (on a Cisco, of course :). When I talked to my UUNet rep he advised that this was the way "every large ISP did it" which I knew wasn't
This is what we ended up with when we moved our UUNet T1 from their Miami POP to their JAX POP. Coincidentally, this is also when our service from UUNet went from flawless to sh!t. My understanding is that we had a full point to point T1 terminated (possibly as part of some much bigger pipe) in Cascade Frame Relay switch, which then had a HSSI connection into a Cisco 75XX router. We were able to pull full T1 bandwidth over the line...but UUNet had chronic problems with the Cascade switch, we had lots of downtime that was never explained, and it seemed to perform particularly badly when faced with more traffic than could be handled by our T1. Smurf attacks would apparently cause the cascade to reset our T1 at regular <1s intervals, such that during an attack, we'd get a burst of traffic, then absolutely nothing, then a burst of traffic.
broadcasts across their backbone) and the engineer said this (basically): the circuit is terminated in a cascade 9000 f/r switch (used for port density) which went to a HSSI interface in a Cisco 7xxx series router which connected directly to their ATM network. Therefore, the f/r encaps
Sounds like what we had.
were needed to speak with the cascade. The engineer advised we had a full CIR and would not suffer any bandwidth loss from using f/r encap.
Probably not...but do they know how to properly run the Cascades yet? We had very serious reliability problems when we were on UUNet. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Mon, Sep 21, 1998 at 02:09:00PM -0400, Barry L James wrote:
We just got a third T1, this time through UUNet and when I looked at their router configuration I got a little surprise. We ordered a point-to-point circuit that is being terminated at their detroit POP.
[...]
Now, I guess my question is: am I getting sold the brooklyn bridge here?
We only have a DS1 that is plugged into one of the Detroit routers for UUNet. It definitely shows signs that it is oversold from time to time. Ocasionally things work less than optimally, but we get good service most of the time. We are unable to push the line at full T1 much of the time. We also had some odd problems with our FR. When the circuit was nearing full congestion the LMI wouldn't get through and the cascade would react by bouncing the circuit (which bounced the BGP, etc. etc.). We finally had to shutoff LMI which causes us problems any time they decide to re-do the circuit for any reason....
Barry L James | Mikrotec Internet Services, Inc (AS3801)
-- Jeffrey Haas "He that breaks a thing to find out what it is has elezar@pfrc.org left the paths of wisdom." (Or works for Fermilab...)
We also had some odd problems with our FR. When the circuit was nearing full congestion the LMI wouldn't get through and the cascade would react by bouncing the circuit (which bounced the BGP, etc. etc.). We finally had to shutoff LMI which causes us problems any time they decide to re-do the circuit for any reason....
Uhh...I think that LMI gets priority over any other data...so the PVC bouncing sounds like something else is causing LMI to stop flowing. But maybe I am wrong. Bill
Uhh...I think that LMI gets priority over any other data...so the PVC bouncing sounds like something else is causing LMI to stop flowing. But maybe I am wrong.
Theory vs. practive, IMHO. Likewise, PPP LQM is supposed to have priority over other PPP data, but I've seen many a link bounce because LQM packets were missed due to congestion. -Phil
You could also order a larger circuit with the same FR paramters. On Thu, 22 Oct 1998, Elvis wrote:
We also had some odd problems with our FR. When the circuit was nearing full congestion the LMI wouldn't get through and the cascade would react by bouncing the circuit (which bounced the BGP, etc. etc.). We finally had to shutoff LMI which causes us problems any time they decide to re-do the circuit for any reason....
Uhh...I think that LMI gets priority over any other data...so the PVC bouncing sounds like something else is causing LMI to stop flowing. But maybe I am wrong.
Bill
On Fri, Oct 23, 1998 at 11:48:00AM -0400, Eric Dean wrote:
You could also order a larger circuit with the same FR paramters.
The circuit in question is from UUNet. We're not terribly interested in paying them more money when they are 3x more expensive than anyone else we get bandwidth from. FWIW, Savvis does _not_ have this problem. -- Jeffrey Haas "He that breaks a thing to find out what it is has elezar@pfrc.org left the paths of wisdom." (Or works for Fermilab...)
participants (11)
-
Barry L James -
Dan Jones -
Dave Carmean -
elezar＠pfrc.org -
Elvis -
Eric Dean -
Jon Lewis -
Mark Tripod -
Nathan Stratton -
Phillip Vandry -
Vijay Gill