- NANOG - lists.nanog.org

South Florida IXes
by Daniel Corbe 06 Jul '04

06 Jul '04

Anyone know of or operate either a commercial or non-commercial IX in the Ft. Lauderdale area? If not I'm willing to drive to Miami or Boca Raton. Please contact me off-list.

2 1

RE: Quick circuit question.
by Michel Py 06 Jul '04

06 Jul '04

> Drew Weaver wrote: > is duplex a consideration with lines of these types? DS3s are full-duplex AFAIK. There are two coax cables (one in one out) and I don't ever remember seeing anything that looked like a collision detection mechanism. Compare to Ethernet: on 10base-2 or 10base-5, you have half-duplex as the physical medium (single coax) is the same for transmit and receive. Same on a 10base-T or 100base-T hub, where even if the TX and Rx pairs are separate they are mixed inside the hub. When connected to a switch, a NIC that either is configured to full-duplex or negociates full-duplex actually deactivates its built-in collision detection circuit. > We have 1 DS-3, that if we get close to 45Mbps IN/OUT the > other direction will be completely unusable. The condition you describe is rather common: your upstream is maxed out and your downstream becomes very slow. This has nothing to do with duplex: your downstream sits unused. The perceived slowness is likely due to DNS requests, TCP SYNs and the like being slowed or discarded in the egress queue. If you traffic-shape your egress (by tweaking queuing, among other things) you could get close to 45Mpbs in and out. Usual tricks include granting small packets a higher priority, and lowering the priority of packets that max out your pipe. Things such as wRED and dCAR are to be looked at too. Michel.

1 0

Re: Peering point speed publicly available?
by Stewart, William C (Bill), RTSLS 06 Jul '04

06 Jul '04

On or about July 1 2004, Erik <allegedly at> myevilempire.net> Amundson allegedly asked about peering point bandwidth. Some North American ISPs will tell you that under non-disclosure, but almost all of them will point you to their standards for peering, and you won't find many Tier 1 ISPs that peer at less than DS3 in the US, and probably not many in Canada, London, Amsterdam, Tokyo, or Singapore either. That means the insertion delay is under 0.27ms, or about 27 fiber-miles, so it's less important than whether the peering is in San Francisco or San Jose. Queuing due to overload is really much more important than absolute size. Also, if you're dealing with ISPs that use public peering points, those may be a performance concern, but in the US that's mostly not Tier1-Tier1. (Linx is a different case entirely, assuming you want your traffic to be in London.) Smaller ISPs might be more talkative, or if you're having actual problems, like why your connection from minneapolis.example1.net to stpaul.example2.net goes through a peering point in San Francisco instead of peering in Minnesota or at most Chicago, big ISPs can also be pretty talkative.

13 25

Re: concern over public peering points [WAS: Peering point speed publicly available?]
by Paul Vixie 06 Jul '04

06 Jul '04

> > i've been told that if i ran a tier-1 i would lose my love for the > > vni/pni approach, which i think scales quite nicely even when it > > involves an ethernet cable through the occasional ceiling. perhaps > > i'll eat these words when and if that promotion comes through. > > meanwhile, disintermediation is still my favorite word in the > > internet dictionary. i like it when one's competitors > > As we have seen before in previous lives, and I'm pretty sure stephen > stuart will step in, normalizing "throw the ethernet over the wall" > school of design just leads to an incredible amount of pain when trying > to operate, run and actually document what you've got. that only happens if you grow, though. in other words it's a nice problem to have. i guess i'll defer to the people who have started from scratch and gotten all the way up to having the problem you describe. i met a lot of them though my PAIX experience. you should defer to them on this point also. > I thought it was illustrative to take a look at some of the other > messages in this thread. People rushing in to argue the scale comment > when the actual heart of the matter was something else entirely, > which apparently only Tony managed to get. i understood and agreed with tony's point. and during my mfn experience i was quite supportive of normalization, and was quite damning in my curses of what had been doing done in the early/growth period "before my time." but that doesn't mean that the occasional ethernet cable over the ceiling isn't the right business decision for people who have done what many here have not done, which is to say, started from scratch. > In any case, I am going to pull a randy here and strongly encourage my > competitors to deploy this "ethernet over ceiling tile" engineering > methodology. i would think that was puerile and shallow no matter who actually said it.

1 0

Re: concern over public peering points [WAS: Peering point speed publicly available?]
by Hannigan, Martin 06 Jul '04

06 Jul '04

