- NANOG - lists.nanog.org

Ascend GRF
by Mark Tripod 06 Nov '97

06 Nov '97

Anyone care to share their experiences with the GRF? I am interested in hearing some real world opinions on its ease of use, stability, compatibility, and realiability. Private emails are fine if you don't want public. Thanks in advance for any insight. Mark Tripod Senior Backbone Engineer Exodus Communications

5 5

Re: New MAE-EAST
by Tim Salo 06 Nov '97

06 Nov '97

> Date: Thu, 6 Nov 1997 10:05:31 -0500 (EST) > From: "Paul D. Robertson" <root(a)gannett.com> > Subject: Re: New MAE-EAST > [...] > I'm sure that's a part of it, I initially saw a lot of dropped packets > through a couple of ATM clouds. I'm seeing some improvements in > some of the providers, however, given the trumpeting of ATM (magic bullet > syndrome), it seems that it's just not something which happens correctly > by default. Some ATM switches are better than others. In particular, some of the early ATM switches had very small buffers. They simply weren't designed to support bursty data like IP. There are a number of "good" ATM switches, at least in the sense that they have adequate buffering, available. Depending on whether you are using ATM as a fine-grained, relatively static multiplexing service (CBR) or as a bandwidth-on-demand service (UBR or ABR), the amount of buffering in the network may make a difference. This is probably a good question to ask your prospective service provider. > before we go off on the 'nothing happens correctly by > default' tangent, it's just been my general observation that whenever > my packets have been transited over ATM, my latency has been less than > ideal. I would have figured that oversubscription would result more in > lost packets and timed out connections (which were also seen, but more > easily screamed about) than latency, but I guess that's a factor of how > oversubscribed the line is. > [...] While I don't know your particular circumstances, lots of things can cause latency. Distance, or perhaps unexpected distance, is often an explanation for propagation delay. Some carriers may backhaul your ATM traffic to a switch far away. So, you don't really know what latency to expect unless you know the physical path your data traverse. By the way, the same sort of thing can happen can happen with point-to- point leased lines. We recently had a line which used a rather circuitous route to reach its destination. We asked the carrier to find a shorter path, which they did. -tjs

1 0

New MAE-EAST
by Adam Hersh 06 Nov '97

06 Nov '97

With all of the problems with MAE-EAST..... Any plans from anyone to create a ATM exchange point in the DC area? -Adam Hersh

9 12

Re: /19 addresses and redundancy
by Harold Willison 06 Nov '97

06 Nov '97

Actually, AGIS currently filters like this: We filter everything at /24. We will apply next-hop-self to all exchange point peering sessions. We expect peers to do likewise and we will route map if necessary. We dropped the filtering of smaller net blocks to facilitate multi-homed customers. We used to feel that the total size of the routing tables was a significant issue but we have seen it hit around 90,000 on a really bad net day and we have been able to hold the tables. Our GRFs are equiped to hold a table with 250,000 routes. I don't know how close to this total the table could successfully hold but it's certainly more than the tables today. CIDR has also helped to lower the total route table size. So AGIS has elected to opt for the solution which will serve the customer the best and we accept every /24 and larger announcement. > >Agis also has a policy statement: > >We will filter TWD at /24. > We will filter 206+ at /19. > We will filter everything else at /16. > We will apply next-hop-self to all exchange point peering sessions. > We expect peers to do likewise and we will route map if necessary. > > >Again, whether these are adhered to strictly by these two providers, or any >others, will remain to be seen when you give it a try. > >Keep persuing your own addressing in the meantime. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * Network Engineer 313-730-5151 * | News Admin. 313-730-1130 | | news(a)agis.net 24 hours a day, 7 days a week | * harold(a)agis.net noc(a)agis.net * | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

1 0

Re: Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities
by Tony Li 06 Nov '97

06 Nov '97

> The operative concept in this paper is 'telephone networks'. > > "Architectural Solutions to Internet Congestion Based On > SS7 and Intelligent Network Capabilities" I particularly liked the myopic use of the term "Internet Congestion". And here I thought that they had a solution for MAE-East.... ;-) I think the paper would have been more accurately titled: "Kludges to get around modems that don't say goodbye." or "We never should have introduced flat rate local dialing. What now?" ;-) ;-) Tony

