- Test - lists.nanog.org

Re: Verio Decides what parts of the internet to drop
by Martin Cooper 05 Dec '99

05 Dec '99

Sean Doran <smd(a)clock.org> wrote: > It doesn't need to be equitable and fair to all; the fact is that > I consider my routing table slots to be a scarce resource, and > I will conserve that resource. Filtering is one approach; a step > towards your approach is relaxing filters for people willing to > pay me money to do so. This is the reality. The Internet is no longer an academic/ research network, and the sooner people accept that money talks (and bullsh*t walks) in a commercial context, the sooner an equitable mechanism for guaranteeing reachability to specific networks will become established. > People with hardcore reasons for using a too-long prefix will > probably be willing to pay a fee to an agent able to broker > cheapest-possible access to the routing slots in the networks > that are smart enough to sell them. I like this idea very much, because it makes a clear distinction between transit and reachability services. For instance, I might not want to use Sprint for transit, even though I want to have reachability to its customers. M.

1 0

Re: How to achieve application reliability
by Sean Donelan 05 Dec '99

05 Dec '99

On Sat, 04 December 1999, James Smith wrote: > Our only alternative is to eliminate every single-point failure with stuff > like high availability clustering, redundant feeds, battery backups, > nuclear reactors, physical separate sites on different planets, etc. :-) > (Pardon me, it's 2:00am and I'm getting punching) If you are using Microsoft products in your nuclear reactor, its not going to be very reliable. They aren't designed for that purpose. The tools exist to make very reliable network applications, but we can't force people to use them. So long as applications neglect to use the other information provided by the network, they are going to be vulnerable to single points of failure. Multiple A records exist for a reason. Even if you have high availability clustering, redundant feeds, battery backups, multi-homing, multi-sites; if you are depending on a single global network announcement there is nothing to prevent another ISP from announcing the same prefix with a shorter AS path length, and effectively blackholing your network. For people with ultra-high reliablility requirements, a /19 isn't the solution.

3 2

Net 24 (was Re: Verio Decides what parts of the internet to drop)
by Sean Donelan 05 Dec '99

05 Dec '99

On Sun, 05 December 1999, "Travis Pugh" wrote: > Absolutely. A standard would give ground rules, and would be something to > point to when you have to go to a client or customer and say "these are your > options." > > Instead, we are looking at a routing system where some traffic will flow on > some networks if it is a longer subnet of a class B address, and will not > flow on some networks based on arbitrary filter decisions. Some kind of RFC > based consistency would be great. I've always wondered, where is the RFC for network 24?

2 1

RE: Verio Decides what parts of the internet to drop
by smd＠clock.org 05 Dec '99

05 Dec '99

| I want to highlight the danger of such, non-coordinated extra | filtering done by one ISP. It's really dangerous for the Internet. ^^^^^^^^^ It has been in place since 1996, and the Internet has not yet died. Q.E.D. I do not believe for one moment that a coordinated approach would ever have happened. Sean.

1 0

Host modify broken/NIC?
by Greg Simpson 05 Dec '99

05 Dec '99

