November 1997 - Test - lists.nanog.org

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

Re: /19 addresses and redundancy
by Al Roethlisberger 06 Nov '97

06 Nov '97

At 08:55 PM 11/5/97 -0500, you wrote: >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 > Well, since Sprint is one of the few major ISPs really filtering at the /19 boundary for some addresses(see below), and since this IS their addressing; you will probably do alright to try to advertise the networks via BGP. Although I would recommend persuing your own portable addressing, there is no reason that you should not be allowed to build some resiliency into your network just because of the networking. Although some networks have had some issues as times with longer than /19 prefixes, generally you can see from reports such as the CIDR report that there are plenty of networks out there, in service, that are not being filtered. Below is what is posted on the NANOG site as far as Sprint's filtering policy: n the classical "A" space: accept nothing longer than /8 In the classical "B" space: accept nothing longer than /16 in 24/8 space: accept nothing longer than /19 in 195/8: accept nothing longer than /19 in 206/8 - 223/8: accept nothing longer than /19 in 192/8 - 205/8: accept nothing longer than /24 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. al

1 0

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

06 Nov '97

Paul Ferguson wrote: > The operative concept in this paper is 'telephone networks'. Yup, "off-loading internet traffic from the PSTN onto data networks." Items of interest include section 3.6 'ISP Issues', technical issues such as tunneling, and strategic issues such as SS7 and TCP/IP. If you don't operate a network that interfaces w/ the PSTN then you may want to skip this.

1 0

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

06 Nov '97

Steve Sobol wrote: > > On Wed, Nov 05, 1997 at 07:53:53PM -0500, Richard Irving wrote: > > 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. > > Your web page loads faster than lightning from here - Who do you > connect (peer?) with? > > Just curious -- > About 25 other backbones (All ATM), and growing , with our primary transit being AS5646. Are you in MAE-E ? If so, pull up an OC3, and let us show what ATM can do! Cheers, Richard > Regards > Steve > > -- > Steve Sobol, Tech Support, New Age Consulting Service, Inc. 216 619-2000 > sjsobol @ nacs.net http://www.nacs.net > "No, we didn't relocate to the airport. Yes, I know that sounds like a > Boeing 747 in the background. It's not; it's our new Cisco 7513."

2 1

Architectural Solutions to Internet Congestion Based On SS7 and Intelligent Network Capabilities
by Sharif Torpis 06 Nov '97

06 Nov '97

I thought more than a few here would be interested in this press release and referenced white paper: http://www.bellcore.com/DISCOVER/PRESS/internetpr.html

3 2

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

06 Nov '97

Richard Irving wrote: > > Paul D. Robertson wrote: > > > > On Wed, 5 Nov 1997, Adam Hersh wrote: > > > > > With all of the problems with MAE-EAST..... > > > > > > Any plans from anyone to create a ATM exchange point in the DC area? > > > > Given the latency we've seen over some ATM backbones, I certainly hope not. I > > agree with Paul that MTU sizes in gigabit ethernet make it very > > attractive as a next step, Our nets *Scream*. > > I'd certainly be interested in seeing anything > > anyone has on fragmentation related delays going from a large MTU switched > > environment to a small MTU switched environment though. Overall, I've > > been less-than-pleased with latency when I've been transited that way. > > Uh... Doctor , it hurts when I do this. Doctor: So don't do that! Hint, it is *pretty* foolish to run mixed MTU's on switched fabric. *Most* people on ATM exchanges run with common MTU's. > > Paul > > ------------------------------------------------------------------------- > > Paul D. Robertson > > gatekeeper(a)gannett.com

1 0