Wed Feb 4 14:04:55 PST 1998 — Pacific Bell has pretty much completed the transition to the new switch protocol, and we no longer have problems with calls from caller-ID blocked users being refused with a fast busy signal. This project took a week to push through PacBell’s monolithic paper pushing organism, and we’re not very pleased about the handling of the whole situation. The good news is that users no longer need to dial ‘*82,’ to get through to the affected equipment! This should mean less of these false fast busy signals (actually a reorder tone), and that’s great! We’re tracking a number of other issues in our dialup group, and we’ll keep you posted here as we find solutions. -Dane

Tue Feb 3 18:34:07 PST 1998 — We’ve ordered four more PRI circuits which will be installed on February 26th. These circuits add 92 ports to our current capacity of about 790 total ports. They will be served by another new USR Total Control Enterprise Hub, offering v.34+, X2 and ISDN. -Dane

Tue Feb 3 18:31:27 PST 1998 — We’ll be working on our X2 equipment on Wednesday morning between midnight at 6am. This should (finally) fix the problems with fast busy signals (aka reorder tone) with users who have caller ID blocking enabled. PacBell has been working for over a week on getting the paperwork together to get this order completed, and it’s been quite a hassle. This equipment also serves analog callers who call any of our Sonoma county dialups during busy times. -Dane

Sun Feb 1 23:13:26 PST 1998 — MAE West Gigaswitch failure At around 9am this morning, MFS Datanet performed some maintenance on a Gigaswitch at their Metro Area Exchange (MAE) West facility in Silicon Valley. The switch failed. MFS is still troubleshooting the problem. They have flown in one of the original designers of MAE West; if reports are correct, he arrived at the facility about 20 minutes ago.

While other exchange points can handle Sunday traffic just fine, the North American chunk of the Internet will begin weekday traffic loads in just a few hours. If MFS can’t get the Gigaswitch back up by then, there could be a noticeable impact on bandwidth in the US. -Scott

Thu Jan 29 12:51:42 PST 1998 — Access has been restored in the South Bay, and all’s well. The OC48 circuit to MFS is back online. -Dane

Thu Jan 29 12:27:50 PST 1998 — There was a small fire in our South Bay facility, and access is currently offline. All bay area numbers are unavailable. At approximately 11:00 this morning, a monitoring box installed by MFS for their OC48 equipment ignited. MFS is on site, and is working with Above.net, Brooks and TCG to restore full access. -Dane

Thu Jan 29 17:55:39 PST 1998 — We’re still having problems with Pacific Bell’s provisioning and USR’s implimentation of the DMS ISDN switch protocol, and we haven’t made much progress with it today. Pacific Bell has promised that they will make more headway tommorow, and we’re hoping to reprovision at least some of our lines on Saturday morning at 2am. Meanwhile, we have completed deployment of quite a bit of new equipment, and we do have available capacity. If you experience any problems getting connected (busy signals, reorder tones, etc), please try calling 522-1003 if it’s local to you. If you have any feedback or comments, please post in the sonic.help newsgroup. -Dane

Wed Jan 28 18:30:47 PST 1998 — We’ve isolated the problem with false busy signals as a bug in the implimentation of the DMS 100 custom switch protocol in USR’s MP16I equipment. We’ve asked PacBell to reprovision all of the lines which are affected (104 BRI lines, 208 ports) to the National ISDN 2 switch protocol, and they are coordinating and scheduling this now. If you are hearing a fast busy, also known as a reorder tone, you can avoid this problem by dialing ‘*82,’ before the access number you are calling. This problem affects customers in almost all of our v.32 and X2 points of presense, including customers calling 522-1001. If you suspect that you may be affected by this, use a regular telephone on the phone line which you use for your modem and dial 522-1002, the line which serves X2, plus overflow for v.34 callers. If you hear the fast busy, add ‘*82,’ to your dial string. We’re hoping that PacBell can coordinate the reprovisioning of these lines for tommorow morning (Thursday AM) between 2AM and 6AM. During this time, 522-1002 will be unavailable, as we’ll be reprogramming all of the modems with the new switch protocol and new SPID numbers. We will probably also take advantage of this opportunity to flash upgrade the X2 gear to the latest firmware, as we’re running 2.1.5 and 2.2.2 was recently released.

Tue Jan 27 17:32:39 PST 1998 — We’ve got partial deployment of our new ISDN PRI access server, nas21, a USR/3Com Total Control Enterprise Network Hub. This unit now serves overflow for analog and X2 callers in Sonoma County, plus dual-B ISDN callers. We’re continuing to have problems with real and false busy signals. The real busy signals should be gone with the partial deployment (46 ports) of the new nas21, and we’ll be finishing deployment (92 ports total) of that hardware tommorow. The false busy signals are due to problems with caller ID blocking. If you are experiencing busy signals, add ‘*82,’ before the access number you are calling. We’re working with Pacific Bell and USR to address this issue. -Dane

Sun Jan 25 10:49:24 PST 1998 — Our dedicated T1 circuit to MCI was offline today from about 1AM until 10:30AM because of what appear to be Pacific Bell line problems or MCI backhaul problems. Because of our investment in fully redundant intelligent routing, no customer services were affected. Our currently connectivity lineup includes an optical T3 circuit to UUNet in San Jose, and metallic T1 circuits to MCI in Sacramento and to Sprint in Stockton. All of these are handled by our huge Cisco 7000 series router. The Cisco decides which circuit is the shortest path to any given Internet destination, and all of these decisions are dynamic. Of course, if a circuit is offline, it’s not the shortest path, so all traffic is automaticly re-routed. Additional routes include T3 peering with DNAI, and T1 peering with NapaNet and a2i. -Dane