- Test - lists.nanog.org

Re: SBC forcing new contract on ISPs
by Bruce Robertson 25 Jun '01

25 Jun '01

> Then mention to them that they must provide you with Reciprocal > Compensation. This probably does not apply, because it isn't actually SBC - it's ASI, which is a wholly owned subsidiary of SBC. ASI is not a telco; it's actually a CLEC. It has its own contracts with the ILEC (Nevada Bell in our case) to access copper. It is not subject to things like Reciprocal Compensation, which we wouldn't qualify for anyway, as an ISP (we are not a CLEC). -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 For PGP key: finger bruce(a)greatbasin.net

1 0

Re:Eliminate Dependency on Telefonica in Brazil?
by rkuhljr＠uol.com.br 25 Jun '01

25 Jun '01

>Company X comes to believe that one of the best things it could do to >achieve reliability >on its circuits in Brazil is to reduce or eliminate its dependency on >Telefonica >for "last mile" support/provisioning. Telefonica circuits are usually very reliable if goes on fiber from end to end; copper-based circuits from them perform poorly. But even on fiber, restore intervals after circuit/equipment failures are not good. > Are there any options available to >such >a Company? If so, which might be best: microwave, satellite, cellular, etc? >Which vendors >might be investigated and considered for these services? Last mile: AT&T LA (www.netstream.com.br) (fiber) Metrored (www.metrored.com.br) (fiber) Diveo (www.diveo.net.br) (microwave radio) Embratel (www.embratel.net.br) (has some fiber/radios, uses the 3 above otherwise) Engeredes (www.engeredes.com.br) (fiber) Pegaus (www.pegasus.net.br) (fiber) > Any difference >between >VPN and point to point circuits? Not on a city or state scale... Telefonica is the incumbent carrier only on Sao Paulo state, in what cities/states do you need circuits ? > If you were goign to build a large scale >web presence >in Brazil...what's your top list of possible circuit providers? The one(s) the backbone(s) you get IP service from prefer. Getting a circuit from Telefonica to connect to Embratel IP backbone will probably give you a headache. >Reliability >is valued >over cost. I guess to put the query in nanog mailing list terms.....who >could I go >with to ensure I'm a good BGP neighbor in Brazil? On IP transit, you should try getting good connection to Embratel (AS 4230), directly from them or from someone who has. Although every other AS in Brazil is trying to change this, current scenario is they have 80% of brazilian web traffic; prices are high, they are a Worldcom company, probably the same song as in US. Also connecting to a peering point bypasses them (and some congested circuits) for going to a number of autonomous systems, so give a look at www.ansp.br/ptt. >I know some may find the above humorous since if you insert Verizon, Not yet represented here. >BellSouth, Owns cellular company(BCP), doesn't provide circuits (although they own a microwave radio network with very good coverage) >etc in place of Telefonica...the hypothetical may not change much. :-) >No offense to the Bells...when I pick up the phone 99.999% of the time >I have dial tone--which I appreciate. :-) But it costs $$$... Lucky you, more than Telefonica can say about their own voice lines. Rubens Kuhl Jr.

1 0

Operational Content, I think...
by Deepak Jain 25 Jun '01

25 Jun '01

This comes up every now and then, and I still haven't seen a good solution, so here is the situation. Every now and then, the graveyard maintenance shift (read: few people) needs to mount a 7' tall or 600 lb piece of equipment we've all come to know and love in a rack. While pad jacks are available to move them around the datacenter floor, equipped with friendly hydraulics and all, there is a piece missing. Is there a common-sense piece of equipment available that 1 person can operate that will support a very bulky, rackmountable piece of equipment so the same, single person can mount/unmount it near the top of a rack? I have seen plenty of solutions for this on warehouse floors, but most datacenters don't have the ceiling height for track-crane. I don't know how people handle the 15' relay racks either now that I am sharing my gap in knowledge. Your advice, suggestions and even jokes are appreciated, but remember, I'm armed. :) Deepak

6 6

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 25 Jun '01

25 Jun '01

Cross posting sucks. However, this is a special case as this discussion really ought to move to NANOG without losing context. Please edit headers to make sure replies go *only* to NANOG. On Tue, 19 Jun 2001 14:55:41 -0700 "Kenneth Porter" wrote: > >P.S. I will be out all day tomorrow testifying to the Public > >Utilities Commission staff and will not be able to respond to any > >further discussion for a few days. > > Testifying on this particular issue? I'd be interested in hearing what > comes of it. Once again it sounds like we're trading a little imagined > security for loss of freedom, and laying the expense on common > carriers. Testifying on an entirely unrelated docket. You make a very important point. I am a believer in strong privacy, and that privacy is constantly under attack. The defense of privacy requires constant vigilance. However, being able to identify which computer is sending traffic does not result in loss of privacy: 1) privacy should come from other, more secure, mechanisms such as encryption of data. 2) Current dial-up IP access provides an even greater ability to identify the user. regards, fletcher

