- Test - lists.nanog.org

Emergency backup for a small net
by Bradley Dunn 20 May '97

20 May '97

Hi, We have a small ISP customer that wants to run a circuit to another local ISP and the ISPs would use that pipe only in the case of primary link failure. The two ISPs would split the cost, etc. The obvious solution would be for both ISPs to set up BGP peering with their upstreams and not announce anything in normal operation. The upstreams would continue to statically route the smaller ISPs' blocks and the smaller ISPs would default to their upstreams. The smaller ISPs would also put in a default pointing at each other with a higher cost. Then in the case of primary link failure the ISP who still has a path to the net would begin announcing the other ISP's block(s) to their upstream. The upstream would in turn see this as a valid announcement and propagate it to the world. Therefore specificity should draw all the traffic to the correct place. The problem is both ISPs are small and have /24s from their providers. The /24s would be filtered by many, leading to only partial connectivity in the case of failure. (Partial connectivity is better than no connectivity, I guess...) Another possible solution I thought of is to use NAT. The small ISPs would use RFC1918 internally and use a block from their provider to translate into. When the primary link fails they switch over to using a block from the other ISP's provider. They would also have to use very low TTLs for their DNS zones and be prepared to switch the DNS zones to point to the other block. Does the NIC consider this efficient utilization to have a block lying around that only gets used when a link fails? An important thing to remember here is that the backup link will not be used in normal operation. This is not multihoming. They do not want load balancing. I would be interested to hear others' thoughts on this. If you reply privately I will summarize any interesting replies to the list. Thanks! pbd -- You can make it illegal, but you can't make it unpopular.

5 6

Update on Feb 1997 notes
by sob＠academ.com 20 May '97

20 May '97

The Gigaswitch notes are now on-line. As some of you know, there was a scheduling snafu with my return flight from San Francisco and I was unable to stay for Paul Vixie's second talk or the closing comments from Bill Norton. If someone else has notes from either of these they are willing to share, please send them along to me and I will put them up on the notes page for the Feb 1997 meeting. Thanks in advance and my sincere apologies for Paul and Bill for not being able to take notes from their presentations. I have already taken steps to insure that I don't have this problem for the June meeting. For those of you in the US, have a good Memorial Day Holiday. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

RE: Root Nameserver Changes
by Peter Galbavy 20 May '97

20 May '97

On Tuesday, May 20, 1997 2:25 PM, Jim Fleming [SMTP:JimFleming@unety.net] wrote: > It would be good if the various continents had > their own Root Name Server Confederations. > If that were the case, traffic would not be shuttled > across the various oceans just to give the > illusion that there is operational redundancy. But does the fact that these packets cross continents imply less redundancy ? Given the number of transatlantic cables in place and the new ones on the way, I do not think it is reasonable to assume that (in this instance) that all of Europe will disappear at once ? > To add European root name servers to the > list that North American operators use does > not do them a service. Well, we Europeans have *suffered* because of the lack (all one of) non-North American root name servers. "You" did not seem so worried then (note the quotes around the word "you"). Distributing name servers is an operational issue, and given enough transit services to them, this is not really a redundancy problem, mearly political. Peter Galbavy Demon Internet Ltd http://www.demon.net/

1 0

NSF Solicitation for High Performance International Internet Services
by Steve Goldstein 20 May '97

20 May '97

"HIGH PERFORMANCE INTERNATIONAL INTERNET SERVICES "Solicitation NSF97-106 "I. Purpose "The U.S. National Science Foundation (NSF) seeks to assist the U.S. research and education community (R&E) in meeting its needs for next generation international Internet services. The goal is to provide the basis for the development of next generation applications supporting international collaborations and enabling interaction with global information and experimental resources. To this end, NSF solicits proposals for high-performance International Internet Services (HPIIS). " For those who might be interested, read/get it at http://www.cise.nsf.gov/ncri/nsf97-106.html. --Steve G. ---------------------------------------------------------------- Steven N. Goldstein, Ph.D. Program Director, International Networking Coordination Div. of Networking and Communications Research & Infrastructure National Science Foundation 4201 Wilson Boulevard, Room 1175 Arlington, VA 22230 USA Tel: +1-703-306-1949 (Extension 1119) FAX: +1-703-306-0621 sgoldste(a)NSF.GOV http://www.cise.nsf.gov/ncri/Stevehome.html ------- end of forwarded message -------

1 0

NSF Solicitation for High Performance International Internet Services
by Steve Goldstein 20 May '97

20 May '97

