- Test - lists.nanog.org

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

Re: zone transfers
by Edward Vielmetti 05 Nov '97

05 Nov '97

I am running an audit of the in-addr zone to determin the extent of defective delegations. If your systems have delegations for zones under in-addr.arpa, they will be probed during the course of the audit. It is expected that the audit will complete within the next 8-10 days, if there are no interuptions. This would be a very useful report to run at appropriate (monthly?) intervals, with results posted as far and wide as Tony Bates's CIDR Report. thanks Ed Edward Vielmetti emv(a)umich.edu (alumni)

2 1

Re: moving to IPv6
by Pedro Marques 05 Nov '97

05 Nov '97

phil(a)charon.milepost.com (Phil Howard) writes: > The transition to IPv6 is clearly going to have some difficulties. We are > waiting on: > > 1. Network equipment, with translation > > 2. End user software > > 3. Address space assignment nice list. > IPv6-only space is of less value than IPv4-private space until IPv6 > becomes at least fully routeable over the Internet. So the backbone > networks are going to have to take the lead to make it happen. Even > when it is routeable, it has to work on all the ends, which will thus > have to have translations to make their IPv4 space appear as IPv6sub4 > space. > > The best workable scenario I can see so far is one where IOS and other > routing software includes translation between IPv4 and IPv6 IOS IPv6 prototype does include that facility. It translates to and from an arbitrary v4 network and an arbitrary v6 network. > Something is thus needed to encourage customers to move into IPv6 even > when it is fully routeable. That is really the key issue... because even with IPv6 NAT (protocol translation) working, IPv6 is as actractive as using IPv4 NAT, unless it brings some value added to the end customers... The potential advantage i see is autoconfiguration support. But DHCP can actually do the same job reasonably well. > But just having IOS translating IPv4 <-> IPv6s4 is not enough. Agreed. > We will need to manage the new IPv6 network. All the various tools we > use will need to understanding IPv6 and how it it configured on the > network. Routing will have to work right even during the transition > to this, which means BGP4v6 has to be there capable of understanding > IPv6 space at some point in time. BGP4 + Multiprotocol Extensions is able to do the job. And it is working resonably well... > > Routing issues will become different in IPv6. How ? > > If IPv6 allocations will have varying sizes like CIDR, then we might > continue to have issues of size based route filtering. OTOH, with the > right methods of allocating IPv6 space, no one should ever have to come > back to get more space. Eventually that should mean fewer routes as > IPv4/IPv6s4 closes down. Route filtering should be encouraged on IPv4 > space and prohibited on IPv6 space, at that point, IMHO. I don't think i really understand your point here.... The only "difference" when it comes to routing information i can think off is that in IPv6 there isn't suppose to be address ownership (which creates holes into CIDR blocks)... but it seems to me that the same policy is being adopted for IPv4. Pedro.

3 2

Overloaded semantics (was Re: moving to IPv6)
by rja＠corp.home.net 05 Nov '97

05 Nov '97

At the risk of stating the obvious, an observation about NAT and security... The problem is that IP addresses have overloaded semantics. Security needs an identifier. NAT and routing need locators. At present IP addresses serve both functions. We need to move to a world where locating a node is decoupled from identifying a node. In such a world, NAT could happen without causing IPsec to get broken by the NAT function. The overloaded semantics are broken. Noel has probably been the most outspoken in making this observation, but others have also noted the issue. Ran rja(a)Home.net

2 1