1 0

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 25 Jun '01

25 Jun '01

Cross posting sucks. However, this is a special case as this discussion really ought to move to NANOG without losing context. Please edit headers to make sure replies go *only* to NANOG. On Tue, 19 Jun 2001 14:52:45 -0700 "Richard Barr Hibbs" wrote: > > -----Original Message----- > > *Snip!* > > > There are three reasons that one needs to be able to map an IP->MAC-> > > particular customer: 1) to provide customer support, 2) to provide > > network metrics and monitoring, 3) to provide identification in court > > cases. > > > > If one builds a network that does not provide these three abilities, > > the public will eventually step in -- via the legislature, the courts or > > the marketplace. > > > > If you can explain how you can provide quality customer support > > without a MAC map, provide network metrics and monitoring without a > > MAC map, and satisfy the courts without a MAC map, then I agree with > > you, there are valid different ways to provide this service. > > > > However, if you can't meet the three criteria, then the only valid > > design for a public network is one that can track > > is an invalid way to build a public network. It is wrong. > > > > *Snip!* > > Let me try to rephrase this a bit: to achieve the three goals that you > mention (customer support, network metrics and monitoring, and legal > identification of users) you assert that the way to do so is to have a > mapping between IP address and MAC address. I don't disagree that an > association between IP and MAC can be useful in achieving those goals, but I > do disagree that it is the only one. I think we are in violent agreement. I don't like the IP->MAC->Customer mapping, it is forgeable, but it is the only one I know we have available. I agree with you that it is not the only possible mapping. If you can point me to a better existing mechanism, I would be greatful. My complaint is with people who could collect and use this information, but then throw it away and claim ignorance when their network is used to as a springboard for attacking other systems. > Other perfectly valid associations include a non-volatile system serial > number of some sort, the "universal user identification" proposed by Intel, > or some algorithmic generation of an identifier based on physical system > characteristics in place of the MAC address. > > I've supported very large client populations and would suggest that it would > have been much more useful to have somehow been able to discern a client's > physical address (for example, 1201 Central Avenue, Room 346) than their MAC > address. MAC address is, of course, useful to distinguish among clients at > the same physical address, but then so would be additional information such > as "port 57, switch 3SW1201SNFC43." The DHCP client and IP stack that we > used did not provide us the luxury of that additional identification, > however. Sounds like a large company or organization network. Frankly, not germane to this discussion. If a database was kept of client MACs, and this information was required before access to service was made available, you then have a network of known devices and have made a long step towards towards assigning responsibility. > Any sort of identifier that helps distinguish among different hardware > classes (as the initial octets of a MAC address identify its manufacturer) > can be crucial in developing a repair history or predictor of failures for > stocking spare parts, but I don't quite see how knowledge of the MAC address > is required to monitor network usage or generate performance metrics that > are not tied to hardware type or specific device: IP address is much more > useful for that, in my opinion, especially if additional information about > physical connections (such as port and switch numbers) is available. Please remember we are talking about large IP over Ethernet *public* networks (cable, Etherloop DSL, wireless) which are used by a completely heterogeneous population. The operator must support the connection of arbitrary devices. Many of the customers have very little knowledge of their configuration or networking. The network operator must support arbitrary devices and clueless customers. Some scenarios: 1) When a customer calls and reports a connection problem, many times the problem will occur before an IP is assigned. The MAC address is the only mechanism for debugging these problems. 2) When a customer's device is misbehaving, by slamming a DHCP server with many uncompleted requests, by broadcasting traffic, or by being hijacked for a DDOS, the only current method of identifying the device is through the MAC address. 3) ARIN has sent the strong message that they expect IP over E public network providers to use dynamic IP allocation in order to conserve IPv4 addresses. Public networks are oversold and a fundamental financial/quality requirement is that the rate of oversell can be accurately tracked, or that customers be accurately charged for their bandwidth usage. In gathering these statistics, a MAC address is a key bit of glue allowing one to tie flows to customers. > Finally, I would not want to declare under oath that a MAC address > absolutely and uniquely identified a client host: it's just too easy to > spoof. Total and absolute agreement. There is no question that it is easy for a technical sophisticated customer to spoof a MAC address. This fact should always be kept in mind when analysing any information. However, there are a couple of possibilities for spoofing: 1) An existing, connected and valid MAC is spoofed. In that case, the spoofing becomes apparent pretty quickly; duplicate MACs make themselves known... 2) A non-existing, non-connected and non-valid MAC is spoofed. In that case, someone will have had to put them in the database in order to get service. One can then go to that person and ask why the spoofed > Having said all of this, I want to be sure you don't misunderstand: > supporting customers, whether there are two or 2 million of them, is > extremely important for any service business. Part of that support includes > administering servers and facilities so that all customers can enjoy the > services without interfering with other customers. So are we really in > disagreement? Mostly not. > I just don't know how to make the last part of the 3-way association > IP-->MAC-->client work reliably without significant changes in most > environments. Yes, it is difficult to add this functionality after the fact. However, the original discussion was prompted by a question about the design of a future network. As others have pointed out, if you start from the beginning, it is possible to design in the simple capture and maintenance of IP -> MAC -> customer data. To do otherwise is irresponsible. regards, fletcher

