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
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
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.
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.
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?
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.
You've hit the proverbial nail on the head. But there is a
customer-perception story to be told here. I think most customers realize
that any provider's backbone is overbooked at some level. Most backbone
links are probably not as large as the sum of all customer connections
coming in. That's packet switching for you.
But I think most T1 customers think that they are getting a full T1 from
their location to the edge of the provider's backbone. What the model at
hand (and emerging connectivity models like cable modems & xDSL) are doing
is pushing the definition of 'edge' closer to the customer. In addition to
general backbone congestion, now the customer has to contend with
congestion in their neighborhood (cable head-end or xDSL DSLAM).
That's fine for Frame Relay customers since they presumably understand what
FR is all about & can choose their CIR/port speed wisely. But I tend to
think that a customer who purchases a pt-pt T1 to reach their provider's
network wants the full T1 all the way to the router on the other end.
It'll be intersting to see if xDSL etc manages to change that expectation.
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.
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....
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.
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.