- NANOG - lists.nanog.org

Re: Why aren't ISPs providing stratum 1 NTP service?
by David C. Kovar 17 Jul '96

17 Jul '96

>It seems to me that the days when running a GPS refclock into an NTP server >was exotic are long past. Why don't providers give NTP stratum 1 service to >their customers? Then I can at least shed some of the most suspect clients >(it's the routing path not the user that is suspect.) > >In search of good time for all, >Jerry I looked into setting up a WWV based refclock a few months back for a client. We were unable to find a WWV capable clock for under a few thousand dollars. The old Heathkit one ($300 or so?) was no longer available and all of the other ones I found mentioned in the xntp docs were in the thousands. You mention using a GPS clock, while I've been looking into WWV. Can you point me to some, hopefully inexpensive, hardware that we could use to provide this service? -David

1 0

Re: The root nameservers will be replaced August 1st
by salo＠msc.edu 17 Jul '96

17 Jul '96

> To: nanog(a)merit.edu > Subject: Re: The root nameservers will be replaced August 1st > Date: Tue, 16 Jul 1996 22:43:38 -0700 > From: Paul A Vixie <paul(a)vix.com> > > > If the information in the following message means what I think it means in > > then somebody is colocating an entire new set of root nameservers at > > exchange points within the USA if not internationally. > > Yes. However, we are expecting exchange point operators to show some kind > of common sense, which means asking the IANA before they sign onto such a > project. > [...] I would like to think that, at lease in a general sense, the exchange point operators will not ask their customers what type of traffic the customer expects to transmit across an exchange point. Granted, connecting a host to an exchange point might warrant greater scrutiny than connecting a network.... More interestingly, if someone wants to create an alternative set of root servers, there is no particularly good reason for them to be located at exchange points, (unless I am confused about what networks are all about...). True, servers at exchange points should exhibit greater availability, but that is probably not the largest challenge faced by alternative root servers. -tjs

1 0

Re: Why aren't ISPs providing stratum 1 NTP service?
by avg＠ncube.com 17 Jul '96

17 Jul '96

>From customer's point of view, getting stratum 1 service is not a good idea. The stratum 2 clocks tend to be more stable. I think it would be a good idea to stop providing startum 1 service to anybody but ISPs who would then provide s2 clocks straight out of their ciscos to customers thus avoiding the symmetry issues. Reducing load on s1 clocks is also a good thing, as it could improve accuracy. --vadim >I just crossed the 200th machine syncing of one of my stratum 1 servers. I >like providing the service and it doesn't cost very much for me to offer the >service. the problem I have with this is that NTP hates asymmetric routing, >so the likelyhood is that for most people outside the provider that serves >this machine, NTP time is suspect. > >It seems to me that the days when running a GPS refclock into an NTP server >was exotic are long past. Why don't providers give NTP stratum 1 service to >their customers? Then I can at least shed some of the most suspect clients >(it's the routing path not the user that is suspect.) >In search of good time for all, >Jerry

1 0

FYI: Internet gridlock article
by Hank Nussbacher 16 Jul '96

16 Jul '96

"Internet gridlock escalates, ISPs predict autumn Web brownouts" By Stephen Lawson InfoWorld Electric http://www.infoworld.com/cgi-bin/displayStory.pl?960715.gridlockisp.htm ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il WWW: http://www.ibm.net.il/~hank ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

3 2

re: problem at mae-west tonight?
by Rob Liebschutz 15 Jul '96

15 Jul '96

> The problem I have with the route server this evening is that I announce > my routes to the route server, and my policy configuration in the route server > reflects that I peer with Netcom, and so the route server tells Netcom how > to reach me. Unfortunately, packets leaving Netcom headed to me at layer 2 > are going into a black hole. To fix this, I've had to dump my peering with > the route server entirely, so that Netcom is only seeing my routes from AGIS > (our transit provider) and not from the route server. Ugh. My fears about > the route server not knowing the status of the layer 2 topology have come true, > and there's no way to fix this that doesn't involve manual intervention. > > -matthew kaufman > matthew(a)scruz.net > > Well, I run gated on a BSDI box for the Hooked MAE West router. I'm thinking about implementing a "pingnouse INTERVAL" option on the peer/group commands in gated, so it will periodically ping next hops received from the route servers and set the nouse bit if the nexthop is unreachable. Any better ideas? It would be nice to come up with a good mechanism for doing 3rd party keepalives that cisco and other router vendors would be willing to implement. Rob