"HIGH PERFORMANCE INTERNATIONAL INTERNET SERVICES "Solicitation NSF97-106 "I. Purpose "The U.S. National Science Foundation (NSF) seeks to assist the U.S. research and education community (R&E) in meeting its needs for next generation international Internet services. The goal is to provide the basis for the development of next generation applications supporting international collaborations and enabling interaction with global information and experimental resources. To this end, NSF solicits proposals for high-performance International Internet Services (HPIIS). " For those who might be interested, read/get it at http://www.cise.nsf.gov/ncri/nsf97-106.html. --Steve G. ---------------------------------------------------------------- Steven N. Goldstein, Ph.D. Program Director, International Networking Coordination Div. of Networking and Communications Research & Infrastructure National Science Foundation 4201 Wilson Boulevard, Room 1175 Arlington, VA 22230 USA Tel: +1-703-306-1949 (Extension 1119) FAX: +1-703-306-0621 sgoldste(a)NSF.GOV http://www.cise.nsf.gov/ncri/Stevehome.html

1 0

REGISTRATION/PAYMENT REMINDER
by Pam Ciesla 20 May '97

20 May '97

The cutoff date for registration & the $100 fee is May 28. After the 28th the fee goes up to $120, also cancelations after the 28th will be charged $20. If you are not sure of your payment status you can check the Attendee LIst on the web page. If I have received any payment info it will show paid after your name. NOTE: I have not yet run credit cards. Speakers, host & a few others are not charged the registration fee and are indicated on the list. If you have questions please e-mail or call me. This list is current as of this morning. Also please allow for humane error, mine :*) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

trawhoisd beta testing
by Xin Liu 20 May '97

20 May '97

ftp://ftp.merit.edu/routing.arbiter/tools/trabeta.tar.gz It needs perl5.003. It works with RtConfig. ---------------------------Liu, Xin------------------------------ Merit Network, Inc Phone: (313)936-2115 (o) http://home.merit.edu/~xliu -----------------------------------------------------------------

1 0

MEETING INFO CORRECTION
by Pam Ciesla 19 May '97

19 May '97

The Nanog Meeting in Tampa at the Hyatt will be held in the Audubon Ballroom, section B thru F. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Feb 1997 notes are almost complete
by sob＠academ.com 18 May '97

18 May '97

Finally, I have been able to get all the notes (except those concerning the Gigaswitch) on line. I have also been able to get a number of slides on-line, but I don't have all of them. I expect to get the Gigaswitch notes on line later this week. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Emergency backup for a small net
by Hank Nussbacher 18 May '97

18 May '97

At 09:04 AM 5/18/97 -0400, Bradley Dunn wrote: This brings up a problem I have been trying to solve for a while that I have not found an answer to. A company with an old style Class B (/16) wants to be multihomed and split their incoming load between 2 ISPs (outgoing they can live with going via 1 and if the primary fails they fallback to the secondary conenction). In order to split the load on incoming, one ISP has to announce a /17 and the other ISP has to announce a /17 (or even the entire /16). But since this net is from the 147.x.x.x range, various ISPs around the globe will filter out the /17. This means that having a /16 from the 192.x.x.x range is better (these days), unless someone can show me a solution. Thanks, Hank >Hi, > >We have a small ISP customer that wants to run a circuit to another local >ISP and the ISPs would use that pipe only in the case of primary link >failure. The two ISPs would split the cost, etc. > >The obvious solution would be for both ISPs to set up BGP peering with >their upstreams and not announce anything in normal operation. The >upstreams would continue to statically route the smaller ISPs' blocks and >the smaller ISPs would default to their upstreams. The smaller ISPs would >also put in a default pointing at each other with a higher cost. Then in >the case of primary link failure the ISP who still has a path to the net >would begin announcing the other ISP's block(s) to their upstream. The >upstream would in turn see this as a valid announcement and propagate it >to the world. Therefore specificity should draw all the traffic to the >correct place. > >The problem is both ISPs are small and have /24s from their providers. The >/24s would be filtered by many, leading to only partial connectivity in >the case of failure. (Partial connectivity is better than no connectivity, >I guess...) > >Another possible solution I thought of is to use NAT. The small ISPs would >use RFC1918 internally and use a block from their provider to translate >into. When the primary link fails they switch over to using a block from >the other ISP's provider. They would also have to use very low TTLs for >their DNS zones and be prepared to switch the DNS zones to point to the >other block. Does the NIC consider this efficient utilization >to have a block lying around that only gets used when a link fails? > >An important thing to remember here is that the backup link will not be >used in normal operation. This is not multihoming. They do not want load >balancing. > >I would be interested to hear others' thoughts on this. If you reply >privately I will summarize any interesting replies to the list. > >Thanks! > >pbd >-- >You can make it illegal, but you can't make it unpopular. > >

3 2