- NANOG - lists.nanog.org

fyi - routing stability reports
by Curtis Villamizar 01 Aug '95

01 Aug '95

FYI- Did anyone notice they weren't getting routing stability reports from ANS? Don't answer that, I get enough mail as it is. :-) Due to a crashed disk, we lost data between July 8 when the last backup on this non-essential filesystem occurred and August 1 when we replaced the drive. You may have noticed lack of reports since July 17 (prior to that reports were generated, but we hadn't archived them to tape, so we've lost them. The main reson I'm asking is that I may have added report generation for one or two AS that don't border us and if this was between July 8 and July 17 the addition has been lost so you have to make the request again. Curtis ps - the routing stability reports are not an officially supported service of ANS. They exist to help identify operational problems. Other providers find them useful, so I'm trying to keep them going.

1 0

Re: US Domain -- County Delegations
by Paul A Vixie 01 Aug '95

01 Aug '95

a private conversation has borne some useful fruit: >> I gathered from some mail that Paul sent out recently >> that there was no problem with overloading of the root >> servers. Something about the fact that his BSD/OS Pentium >> was handling 100lookups/second without breathing hard... > The question is is the growth exponential? the 100/sec number has been pretty stable for the last four months. it was 80/sec last year. it bursts up to 150/sec a few times an hour. no big deal. i could do 600/sec before i would have to worry about the cpu speed. i would fear for the interconnects if all seven root servers got 600/sec. there are two kinds of root server queries. one is a name server starting up and trying to "bootstrap" its cache using its root.cache or named.ca or what- ever file. the other is when a recursive server doesn't have an answer and has to delegate. therefore the root server load scales with the number of recursive name servers, not with the number of clients or the number of domains registered. if it were otherwise, the world would have melted long before now.

1 0

BMWG/IPPM Meeting Adjacent to NANOG
by almes＠advanced.org 01 Aug '95

01 Aug '95

As you develop your travel plans for the Pittsburgh NANOG meeting (which runs from morning of Monday, 11-Sep, through noon of Tuesday, 12-Sep), be aware of the following. At the Stockholm IETF meeting, there was a decision to have an interim meeting of the BMWG regarding our new effort in the area of IP Provider Metrics, and that the best time to have this meeting would be adjacent to NANOG. So, a more formal message defining that meeting and its agenda will be sent to the appropriate lists within a week. For the present, I only want to encourage anyone who will be attending NANOG and is interested in IPPM agenda to reserve the afternoon of Tuesday, 12-Sep, between 1:30p and 5:00p, at PSC, for that meeting. -- Guy

1 0

Re: root name servers
by Robert E. Seastrom 01 Aug '95

01 Aug '95

> Erik Sherk and I have arranged for internic to be one hop off of > suranet's router on mae-east. Additionally, expect to see some changes > in the root servers configuration on namedroppers as soon as I can dig > out of my large amount of mail that I recently have received... terp.umd.edu will likely be in a similar situation real soon now, but i'm not the one who's coordinating that. ---Rob

1 0

Re: US Domain -- County Delegations
by Vadim Antonov 31 Jul '95

31 Jul '95

> We are planning to delegate every county name as a locality name in each > State. For example, "Ventura.CA.US", "Dade.FL.US", "Riverside.CA.US". Too many levels is _very_ bad, as people will stick to using old three-letter domains. How about limiting the scheme to <orgname>.<state>.us? Or, even better, for major metropolitan areas like SF, LA, NYC, CHI etc the name central city can be used instead of state. That scheme worked reasonably well for .SU :) --vadim

15 33

Re: root name servers
by Peter Lothberg 31 Jul '95

31 Jul '95