5 5

Re: problem at mae-west tonight?
by Rob Liebschutz 15 Jul '96

15 Jul '96

Actually I've seen the arp problem as well. What arp entry do you have for them? We have: mae-west.netcom.net (198.32.136.15) at 0:0:c:61:b:0 If yours is different, you could try deleting it and if it still comes back wrong, you could try temporarily adding a static entry. Are either you or netcom connected through a netedge? > ps. At this point, we still can't see Netcom... problem has lasted for 1 day, > 8 hours. From my interface (198.32.136.18) I cannot ping Netcom at > 198.32.136.15, but I can ping Alternet at 198.32.136.42. That points to > a layer 2 discontinuity. > >

1 0

Re: problem at mae-west tonight?
by Rob Liebschutz 15 Jul '96

15 Jul '96

Yes, this type of topology failure is possible too. I can recall times when there were problems on the links between Ames and MFS. Yes, the link is 2 OC3s. > > Robert, > > It's my understanding that MAE-W is composed of two facilities, > one at MFS, and the second at NASA-AMES. > > It's my understanding that while a virtual medium is created, they > actually reside on two separate gigaswitches. I seem to recall 1 > or 2 OC3s connecting the two..... > > Given this, it is, then, possible that the route server is located > on segment A, while customers x,y, and z are located on segment B. > > If you are on segment A, and try to follow the RSes advice to talk > to x, y, and z, you are depending on the links connecting the two > segments. > > However, I may be incorrect. > > -alan

1 0

Re: problem at mae-west tonight?
by matthew＠scruz.net 15 Jul '96

15 Jul '96

Original message <199607150340.UAA00784(a)elite.exodus.net> From: Robert Bowman <rob(a)elite.exodus.net> Date: Jul 14, 20:40 Subject: Re: problem at mae-west tonight? > > We experienced the same thing with Netcom. Currently we are peered with over > 40 netwroks through the RS, but I have only had this problem with Netcom. > > Is it really a next-hop problem or a Netcom internal problem? Last time > this happened, about 2 weeks ago, they cleared their RA session and did > some other things and everything came up fine. I did not get details from > the routing folks over there. > > I don't quite see how and where the layer 2 topology comes into play here. > Netcom should simply be seeing routes (through the RS) that state your MW > IP address and the routes advertised from it. Is there some reason that your MW > IP would be unreachable by Netcom? I am confused as to why this would ever > happen in the MW scenario. Now the PB-NAP is a different story with the > non-fully meshed scenario. > > Please explain what you mean Matt. Sure. Netcom changed out an FDDI card. There is a bad ARP entry or bridge table entry somewhere, which causes packets transmitted by Netcom towards me to be black-holed. MFS is, as far as I know, _still_ investigating this. However we can see the route server as can Netcom. The route server states our MW IP address, and so they transmit packets towards us using that, and yet the underlying layer 2 fabric is discarding those before they get to us. Yes, IF EVERYTHING WAS WORKING PROPERLY it is fully meshed... but things don't always work properly. What I know is that when I stopped believing the route server's routes to Netcom, there was still a discontinuity, but when I stopped telling the route server my routes (and it then stopped telling Netcom), Netcom switched to sending my packets to our transit provider, and my Netcom connectivity came back. That required both manual intervention AND tearing down the whole session with the route server (I can't easily get the route server to stop telling Netcom about me while still telling everyone else about me without editing my policy and waiting for it to appear on the RS) -matthew kaufman matthew(a)scruz.net ps. At this point, we still can't see Netcom... problem has lasted for 1 day, 8 hours. From my interface (198.32.136.18) I cannot ping Netcom at 198.32.136.15, but I can ping Alternet at 198.32.136.42. That points to a layer 2 discontinuity.

1 0

Re: problem at mae-west tonight?
by Rob Liebschutz 15 Jul '96

15 Jul '96