3 3

Re: New MAE-EAST
by Sean Donelan 06 Nov '97

06 Nov '97

>Just try to bring up another point. Anyone has thought about Gigabit ethernet >switches? > >Prominet's Cajun switch has a 45GB backplane. Supports up to 24 full-duplex >Gigabit ethernet ports or 120 full-duplex fastethernet ports, or a mix >of both. The price is also very reasonable. There was a BOF at the last NANOG about the Digital version, Gigaswitch/Ethernet. However, it wasn't clear what the switch did when congested. There was some mention of IEEE congestion control, but that seems to use some sort of back pressure on the sender. I don't think that is what you want in an exchange point. A single congested egress port shouldn't block an ingress port at an exchange point. Especially if you are going to mix different types and speeds of ports. There was also some concern about the amount of buffering in the switch. And finally, when fully maxed out with ports the switch is oversubscribed, but that could be managed by only using two port cards rather than four port cards. And for a MAE-East size exchange, you will still quickly be faced with the problem tying two or more switches together, which makes the congestion control issue even more critical if it happens on a port between switches. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: New MAE-EAST
by Richard Irving 06 Nov '97

06 Nov '97

Richard Irving wrote: > > Reid Fishler wrote: > > > > Not to be rude or anything, but who is onecall? :-) > > Reid > > > > > We are a telco, specifically an IXC. We run an Exchange in Indiana. http://www.onecall.net/ http://www.indyx.net/ We, like Pac-Bell, and CHI, aren't having the same problems you are seeing at the FDDI exchanges.....

3 2

Re: New MAE-EAST
by Sean Donelan 06 Nov '97

06 Nov '97

>> I don't really fault MFS with these problems. Show me another >> exchange that is trying to pass as much traffic as MAE-east is and >> functioning properly. >> > > CHI is pretty close. Also, check Pac-Bell. > > Smooth surf. Pac-bell is running about 50% of MAE-East's aggregate inbound traffic level. AADS's web pages said they were going to get rid of their statistics pages, and it looks like they did because I can't find them anymore. But my memory was the Chicago-NAP was also much lower than MAE-East. The ATM NAPs have had different problems than the FDDI/Ethernet NAPs; but they've both had their growing pains. At one point both ATM NAPs installed FDDI rings as a work-around. Fortunately the Internet has had multiple types of NAPs available, and so far all the NAPs haven't had the same problems at the same time. However, all the NAPs do suffer from one common problem, providers who don't upgrade their egress from the NAPs when it is full. Even the ATM NAPs are having huge numbers of cell drops on certain providers' ports. This goes all the way back to the CIX router. Even the private interconnects between some providers have this problem. I think the third-party problem is pretty much a red-herring. Everyone is getting paid for service by somebody. The third-party problem seems to be one of finger-pointing. If I give all my Internet traffic to Sprintlink, Sprintlink act as much like a third-party as the Sprint-NAP acts when there are end-to-end performance problems. There isn't a single circuit in the Internet that isn't nominally 'managed' by someone, so there shouldn't be a single circuit connection problem that can't be isolated. No matter what the public may think, Internet circuits don't grow on trees. There is a observation problem for an outside observer, which lets the poorly performing provider shift blame. I've had an ISP tell me the reason packets were being dropped was MAE-East was full. Ok, open a ticket with MFS and after checking, it turned out the provider's circuit was running at capacity. Go back to the original provider, escalate it to their 'backbone engineering group' and find out they knew the port was full. It was just easier for their customer service people to blame it on "MAE-East," rather than the lack of facilities on the ISPs side. I see much of the same behavior from providers when it comes to fiber cuts. Mythology says the Internet can survive a atomic bomb, but not the backhoe. MFS has a MTTR of 2 hours, and a 99.99% availability target for its MAE's which is a higher target service-level than I see from most ISPs. I couldn't find any target performance goals for either of the Bellcore ATM NAPs, or most other exchange points. Of course, whether MFS is meeting their target service-levels is questionable. I had a question a few weeks ago, what is the best way to interconnect multiple things? If N providers want to exchange traffic, should each connect one large pipe to a common exchange point, or should each connect N smaller pipes with all the other providers? If I went out today, and tried to connect individual pipes between all the providers I exchange traffic, I end up with the same scaling problem as any other NAP. So far the solution I've seen from providers doing trying this is simply not scale past a small number n (3, 4, etc). Some folks try to limit connections by using unknowable numbers like the percentage of total Internet traffic a provider carries. Since no one knows or can even measure the total amount of Internet traffic, it is impossible to know any single provider's percentage of the total. Claims like 3 ISPs account for 90% of the Internet traffic are in the catagory that 80% of all statistics are made up. Even measuring just the traffic between end-points on two different providers is difficult because multi-homing may lead the traffic through diverse paths. I didn't know the InterNIC had so many different providers until I started peering with different providers. Besides Mark Kosters, I don't know if anyone on the outside NSI can really be sure they know of every single path to the InterNIC. Predicting what adding an additional path will do to existing traffic levels remains a problem. Simulating the Internet on anything smaller than the Internet is one of those traditional research problems, or a Scientific Wild-A** Guesses. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Communities
by James A. Farrar 06 Nov '97