Has anyone else experienced unusual trouble with emailed host modifications wrt 'network solutions' ? [And is there a list dedicated to netsol problems?] Submitting a modify from the owner of the domain generates the following standard message.. Unfortunately, 'gws(a)sweet.com'!='gws(a)sweet.com' in their eyes, and no ACK rqsts are ever sent to the contacts. I fear something [else] may be broken.. [Their helpful customer service has indicated multiple times that an ACK rqst form will be sent to the contacts, and upon learning that this isn't the case, they get confused and scurry.] Suggestions eagerly awaited (off the list?). -g ---------- Forwarded message ---------- Date: Fri, 3 Dec 1999 03:19:40 -0500 (EST) From: Host Registration Account <hstreg(a)internic.net> To: gws(a)sweet.com Subject: Re: [NIC-991202.18749] NOFEAR.SWEET.COM We have received your request to register or modify a host record, but we are unable to process it at this time. All Host Forms must be submitted from the e-mail address of the current host contact, or from the administrative or technical contact for the second level domain name registration. It appears that the request we received was not submitted from an appropriate e-mail address. We have sent a notification message to the e-mail address on file for all of the above mentioned contacts. If any one of them acknowledges the update, we will process the request. Network Solutions email hostmaster(a)internic.net ========================================================================= (NOFEA-HST) Hostname: NOFEAR.SWEET.COM Address: 209.244.254.22 Contact: Simpson, Greg W (GWS2) gws(a)SWEET.COM 617-373-7396 Record last updated on 08-Oct-1998. Record created on 11-Feb-1998. =========================================================================

2 3

RE: Verio Decides what parts of the internet to drop
by smd＠clock.org 05 Dec '99

05 Dec '99

| The memory for the routing tables was a deal just about 2 years ago; this | became easier to maintain big tables today (when routers can be easily upgraded | to 256 MB RAM). So, Alex, this is a 4x improvement over the situation in 1995, when 64Mb was possible but rare... Sean.

2 1

IP cannot provide reliability on the public Internet
by mark＠vielle.datasys.net 05 Dec '99

05 Dec '99

The persistent furor over route filtering does make a depressing point: in general, IP cannot be used to provide reliability or load distribution over the public Internet. It seems that every significant ISP enforces filtering on routes that goes beyond the filtering necessary for correctness. The cumulative effect is that the reliability features inherent to IP and dynamic routing protocols cannot be enjoyed by the Routing Underpriviledged -- those organizations that are small enough (or frugal enough) to live with a small IP space. And there is not any real, fundamental reason for this. It's such a common practice that it doesn't seem to get its fair share of critical analysis. (Just when *will* routers be capable?) >From my perspective as a developer, the widespread long-prefix filtering undermines the value of much of the original work done to develop the Internet. Problems that have already been solved at the IP layer have to be solved again at a higher layer; we're likely to find ourselves working in a soup of protocols where a problem may be solved well at one layer, or kludged poorly at several other layers, and in which we're forced to kludge poorly because of antiquated ideas of propriety or efficiency. I welcome comments. --- Mark R. Lindsey, mark(a)datasys.net DSS Online Development Group Voice: 912.241.0607, Fax: 912.241.0190 (US)

2 1

Re: How to achieve application reliability
by Sean Donelan 05 Dec '99

05 Dec '99

On Sat, 04 December 1999, James Smith wrote: > internetsecure to type in the credit card. The problem with Round-Robin > DNS is the possibility of the consumer's web browser picking up an IP > address of a server that is down. If it was a real payment gateway, your Finally, a problem I can agree with. Netscape's browser did some interesting things for application reliability when accessing home.netscape.com. But for other web sites it seems to be one strike and you're out. Other browsers followed their lead. Actually, I think Mosiac was first, so the programmer meme was already formed. The original CERN web browser did try alternate A records. The CERN browser had a problem handling interrupts when the user got tired of waiting, so the Mosaic "error-recovery" method of the user clicking on refresh until it finally worked seemed like an improvement. The law of unintended consequences? The application programmers will say its the networks fault. The network engineers will say its the applications fault. And the user says a pox on all your houses.

2 1

Re: How to achieve application reliability
by James Smith 05 Dec '99

05 Dec '99

With stuff like that you're still faced with a problem. What if a customer has been directed to a server that is working fine to begin with, and then dies. The 3DNS stuff will make the changes to avoid the server, but the customer's browser won't pick up those DNS changes and they'll be left hanging. Also, you'd have to keep the DNS TTL low or else you have to deal with the DNS info being caching on ISP server. To further complicate things the TTL is only the minimum required time to live. I've discovered instances where cached DNS information will be stored for weeks, even though the authoritative DNS TTL was originally set to a day. Our only alternative is to eliminate every single-point failure with stuff like high availability clustering, redundant feeds, battery backups, nuclear reactors, physical separate sites on different planets, etc. :-) (Pardon me, it's 2:00am and I'm getting punching) -- James Smith, CCNA Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2140 Winston Park Drive, Suite 203 Oakville, ON, CA L6H 5V5 Tel: 905-829-3389 (email preferred) Fax: 905-829-5692 1-877-DXSTORM (1-877-397-8676) On Sat, 4 Dec 1999, Jason A. Mills wrote: > Isn't this why you use things like F5/3DNS? > > Just curious... > > -Jason > > > On Sun, 5 Dec 1999, James Smith wrote: > > > ... > > internetsecure to type in the credit card. The problem with Round-Robin > > DNS is the possibility of the consumer's web browser picking up an IP > > address of a server that is down. If it was a real payment gateway, your > > ... > > > > -- > > James Smith, CCNA > > Jason A. Mills phyxis(a)rottweiler.org > "We all live in a house on fire, no fire department to call, no way > out, just the upstairs window to look out of while the fire burns the > house down with us trapped, locked inside it." -- Tennessee Williams > >

1 0

RE: Long Prefix Redundancy (Was: Verio Decides what parts of the internet to drop)
by Derrick Bennett 05 Dec '99

05 Dec '99