Kind of summarizes why we are still heavy on the "best effort" side of the equation. -M Regards, -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 http://www.verisign.com/ -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: Paul Vixie <vixie(a)vix.com> CC: nanog(a)merit.edu <nanog(a)merit.edu> Sent: Mon Jul 05 21:32:14 2004 Subject: Re: concern over public peering points [WAS: Peering point speed publicly available?] On Tue, Jul 06, 2004 at 01:43:14AM +0000, Paul Vixie wrote: > > vgill(a)vijaygill.com (vijay gill) writes: > > Throwing ethernet cables over the ceiling does not scale. > > i think it's important to distinguish between "things aol and uunet don't > think are good for aol and uunet" and "things that aren't good for anybody." > > what i found through my PAIX experience is that the second tier is really > quite deep and broad, and that the first tier doesn't ignore them like their > spokesmodels claim they do. Paul, I think you took a left at the pass and went down the wrong road here. I am not saying ethernet doesn't scale or even vni/pni doesn't scale, but the mentality embodied in the approach "throw it over the wall" doesn't bode well if you are to scale. > not agree is free to behave that way. but it's not useful to try to dissuade > cooperating adults from peering any way they want to. > > i've been told that if i ran a tier-1 i would lose my love for the vni/pni > approach, which i think scales quite nicely even when it involves an ethernet > cable through the occasional ceiling. perhaps i'll eat these words when and > if that promotion comes through. meanwhile, disintermediation is still my > favorite word in the internet dictionary. i like it when one's competitors As we have seen before in previous lives, and I'm pretty sure stephen stuart will step in, normalizing "throw the ethernet over the wall" school of design just leads to an incredible amount of pain when trying to operate, run and actually document what you've got. I thought it was illustrative to take a look at some of the other messages in this thread. People rushing in to argue the scale comment when the actual heart of the matter was something else entirely, which apparently only Tony managed to get. In any case, I am going to pull a randy here and strongly encourage my competitors to deploy this "ethernet over ceiling tile" engineering methodology. /vijay

1 0

Announcing a /19 from a /16
by Eric Pylko 05 Jul '04

05 Jul '04

Hi- I'm working on a project within a large corporation and asked their network folks about getting a /19 from one of their /16s. I wanted it to avoid NAT and any possible overlapping from using RFC1918 addresses. This project gets connected to the internet at different times throughout the year at different locations through different ISPs. I would announce the /19 for a short period of time, maybe a month or so. The response I got back was that this was impossible since ISPs require an announcement of the /16 the /19 would come from. I have done work with ISPs before (and have read the NANOG list for many years) but haven't heard of such a requirement nor can I find any standards that indicate the same thing. Does anyone have requirements of a /19 announcement requires the /16 to be there as well? The company has plenty of /16s that it uses internally that are not being announced on the Internet at all. Thanks- -Eric

3 2

RE: Announcing a /19 from a /16
by Michael Hallgren 05 Jul '04

05 Jul '04

> > > > Hi- > > > > I'm working on a project within a large corporation and asked > > their network folks about getting a /19 from one of their > > /16s. I wanted it to avoid NAT and any possible overlapping > > from using RFC1918 addresses. This project gets connected to > > the internet at different times throughout the year at > > different locations through different ISPs. I would announce > > the /19 for a short period of time, maybe a month or so. > > > > The response I got back was that this was impossible since > > ISPs require an announcement of the /16 the /19 would come > > from. > > Maybe one of the (fairly rare, from what I see) actors that > ingress filter > (or takes into account those small few that does) by strict > allocation border >? (What > prefixes are yopu talking about?) > > mh > ;) mh > > > I have done work with ISPs before (and have read the > > NANOG list for many years) but haven't heard of such a > > requirement nor can I find any standards that indicate the > same thing. > > > > Does anyone have requirements of a /19 announcement requires > > the /16 to be there as well? The company has plenty of /16s > > that it uses internally that are not being announced on the > > Internet at all. > > > > Thanks- > > > > -Eric > > > > > > >

1 0

Re: Sipura VoIP phone adapters and DoS against name servers
by sthaug＠nethelp.no 05 Jul '04

05 Jul '04

> I guess the real question is why was the local VoIP provider giving the > phones your DNS IP? Should they have been using their own DNS server? As to why, we don't know. They *will* be using their own DNS servers soon, however :-) Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Sipura VoIP phone adapters and DoS against name servers
by sthaug＠nethelp.no 05 Jul '04

05 Jul '04

> Get in contact with manufacturing vender for a fix, > and then tell us what they did or what they intend > to do to remedy the problem. We have already suggested this to the local VoIP provider. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Sipura VoIP phone adapters and DoS against name servers
by sthaug＠nethelp.no 05 Jul '04

05 Jul '04

Last night we configured our equipment to reject recursive DNS lookups from non-customers. This morning, soon after normal office hours began, we started receiving around 2500 DNS lookups per second more than normal to our recursive name servers. After analyzing the DNS lookups, we found that all of the extra traffic was generated from customers of a local VoIP provider which uses Sipura (SPA-2000) phone adapters. It seems that when these adapters don't receive answers to their DNS queries, they will retransmit the query once per second (until they receive an answer). Multiply by number of adapters, and you have the recipe for a nice DoS. Shades of Netgear NTP DoS (http://www.cs.wisc.edu/~plonka/netgear-sntp/) - don't vendors ever learn? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

3 2