> the root servers are not currently suffering from load (my own server does > about 100 queries per second, which is about 10% of the capacity of my little > 66Mhz/64MB BSD/OS machine). the goal here is to reduce load on the wide area > net rather than on the root servers themselves. and also to increase the > likelihood that any given host can reach a root server during times of wide- > scale connectivity problems (which seem to be more common lately?) >From a pretty central place in the Internet; 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 4 msec 4 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 40 msec 8 msec 88 msec 3 icm-fix-e-H2/0-T3.icp.net (192.157.65.122) 20 msec 0 msec 0 msec 4 sura9-fix-cf.sura.net (192.203.229.9) 56 msec 4 msec 4 msec 5 cpk9-cpk-cf.sura.net (128.167.252.9) [AS 86] 0 msec 4 msec 4 msec 6 wtn8-cpk9-c3.sura.net (128.167.212.2) [AS 86] 8 msec 4 msec 4 msec 7 wtn4-wtn8-ce.sura.net (128.167.24.4) [AS 86] 12 msec 12 msec 4 msec 8 netsol-wtn4-c1.sura.net (192.221.22.2) [AS 86] 16 msec 4 msec 8 msec 9 NS.INTERNIC.NET (198.41.0.4) [AS 86] 8 msec 8 msec 8 msec ICM-MAE-E#sh ip bgp 128.63.4.82 % Network not in table ICM-FIX-E>sh ip bgp 128.63.4.82 % Network not in table 1 cpe2.Washington.mci.net (192.41.177.181) 0 msec 0 msec 4 msec 2 border2-hssi4-0.Washington.mci.net (204.70.57.9) [AS 3561] 12 msec 0 msec 0 msec 3 core-fddi-1.Washington.mci.net (204.70.3.1) [AS 3561] 0 msec 4 msec 4 msec 4 core-hssi-3.Atlanta.mci.net (204.70.1.10) [AS 3561] 24 msec 16 msec 20 msec 5 core-hssi-4.Houston.mci.net (204.70.1.26) [AS 3561] 40 msec 36 msec 36 msec 6 core-hssi-3.Bloomington.mci.net (204.70.1.34) [AS 3561] 76 msec 72 msec 76 msec 7 border1-fddi0-0.Bloomington.mci.net (204.70.2.130) [AS 3561] 72 msec 72 msec 72 msec 8 csunet-losnettos.Bloomington.mci.net (204.70.48.6) [AS 3561] 76 msec 76 msec 76 msec 9 ISI-SWRL-GW.LN.NET (204.102.78.1) [AS 2150] 284 msec 236 msec 216 msec 10 ln-gw.isi.edu (128.9.16.1) [AS 226] 228 msec 196 msec 80 msec 11 NS1.ISI.EDU (128.9.0.107) [AS 226] 80 msec 80 msec * 1 mae-east.psi.net (192.41.177.245) 4 msec 4 msec 4 msec 2 38.1.2.14 [AS 174] 124 msec 16 msec 4 msec 3 C.PSI.NET (192.33.4.12) [AS 174] 4 msec 8 msec 16 msec 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 12 msec 12 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 4 msec 4 msec 4 msec 3 icm-fix-e-H2/0-T3.icp.net (192.157.65.122) 4 msec 4 msec 4 msec 4 sura9-fix-cf.sura.net (192.203.229.9) 4 msec 4 msec 0 msec 5 umd-cpk2-c1.sura.net (192.221.61.2) [AS 86] 12 msec 8 msec 4 msec 6 csc1gw-f0.umd.edu (128.8.1.224) [AS 86] 4 msec 8 msec 8 msec 7 TERP.UMD.EDU (128.8.10.90) [AS 86] 8 msec 4 msec 4 msec 1 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 0 msec 0 msec 4 msec 2 sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41) [AS 1239] 0 msec 0 msec 4 msec 3 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) [AS 1239] 4 msec 4 msec 4 msec 4 sl-stk-5-H1/0-T3.sprintlink.net (144.228.10.2) [AS 1239] 68 msec 64 msec 64 msec 5 icm-fix-w-H2/0-T3.icp.net (144.228.10.22) [AS 1239] 136 msec 68 msec 80 msec 6 NS.NASA.GOV (192.52.195.10) [AS 297] 68 msec 68 msec 68 msec 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 4 msec 4 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 164 msec 16 msec 0 msec 3 icm-pen-1-H1/0-5M.icp.net (198.67.131.18) 8 msec 16 msec 16 msec 4 icm-uk-1-H0/0-T3.icp.net (198.67.131.26) 104 msec 100 msec 100 msec 5 icm-stockholm-2-H0/0-5M.icp.net (198.67.131.42) 124 msec 128 msec 136 msec 6 nord-gw.nordu.net (192.36.148.194) [AS 2603] 196 msec 128 msec 124 msec 7 NIC.NORDU.NET (192.36.148.17) [AS 2603] 128 msec 128 msec 128 msec 1 Vienna1.VA.Alter.Net (192.41.177.249) 4 msec 4 msec 0 msec 2 Vienna5.VA.ALTER.NET (137.39.11.9) [AS 701] 0 msec 4 msec 0 msec 3 San-Jose3.CA.ALTER.NET (137.39.13.5) [AS 701] 68 msec 68 msec 68 msec 4 San-Jose5.CA.ALTER.NET (137.39.27.6) [AS 701] 64 msec 68 msec 68 msec 5 Palo-Alto1.CA.ALTER.NET (137.39.29.3) [AS 701] 68 msec 72 msec 208 msec 6 Palo-Alto3.CA.ALTER.NET (137.39.47.7) [AS 701] 232 msec 72 msec 68 msec 7 fw.ramona.vix.com (204.123.0.3) [AS 33] 84 msec 68 msec 72 msec 8 NS.ISC.ORG (192.5.5.241) [AS 3557] 72 msec 72 msec 68 msec 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 12 msec 8 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 0 msec 0 msec 12 msec 3 icm-fix-e-H2/0-T3.icp.net (192.157.65.122) 20 msec 4 msec 4 msec 4 192.203.229.251 4 msec 4 msec 4 msec 5 137.209.1.2 [AS 568] 8 msec 8 msec 8 msec 6 GSI-GW3.DDN.MIL (198.25.64.2) [AS 568] 12 msec 12 msec 12 msec 7 NS.NIC.DDN.MIL (192.112.36.4) [AS 568] 12 msec 12 msec 12 msec > > For security and stability reasons (aswell as political) they should > > not be run by a single organisation. > > they never have been. The Mannings proposal of a single domain, seems to me like the first step... --Peter