Since we are all here at this point I would like to ask some questions on what should be done for the small companies. I have setup several /24's with various ISP's and have gotten them multi-homed with secondary ISP's, setup BGP and overall things work relatively well. Now I have always been able to go to some of the route servers and looking glass sites and see my annoucements making it to several providers. But I have no way of knowing that every ISP is accepting these routes and I have always beleived that they weren't anyway. Now through all this many people have asked the same question I am asking. Companies that are being responsible and only occuping a single class C still need redundancy and to me this is what BGP was meant to do. What does the nanog community in general think should be done to help this growing group of customers ? I never remember reading a FAQ anywhere that said only large networks should get the redundancy features that have been built into the Net. And to answer the other point many of my customers would not mind paying a fee to make their routes known. I would rather pay for proper routing then pay for a /19 and waste space. Derrick > -----Original Message----- > From: James Smith [mailto:jsmith@dxstorm.com] > Sent: Saturday, December 04, 1999 4:21 PM > To: Travis Pugh > Cc: Alex P. Rudnev; nanog(a)merit.edu > Subject: Re: Verio Decides what parts of the internet to drop > > > > The unfortunate reality is that there are a lot of businesses > that need > 99.99% reliability and uptime, but aren't big enough to get a /19. > > My previous company was a credit card processing gateway. If > they went > down, their customers were screwed. But they hadn't even > used a Class C, > so they weren't eligible for a /19 or /20 from ARIN. > > My point is that the current requirement that a network must > have a large > chunck of IP space to be multi-homed is not ideal. According to the > status quo, while an e-commerce company such as a credit card > processor > may be big in the business world and worth millions, but > insignificant on > the Net and left vulnerable because it can't be multi-homed. > > > -- > James Smith, CCNA > Network/System Administrator > DXSTORM.COM > > http://www.dxstorm.com/ > > DXSTORM Inc. > 2140 Winston Park Drive, Suite 203 > Oakville, ON, CA L6H 5V5 > Tel: 905-829-3389 (email preferred) > Fax: 905-829-5692 > 1-877-DXSTORM (1-877-397-8676) > > On Sat, 4 Dec 1999, Travis Pugh wrote: > > > > > I've been lurking and looking at this conversation too long > ... my head is > > spinning. Alex says there are many reasons causing people > to announce B > > nets with short prefixes, and he is entirely right. The > primary one would > > be that a client, by some inexplicable reasoning, expects > their Internet > > service to be up and running reliably at least 95% of the time. > > > > The disturbing message I have been able to glean from this > thread is that: > > > > - If you need reliability, get a /19 > > - If you are a small customer, using only a /24 for > connectivity (and thus > > helping to slow depletion) you are not BIG enough to expect > multi-path > > reliability into your network > > - If you are a big provider, not only do you not have to provide a > > consistent level of service to your customers, but you are > free to block > > them (and anyone else from other providers) arbitrarily > when they spend a > > good deal of money to augment your service with someone else's > > > > The gist of the conversation, IMO, is that customers can't > have reliability > > with one provider, but they will be blocked from having > reliability through > > multiple providers if their addresses happen to be in the > "wrong" space. > > Something's wrong with that. > > > > Cheers. > > > > Travis > > Eeeevillll consultant > > > > ----- Original Message ----- > > From: Alex P. Rudnev <alex(a)virgin.relcom.eu.net> > > To: Randy Bush <rbush(a)bainbridge.verio.net> > > Cc: <doug(a)safeport.com>; <nanog(a)merit.edu> > > Sent: Saturday, December 04, 1999 5:08 PM > > Subject: Re: Verio Decides what parts of the internet to drop > > > > > > > > > > > > > It should be your problem. You simply loss the part of > connectivity... > > > > > > The real world is more complex than you drawn below. > There is many reasons > > > causing people to announce class-B networks with the > short prefixes. > > > > > > > > > > > > > > > > > > On Thu, 2 Dec 1999, Randy Bush wrote: > > > > > > > Date: Thu, 02 Dec 1999 13:00:17 -0800 > > > > From: Randy Bush <rbush(a)bainbridge.verio.net> > > > > To: doug(a)safeport.com > > > > Cc: nanog(a)merit.edu > > > > Subject: Re: Verio Decides what parts of the internet to drop > > > > > > > > > > > > > Apparently for their convenience Verio has decided > what parts of the > > > > > Internet I can get to. > > > > > > > > verio does not accept from peers announcements of > prefixes in classic b > > > > space longer than the allocations of the regional registries. > > > > > > > > we believe our customers and the internet as a whole > will be less > > > > inconvenienced by our not listening to sub-allocation > prefixes than to > > have > > > > major portions of the network down as has happened in > the past. some > > here > > > > may remember the 129/8 disaster which took significant > portions of the > > net > > > > down for up to two days. > > > > > > > > the routing databases are not great, and many routers > can not handle > > ACLs > > > > big enough to allow a large to irr filter large peers. > and some large > > peers > > > > do not register routes. > > > > > > > > so we and others filter at allocation boundaries and > have for a long > > time. > > > > we assure you we do not do it without serious > consideration or to > > torture > > > > nanog readers. > > > > > > > > > With no notification. > > > > > > > > verio's policy has been constant and public. > > > > > > > > randy > > > > > > > > > > > > > > Aleksei Roudnev, > > > (+1 415) 585-3489 /San Francisco CA/ > > > > > > > > > > > > > >

3 2