1 0

Eliminate Dependency on Telefonica in Brazil?
by Murphy, Brennan 25 Jun '01

25 Jun '01

Consider the following *hypothetical*: Company X comes to believe that one of the best things it could do to achieve reliability on its circuits in Brazil is to reduce or eliminate its dependency on Telefonica for "last mile" support/provisioning. Are there any options available to such a Company? If so, which might be best: microwave, satellite, cellular, etc? Which vendors might be investigated and considered for these services? Any difference between VPN and point to point circuits? If you were goign to build a large scale web presence in Brazil...what's your top list of possible circuit providers? Reliability is valued over cost. I guess to put the query in nanog mailing list terms.....who could I go with to ensure I'm a good BGP neighbor in Brazil? I know some may find the above humorous since if you insert Verizon, BellSouth, etc in place of Telefonica...the hypothetical may not change much. :-) No offense to the Bells...when I pick up the phone 99.999% of the time I have dial tone--which I appreciate. :-) But it costs $$$... Thanks!

2 1

Warning: AS14897 leaking routes
by nanog-poster＠axu.tm 25 Jun '01

25 Jun '01

Hello, It appears that AS14897 has decided to leak AS701's (UUnet) full routing table to AS2548 (DIGEX/Intermedia Communications) who are accepting it and announcing it on. -- Aleksi Suhonen / Axu TM Oy Internetworking Consulting Contact Info: AXU-RIPE

1 0

Re: Global BGP - 2001-06-23
by Sean Donelan 25 Jun '01

25 Jun '01

Yes, but I guess you'll have to wait for the official press announcement since everyone wants to keep what happened under NDAs. One way to sure-fire attract the attention of reporters is to claim something is a secret. Its like waving a red cape in front of a bull. Those that don't remember their history are doomed to repeat it. Anyone remember why NERC, NRIC and mandatory goverment reporting of outages in other industries came to be? On Sun, 24 June 2001, lucifer(a)lightbearer.com wrote: > Out of curiosity - did anyone see a duration of significanlt instability > in the global routing tables on Saturday afternoon? Without violating NDA, > all I can say is that it resembled a historic event involve a bad route, > Ciscos, and Bay routers (only this time, it was a bad route, Ciscos, and > <X> vendor whom I cannot name but is being soundly beaten with wet noodles > to resolve the issue). The bad route, and instability, were seen across > all of our transit vendors (all "household" names of transit service). > > Anyone else see this sort of event, or further details on the cause?

1 0

BGP announcements 'stuck' in route-reflector
by Pete Kruckenberg 25 Jun '01

25 Jun '01

I think this may be re-hash, apologies if so. Several people have told me Cisco IOS 'used' to have a well-known bug related to route-reflectors (clients), where they would ignore BGP withdraw messages and continue to announce routes (including full original AS path). I can duplicate this type of problem with one upstream provider (but not the other), I am trying to help them help me (as they seem to be somewhat at a stand-still resolving the problem). So far I've only gotten somewhat vague information, and haven't been able to find anything specific myself. Any pointers (Cisco bug ID, IOS releases with the problem and those that fixed it, etc) would be helpful. Thanks. Pete.

1 0

Re: Operational Content, I think...
by George William Herbert 25 Jun '01

25 Jun '01

There are plenty of things in the Grainger and similar catalogs. Get either the complete one, or the "Materials Handling" subset catalog. -george william herbert gherbert(a)retro.com

1 0