4 3

Re: EP.NET ???
by Peter Lothberg 31 Jul '95

31 Jul '95

> > There have been a number of questions that have been fielded > wrt the EP.NET domain and traceroute failures within that > domain. For your edification, here is a brief note on the EP.NET > domain. > > EP.NET operated as a service by the RA for exchange points around > the globe. Any exchange point may become part of the EP.NET domain. > The default assignment algorithm follows. The next level > identifies the specific exchange. The next level identifies > the attaching organization. > > So, the default for BillsBait&SushiShop (BBSS) at MAE-WEST is: > > bbss.mae-west.ep.net > > When BBSS attachs to the AADS NAP, the default name is: > > bbss.aads.ep.net > > Selection of provider specific names is encouraged. > So when BBSS gets around to it, they may change the names to > something like this: > > mae-west.bbss.org > aads.bbss.org Bill, Personally I think that this is actually a value-subtracted service, as the EP.NET organisation does not run the named boxes, or the exchange points. It would be much more helpfull the the interfaces that faces the NAP and another provider where following each providers naming conventions, and had a domain-name that would point the users to the organisation that actually operates the boxes. You can still provide the service of running the nameservice. --Peter

3 4

Re: EP.NET ???
by Peter Lothberg 31 Jul '95

31 Jul '95

begin kludge interface fddi0/0 ip address yor.own.net.work your.mask.as.desired ip address bill.assigned.c.net 255.255.255.0 secondary end kludge; If the box decides to send a ICMP message out on the interface that faces the RA pirated network it will use the primary address, so it will show up with the name and network number you prefer. -Peter

2 1

Re: root name servers
by owen＠DeLong.SJ.CA.US 31 Jul '95

31 Jul '95

> there has never been a shortage of volunteers to run root servers. i'm > not sure that the exchange points are good spots, since the folks who run > exchange points (MFS, NASA, Pac Bell, etc) usually know a lot more about > the link level than the network level -- and besides, i'm not sure that a > root name server ought to have an ASN and run BGP4, which means that it > will have to be behind a router that _does_ have an ASN and run BGP4. if > this is to be the case, i'd rather see the routers inside NSP offices, > where UNIX experts and network experts are more plentiful than at the > exchange points. > Actually, I think that it might be interesting to look at the possibility of putting Root DNS on the Route-Servers. > to that end, NS.ISC.ORG is one 10Mb/s hop away from BADnet (barrnet-alternet- > digital) in the DECWRL computer room. it's likely that i will shortly add > an SMDS T1 connection to the CIX cloud for other reasons, and that will help > a tiny bit (only a tiny bit, since Alternet has T3 to that cloud from the > router i peer with in that room.) > > work is underway (by the Postel-Mockapetris-Vixie-Kosters quadumvirite) to > implement Bill Manning's suggestion of putting all the root servers under > a single domain, which will let DNS' name compression start winning for us. > if this works out, we should be able to just about double the number of root > name servers. NSP's with multiple T3's to geographically disparite exchange > points will be given strong preference. sites outside the United States will > be given strong preference. > Interesting... That should definitely help. > the root servers are not currently suffering from load (my own server does > about 100 queries per second, which is about 10% of the capacity of my little > 66Mhz/64MB BSD/OS machine). the goal here is to reduce load on the wide area > net rather than on the root servers themselves. and also to increase the > likelihood that any given host can reach a root server during times of wide- > scale connectivity problems (which seem to be more common lately?) > True. However, the nice thing about a RNS on an XP is that the RNS is one hop from EVERY provider at the XP, and is independent of OTHER providers. I agree that the XP management shouldn't manage the RNS. However, I would be QUITE comfortable with MERIT running it on the RS or adjacent machine. > > For security and stability reasons (aswell as political) they should > > not be run by a single organisation. > > they never have been. > Although I agree that ALL RNS's shouldn't be run by a single organization, I would not have a problem with the RNS's at the XP's being run by the RADB group. Owen

4 3

Re: root name servers
by Sean Doran 30 Jul '95

30 Jul '95

>I would not have a problem with the RNS's at the XP's being run >by the RADB group. Well, *I* would! Sean.

2 1