06 Nov '97

At 03:53 AM 11/2/97 -0500, you wrote: > >On Sun, 2 Nov 1997, Kirby Files wrote: > >> Can you be a little more precise? Most providers probably use >> communities to tag subsets of the routes they carry, and some set of >> those communities, either through inclusion or exclusion, almost >> certainly describes the set of customer routes carried by that >> provider. (I'm sure this can be stated more clearly.) GTE certainly >> does, I'm pretty sure MCI still does, etc. > You are correct. http://infopage.mci.net/Routing/communities.html >What the basic question involved was whether providers have >some sort of community in place to distribute to customers >concerning their customer/internal routes. Also, it would be >nice if the provider would distribute this information to the >customer. Therefore, I was wondering which providers >had such communities and which providers were willing >to distribute said communities to customers. > >> Another question is, "Why do you want this info?" Taking full transit >> routes from a provider and trying to set localpref or MED based on >> whether the destination is a customer or peer network? If you are >> taking transit, there are good arguments for *not* running >> default-free. >> >It would seem to me to be helpful when coming up with >policy to route traffic bound for internal/customer >networks of an upstream to that upstream (unless that link >is down). Sometimes the path selection does not allow >this and we are forced to use foolish kludges like >as path prepending and other neanderthalic clubbings. > MCI offers announcemnets of: Backbone Routes Customer Routes Customer Routes - w/MED Full Routes Full Routes - w/MED For information on multihoming to MCI: http://infopage.mci.net/Routing/mhmci.html For information on mulitihoming to MCI and another provider: http://infopage.mci.net/Routing/mhp.html Jim Farrar jfarrar(a)mci.net >Bradley Reynolds >brad(a)iagnet.net >No Inflated Title >Internet Access Group > > >

2 1

/19 addresses and redundancy
by Steve Camas 06 Nov '97

06 Nov '97

Greetings, Here is a question -- maybe someone out there can suggest a solution to a problem... We are a small to mid-sized ISP and we feel that in order to compete in todays market we need to provide multiple circuits to different backbone providers and run BGP. We currently have a single T1 (from Sprintlink) which is handling our leased line, web, and dialup customers with little trouble (running at about 20-25%). We want to add another T1 to another major carrier so we can offer a backup circuit in the event our T1 goes down or if Sprint has a major outage. Of course, this wouldn't be just for backup -- it would share the load... We currently have 15 class C addresses and we have been told by Sprint that anthing smaller than a /19 BGP may get filtered. Since we have a whole bunch of non-contiguous class C address (which Sprint gave us), it seems that BGP would never work. So, we contacted the Internic and requested a /19 block so we can do this. The Internic refuses to give someone a /19 block unless they are in need of it right away (a few months projections). We don't need 32 Class Cs because we need to assign that many but we need them because we want to be able to use BGP. The Internic will not give them to us and we seem to have no options. Are there ways around this? Thanks, Steve

3 2