On a regular basis, MAE West has failures that cause only some of the other routers to become unreachable. I believe all of the instances that I have heard of are related to problems with the Netedges which show up mostly under high load. I've heard various people call it the "Sleeping Interface" problem. It usually goes away when you reset the netedges, but under heavy load it can come back quickly. We have seen it extensively, when our 10mb connection became heavily loaded. Just yesterday, we upgraded to a DS3, so were hoping not to see it for a while. I know AGIS has also had this problem and I believe Best has seen it as well. Maybe you haven't seen it because you have a colocated router at MAE-WEST. Rob > We experienced the same thing with Netcom. Currently we are peered with over > 40 netwroks through the RS, but I have only had this problem with Netcom. > > Is it really a next-hop problem or a Netcom internal problem? Last time > this happened, about 2 weeks ago, they cleared their RA session and did > some other things and everything came up fine. I did not get details from > the routing folks over there. > > I don't quite see how and where the layer 2 topology comes into play here. > Netcom should simply be seeing routes (through the RS) that state your MW > IP address and the routes advertised from it. Is there some reason that your MW > IP would be unreachable by Netcom? I am confused as to why this would ever > happen in the MW scenario. Now the PB-NAP is a different story with the > non-fully meshed scenario. > > Please explain what you mean Matt. > > Rob > Exodus Communications Inc. > > > > > The problem I have with the route server this evening is that I announce > > > my routes to the route server, and my policy configuration in the route server > > > reflects that I peer with Netcom, and so the route server tells Netcom how > > > to reach me. Unfortunately, packets leaving Netcom headed to me at layer 2 > > > are going into a black hole. To fix this, I've had to dump my peering with > > > the route server entirely, so that Netcom is only seeing my routes from AGIS > > > (our transit provider) and not from the route server. Ugh. My fears about > > > the route server not knowing the status of the layer 2 topology have come true, > > > and there's no way to fix this that doesn't involve manual intervention. > > > > > > -matthew kaufman > > > matthew(a)scruz.net > > > > > > > > > > Well, I run gated on a BSDI box for the Hooked MAE West router. I'm > > thinking about implementing a "pingnouse INTERVAL" option on the > > peer/group commands in gated, so it will periodically ping next hops > > received from the route servers and set the nouse bit if the nexthop > > is unreachable. Any better ideas? > > > > It would be nice to come up with a good mechanism for doing 3rd party > > keepalives that cisco and other router vendors would be willing to > > implement. > > > > Rob > > > >

1 0

Re: Re: problem at mae-west tonight?
by eautheme＠BayNetworks.com 14 Jul '96

14 Jul '96

Rob, In the OSPF community,we faced this same issue a few years back -- the issue being that all members of a single subnet were not reachable either by design or by error and fooling the listeners of the Designated Router (like the route server) into thinking that the nexthops were really reachable. We felt the pains of this especially over virtual circuit networks (Frame Relay, SMDS, and ATM). Temporary workarounds were created. The two better solutions were: 1) Using recommendations in RFC1586,"Guidelines for Running OSPF Over Frame Relay Networks". 2) Using Point-MultiPoint (P-MP) OSPF which is in the latest Internet-Draft of the revision to the RFC1583 (V2 OSPF Spec.). I prefer the P-MP solution because it is an automatic mechanism requiring very little configuration on a network administrators part and keeps the number of routing hops to a minimum. I vote for P-MP as a "Standard" solution for BGP-4 over discontiguous networks. I believe this concept was proposed on this mailing list a few months back. Now that ATM VCs are being used at NAPs with route servers, you'll see more and more of these problems arising...especially at NAPs where there isn't much coordination and cooperation in building and maintaining these high speed, virtual connections. Eural Authement Bay Networks Professional Services ******** > The problem I have with the route server this evening is that I announce > my routes to the route server, and my policy configuration in the route server > reflects that I peer with Netcom, and so the route server tells Netcom how > to reach me. Unfortunately, packets leaving Netcom headed to me at layer 2 > are going into a black hole. To fix this, I've had to dump my peering with > the route server entirely, so that Netcom is only seeing my routes from AGIS > (our transit provider) and not from the route server. Ugh. My fears about > the route server not knowing the status of the layer 2 topology have come true, > and there's no way to fix this that doesn't involve manual intervention. > > -matthew kaufman > matthew(a)scruz.net > > Well, I run gated on a BSDI box for the Hooked MAE West router. I'm thinking about implementing a "pingnouse INTERVAL" option on the peer/group commands in gated, so it will periodically ping next hops received from the route servers and set the nouse bit if the nexthop is unreachable. Any better ideas? It would be nice to come up with a good mechanism for doing 3rd party keepalives that cisco and other router vendors would be willing to implement. Rob

1 0