Re: OpenTransit (france telecom) depeers cogent
John van Oppen wrote: > All, > > > Here is an output of show ip bgp regexp _5511_ on my cogent facing router (ie > with a full cogent feed)...Most of the prefixes with best paths that are > not through cogent don't exist in my cogent route feed at all (even via a non > FT path). It looks like things are still a bit wonky. > > http://as23265.net/cogent.txt > > Thanks, > John van Oppen > PocketiNet Communications > AS23265 > > > -Ursprüngliche Nachricht- > Von: Patrick W. Gilmore [mailto:[EMAIL PROTECTED] > Gesendet: Sunday, April 17, 2005 10:26 PM > An: nanog@merit.edu > Cc: Patrick W. Gilmore > Betreff: Re: OpenTransit (france telecom) depeers cogent > > > > On Apr 17, 2005, at 11:16 PM, Patrick W. Gilmore wrote: > > >>On Apr 17, 2005, at 10:49 PM, John van Oppen wrote: >> >> >> >>>As a cogent customer, I still see no routes to 217.167.0.0/16 (the >>>route that holds www.francetelecom.com) via my cogent feed. >>> >>>That /16 also appears to be unreachable from the looking glass on >>>cogent's website still. >>> >> >>I can trace from Cogent to FT just fine. >> >>Haven't checked all possible end points, but my spot check shows >>connectivity. > > > Replying to my own post, I still see some Cogent <-> FT strangeness. > > Tracing to www.opentransit.net works fine, but www.fracetelecom.com > dies on the first hop. > > Spot checking other IPs in FT, they seem to work. Is it just the > 'fracetelecom.com' sub-network that is still not connected? > > Anyone have any more info? > I am seeing wonkiness too. I have a default-free router peering exclusively with AS174 that's not seeing routes for hosts in rain.fr and francetelecom.com, and traces to those hosts die two hops into AS174. The same hosts are reachable via level3 and their traces go through on our routers that have multiple peerings. Note that the authoritative nameservers for francetelecom.com are in rain.fr and are not reachable via an exclusive cogent path. Hence, I am not able to even get DNS resolution on the cogent-only path. michael
Re: Memory leak cause of Comcast DNS problems
Hi, On Apr 17, 2005, at 8:20 PM, Eric A. Hall wrote: | The maximum amount of memory to use for the server's cache, in | bytes. [...] The default is unlimited, meaning that records are | purged from the cache only when their TTLs expire. That was my first guess too. Most DNS servers don't even have this switch. Actually, I suspect most servers now do, at least in the context of Internet service provision. I believe BINDv9 + dnscache + CNS (don't know about maradns, powerdns, or posadis but I believe their relative percentage isn't significant) outnumber BINDv4 and BINDv8. Don't know if Microsoft DNS allows you to limit memory consumption, but I don't think it is used in an ISP context that frequently (although I might be wrong). Rgds, -drc
RE: OpenTransit (france telecom) depeers cogent
All, Here is an output of show ip bgp regexp _5511_ on my cogent facing router (ie with a full cogent feed)...Most of the prefixes with best paths that are not through cogent don't exist in my cogent route feed at all (even via a non FT path). It looks like things are still a bit wonky. http://as23265.net/cogent.txt Thanks, John van Oppen PocketiNet Communications AS23265 -Ursprüngliche Nachricht- Von: Patrick W. Gilmore [mailto:[EMAIL PROTECTED] Gesendet: Sunday, April 17, 2005 10:26 PM An: nanog@merit.edu Cc: Patrick W. Gilmore Betreff: Re: OpenTransit (france telecom) depeers cogent On Apr 17, 2005, at 11:16 PM, Patrick W. Gilmore wrote: > On Apr 17, 2005, at 10:49 PM, John van Oppen wrote: > > >> As a cogent customer, I still see no routes to 217.167.0.0/16 (the >> route that holds www.francetelecom.com) via my cogent feed. >> >> That /16 also appears to be unreachable from the looking glass on >> cogent's website still. >> > > I can trace from Cogent to FT just fine. > > Haven't checked all possible end points, but my spot check shows > connectivity. Replying to my own post, I still see some Cogent <-> FT strangeness. Tracing to www.opentransit.net works fine, but www.fracetelecom.com dies on the first hop. Spot checking other IPs in FT, they seem to work. Is it just the 'fracetelecom.com' sub-network that is still not connected? Anyone have any more info? -- TTFN, patrick
Re: OpenTransit (france telecom) depeers cogent
On Apr 17, 2005, at 11:16 PM, Patrick W. Gilmore wrote: On Apr 17, 2005, at 10:49 PM, John van Oppen wrote: As a cogent customer, I still see no routes to 217.167.0.0/16 (the route that holds www.francetelecom.com) via my cogent feed. That /16 also appears to be unreachable from the looking glass on cogent's website still. I can trace from Cogent to FT just fine. Haven't checked all possible end points, but my spot check shows connectivity. Replying to my own post, I still see some Cogent <-> FT strangeness. Tracing to www.opentransit.net works fine, but www.fracetelecom.com dies on the first hop. Spot checking other IPs in FT, they seem to work. Is it just the 'fracetelecom.com' sub-network that is still not connected? Anyone have any more info? -- TTFN, patrick
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
On Sun, 17 Apr 2005, Randy Bush wrote: Do you have any idea what sort of underprovisioning is typical for this sort of service in Japan ? Do they really have anything like a symmetric 100 Mbps all the way back to the backbone ? yep Do you have any reference for this? Provisioning 10G distribution links for every 100 customers doesn't seem a viable business model considering the cost of equipment today. Where is the aggregation done and at what traffic level? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005, Randy Bush wrote: > celebrate diversity (aka i wish all my competitors did that:-) What did people think would happen if they try to hold third-parties liable for the actions of others? Third-parties have very little interest in defending your diversity. And if the FCC starts extending multi-million dollar fines from television to cable and Internet, you'll find very few providers you can migrate quickly, or otherwise, too. Look at the US Federal EnergyStar program. It is nearly impossible to buy a PC which doesn't comply with EnergyStar requirements, and even Microsoft was forced to change Windows default settings to comply. If there was a SecurityStar logo, would PC makers and providers have to comply with it?
Re: Memory leak cause of Comcast DNS problems
On 4/16/2005 10:03 PM, Sean Donelan wrote: > Should other ISPs be concerned they might have the same latent problem > in their systems? "ps v -C " will tell you how badly you're hurting Anybody that does a bunch of lookups -- whether this is forward lookups for customers or blacklist lookups on mail or whatever -- is probably using more than they think. I don't know of many directly related crash scenarios but there are other penalties like shallow caching which aren't entirely trivial. The churning strategy employed is the question that doesn't get answered. Some servers do FIFO, some do random discards, some use swap space... This whole area is treated like the embarrassing aunt in the cellar. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Memory leak cause of Comcast DNS problems
On 4/17/2005 12:29 PM, Florian Weimer wrote: > * Sean Donelan: > >>Perhaps your DNS software also has a memory leak? Anyone know which >>software Comcast was using? Should other ISPs be concerned they might >>have the same latent problem in their systems? > > Probably yes, especially if they don't read documentation of their DNS > software. > > | The maximum amount of memory to use for the server's cache, in > | bytes. [...] The default is unlimited, meaning that records are > | purged from the cache only when their TTLs expire. That was my first guess too. Most DNS servers don't even have this switch. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: OpenTransit (france telecom) depeers cogent
On Apr 17, 2005, at 10:49 PM, John van Oppen wrote: As a cogent customer, I still see no routes to 217.167.0.0/16 (the route that holds www.francetelecom.com) via my cogent feed. That /16 also appears to be unreachable from the looking glass on cogent's website still. I can trace from Cogent to FT just fine. Haven't checked all possible end points, but my spot check shows connectivity. -- TTFN, patrick -Ursprüngliche Nachricht- Von: Jonas Frey [mailto:[EMAIL PROTECTED] Gesendet: Sunday, April 17, 2005 7:36 PM An: [EMAIL PROTECTED] Betreff: Re: OpenTransit (france telecom) depeers cogent Cogent is now reachable from OT and vice versa, apparently Cogent dropped the filters, i see everything passing verio now. Not sure since when this works again. Regards, Jonas
RE: OpenTransit (france telecom) depeers cogent
As a cogent customer, I still see no routes to 217.167.0.0/16 (the route that holds www.francetelecom.com) via my cogent feed. That /16 also appears to be unreachable from the looking glass on cogent's website still. John van Oppen PocketiNet Communications AS23265 -Ursprüngliche Nachricht- Von: Jonas Frey [mailto:[EMAIL PROTECTED] Gesendet: Sunday, April 17, 2005 7:36 PM An: [EMAIL PROTECTED] Betreff: Re: OpenTransit (france telecom) depeers cogent Cogent is now reachable from OT and vice versa, apparently Cogent dropped the filters, i see everything passing verio now. Not sure since when this works again. Regards, Jonas
Re: Topics for NANOG 34
On Sun, Apr 17, 2005 at 10:20:24AM -0700, william(at)elan.net wrote: > > This is not parallel track sessions yet, right? At the moment, we have neither enough meeting space or content for real parallel track sessions this time. We might do something like split off the peering topics and BOF (for example) into a separate semi-track if we can find a logical way to do it, but we won't know until closer to the meeting. Steve
Re: BCP for ISP to block worms at PEs and NAS
> interesting... everytime we have filtered in the core we've gotten > complaints, I believe many folks filtered/rate-limited in their cores for > welchia/nachia and got bunches of complaints about it as well... Hrm, > maybe all of these folks are just grumpy-geeks? i suspect that the remaining small dial-up and other local consumer providers have customer bases who just want their mtv. larger isps and big backbone isps have customer bases with wider usage patterns, and hence become quite unhappy when all they can get is mtv and 500 channels of home shopping. and the customers of the former who don't like partial service, have enough clue to quickly migrate to the latter. celebrate diversity (aka i wish all my competitors did that:-) randy
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005, Randy Bush wrote: > >>> On my Cisco-based SP network with RPMs in MGX chassis acting as > >>> PEs: I have the ACL below applied on many network devices to > >>> block the common worms ports, > >> if you are a service provider, perhaps filtering in the core > >> will not be appreciated by some customers. of course, as a > >> provider, you can choose what 'service' you are providing. but, > >> if you filter ports, it is not clear you are providing internet > >> service. > > one approach might be radius installed filters? some contract > > language to allow 'customers' to request standard templated > > filters at little/no-extra cost to them. Allow them to make the > > decision to filter themselves (where 'themselves' may be a dial > > reseller, of course). Making them responsible means when > > odd-application-12 comes along to utilize tcp/135 you won't have > > to poke spot holes through your filters to permit this access. > > yep. but note that kim says "ACL below applied on many network > devices," and went on to mention ras, which i, possibly mistakenly, > took to mean not just the radius-able edge. whoops, I read his original note as: "i have a large dial/dsl plant for a network and I want to offer filtered Internet" So I lept to: "wow, use radius applied acls for your users, let them choose to have it or not, make standard templates available." If there is no need to filter 'all links' just 'customer links' (and 'customer links' == dial/dsl/radius-authed-connection-types) then the radius filters thing might be a boone to Kim's productivity.
Re: OpenTransit (france telecom) depeers cogent
Cogent is now reachable from OT and vice versa, apparently Cogent dropped the filters, i see everything passing verio now. Not sure since when this works again. Regards, Jonas
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005, J.D. Falk wrote: > > On 04/17/05, John Kristoff <[EMAIL PROTECTED]> wrote: > > > > deny tcp any any range 135 139 > > > deny udp any any range 135 netbios-ss > > > deny tcp any any eq 445 > > > deny udp any any eq 1026 > > > > Similar as before, you are going to be removing some legitimate > > traffic. > > Is this really true? All of the ports listed above are used by > LAN protocols that were never intended to communicate directly > across backbone networks -- that's why VPNs were invented. and people use them all the time across the real Internet :( It's dumb, we can argue about it's 'correctness' or 'localness' or whatever until we are blue in the face, but people still do it. > > Or, is your argument that some system somewhere MIGHT ignore the > offical port numbers allocated by IANA and try to pass some > other kind of traffic there instead? > Certainly, ssh over tcp/80 is common, other protocols can become agile as well... people SHOULD use the IANA port numbers, in practice they don't always abide by them :( > > Perhaps set the rules to permit and log first, let it run for awhile > > and then see what you'll be missing. > > Yep, this is always good advice. But don't give up just because > of some naysayers rolling out the usual FUD. In the real world, > security for the many outweighs the extremely unlikely edge cases > of the few. > Or... use a system where your users can 'subscribe' to a 'better Internet' (define 'better Internet' as you like)
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005, J.D. Falk wrote: > > On 04/17/05, Randy Bush <[EMAIL PROTECTED]> wrote: > > > > On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: > > > I have the ACL below applied on many network devices to block the > > > common worms ports, > > > > if you are a service provider, perhaps filtering in the core will > > not be appreciated by some customers. of course, as a provider, > > you can choose what 'service' you are providing. but, if you > > filter ports, it is not clear you are providing internet service. > > In practice, it is nearly certain that your users won't care (or > even notice) -- but grumpygeeks will argue about it anyway. interesting... everytime we have filtered in the core we've gotten complaints, I believe many folks filtered/rate-limited in their cores for welchia/nachia and got bunches of complaints about it as well... Hrm, maybe all of these folks are just grumpy-geeks?
Re: Memory leak cause of Comcast DNS problems
On Sun, 17 Apr 2005, Fergie (Paul Ferguson) wrote: > > > Not to my knowledge, or at least, none that has been > publicly acknowledged. > > >From a Washington Post article yesterday (posted via Yahoo! > News), Comcast said that the problem manifested itself when > they were in the process of upgrading their DNS servers: > > http://story.news.yahoo.com/news?tmpl=story&ncid=1212&e=3&u=/washpost/20050416/tc_washpost/a56223_2005apr15&sid=96168964 > > -- Florian Weimer <[EMAIL PROTECTED]> wrote: > > > Regardless of whether it actually _was_ a memory leak, > > or not, it appears that the impact was on a rather > > large enough scale. So, 'wide scale' because they, presuming of course the article is on the level, upgraded all devices at approximately the same time...
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005, Christopher L. Morrow wrote: > one approach might be radius installed filters? some contract language to > allow 'customers' to request standard templated filters at little/no-extra > cost to them. Allow them to make the decision to filter themselves (where > 'themselves' may be a dial reseller, of course). Making them responsible > means when odd-application-12 comes along to utilize tcp/135 you won't > have to poke spot holes through your filters to permit this access. Microsoft (the company that cares about security) has already done that for you by implementing RPC-over-HTTP complete with the same vulnerabilities as RPC-over-135. The sad thing is the number of computers using RPC/Netbios outnumbers the number of computers using SSH. Most former @Home cable providers have blocked various rpc/netbios (network neighborhood) ports for years because people used to be able to see their neighbor's computers in the Windows rpc/netbios browser. You probably want to be a bit careful, because some people use remote Exchange/Outlook which uses RPC. Ephemeral ports can be used by anything, although in practice they are not randomly distributed. Programmers are humans, and they tend to have favorites and those favorites are exploited by attackers. If we lived in a perfect world, everything would be perfect. But we live in a world were 300 million computers do stupid things and Microsoft sells over 10 million new Windows licenses a month. On the other hand, the number of people who actually want to use RPC over the Internet is a very small number. Is it more practical for the few people who want to use RPC over the Internet to make special arrangements; or to keep millions of computers at risk? A few other comments. Port 136 is not used by Microsoft. Port 5554 is probably too specific to a single worm, which is on the decline.
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005 13:00:30 -0700 "J.D. Falk" <[EMAIL PROTECTED]> wrote: > > > deny udp any any eq 1026 > > > > Similar as before, you are going to be removing some legitimate > > traffic. > > Is this really true? All of the ports listed above are used by > LAN protocols that were never intended to communicate directly > across backbone networks -- that's why VPNs were invented. I was speaking to the last UDP rule as shown above, but a port number is becoming increasingly more ambiguous as applications adapt when specific ports are filtered. There is also the idea of a 'port switching' process. Find an archived copy of draft-shepard-tcp-reassign-port-number for an example. Or even consider how TFTP works (port 69 is only in use for the initial packet to the TFTP server). Such a process actually has two 'good' properties, that are often add odds in many deployments. One is to foster transparency back into the network and the other is to improve resiliency from attackers attempting to insert spoofed packets into the communications. John
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
> Do you have any idea what sort of underprovisioning is typical for this > sort of service in Japan ? Do they really have anything like a symmetric > 100 Mbps all the way back to the backbone ? yep randy
Re: grrr
On Sun, Apr 17, 2005 at 03:15:04PM -0400, David Lesher wrote: > > As far as I can tell, eBay reads NO mail addresses. I am in a minor > issue re: a purchase, and while I send off responses to their > boilerplate "We are here to help you" messages; I merely get different > boilerplate messages back. I have dealt with some real people at Ebay, and I will say that they are one of the few organizations that actually DOES try to do something about phishing scams etc. My experience is that they do read, and take action based on, spoof reports. w
Re: ATT.net Security Contact
At 04:39 PM 17/04/2005, Joseph W. Breu wrote: Can someone from ATT.net security contact me offlist RE: our network in their RBL? Try [EMAIL PROTECTED] Humans do seem to read it. During the week they responded within a few hrs. However, when I asked why they blacklisted us in the first place, I never got an answer-- Only a few dozen auto ticket responses for some reason. Not sure if that was a hint that was lost on me, or something broken. ---Mike
Re: grrr
Indeed, it does appear that eBay is attempting to use Eliza to perform all of their customer service. Owen pgpoKiy1tfq5g.pgp Description: PGP signature
ATT.net Security Contact
Can someone from ATT.net security contact me offlist RE: our network in their RBL? -- Thanks, - Joseph W. Breu, CCNA phone : +1.319.268.5228 Senior Network Administratorfax : +1.319.266.8158 Cedar Falls Utilities cell : +1.319.493.1686 support: +1.319.268.5221 url : http://www.cfu.net
Re: BCP for ISP to block worms at PEs and NAS
In message <[EMAIL PROTECTED]>, "J.D. Falk" writes: > >On 04/17/05, John Kristoff <[EMAIL PROTECTED]> wrote: > >> > deny tcp any any range 135 139 >> > deny udp any any range 135 netbios-ss >> > deny tcp any any eq 445 >> > deny udp any any eq 1026 >> >> Similar as before, you are going to be removing some legitimate >> traffic. > > Is this really true? All of the ports listed above are used by > LAN protocols that were never intended to communicate directly > across backbone networks -- that's why VPNs were invented. > > Or, is your argument that some system somewhere MIGHT ignore the > offical port numbers allocated by IANA and try to pass some > other kind of traffic there instead? The issue is client-side port numbers -- those aren't rules that block only inbound SYNs. That was clear from another paragraph of Kristoff's post: Whatever worm you're trying to mitigate above (sasser?), you will also be occasionally be taking out TCP sessions that happen to be using that port. Most commonly where one side uses 5554 as it's ephemeral port. The result will be intermittent, undiagnosed failures. "Why isn't that Internet reliable? I do the same thing twice in a row and the second time it fails." --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BCP for ISP to block worms at PEs and NAS
On 04/17/05, John Kristoff <[EMAIL PROTECTED]> wrote: > > deny tcp any any range 135 139 > > deny udp any any range 135 netbios-ss > > deny tcp any any eq 445 > > deny udp any any eq 1026 > > Similar as before, you are going to be removing some legitimate > traffic. Is this really true? All of the ports listed above are used by LAN protocols that were never intended to communicate directly across backbone networks -- that's why VPNs were invented. Or, is your argument that some system somewhere MIGHT ignore the offical port numbers allocated by IANA and try to pass some other kind of traffic there instead? > Perhaps set the rules to permit and log first, let it run for awhile > and then see what you'll be missing. Yep, this is always good advice. But don't give up just because of some naysayers rolling out the usual FUD. In the real world, security for the many outweighs the extremely unlikely edge cases of the few. -- J.D. Falk As a carpenter bends the seat of a chariot <[EMAIL PROTECTED]>I bend this frenzy round my heart.
Re: Memory leak cause of Comcast DNS problems
Steve (and all),
>At least in my neighborhood, Comcast appears to be running BIND 9.2.4rc6
Ah... Then there are to possible paths...
1) There was a real memory-leak bug and this was an unfortunate operations
event. The CHANGES file for 9.3.1 and bind-9.2.5rc1 show various big fixes
related to memory leak issues. I leave it to someone else to comment on the
potential of being tickled within a Comcast environment.
-or- (And on a much more cynical note.)
2) Someone checked the latest CHANGES file for bind and realized that saying it
was a memory leak was a good cover (see quick pseudo-grep of file below. Note
that not all the bug's affect the running bind name server code).
Whichever it was, I wonder how it could affect so many name servers at only one
provider and all at the same time. This is just plain strange. I would have
thought that best practices for a DNS service would recommend staggered
upgrades, heck, even forced different s/w releases. etc. etc.
Martin
---
awk '
/^ --- 9\.2\.[0123][^ ]* released ---/ { print; exit; }
/^ --- [^ ]* released ---/ { print; next; }
/^[ ]*$/ { if (memory) { print all; } all = ""; memory = 0; next; }
/[mM]emory/ { memory = 1; }
{ all = all "\n" $0; next }
' < bind-9.3.1/CHANGES
---
--- 9.3.1 released ---
--- 9.3.1rc1 released ---
--- 9.3.1beta2 released ---
--- 9.3.1beta1 released ---
--- 9.3.0 released ---
--- 9.3.0rc4 released ---
--- 9.3.0rc3 released ---
--- 9.3.0rc2 released ---
1683. [bug] dig +sigchase could leak memory. [RT #11445]
--- 9.3.0rc1 released ---
1643. [bug] dns_db_closeversion() could leak memory / node
references. [RT #11163]
--- 9.3.0beta4 released ---
1635. [bug] Memory leak on error in query_addds().
--- 9.3.0beta3 released ---
1599. [bug] Fix memory leak on error path when checking named.conf.
--- 9.3.0beta2 released ---
--- 9.3.0beta1 released ---
1562. [bug] isc_socket_create() and isc_socket_accept() could
leak memory under error conditions. [RT #10230]
1561. [bug] It was possible to release the same name twice if
named ran out of memory. [RT #10197]
1547. [bug] Named wasted memory recording duplicate lame zone
entries. [RT #9341]
1545. [bug] It was possible to leak memory if named was unable to
bind to the specified transfer source and TSIG was
being used. [RT #10120]
1364. [func] Log file name when unable to open memory statistics
and dump database files. [RT# 3437]
1235. [func] Report 'out of memory' errors from openssl.
1143. [bug] When a trusted-keys statement was present and named
was built without crypto support, it would leak memory.
982. [func] If "memstatistics-file" is set in options the memory
statistics will be written to it.
--- 9.2.3rc1 released ---
Re: grrr
http://rfc-ignorant.org/tools/lookup.php?domain=ebay.com it's been three years, I don't think they really give a damn. matto On Sat, 16 Apr 2005, Scott Grayban wrote: If there are any eBay admin here please fix your spoof@ & abuse@ address because it is denying every spoof complaint sent to it. It constantly replies back "Your email has not been delivered" I dont understand why this company has to be so hard headed in abuse issues. [EMAIL PROTECTED]< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke This is the same company that runs Path MTU discovery on their web servers, and then blocks ICMP at their border. -Jerry
RE: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
On Sun, 17 Apr 2005, Malayter, Christopher wrote: I think you're very wrong here. For packet delivery of video based services, I could see a home using 100mb/s between voice, video, and data within the next 12-24 months. All of the product roadmaps I've been looking at contain "How to get 100mb/s to the home", "How do we push BRAS/Multicast deployment closer to the edge", "What is the roadmap for converged services past triple play?" Really? 100 megabit/s would be six simultanious HDTV feeds (mpeg2)... I don't see any other content that is constant high bandwidth? And in my calculations I used 5 meg as the average, meaning that your 100 meg would mean that peak bw usage should be much higher to compensate for anyone who just happens not to look at 6 TV channels at the time? The question is also about converged networks, what do we converge past data, video and voice? 100 meg to the home is no problem as long as each user is only using a few hundred kilobit/s (which seem to be the norm around the world right now on these networks), it's when each user is using much more than that we run into scalability problems (and monetary problems). -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: grrr
* David Lesher: > As far as I can tell, eBay reads NO mail addresses. I am in a > minor issue re: a purchase, and while I send off responses to > their boilerplate "We are here to help you" messages; I merely > get different boilerplate messages back. I don't think Ebay is in the conflict resolution business. You should contact your civial action provider if you need this kind of service.
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
On Sat, 16 Apr 2005 22:23:53 -1000 Randy Bush <[EMAIL PROTECTED]> wrote: > > > Let's say for the sake of argument that by 2010 we want to give every > > household 5 megabit/s on average. How could this be done with technology > > today seen on the radar? Remember that the households should want to pay > > for the bandwidth as well, meaning they might be willing to pay $30 per > > month for the bandwidth part (this is kind of high, but let's go with it). > > fwiw, 100mb to the home costs about that in japan > > randy > Hi Randy; Do you have any idea what sort of underprovisioning is typical for this sort of service in Japan ? Do they really have anything like a symmetric 100 Mbps all the way back to the backbone ? Regards Marshall Eubanks
Re: grrr
Speaking on Deep Background, the Press Secretary whispered: > > > http://rfc-ignorant.org/tools/lookup.php?domain=ebay.com > > it's been three years, I don't think they really give a damn. > > matto > > On Sat, 16 Apr 2005, Scott Grayban wrote: > > > If there are any eBay admin here please fix your spoof@ & abuse@ > address because it is denying every spoof complaint sent to it. > > It constantly replies back "Your email has not been delivered" As far as I can tell, eBay reads NO mail addresses. I am in a minor issue re: a purchase, and while I send off responses to their boilerplate "We are here to help you" messages; I merely get different boilerplate messages back. It's rather like the conversations in Brian Aldiss's "Who Can Replace a Man?" or that short story about the guy trying to order a copy of Robert Louis Stevenson's classic "Kidnapped"... -- A host is a host from coast to [EMAIL PROTECTED] & no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005 13:28:21 +0200 Kim Onnel <[EMAIL PROTECTED]> wrote: > I have the ACL below applied on many network devices to block the > common worms ports, Beware, you are guaranteed to be blocking other, legitimate things too with some of these rules. More below. > ip access-list extended worms > deny tcp any any eq 5554 Whatever worm you're trying to mitigate above (sasser?), you will also be occasionally be taking out TCP sessions that happen to be using that port. Most commonly where one side uses 5554 as it's ephemeral port. > deny tcp any any range 135 139 > deny udp any any range 135 netbios-ss > deny tcp any any eq 445 > deny udp any any eq 1026 Similar as before, you are going to be removing some legitimate traffic. With UDP ephemeral ports this may most likely be DNS and NTP traffic. Note, many people do what you do all the time to the detriment of both real security and robustness in my opinion, but it's your net and you can throw away random packets if you want to. Perhaps set the rules to permit and log first, let it run for awhile and then see what you'll be missing. John
Re: BCP for ISP to block worms at PEs and NAS
Even if they care, its consuming alot of CPU resources and bandwidth, i had a long quarrel with my teams members on should we do it or not, i understand that if we only provide best effort traffic without any filtering contracted its wrong to do it, but the ACL matches are so big, doing it on the Radius however is one nice other way to do it IMHO, there was once a worm using port 5000 which broke IPSec, and i had to modify it all over the place, same with MSSQL ports, a Centralised configuration is much better, i would like to see these methods documented anywhere (Practices for ISPs to block worms) On 4/17/05, J.D. Falk <[EMAIL PROTECTED]> wrote: > On 04/17/05, Randy Bush <[EMAIL PROTECTED]> wrote: > > > > On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: > > > I have the ACL below applied on many network devices to block the > > > common worms ports, > > > > if you are a service provider, perhaps filtering in the core will > > not be appreciated by some customers. of course, as a provider, > > you can choose what 'service' you are providing. but, if you > > filter ports, it is not clear you are providing internet service. > > In practice, it is nearly certain that your users won't care (or > even notice) -- but grumpygeeks will argue about it anyway. > > -- > J.D. Falk As a carpenter bends the seat of a chariot > <[EMAIL PROTECTED]>I bend this frenzy round my heart. >
Re: Anyone familiar with the SBC product lingo?
On Sun, 17 Apr 2005, Jay R. Ashworth wrote: So here's the 64GB/s question: If carriers are being paid to ensure physical separation between circuits for the life of the circuit, why is it that they haven't implemented change management systems (and I don't solely mean the software) to ensure they they *can* (not even that they will) manage to ensure such separation? Simple math. The cost of the occasional SLA credit and/or circuit regrooming when the customer discovers a non-diverse path where one was specified is obviously much less than the cost of tracking, maintaining ( and surely providing ) path diversity. Surely large providers have spent a lot more time and money developing processes and software that allow them to groom circuits into the least number of physical paths possible. Or at least I would, if I were paying for the facilities. matto [EMAIL PROTECTED]< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Re: Anyone familiar with the SBC product lingo?
On Fri, Apr 15, 2005 at 08:58:50AM -0400, David Lesher wrote: > He describes it as a long drawn-out exercise in futility. A > non-trivial employee has to spend eons on the task. It's a recursive > onion peeling, or a data version of Tom Lehrer's "I Got It From > Agnes"... > > And once done... the errors found, the diversity restored, and the > report signed off; it's soon worthless...because the carriers > soon shuffle things around Yet Again. So here's the 64GB/s question: If carriers are being paid to ensure physical separation between circuits for the life of the circuit, why is it that they haven't implemented change management systems (and I don't solely mean the software) to ensure they they *can* (not even that they will) manage to ensure such separation? A simple "don't move this circuit without investigation" flag that would drill-up to higher level flows would seem to be enough -- though certainly I am not familiar with the internals of the CMSen at such scale carriers. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: grrr
http://rfc-ignorant.org/tools/lookup.php?domain=ebay.com it's been three years, I don't think they really give a damn. matto On Sat, 16 Apr 2005, Scott Grayban wrote: If there are any eBay admin here please fix your spoof@ & abuse@ address because it is denying every spoof complaint sent to it. It constantly replies back "Your email has not been delivered" I dont understand why this company has to be so hard headed in abuse issues. [EMAIL PROTECTED]< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
RE: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
> -Original Message- > From: Mikael Abrahamsson [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 17, 2005 12:55 PM > To: Randy Bush > Cc: [EMAIL PROTECTED] > Subject: Re: cost of doing business (was:Re: OpenTransit > (france telecom) depeers cogent) > > > > On Sat, 16 Apr 2005, Randy Bush wrote: > > > fwiw, 100mb to the home costs about that in japan > > Well, I dont really see the average home actually using > 100meg all the > time in the near future, thus my 5 meg utilization average estimate. > Access could be whatever speed of course, access speed not > used doesn't > cost very much. I think you're very wrong here. For packet delivery of video based services, I could see a home using 100mb/s between voice, video, and data within the next 12-24 months. All of the product roadmaps I've been looking at contain "How to get 100mb/s to the home", "How do we push BRAS/Multicast deployment closer to the edge", "What is the roadmap for converged services past triple play?" Regards, Chris Malayter TDS Telecom - Network Services Data Network Engineering [EMAIL PROTECTED] Phone: (608) 664-4878 FAX:(608) 664-4644
Re: Memory leak cause of Comcast DNS problems
In message <[EMAIL PROTECTED]>, "Fergie (Paul Ferguson)" writes: > > >Not to my knowledge, or at least, none that has been >publicly acknowledged. > >>From a Washington Post article yesterday (posted via Yahoo! >News), Comcast said that the problem manifested itself when >they were in the process of upgrading their DNS servers: > >http://story.news.yahoo.com/news?tmpl=story&ncid=1212&e=3&u=/washpost/20050416 >/tc_washpost/a56223_2005apr15&sid=96168964 > At least in my neighborhood, Comcast appears to be running BIND 9.2.4rc6 --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
On Sat, 16 Apr 2005, Randy Bush wrote: fwiw, 100mb to the home costs about that in japan Well, I dont really see the average home actually using 100meg all the time in the near future, thus my 5 meg utilization average estimate. Access could be whatever speed of course, access speed not used doesn't cost very much. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: cost of doing business
>> Mikael Abrahamsson <[EMAIL PROTECTED]> wrote: >> Let's say for the sake of argument that by 2010 we want to give every >> household 5 megabit/s on average. How could this be done with technology >> today seen on the radar? Remember that the households should want to pay >> for the bandwidth as well, meaning they might be willing to pay $30 per >> month for the bandwidth part (this is kind of high, but let's go with it). > Randy Bush <[EMAIL PROTECTED]> wrote: > fwiw, 100mb to the home costs about that in japan We are talking of two different things here, traffic versus access bandwidth. It will be a while before the average household generates 5 megabit/s traffic. Even in Korea and Hong Kong, where the average broadband link is in the 5-10 Mbps range, average traffic is about 0.1 Mbps. The main purpose of high speed links is to get low transaction latency (as in "I want that Web page on my screen NOW," or "I want that song for transfer to my portable device NOW"), so utilizations are low. Andrew Odlyzko
RE: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
Hannigan, Martin writes: >As long as the hardware can keep up, the amount of glass in spectrum >in the ground should make this an impossibility for the near term, >10 years plus. Fiber isn't useful by itself; there are two obvious things needed to turn a piece of glass into something that can carry IP - transmission equipment and routers. While it'll be a while before carriers need to trench across the Rockies again, the day of needing to buy the equipment to plug into the fiber is already here for some providers.
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
Brandon Butterworth writes: >Perhaps they aim to keep driving the competition out of business >to ensure there's a cheap supply of equipment so they can grow >whilst charging so little? There are several problems with such a plan, even were someone to attempt it. One, overall traffic is still growing, so cannibalizing the already-constructed equipment owned by others after you drive them out of business only goes so far. (Note that low prices stimulate demand.) Two, requirements change - for example, filtering capabilites more or less acceptable years ago when certain linecards were released are no longer. And then there's the fact that the world is moving in the ethernet direction. Providers need to keep up, because their competitors will do so. Three, vendors won't support the current equipment forever, and once they don't, that will quickly end the usefulness of the equipment in question. Joe
Re: Topics for NANOG 34
This is not parallel track sessions yet, right? On Sun, 17 Apr 2005, Steve Feldman wrote: Greetings - here are the topics we've lined up so far for Seattle. Keep an eye out as we post additional talks: http://www.nanog.org/mtg-0505/topics.html Also, just a quick reminder that the registration fee goes up $50 on Monday, April 25, and our hotel room block rate expires on April 27. TUTORIALS - - Challenges in Network Security Protocols Level: Introductory Radia Perlman, Sun - Bridges, Routers, Switches, Oh My! Level: Introductory Radia Perlman, Sun - Best Practices for Determining the Traffic Matrix in IP Networks Level: Intermediate Thomas Telkamp, Cariden - BGP Techniques for Service Providers Level: Introductory/Intermediate Philip Smith, Cisco SUNDAY EVENING COMMUNITY MEETING --- - A follow-up to our meeting in Las Vegas (see http://www.nanog.org/mtg-0505/coordination.html). Please join us! GENERAL SESSION --- - DNS Anycast Stability Daniel Karrenberg, RIPE - Design Decisions and Architecture Analysis of a Global 10G Backbone (We Do it, so You Don't Have To) Vijay Gill, Time Warner - Securing Carrier VoIP: Session Border Control Hadriel Kaplan, Avici - Anatomy of a Leak: AS9121 (or, "How We Learned To Start Worrying and Hate Maximum Prefix Limits") Alin C. Popescu, Brian J. Premore, and Todd Underwood, Renesys - Building Nameserver Clusters with Free Software Joe Abley, ISC - Trust Reflection: A Distributed Approach to PGP Key Signing at Multi-Day Events Joe Abley, ISC - Anycast Measurements Used to Highlight Routing Instabilities Peter Boothe; Randy Bush, IIJ - Beyond 10 Gigabit Ethernet Neena Pemmaraju, Force10 - Internet Mini-Cores: Local Communications in the Internet's "Spur" Regions Steve Gibbard, PCH - The Spoofer Project: Inferring the Extent of Internet Source Address Filtering on the Internet Robert Beverly, MIT - Network-Wide Inter-Domain Routing Policies: Design and Realization Olaf Maennel, RIPE; Anja Feldmann and Christian Reiser, Technical University Munich; Ruediger Volk and Hagen Boehm, Deutsche Telekom BOFS - ISP Security and NSP-SEC BOF IX - Peering BOF IX William B. Norton, Equinix, moderator - INOC-DBA BoF with INOC-DBA Operators Gaurab Raj Upadhaya, PCH, moderator
Re: BCP for ISP to block worms at PEs and NAS
On 04/17/05, Randy Bush <[EMAIL PROTECTED]> wrote: > > On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: > > I have the ACL below applied on many network devices to block the > > common worms ports, > > if you are a service provider, perhaps filtering in the core will > not be appreciated by some customers. of course, as a provider, > you can choose what 'service' you are providing. but, if you > filter ports, it is not clear you are providing internet service. In practice, it is nearly certain that your users won't care (or even notice) -- but grumpygeeks will argue about it anyway. -- J.D. Falk As a carpenter bends the seat of a chariot <[EMAIL PROTECTED]>I bend this frenzy round my heart.
Re: Memory leak cause of Comcast DNS problems
Not to my knowledge, or at least, none that has been publicly acknowledged. >From a Washington Post article yesterday (posted via Yahoo! News), Comcast said that the problem manifested itself when they were in the process of upgrading their DNS servers: http://story.news.yahoo.com/news?tmpl=story&ncid=1212&e=3&u=/washpost/20050416/tc_washpost/a56223_2005apr15&sid=96168964 - ferg -- Florian Weimer <[EMAIL PROTECTED]> wrote: > Regardless of whether it actually _was_ a memory leak, > or not, it appears that the impact was on a rather > large enough scale. Have other service providers been affected, too? -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Memory leak cause of Comcast DNS problems
> Regardless of whether it actually _was_ a memory leak, > or not, it appears that the impact was on a rather > large enough scale. Have other service providers been affected, too?
Re: Memory leak cause of Comcast DNS problems
Regardless of whether it actually _was_ a memory leak, or not, it appears that the impact was on a rather large enough scale. - ferg -- Florian Weimer <[EMAIL PROTECTED]> wrote: | The maximum amount of memory to use for the server's cache, in | bytes. [...] The default is unlimited, meaning that records are | purged from the cache only when their TTLs expire. The number of complaints I've heard that "DNS resolvers eat *so* much memory" suggests that few people tweak the default configuration. 8-( However, it's unlikely that this was the cause of Comcast's problems because DNS cache overflows would have an impact on a much larger scale. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Memory leak cause of Comcast DNS problems
* Sean Donelan: > Perhaps your DNS software also has a memory leak? Anyone know which > software Comcast was using? Should other ISPs be concerned they might > have the same latent problem in their systems? Probably yes, especially if they don't read documentation of their DNS software. | The maximum amount of memory to use for the server's cache, in | bytes. [...] The default is unlimited, meaning that records are | purged from the cache only when their TTLs expire. The number of complaints I've heard that "DNS resolvers eat *so* much memory" suggests that few people tweak the default configuration. 8-( However, it's unlikely that this was the cause of Comcast's problems because DNS cache overflows would have an impact on a much larger scale.
Re: BCP for ISP to block worms at PEs and NAS
>>> On my Cisco-based SP network with RPMs in MGX chassis acting as >>> PEs: I have the ACL below applied on many network devices to >>> block the common worms ports, >> if you are a service provider, perhaps filtering in the core >> will not be appreciated by some customers. of course, as a >> provider, you can choose what 'service' you are providing. but, >> if you filter ports, it is not clear you are providing internet >> service. > one approach might be radius installed filters? some contract > language to allow 'customers' to request standard templated > filters at little/no-extra cost to them. Allow them to make the > decision to filter themselves (where 'themselves' may be a dial > reseller, of course). Making them responsible means when > odd-application-12 comes along to utilize tcp/135 you won't have > to poke spot holes through your filters to permit this access. yep. but note that kim says "ACL below applied on many network devices," and went on to mention ras, which i, possibly mistakenly, took to mean not just the radius-able edge. randy
Re: BCP for ISP to block worms at PEs and NAS
On Sun, 17 Apr 2005, Randy Bush wrote: > > > On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: > > I have the ACL below applied on many network devices to block the > > common worms ports, > > if you are a service provider, perhaps filtering in the core will > not be appreciated by some customers. of course, as a provider, > you can choose what 'service' you are providing. but, if you > filter ports, it is not clear you are providing internet service. one approach might be radius installed filters? some contract language to allow 'customers' to request standard templated filters at little/no-extra cost to them. Allow them to make the decision to filter themselves (where 'themselves' may be a dial reseller, of course). Making them responsible means when odd-application-12 comes along to utilize tcp/135 you won't have to poke spot holes through your filters to permit this access.
Re: BCP for ISP to block worms at PEs and NAS
> On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: > I have the ACL below applied on many network devices to block the > common worms ports, if you are a service provider, perhaps filtering in the core will not be appreciated by some customers. of course, as a provider, you can choose what 'service' you are providing. but, if you filter ports, it is not clear you are providing internet service. randy
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
> Let's say for the sake of argument that by 2010 we want to give every > household 5 megabit/s on average. How could this be done with technology > today seen on the radar? Remember that the households should want to pay > for the bandwidth as well, meaning they might be willing to pay $30 per > month for the bandwidth part (this is kind of high, but let's go with it). fwiw, 100mb to the home costs about that in japan randy
RE: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, April 16, 2005 1:58 PM > To: [EMAIL PROTECTED] > Subject: cost of doing business (was:Re: OpenTransit (france telecom) > depeers cogent) > > > > Mikael Abrahamsson writes: > >So what will people do? Stop selling when their networks are > full? Ignore > >the economics and let other business carry the cost of bulk > internet? Go > >for cheaper platforms? Go bankrupt (if no other business can > carry the > >cost) ? > > This problem will be fixed when the excess capacity built in the > latter years of the boom is gone. That's not to say that the > adjustment won't be painful - I'm sure a few more provider failures > are in the offing - but obviously if the marginal price for bandwith > doesn't pay for the capital costs of expansion, either eventually > bandwidth will be more expensive, or the equipment will be cheaper. As long as the hardware can keep up, the amount of glass in spectrum in the ground should make this an impossibility for the near term, 10 years plus. -M<
Re: BCP for ISP to block worms at PEs and NAS
On 4/17/05, Kim Onnel <[EMAIL PROTECTED]> wrote: > > Can someone confirm if my approach explained below is sufficient and > if there is other/better ways to do this ? something i am missing. > blocking netbios and 2..3 other ports is one way to go. however, what you need is fast detection and nullrouting / walled garden setup for infected machines on your LAN Joe St.Sauver's presentation at http://darkwing.uoregon.edu/~joe/zombies.pdf should help -- Suresh Ramasubramanian ([EMAIL PROTECTED])
BCP for ISP to block worms at PEs and NAS
Hello, Can someone confirm if my approach explained below is sufficient and if there is other/better ways to do this ? something i am missing. On my Cisco-based SP network with RPMs in MGX chassis acting as PEs: I have the ACL below applied on many network devices to block the common worms ports, On the NAS, i have placed the worm on the Group-Async interfaces so the worms will not propagate between user who dial up on the same NAS, and on the uplink ethernet interface.(in and out) On the PEs, i have placed it on the interface switches for the customers and on the uplink too, and then on the aggregating routers and on the gateway for all these. ip access-list extended worms deny tcp any any eq 5554 deny tcp any any range 135 139 deny udp any any range 135 netbios-ss deny tcp any any eq 445 deny udp any any eq 1026 permit ip any any Regards
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
On Sun, 17 Apr 2005, Mike Leber wrote: H, router and optical gear capabilities are growing faster than the market. Can you say "permanent state of affairs". Do you have any facts to back up this statement, as I am of another opinion. We're seeing doubling in traffic growth each year and the optics seem to quadruple every 3-4 years. Of course if equipment cost goes up the vendors will have more resources to make more expensive gear, but I believe the price per bit has to come down rather than the opposite. moores law > market growth Well, speaking of that, the performance increase in harddrives and CPUs seem to have degenerated over the past year and the hefty price per bit decrease in harddrive space we saw 1999-2003 seem to have stopped in 2004. A better (healthier? more sane?) metric is revenue per customer. Increase in usage is of course driven by the price of bandwidth going down. Let's say for the sake of argument that by 2010 we want to give every household 5 megabit/s on average. How could this be done with technology today seen on the radar? Remember that the households should want to pay for the bandwidth as well, meaning they might be willing to pay $30 per month for the bandwidth part (this is kind of high, but let's go with it). 5 megabit/s at $30 is $6 per meg, with no oversubscription. It also means that for a large city with a million households we need to shuffle around 1M*5M=5Tbit/s in that city alone. We probably need 10Tb national backbone to handle it, how do you do that with 40G or 100G links? That's a lot of parallell DWDM links :/ So the distributed p2p networks of the future will probably have to wait, and instead we'll do regular 1-many broadcasting via these networks and we'll be an interactive cable TV distribution instead. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: cost of doing business (was:Re: OpenTransit (france telecom) depeers cogent)
On Sat, 16 Apr 2005 [EMAIL PROTECTED] wrote: > Mikael Abrahamsson writes: > >So what will people do? Stop selling when their networks are full? Ignore > >the economics and let other business carry the cost of bulk internet? Go > >for cheaper platforms? Go bankrupt (if no other business can carry the > >cost) ? > > This problem will be fixed when the excess capacity built in the > latter years of the boom is gone. That's not to say that the > adjustment won't be painful - I'm sure a few more provider failures > are in the offing - but obviously if the marginal price for bandwith > doesn't pay for the capital costs of expansion, either eventually > bandwidth will be more expensive, or the equipment will be cheaper. H, router and optical gear capabilities are growing faster than the market. Can you say "permanent state of affairs". moores law > market growth A better (healthier? more sane?) metric is revenue per customer. Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Topics for NANOG 34
Greetings - here are the topics we've lined up so far for Seattle. Keep an eye out as we post additional talks: http://www.nanog.org/mtg-0505/topics.html Also, just a quick reminder that the registration fee goes up $50 on Monday, April 25, and our hotel room block rate expires on April 27. TUTORIALS - - Challenges in Network Security Protocols Level: Introductory Radia Perlman, Sun - Bridges, Routers, Switches, Oh My! Level: Introductory Radia Perlman, Sun - Best Practices for Determining the Traffic Matrix in IP Networks Level: Intermediate Thomas Telkamp, Cariden - BGP Techniques for Service Providers Level: Introductory/Intermediate Philip Smith, Cisco SUNDAY EVENING COMMUNITY MEETING --- - A follow-up to our meeting in Las Vegas (see http://www.nanog.org/mtg-0505/coordination.html). Please join us! GENERAL SESSION --- - DNS Anycast Stability Daniel Karrenberg, RIPE - Design Decisions and Architecture Analysis of a Global 10G Backbone (We Do it, so You Don't Have To) Vijay Gill, Time Warner - Securing Carrier VoIP: Session Border Control Hadriel Kaplan, Avici - Anatomy of a Leak: AS9121 (or, "How We Learned To Start Worrying and Hate Maximum Prefix Limits") Alin C. Popescu, Brian J. Premore, and Todd Underwood, Renesys - Building Nameserver Clusters with Free Software Joe Abley, ISC - Trust Reflection: A Distributed Approach to PGP Key Signing at Multi-Day Events Joe Abley, ISC - Anycast Measurements Used to Highlight Routing Instabilities Peter Boothe; Randy Bush, IIJ - Beyond 10 Gigabit Ethernet Neena Pemmaraju, Force10 - Internet Mini-Cores: Local Communications in the Internet's "Spur" Regions Steve Gibbard, PCH - The Spoofer Project: Inferring the Extent of Internet Source Address Filtering on the Internet Robert Beverly, MIT - Network-Wide Inter-Domain Routing Policies: Design and Realization Olaf Maennel, RIPE; Anja Feldmann and Christian Reiser, Technical University Munich; Ruediger Volk and Hagen Boehm, Deutsche Telekom BOFS - ISP Security and NSP-SEC BOF IX - Peering BOF IX William B. Norton, Equinix, moderator - INOC-DBA BoF with INOC-DBA Operators Gaurab Raj Upadhaya, PCH, moderator
