Re: Customer-facing ACLs
On 7 Mar 2008, at 23:57, Scott Weeks wrote: Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Oh, no, this one again. *** The Internet Is Not The Web. *** Could someone put that onto a t-shirt ? If it becomes normal for home users to only have 80 and 443, then how can I innovate and design something that needs a new protocol ? What happens to the new voice and video services for example ? On 11 Mar 2008, at 02:33, Christopher Morrow wrote: vpns fix this... They stop fixing stuff when they stop working. If you start running vpn services on tcp/80 (yuck, yuck, yuck), and naturally because it's the only port open lots of other non http protocol stuff does too, will filter-happy domestic providers start proxying the web instead of just filtering the rest of the traffic ..? Andy
Re: Transition Planning for IPv6 as mandated by the US Govt
On Tue, 18 Mar 2008, Nathan Ward wrote: I'm not selling anything. Code is freely available. When I've got some decent instructions for it I'll post links to NANOG if you like. To be fair, it's really nothing more than FreeBSD with a couple of patches, and Miredo packaged up in a nice-to-deal-with bundle, that means you can plug it in today and make it work with 2 or 3 lines of config, instead of spending the next 3 years engineering a solution that the various parts of the business agree with - that is, assuming they give their engineers time to even think about IPv6, let alone engineer for it. Key word: pragmatic. Perhaps you could integrate your work with a project like pfsense? From what I've seen, that's the best open source CPE solution, and doesn't yet have real IPv6 support (but has just about everything else). That would be a huge benefit to the community and potentially open up some business opportunities for you. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Customer-facing ACLs
On Tue, 11 Mar 2008, Ang Kah Yik wrote: Hi Justin (and all others on-list) I understand your grounds for blocking outbound SMTP for your customers (especially those on dynamic IP connections). It probably will do good to block infected customers that are spewing spam all over the world. However, considering the number of mobile workers out there who send email via their laptops to corporate SMTP servers, won't blocking outbound SMTP affect them? Since these corporate types (I'm guessing here) are probably unaware of how to change their email client's SMTP configurations, chances are that blocking outbound SMTP will probably cause quite a lot of pain. After all, there are also those who frequently move from place to place so they're going to have to keep changing SMTP servers every time they go to a new place that's on a different ISP. For what it's worth, that's what port 587 was created for. And wouldn't those corporate types require VPN to access the network? On top of that, most who block 25 don't block it but direct it to internal mail servers where it can be subjected to limits and filtering. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Customer-facing ACLs
On Fri, 7 Mar 2008, Dave Pooser wrote: Might as well do TCP 20, 21 and 23, too. Woah, that slope's getting slippery! Do bots try brute force attacks on Telnet and FTP? All I see at my firewall are SSH attacks and spam. But sure, if there's a lot of Telnet abuse block 23 too; I think it's used about as rarely by normal customers as SSH is. And I'm amazed how often slippery slope arguments are deployed to oppose any sort of change at all. What percentage of consumer broadband users do you think use SSH to connect to remote servers? 1%? 0.1%? 0.01%? It seems intuitively obvious that the number of people who will call the help desk to unblock their SSH (which should be a ~2 minute call anyway, if not a self-service Web page with captcha) would be an order of magnitude less than the number of remote network users who WON'T be calling/emailing your abuse desk to complain about bots on your network hammering their servers. Just straight up blocking outbound ports (with the debatable exception of port 25) seems heavy handed and too slanted toward admin convenience over customer satisfaction. It's a slippery slope because unlike with spam, people who are affected by brute force attacks have some degree of complicity through either negligance or laziness. Once you decide it's your job to protect other people's networks from their own stupidity, you may as well do full blown deep packet inspection and look for customers who are using your network to download kiddie porn...step by step you get closer to losing safe harbor, or at least having to pay a lawyer to convince otherwise. Perhaps a more thoughtful solution would work, but would take a bit of engineering. Ideally you would only block a certain class of brute-forceable ports once you cross some threshold amount of brief TCP sessions in a given period. I would suspect an extremely low false positive rate of blocking the ports of a user who has had, say 100 brief telnet, ssh, ftp, pop, or imap sessions in 5 minutes. Perhaps instead of filtering just those ports, you instead do a captive portal where they forced to a webapp which presents them with the logs of their issues and the suggestion they may be compromised, along with locally reachable resources to assist in correcting the issue. But just in case, if they feel it was an accidental situation (a perl script gone mad, say), they could merely click a button to open them right back up. However, three strikes and you're out until an admin reviews the case and considers the feedback (we run a cyber cafe, sometimes people come in with messed up laptops) and implements a whitelisting. Remember, YOUR customers are what matter. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Prefix filtering for Cisco SUP2
On Fri, 29 Feb 2008, Henry Futzenburger wrote: 2. Accept only default and RIR minimum routes from upstream. a. Filter based on RIR minimums, rely on default for unaggregated routes. b. Assume a reduction of about 50,000-100,000 total routes. Does anyone have any opinions as to whether one option is better than the other? Are there options that would be better than either of these? Are there serious risks to either option? My sense is that either of these would be a fairly benign change, only having a marginal impact on routing efficiency in either case. It seems like the better option is the one that retains the greater number of routes within some margin of safety. What do you think? I chose number 2. It works so well I'm starting to wonder why any network with less than, say, three or four transit providers would want to do anything else, even without system limits. My philosophy is rapidly becoming Let the settlement-free club worry about all the deaggregated prefixes. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Question on the topology of Internet Exchange Points
On 14 Feb 2008, at 17:02, Kai Chen wrote: A typical Internet Exchange Point (IXP) consists of one or more network switches, to which each of the participating ISPs connect. We call it the exchange-based topology. My question is if some current IXPs use directly-connected topology, in which ISPs just connect to each other by direct link, not through a network switch?? If so, what's the percentage of this directly-connected case? ISPs use a direct link (PNI) all the time to peer, and they don't need to be a member/customer of an internet exchange point to do so. In fact, the network you want to peer with might not be available at your local IXP even though they're in your local carrier hotel - then it becomes pretty much the only way to peer. In London, the LINX offer switched *and* unswitched connectivity between members - you can rent fibers from them in order to perform PNI with other members. That the exchange offer this is unusual, and it's offered as an additional service, in order to smooth the process of organising interconnection between member organisations. [www.linx.net ] We (LONAP) don't offer PNI services, and only offer the conventional switch ports, which members normally want so that they can get access to our peering lan and swap some traffic. [www.lonap.net] All exchanges offer this connectivity model. We offer private CUG and member-to-member private VLANs, which is similar, but still passes through the switch fabric. Best wishes Andy
Re: EU Official: IP Is Personal
On 25 Jan 2008, at 10:42, Roland Perry wrote: In article [EMAIL PROTECTED], Matt Palmer [EMAIL PROTECTED] writes Tunnels all over the place seems like the only way it'd even be halfway practical. It's more-or-less how phone number portability works anyway, from what (little) I know. I don't know about the USA, but in the UK it's done with something similar to DNS. The telephone system looks up the first N digits of the number to determine the operator it was first issued to. And places a query to them. That either causes the call to be accepted and routed, or they get an answer back saying sorry, that number has been ported to operator FOO-TEL, go ask them instead. Not quite, the simplistic overview is that operators have an obligation to offer porting wherever practical, so operate ports on a accept-then-forward principal. If I port my number from CarrierA to CarrierB, then my calls still pass through A's switch, who transits the call to B without charging the end user. For the benefit of completeness, the regulator has mandated that this situation must change, as CarrierB's inward-port customers are not protected from the technical or commercial failure of CarrierA. The industry [www.ukporting.com] has responded and is building a framework to support all-call-query style lookups to handle number ports. Best wishes, Andy
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On 22 Jan 2008, at 17:30, Michael K. Smith - Adhost wrote: Hmm, who gets paid? It sounds like your hinting around a telco-type reciprocal payment model (correct me if I'm wrong). Do I pay my upstreams who in turn pay there upstreams and so on and so on? Or, is there some central, uber-authority that gets paid by all of us? It seems to me that there are many billing models that accommodate point-to-point relationships, but I'm having a hard time coming up with a mental model of payment in the many-to-many environment in the DFZ. People pay the RIRs. The RIRs spend money on parties for network operators. I think that charging for deaggregation of PA is hard to imagine. I think charging for PI as a model may have been worthy of consideration several years ago, but since we're only months away from entire product lines of deployed edge kit nolonger accepting a full table, the battle is over (and operators lost). Andy
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On 23 Jan 2008, at 17:24, Paul Vixie wrote: [EMAIL PROTECTED] (Andy Davidson) writes: People pay the RIRs. The RIRs spend money on parties for network operators. ... according to http://www.arin.net/about_us/corp_docs/budget.html for 2007 and http://www.arin.net/about_us/corp_docs/annual/2006_audited_financials.pdf for 2006 and 2005, ARIN's expenses are mostly unrelated to partying. After fielding plenty of offlist mail - I'm sorry that my tongue in cheek comments caused some raised eyebrows; it was a non-serious suggestion for how the RIRs could spend an imaginary windfall, not a comment that they spend too much on socials. I recognise the value of conferencing, and the importance of injecting some socials at conference events since it's really good opportunity for delegates to spend time talking to others in the industry. Andy
Re: Lessons from the AU model
On 21 Jan 2008, at 01:43, Martin Barry wrote: $quoted_author = Andy Davidson ; .. think about what happens when your customers' routes start appearing through your MLP session as well. Standard practice would be to localpref customer routes over peering routes.[...] The customer's inbound (standard billing metric) won't be affected but their ratio might. I'm really happy for you to sell me some transit as long as I can peer with you over MLP as well. Small commit. I agree to give you some of my prefixes over the paid session, but I'm going to put all of my routes and my customer's routes on the MLP. With any luck you wont notice, just be happy that you suddenly seem to be selling more transit via your upstreams and also peering off more data too.. :-) Andy
Re: Lessons from the AU model
On 21 Jan 2008, at 14:02, Marshall Eubanks wrote: OK, I give and admit my ignorance. What does MLP mean in this context ? A google search for Australia mlp reveals many hits for My Little Pony, which somehow I doubt is the intended meaning on this list. Smile... Here it stands for Multilateral peering, so in simplistic terms it means you peer with everyone at an exchange. A route server. My issue isn't that they exist (and in fact one network I maintain is a member of three MLPs.) The issue is compelling people to join the MLP. This dissuades large networks from joining in with the public peering game, and is probably harmful to the peering ecology of the region rather than helpful. Best wishes Andy
Re: Lessons from the AU model (was: An Attempt at Economically Rational Pricing: Time Warner Trial)
awareness into their p2p implementation. Peering widely will help here. As for the file sharers, then (I really, really hate to say it) but can you just make sure you're picking up the seedier parts of usenet binaries over peering instead, and hope people use that ? Sad to think in these terms, but if we're being pragmatic ... I'd love to hear the opinions of AU operators on these issues, and think that there's lessons for everyone - if AU operators can show us how they deploy more cost effective connectivity products, then there are some regional ISPs in the rest of the world who would also benefit. Andy [1] £1,758,693 ($3.5m) PA for a 622Mbit BT Central, (so in bandwidth terms, equates to $471/Mbit per month - if the central is maxxed out) - I posted this to Nanog in October.
Re: Lessons from the AU model
On 21 Jan 2008, at 00:16, Matthew Moyle-Croft wrote: Andy Davidson wrote: - Am I peering widely enough ? Should I actually be stuffing a switch under the floor in my employer's suite and letting my buddies plug in ? Peeringdb knows about eight exchanges in a developed economy of 20 million people. We have more than eight in single cities of Europe. Peering in Oz is MPLA. This leads to no one worrying about having to be found to form peering relationships, so peeringdb is incomplete at best. I've tried to encourage people to add their data in. Is it always compulsory ? (I just did some legwork and read the WAIX policies, and it seems to be mandatory here) This surprises me, Multi-lateral peering is great for lots of networks, but really bad for others, and (if forced) probably acts as a barrier to the bigger networks from taking part in any public peering 1/3 from (expensive) transit to the Gang of Four) who won't peer and acts as an incentive to pull out of the agreement as networks grow .. think about what happens when your customers' routes start appearing through your MLP session as well. I can think of some MLP-only exchanges in Europe, but I can't think of any that do significant traffic. Andy
Re: BGP Filtering
On 15 Jan 2008, at 16:11, Ben Butler wrote: As a transit consumer - why would I want to carry all this cr*p in my routing table, I would still be getting a BGP route to the larger prefix anyway - let my transit feeds sort out which route they use traffic engineering. Maybe you don't get covering aggregates. That causes holes. Whether you care is a matter of local policy, though. :-)
Re: request for help w/ ATT and terminology
On 17 Jan 2008, at 12:45, Jeff McAdams wrote: Tony Li wrote: On Jan 16, 2008, at 1:37 PM, Mike Donahue wrote: Anyway, it's all getting (for us) pretty complicated. We're a fairly small firm and just want an Ethernet handoff with our IP block on it. Sprint didn't blink at the request, but ATT... We're getting a good rate from ATT for the IP services because it's at their colo. Switching back to Sprint would definitely be more costly. Please renumber into an ATT prefix. Yeah, because that's what's best for everyone else in the world *except* him. I understand the desire to keep from exploding the routing tables, but come on. You big ISP folks need to remember that you exist to provide service to customers. Jeff, Respectfully, do you see anyone from the big ISPs posting to NANOG complaining about the impact of the routing table size in their DFZ ? The big ISPs (e.g. many of them at the top of the 'Aggregation Summary' of the CIDR report) can probably afford the routing table to be twice the size (perhaps, if they're really big, their igp is already carrying twice as many routes ... ?) It's the multihomed enterprises, hosting companies, and smaller regional isps who today take advantage of having the full routing table to use, but soon might not be able to afford to, when companies like the OP don't renumber into their new ISP's space when they decide to change provider. There's some debate in RIPE land right now that discusses, what actually is the automatic, free, right to PI ? Every other network in the world pays the cost when someone single homes but wants their / 24 prefix on everyone else's router. If one had to pay a registry for PI, then small networks would have to think about the negative externalities of their decision to deploy using PI. Best wishes, Andy
Fwd: UKNOF9: London, Monday 14th January - Agenda
Hi, For the small number of us in the UK who have not seen this notification, the ninth UKNOF meeting is going to happen on Monday - there are some spaces left, so why not visit and meet some of your counterparts in the industry ? For those who are not local, remote participation is available by following the 'Webcast' link on http://www.uknof.org.uk/uknof9/ The listed times are in GMT, so the kick off would be 5am on the east coast. I hope to see some of you there. Best wishes Andy Begin forwarded message: From: Keith Mitchell [EMAIL PROTECTED] Date: 4 January 2008 20:22:10 GMT To: [EMAIL PROTECTED] Subject: [uknof] UKNOF9: London, Monday 14th January - Agenda Reply-To: [EMAIL PROTECTED] Happy New Year. If you are looking for a cure for those post-holiday blues, UKNOF9 is only 10 days away, and I'm pleased to announce a draft agenda of presentations for it - you can find this at: http://www.uknof.org.uk/uknof9/ I'd like to thank our sponsors Nominet UK, for their generous support of UKNOF9, which as well as keeping meeting attendance and catering free to all, is this time allowing us to move to a bigger room at the same venue. This time around we have a number of DNS-related talks, including Nominet's CTO talking about their plans for enhanced DNS security, and on the future of BIND. There are also operational deployment presentations on IPv6 and IPTV, and the latest developments in SS7 support for Asterisk. Richard Clayton will be talking about the recent report he worked on for the House of Lords on Personal Internet Security. We already have 4, but there is still room in the programme for 1 or 2 more lightning presentations: short and/or late-breaking items of interest. Please contact me anytime between now and on the day if you'd like to submit one of these. We also hope to webcast this event and support remote participation. Meeting connectivity is being provided by LINX, Entanet and Claranet, and we have a unique opportunity this time around to beta-test LINX's upgraded meeting wireless infrastructure. If you are planning to attend, and have not yet done so, please register as soon as possible at: http://www.uknof.org.uk/uknof9/regform.php A finalised meeting agenda and any other logistic details will appear here and on the UKNOF website http://www.uknof.org.uk in due course. Keith Mitchell UKNOF Chair
Re: ISPs slowing P2P traffic...
On 9 Jan 2008, at 20:04, Deepak Jain wrote: I remember Bill Norton's peering forum regarding P2P traffic and how the majority of it is between cable and other broadband providers... Operationally, why not just lash a few additional 10GE cross-connects and let these *paying customers* communicate as they will? This does nothing to affect last-mile costs, and these costs could be the reason that you need to cap at all (certainly this is the case in the UK).
Re: European ISP enables IPv6 for all?
On 19 Dec 2007, at 11:58, Mikael Abrahamsson wrote: So, out of our /32, if we assign each customer a /48 we can only support 65k customers. So in order to support millions of customers, we need a new allocation and I would really like for each new subnet allocated to be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed). From the RIPE perspective, there are seven empty /32s between my / 32 and the next allocation. I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table. Andy
Re: /48 for each and every endsite (Was: European ISP enables IPv6 for all?)
On 19 Dec 2007, at 12:24, Jeroen Massar wrote: Andy Davidson wrote: [..] From the RIPE perspective, there are seven empty /32s between my /32 and the next allocation. I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table. That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request... With respect, Jeroen, because I did *PLAN* (your emphasis) our organisational requirements, this is precisely the reason why I think it's significant that a lot of space was left unallocated following my allocation. My RIR only asked me to *PLAN* two years in advance (see ripe-414 [footnote 0]), though prudent organisations may plan for longer. I thought it was significant (and good) to note that they are allow me room to grow sometime after that period. If you offer the sweeping statement that anyone who ever needs to go back to the RIR for more space has made a 'mistake' with their requirement planning shows you're only thinking in an incredibly short term manner. Unless, of course, you are only used to working in companies which do not grow. :-) --- [0] #[IPv6 ALLOCATION USAGE PLAN]# % % When will you use this address space? % % Subnet Within Within Within % size (/nn) 3 months 1 year 2 years Purpose subnet: subnet:
Re: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
On 2 Dec 2007, at 20:19, [EMAIL PROTECTED] wrote: On Sun, 02 Dec 2007 09:59:19 EST, Andy Davidson said: On 29 Nov 2007, at 22:05, Eduardo Ascenco Reis wrote: The methodology shows a good efficiency (around 40%) reducing BGP table size, but the estimated number of affect prefixes are also high (around 30%). This is an interesting piece of work, and highlights an interesting model (40% table size saving hurts 30% of traffic.) No, it hits 30% of the *routes*. Yes, I completely agree, bad terminology indeed. I'll make a truly wild guess and say that those 30% of routes actually only represent 0.3% of the *traffic* for most providers, and the *only* people who really care are the AS that's doing the deaggregate... As you nearly point out, it's 100% of the traffic for some networks, and will still be high for other networks. The only way to feel confident that traffic is unaffected by routing table compression is to aggregate sensitively. This is where my permit one deagg question came from. Andy
Re: IPv4 BGP Table Reduction Analysis - Prefixes Filter by RIRs Minimum Allocations Boundaries
On 29 Nov 2007, at 22:05, Eduardo Ascenco Reis wrote: Although the BGP data is around one month old and the original focus was on Brazilian AS and IP prefixes, the general analysis covers all Regional Internet Registries (RIRs). [...] The methodology shows a good efficiency (around 40%) reducing BGP table size, but the estimated number of affect prefixes are also high (around 30%). This is an interesting piece of work, and highlights an interesting model (40% table size saving hurts 30% of traffic.) I have a couple of thoughts: from the text: Although representing less than 1% of all suboptimal and unreachable prefixes, /20 prefixes call attention because of their mask size to be expected as normal. In this experiment all /20 affected prefixes are from 2 RIPE CIDR (62/8 and 212/7) with /19 longest prefix, which data could eventually be used by RIPE to reviews these CIDR policy allocations. This is only one use example of applications that can be derived from analysis like this one. Do you still have the lab setup ? Could you work out what happens to the routing table and traffic routing if you permit one deaggregation per rir prefix ? I.e. This /19 is permitted to become two /20s, but it is not permitted to become four /21. My desire would be to see the resolved routing table look almost as trim as your 40% saving, but a significant amount of traffic routed as intended by the originating network. Lastly, perhaps another comment for your recommendations and conclusions section could be that traffic is hurt most in this model for networks who deaggregate most. Lets encourage people who read this document to infer that aggregating their prefixes would improve their reach in the post 250k routing table world. Andy
Re: Postmaster Operator List?
On 16 Nov 2007, at 15:54, Justin Scott wrote: Is there a mailing list similar to NANOG specifically for e-mail operations? I've seen some smaller lists around that deal with specific issues (spam, etc.) but have not seen a general postmaster operations mailing list, though I'm sure there has to be one around somewhere. Sorry for the noise. I emailed -futures registering my interests for such a list, and it got a mixed response. It's a shame, as like you I would like to see a busy, interesting, mail operations list, and derive value from one. I think that it will always be to controversial to start a nanog 'branded' mail operators list. I also understand why the MAAWG lists are run as a closed system, but recognise this prevents smaller sites from taking part. When discussing this with folks on -futures or irc people agree that a public mail operations list might be a good experiment, so I have just created one [EMAIL PROTECTED] Join here: http://chilli.nosignal.org/mailman/listinfo/mailop I'll set the reply-to: to me to prevent further noise. Best wishes Andy
Re: Friendly XO Mail-operational contact ?
On 7 Nov 2007, at 12:50, Suresh Ramasubramanian wrote: You sure XO hasn't been playing with banner delays, and your MTA is timing out before establishing an smtp connection? Yep [EMAIL PROTECTED]:~$ time telnet dalsmlprd08.dal.dc.xo.com 25 Trying 207.88.96.46... telnet: Unable to connect to remote host: Connection refused real0m0.170s I did call their NOC who couldn't help directly (which I expected), but also couldn't pass me on to someone who could.
Re: Friendly XO Mail-operational contact ?
On 7 Nov 2007, at 14:01, Tim Jackson wrote: Contact your account manager, they can get it fixed in about an hour w/ an internal IT ticket. They were doing the same thing to us. I don't open a business relationship with everyone that my users want to email. :-)
Re: mail operators list
On 30 Oct 2007, at 16:21, Daniel Senie wrote: At 12:07 PM 10/30/2007, Al Iverson wrote: On 10/30/07, chuck goolsbee [EMAIL PROTECTED] wrote: On a more relevant and operational sort of note, it sure would be nice if there were a NAMOG (North American Mail Operators Group) or the like to resolve these sorts of issues. Feel free to clue-by- four me if I've missed it. MAAWG come pretty close: http://www.maawg.org/home Smaller/regional ISPs need not apply. Minimum cost of entry is $3,000/year, no voting rights ($12.5K if you actually care about voting). So if you're not Verizon or Comcast or similarly sized, it appears you're not really welcome. Though it might make sense to discuss some other things NANOG could do in addition to worrying about routing table size and churn in the core, those are all discussions for the Futures list. I would support the creation of a mail-operators list ( agenda time for a mailops bof, since a lot of networks are small enough to mean that netops and sysops are often the same guys) if it's deemed to be offtopic on nanog-l.
Re: more-specifics via IX
On 15 Oct 2007, at 13:33, John Payne wrote: To answer the OP's question I'd be looking at manually filtering the more specifics if they are also sending the aggregates through the IX. The customer's customer is still going to see *your* routes via the MLP, unless (without knowing what exchange) you can attach a community to the announcement that forbids the route-server from propagating it to specific networks.
Re: Sun Project Blackbox / Portable Data Center
On 14 Oct 2007, at 01:26, Jim Popovitch wrote: - New Media / Web 2.0 HUH? I understand what Lorell means - the web 2.0 scaling model is to throw resources, rather than intelligence at your bottlenecks. I met some 'web 2' people at a conference quite recently, and they were telling me their platform scales because they can keep throwing servers at a cluster and performance increases. Problem is that it needs to scale early, and scale often. I asked if any of them understood the power requirements of a typical server, whether they'd heard of the power constraints in the datacentres that they'd all heard of, and how this model affected their new company's OSS costs long-term, and none of them knew. Scaling meant something else when I was solving these problems for the first time.
Re: meeting format/content
On 10 Oct 2007, at 17:56, Sean Figgins wrote: Spam, on the other hand, always seemed to be a scarlet topic here. If someone mentions spam or mail servers, there are those here that start breathing fire and claiming that their email should not be subject to spam filters. I don't know that it's really a relevant topic, as not all network operators provide email services to their customers, and the number that actually do seem to be getting smaller and smaller. [...] 2) Voice over IP. 3) Video over IP. If we let email be called 'Literature over IP', then if voice and video are on topic, email is. -a
Re: How Not to Multihome
On 8 Oct 2007, at 22:43, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? There was a good discussion following this, but I couldn't find mention of IRR Consistency in the follow ups. If I publish in an IRR that I am the legitimate originator of a prefix, 10.0.0.0/19, and someone else announces 10.0.2.0/24, whether I am aware or not, then they get the traffic. This could be the desired outcome, as in the scenario the OP refers to. However, if a different third-party network then sweeps up their routing table by looking to remove more specifics that seem 'spoofed' using IRR data, the routes you intend to push onto the internet may well start to disappear from their perspective. I'm talking in fairly superficial terms, rfc 2650 might give you more ideas. There's a reason things 'tend' to be done one way even though it means burning through AS numbers and v4 address resources.
Re: How Not to Multihome
On 9 Oct 2007, at 18:48, Leo Vegoda wrote: On 9 Oct 2007, at 17:47, Andy Davidson wrote: However, if a different third-party network then sweeps up their routing table by looking to remove more specifics that seem 'spoofed' using IRR data, the routes you intend to push onto the internet may well start to disappear from their perspective. I don't think this should be possible if the database implements RPSS (RFC 2725) properly. I believe that it should only be possible to create a more specific route object with the agreement using whatever PGP/X.509 security you like if you have used mnt-lower and mnt-routes attributes as appropriate. mnt-lower works, but only if I know someone else wants to originate a more specific. Routing in general doesn't care - this was the case I was making - hope I didn't cause confusion. Andy
Re: Why do some ISP's have bandwidth quotas?
On 8 Oct 2007, at 13:06, Roland Perry wrote: Surely the incumbent doesn't impose a cost on the bandwidth along the local loop - the bottleneck (and cost per gigabyte) is the backhaul from their locally operated DSLAM to the ISP's own network. Yes, and it's £1,758,693 ($3.5m) PA for a 622Mbit BT Central, (so in bandwidth terms, equates to $471/Mbit per month - if the central is maxxed out). (Using $2=£1)
Re: Why do some ISP's have bandwidth quotas?
From: Daniel Senie [EMAIL PROTECTED] Verizon, it's particularly sad, charges $19.95/month for dialup that'll also tie up a POTS line, where it'll offer the lowest DSL speeds at $14.95. And Verizon cherry picks the places where it offers DSL (and moreso for FiOS) so the affluent towns get high speed service, while the rural and poorer places only have available dialup (and that dialup is more expensive). In my experience, the support cost of DSL is significantly cheaper than dial-up in terms of helpdesk calls. DSL/Cable/FiOS is typically a plug and play, where as dialup can be quite a bit more troublesome, involving more tech time in the long run.
Re: Apple Airport Extreme IPv6 problems?
On 16 Sep 2007, at 07:39, Martin Hannigan wrote: On 9/15/07, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: Browsers are pretty good at falling back on a different address in general / IPv4 in particular when the initial try doesn't work, Pretty good as in there is a browser standard to poke for v6 then v4 or is this a stack behavior? Since this conversation has already talked about behaviour when encountering vs A, I am worried that a browser running on a dual- stack laptop might cache the returned when it has some v6 connectivity, and then refuse to look again for the A when I pick it up and take it somewhere with only v4 connectivity. We see the browser cache bite us regularly with regard to the way they dip into the cache for long-stale records today. The support burden will increase if there are stack transitionary woes as well. Andy
Re: Apple Airport Extreme IPv6 problems?
On 16 Sep 2007, at 15:13, Iljitsch van Beijnum wrote: We see the browser cache bite us regularly with regard to the way they dip into the cache for long-stale records today. Does browser caching still work these days? I thought all web admins disabled it on their servers because they can't be bothered to think about which cache directives to send along with each page. I can rarely return to a previously viewed page without the browser hitting the network, in any event. I mean the dns cache sorry. Firefox definitely has one, it keeps annoying me.
Re: Market for diversity (was: Re: Cogent latency / congestion)
Hi, David, everyone -- On 21 Aug 2007, at 17:55, David Lesher wrote: And still not getting it. A friend oversees various expensive USG networks. They pay for physically diverse routing from multiple sources. Yet every year, when they do an laborious audit down to the what fiber, in what bundle, in what trench level; they find.. Guess What! Yep, someone has moved this circuit or that one to where both pipes are intimate neighbors. Is it not possible to require that each of your suppliers provide over a specified path ? I'm planning a build-out that will require a diverse path between two points, and one supplier has named two routes, and promised that they wont change for the duration of the contract. Perhaps I am naive, but a promise should be a promise. Also instead of buying path A from supplier X and path B from supplier Y, it might be worth buying paths A and B from supplier X and a spare path B from supplier Y too. Supplier X must know they only get dollar N because they can provide both paths.. and in addition diversity has to matter more than money because you are in effect paying for one path twice. Andy -a -- // http://www.andyd.net/
Re: inter-domain link recovery
On 15 Aug 2007, at 08:07, Chengchen Hu wrote: Just suppose no business fators (like multiple ASes belongs to a same ISP), is it always possible for BGP to automatically find an alternative path when failure occurs if exist one? If not, what may be the causes? I think everyone here has already covered a lot of the bases to do with your original question (i.e. 'Because kit might not be configured to re-converge in an optimal way'), but if I can summarise the question you are trying to answer as how can we improve convergence times, you might like to look at the notes that Nate Kushman presented in Toronto this year http://www.nanog.org/mtg-0702/kushman.html Summary Many studies show that when Internet links go up or down, the dynamics of BGP may cause several minutes of packet loss. The loss occurs even when multiple paths between the sender and receiver domains exist, and is unwarranted given the high connectivity of the Internet. Instead, we would like to ensure that Internet domains stay connected as long as the underlying network is connected. Andy
Routing public traffic across county boundaries in Europe
I think this is a pretty dumb question, because I presume this is how most organisations save money and provide resilience. What (if any) are the legal implications of taking internet destined traffic in one country and egressing it in another (with an ip block correctly marked for the correct country). Somebody mentioned to me the other day that they thought the Dutch government didn't allow an ISP to take internet traffic from a Dutch citizen and egress in another country because it makes it easy for the local country to snoop. I've done lots of searching and have our legal council investigating but I thought someone here might be able to point me in the direction of any legislation? (I'll summarise any off-list replies)... Thanks, -- Andy Loukes Senior Systems Architect The Cloud Networks http://www.thecloud.net/content.asp?section=1content=32
Re: trans-Atlantic latency?
ae-21-79.car1.NewYork1.Level3.net ae-11-69.car1.NewYork1.Level3.net ae-41-99.car1.NewYork1.Level3.net 7. bdr01.ny1.qubenet.net 0.0% 187 67.4 67.4 66.8 69.8 0.4 Over a private DS-3 circuit from and to same buildings the average latency is probably 4ms less than the above. Andy.
Re: Use of portions of 44.0.0.0/8?
I can't speak for the overall reachability of the netblock, but you can find out more at http://hamradio.ucsd.edu/ and find a coordinator here: http://noh.ucsd.edu/~brian/amprnets.txt -- ~Andy Brezinsky On Mon, 2007-05-21 at 17:09 -0500, Neal R wrote: 44.0.0.0/8 is assigned to amateur radio operators. I'm a technician licensee in good standing (callsign K0BSD) and I'd like to start using portions of this space for an access project. I've been casting around with the Google for a little bit and I can't find any central authority from which to request a prefix. Does anyone on here know how this is done? Can I expect full reachability or will prefixes from this /8 be treated as a bogons? route-views.oregon-ix.netsh ip ro 44.0.0.0 Routing entry for 44.0.0.0/8, 3 known subnets Variably subnetted with 2 masks B 44.0.0.0/8 [20/629] via 64.125.0.137, 3d14h B 44.16.15.0/24 [20/20] via 129.250.0.11, 04:55:18 B 44.130.99.0/24 [20/0] via 134.55.200.1, 2w0d
Re: Colocation facilities in britian
On 16 May 2007, at 17:14, [EMAIL PROTECTED] wrote: Does anyone have ballpark costs on what colo space costs in England. Space costs lots and lots in central London where connectivity is cheaper. There are datacentres away from London which are much less expensive, but connectivity tends to cost more. Make sure your power requirements are well defined, 8A per cab is becoming a luxury in the Docklands !
Re: On-going Internet Emergency and Domain Names
On 2 Apr 2007, at 21:21, Lasher, Donn wrote: Rather, I thought a lot more providers would actually be blocking outbound 25 except to their SMTP servers. Just brought up a new mail server for a friend; moved an old (14+ year) domain.. I was amazed at the number of connections from rr.com, comcast.net, cox.net, verizon, etc etc etc obviously not official mail servers. I'm actually tempted to start blocking anything that doesn't say mail. in it somewhere.. :) Lots of people do use the 'came from some consumer isp dynamic range' as a reason to block mail by using RBLs which list the entire dial-up/ dynamic ranges of ISPs they know about[0], so if you wan to have a go at doing that, don't just drop any inbound mail from mtas which don't have reverse dns set to mail.something. At least, not without telling your customers that they can outsource their mail to my company ;-) [0] - e.g. http://mail-abuse.org/dul/
Re: ICANNs role [was: Re: On-going ...]
On 3 Apr 2007, at 03:02, Gadi Evron wrote: What are your thoughts on basic suggestions such as: 1. Allowing registrars to terminate domains based on abuse, rather than just fake contact details. I don't like this because its impossible to define abuse clearly enough in this context. If a fictitious web-shop 'nice-but-dim.com' get a box owned which has the reverse dns set to something in that zone, is this abuse ? Yes .. sort of, but it's no business of the registry. Is registering a domain name which causes offense to some people abuse ? It might be, but its no reason not to let the domain name registration go through. What if you and I fall out, and I manage to build a case against you to get linuxbox.org de-registered ? Do you want to spend time and effort fighting it ? Who arbitrates/polices this scheme ? Who pays for any mistakes ? Who decides when the domain name can be re-registered ? What about when someone registers a domain name in an international registry that doesn't want to implement the scheme, or perhaps isn't allowed to because its governance forbids it ? Some bad people have their names and numbers listed in the phone book. I can setup a fraudulent window cleaning company with no desire to do a good job for any of my customers .. does this mean 411 or the yellow pages should delist me when someone complains ? DNS is another directory. DNS is no more than a way for me to say Hey, where's Fred', to get a reply saying 'here he is'. DNS shouldn't whisper in my ear, 'but Fred is a bit dodgy'. If Fred is doing something illegal he should be in jail. This analogy isn't very good, but I need another coffee before I can think of a better one. :-) -a
Re: On-going Internet Emergency and Domain Names
You got me there. I will add: You can NEVER make the Pirates go away but; You can make sure they never enter your seas At which point, they take to land. The real issue at heart here is that some people wish to pursue evil means, and will change tactics and seek out weaknesses wherever they may find them. Today it might be weak verification of domain registry infrastructure, tomorrow it might be exploiting some p2p network. As has been repeated already, creating a fix in one technology will just force the would-be criminal to use another. The only real solution here is to make fewer criminals, and your only chances of that are to have more effective means of prosecuting them. In that aspect, I'm afraid we are quite a long way off, and will still always be a reactive process as opposed to a proactive process. The only hope is that it would deter future riffraff (though you could argue, such as with the pirate analogy, they will just find new avenues of attack).
Re: On-going Internet Emergency and Domain Names
so, what exactly is the problem with registrations? One of the problems I see is with a seeming lack of follow-through on fraudulently purchased domains. Another is a seemingly long time to remove domains that are 'up to no good'. Agreed with on both points. See below for view of the problem. If you look at the domain registration system as a legacy process, what would you do differently if re-inventing it? That, it seems to me, is likely the best path forward. Take your opinions/options and get them codified into new policy for registries/registrars to follow. With every relatively static and relatively open set of policies eventually bad-actors will find a set of loopholes or vulnerabilities to get their job done. It seems that re-evaulating the polcies/procedures/requirements would be useful in this matter. Absolutely, we should always be re-evaluating our policies to verify they are up to meeting todays demands. The unfortunate side of this is, it may end up increasing costs. If we cut down on the automation of domains, and had more respect for what ends up in the TLD/root servers, perhaps it would cut down (note: cut down does not imply eradicate) DNS abuse. The process should be more akin to requesting more IP space. If we treat DNS space as an unlimited resource, and give it away for a couple of bucks per year, its much easier to abuse. However, if you had to justify your usage and naming, and have a human actually process that request, perhaps it would cut down on bogus registrations. Though, as I've mentioned already, once DNS becomes sufficiently difficult to abuse, said bad-actors will just pursue other methods, and we will be left with an overzealous registration process that costs entirely too much.
Re: Jumbo frames
On 28 Mar 2007, at 00:28, Jim Shankland wrote: Jumbo frames seem to help a lot when trying to max out a 10 GbE link, which is what the Internet land speed record guys have been doing. At 45 Mb/s, I'd be very surprised if it bought you more than 2-4% in additional throughput. It's worth a shot, I suppose, if the network infrastructure supports it. The original poster was talking about a streaming application - increasing the frame size can cause it take longer for frames to fill a packet and then hit the wire increasing actual latency in your application. Probably doesn't matter when the stream is text, but as voice and video get pushed around via IP more and more, this will matter.
Re: [funsec] Not so fast, broadband providers tell big users (fwd)
On 13 Mar 2007, at 20:31, Roland Dobbins wrote: On Mar 13, 2007, at 11:19 AM, Daniel Senie wrote: A universal service charge could be applied to all bills, with the funds going to subsidize rural areas. This is already done in the U.S., to no discernible effect. That isn't *quite* the opinion that ATT have ... ... http://gigaom.com/2007/02/07/atts-free-call-bill-2-million/ Although that is people using the rural kickback as a loophole to provide free telephony to people outside the area.. still shows that regulation always comes with an unexpected effect when times, technology and ideas advance. Cheers -a
Re: single homed public-peer bandwidth ... pricing survey ?
On 6 Mar 2007, at 21:51, Jason Arnaute wrote: But, I am charged between $150 and $180 per megabit/s for non- redundant, single-homed bandwidth (not sure which provider they put it on) and even if I commit to 20 or 30 megabits/s it still only drops down to $100 - $120 per megabit/s. [...] Or am I just getting ripped off ? That depends ... does your current service often go wrong ? :-)
Re: Birmingham UK colocation
On Mon, 2007-01-29 at 12:56 -0800, Andrew Gristina wrote: I have two racks in London UK. The colocation is currently in London. The contract is up soon and most of the feet on the ground in the UK of the company is in the greater Birmingham area. So I'm interested in colocating about two racks of servers to Birmingham. I would need a cage if the space were shared. BT have a POP there (certainly our BT leased line into East Yorkshire bursts out there), so you stand a chance of getting BT someone else for two transits, if you can find DC space. There's no (public) peering, so you would have to rely on something hacky like L2TP to get over to London for peering... yuck. Birmingham has a great Selfridges store, but is a bit of an IP frozen wasteland. If your London DC space is with Telecity, talk to them; they have buildings in Manchester (although I don't know whether they are full). Manchester has some public peering, and a reasonable concentration of carriers, so there's some chance of private peering. London has problems - the data centres with space may not be represented by the transit providers you like working with, or the exchanges you want to join. The well connected DCs are getting full, certainly in terms of power and cooling capacity. Good luck, I hope if you do move it goes smoothly. If you (or anyone else) wants to share recent experiences of UK hosting/colo projects, then I'll be in Toronto next week. -a
Re: Google wants to be your Internet
On 23 Jan 2007, at 16:48, Sean Donelan wrote: Why is IP required, Because using something that works so well means less wheel reinvention. and even if you used IP for transport why must the meter identification be based on an IP address? Idenification via IP address (exclusively) is bad. I'd argue that if you are looking to check the meter for consumption data and for problems, a store-and-forward message system which didn't depend on always-on connectivity would preserve enough address space to make it viable as well. -a
Re: DNS Query Question
On 18 Jan 2007, at 17:39, Dennis Dayman wrote: What they have discovered is their current DNS service has a 1% failure/timeout rate. Is the request even hitting their DNS servers ? If the problem is actually connectivity, then moving DNS off-network will improve dns performance, but everything else will still lose a few percentage of inbound packets ... Unless you want to outsource your entire hosting to someone on the list. ;-) -- Regards, Andy Davidson http://www.devonshire.it/ - 0844 704 704 7 - Sheffield, UK
Re: Network end users to pull down 2 gigabytes a day, continuously?
On 12 Jan 2007, at 15:26, Gian Constantine wrote: I am pretty sure we are not becoming a VoD world. Linear programming is much better for advertisers. I do not think content providers, nor consumers, would prefer a VoD only service. A handful of consumers would love it, but many would not. There are already cheap and efficient ways of doing VoD-like services with a PVR - I timeshift almost everything that I want to watch because it's on at inconvenient times. So shows get spooled to disk whilst they're broadcasted efficiently, and I can watch them later. Any sort of Broadcast-Video-over-IP system that employed that technology would be a winner. You don't need to 'broadcast' the show in real time either if it's going to be spooled to disk, even as it is viewed. -a
Re: AS41961 not seen in many networks
On 4 Jan 2007, at 13:57, Sebastian Rusek wrote: Since November 2006 we announce our 3 new prefixes: 194.60.78.0/24 194.60.204.0/24 194.153.114.0/24 from new AS41961. If you're interested in how Europeans see you.. I have three default-free transit providers and only see you behind two of them, eventually through 'LambdaNet' on both. -a -- Regards, Andy Davidson Consultant Systems and Network Engineer, Devonshire IT Limited http://www.devonshire.it/ - 0844 704 704 7 - Sheffield, UK
Re: Phishing and BGP Blackholing
On 3 Jan 2007, at 01:02, Joy, Dylan wrote: I'm curious if anyone can answer whether there has been any traction made relative to blocking egress traffic (via BGP) on US backbones which is destined to IP addresses used for fraudulent purposes, such as phishing sites. I'm sure there are several challenges to implementing this... I have often thought that this would be a brilliant idea (on paper), when working with one of my clients who suffer regular denial of service attacks through open http and socks proxies. They are a multi-homed end site running bgp4 on their edge networks. From a 'problem solving' perspective, a Team Cymru-style bgp peer that injected very specific routes into their routing table, and matching configuration which caused those particular routes to be dropped would be ideal. Additions and deletions would be as close to real-time as possible. From a political perspective, I could only advocate to clients such a service that had a strict policy of adding routes to addresses because of a provable policy infringement. For example, a route for 1.2.3.4/32 would only be announced by my bgp-blacklist peer if it could be demonstrated that a device reachable at 1.2.3.4 was an open http proxy (or socks proxy, or smtp relay) and not because a phishing site was hosted there. Different priorities for different networks I guess .. No interest in a service which requires companies running a blocked proxy to pay before the route/block is lifted. Also no interest in a service which blocks entire networks in the event of a policy infringement, only the polluting hosts. I mention this paragraph thanks to some of the policies of DNS-based email-abuse blacklists. Phishing is content - when a service opens which filters based on content, there's a whole new can of worms being opened - what *else* is abusive content ? Does it stop being abusive content at some point ? If phishing is abusive, is pornography abuse ? A mouthy anti-West news agency ? Anyone going to talk about this at Toronto ? Trying to justify taking a week 'off' to visit ... ;-) -- Regards, Andy Davidson http://www.devonshire.it/ - 0844 704 704 7 - Sheffield, UK
Re: today's Wash Post Business section
On 21 Dec 2006, at 12:04, Alexander Harrowell wrote: Yes, Mac OSX has a whois client in Network Utility, but it's crap. There is a fully featured command line whois client. factory:~ andy$ whois usage: whois [-aAbdgiIlmQrR6] [-c country-code | -h hostname] [-p port] name ... -- Regards, Andy Davidson Consultant Systems and Network Engineer, Devonshire IT Limited http://www.devonshire.it/ - 0844 704 704 7 - Sheffield, UK
Re: The IESG Approved the Expansion of the AS Number Registry
On 30 Nov 2006, at 07:02, Chris L. Morrow wrote: On Wed, 29 Nov 2006, Deepak Jain wrote: Afraid so. I'm hoping to be out of the industry before calls for 128 bit AS#s come down the pipe and people (at that time) are laughing about how silly 32 bit AS#s seem. anyone have a swag at the number of things that this (32bit asn) touches? Yes, and it means plenty of work for us all - hurray. But we need to take action to preserve the availability of new AS numbers for new network builders. RIPE will be accepting requests for 32-bit ASNs from 1/1/07, according to an email to ncc-services two weeks ago. It does not feel too early to start to understand what we must do to as a community to guarantee ubiquity of reachable networks. There were no definitive answers when John Payne asked on the list about images supporting 32 bit as numbers - are any independent bodies going to setup a route behind a 32-bit ASN so that we can start public reachability testing ? Andy
Re: OT: How to stop UltraDNS sales people calling
On Tue, 2006-11-28 at 16:44 +, Paul Vixie wrote: [EMAIL PROTECTED] (Andy Davidson) writes: I am really fed up of calls from UltraDNS - we seem to get them every few days. We don't need their product. every month or two somebody will ask me does BIND really drop 20% of all queries it receives? and i say, um, no, why do you ask? and the answer is always that's what the ultradns salesman told me. i can't argue with their success, but i guess i am ready to quibble over their manners. The volumes are different, but the message is the same when I am called, there's a claim that we are dropping queries because we use bind, but the people on the phone can't explain why. This is a problem when our CTO gets the sales call, as it generates effort explaining that the company are employing scare tactics. Thanks for the volume of offlist replies with some good suggestions, too, everyone - many were very amusing.
OT: How to stop UltraDNS sales people calling
Hi, I am really fed up of calls from UltraDNS - we seem to get them every few days. We don't need their product. We've tried saying no, and additionally we've tried putting people on hold indefinitely, trying to be enough of a nuisance to drop off their sales call list (works with UK telcos - try it). I just had a guy on hold for 18 minutes before taking him off hold to say that we didn't want their product, and could he please stop calling. He told me he would still calling until he got through to the right person. I am the right person. In the interest of Anglo-American relationships - any Neustar people on list willing to help ?
Re: West Coast Fiber Cut?
Global crossing is reporting that SBC was horizontal boring and knocked out Quest and SBC fiber. This is 4 km north of Wolden Ave and Main St. in Red Bluff, CA. Qwest has techs on site and they're digging. -- ~Andy Brezinsky On Fri, 2006-09-29 at 12:29 -0700, Rick Kunkel wrote: Anyone know much about this major west coast fiber between Los Angeles and Washington that was supposed cut this morning? Our network is having gnarly problems through one of our providers and lesser ones through the other. Investigation went on for about 2 hours, whereupon i finally received an email from InterNAP talking about the problems starting at 9:45AM PDT, and being rooted in this fiber cut. My other provider has since told me that it was a Qwest fiber, and that most major transit providers were using it. Anyone heard anything else about this? Thanks, Rick Kunkel
Re: Database for customer assignments [WAS Re: Data Center Wiring Standards]
In my experience, most folks roll their own IP management software. Most coming from spreadsheets such as yourself, end up with some sort of custom written provisioning software that integrates into their existing applications. I've seen very few commercial products in use, though I can't say whether or not they were any better or worse than the home grown solutions. IIRC, there were two major open source projects, FreeIPDB, and Northstar. Both had some promise for a decent open source IP management suite. As far as Switch Ports/Patch panels, I've not seen anyone keep real good track of usage other than switch port descriptions. --- Andy - Original Message - From: Rick Kunkel [EMAIL PROTECTED] To: nanog@merit.edu Sent: Tuesday, September 12, 2006 1:30 PM Subject: Database for customer assignments [WAS Re: Data Center Wiring Standards] Thanks much for all the info folks. I'm sure I can amalgamate this info into a good plan, or at least a pie-in-the-sky place to reach for. On a related but dissimilar topic: What are people using for storing customer assignment info and stuff? Right now, we've got an Excel spreadsheet covering patch panels, another covering colo customers and the types of usage plans that they're on, and our general customer database that hasn't been updated since the colo biz has picked up, and is thus currently poorly equipped to deal with it. Additionally, we use RTG for usage stuff, and a combination of well-commented DNS zone files and customized Excel spreadsheets for managing IP Space. Needless to say, the integration of these things is pretty non-existent. Are people using off-the-shelf products (freeware or otherwise) for these types of things, or are they custom designing their own? I've recently started to create a proper database that stores patch panel, switchport, customer, VLAN, and usage information, but the queries I'm dealing with in an attempt to extract information from it are so complex that I just can't seem to justify spending the time on this, when -- regardless of the low-techiness of them -- the current method of spreadsheets and such gets by. Eventually though, I'm sure it's the scalability that will be the killer. I've messed briefly with IPTrack (or was that the old name for it?) for IP address management, but nothing else too much. Any suggestions? Thanks in advance, Rick Kunkel
sbcglobal.net email
Anyone from sbcglobal.net support around? We're trying to send emails to some of your customers and your mailserver tells us that it's accepted for delivery but it never gets there. This is reproducable for a few addresses. SBC's noc line and tier-1 yahoo dsl support have not been of any help. Jul 17 14:01:03 localhost postfix/smtp[5433]: E89E23D40E5: to=[EMAIL PROTECTED], relay=sbcmx4.prodigy.net[207.115.57.18], delay=2, status=sent (250 2.0.0 k6HIxhY0006651 Message accepted for delivery) Thanks.
Re: IP failover/migration question.
Hi, guys Very late reply, but this is a 'hot topic' in my space.. On 12 Jun 2006, at 04:02, Randy Bush wrote: I'm trying to get a more clear understanding as to what is involved in terms of moving the IPs, and how fast it can potentially be done. can we presume that separate ip spaces and changing dns, i.e. maybe ten minutes at worst, is insufficiently fast? Ten minutes at worst, only if everyone is behaving. Some of the UK's largest (in terms of consumer customer numbers) ISPs disobey short dns refresh times, and will cache expired or old records for 24(+?) hours. Popular web browsers running on popular desktop operating systems also display extra-long dns cache time 'bugs'. 24 hours + outage whilst stale dns disappears will never do in internet retail. BGP, two datacentres, both equivalent endpoints for customer traffic, same IP space, and an e-commerce application which will happily run 'active/active' is the holy grail, I think. The problem isn't setting this up in IP, it's getting your commerce application to fit this model (a problem I have today). Best wishes, Andy
Re: IP failover/migration question.
[EMAIL PROTECTED] wrote: Andy Davidson wrote: 24 hours + outage whilst stale dns disappears will never do in internet retail. And yet, with 90% of the net implementing the will never do scenario, we manage to get a lot of internet retail done anyhow. I'm obviously going to need a *lot* more caffeine to sort through that conundrum Hi, Vladis -- Thanks for the email. Unlike a number of ISPs operating in the same geographic region as ourselves, a loss of core systems or connectivity causes something more than the sweat on the forehead of the people responsible for SLA-credit-avoidance... it causes a 100% revenue loss for the period of the outage. When you reach a certain size, in the UK at least, your business insurance partners will expect you to demonstrate how you have taken steps to avoid this entire outage. When the company reaches another size, you may find your continued employment also depends on some degree of constant availability. This is what I mean by 'will never do'. A lot of small firms can sit out an evening without trading. To us, this represents 'real pain'. Best wishes, Andy
Re: IP ranges, re- announcing 'PA space' via BGP, etc
On Fri, Apr 07, 2006 at 01:13:19PM +0200, Alexander Koch wrote: When a random customer (content hoster) asks you to accept something out of 8/8 that is Level(3) space, and there is no route at this moment in the routing table, do you accept it, or does Level(3) have some fancy written formal process and they get approval to do it, etc.? Initial instinct has to just be 'yuck', but in the interest of getting the job done, I'd look at : - how is it registered ? Are your customer mentioned ? - is it already a prefix which is announced seperately from the rest of the aggregated block ? - if the customer wants to multihome, have they even considered PI ? - are the customer happy for you to talk to the aggregating company ? are you happy to talk to them ? - it's still 'yuck'. -a
Re: Spam filtering bcps
On Wed, Apr 12, 2006 at 03:35:51PM -0400, [EMAIL PROTECTED] wrote: On Wed, 12 Apr 2006 14:28:59 CDT, Bryan Bradsby said: Silently deleting other people's e-mail should never even be considered. Unless that email is a virus, or a spam with a forged envelope sender. No, in that case you 550 the sucker. Unfortunately there is plenty of mailing list manager software that will disable your subscription if your mail is rejected enough times. Mailman being a good example. I have been unsubbed from mailman lists that have allowed viruses through, even with the default mailman settings for boucne processing. In a perfect world, no mailing lists distribute spam, viruses and malware. At the moment therefore while practicing reject after DATA I do find it necessary to mark as spam and accept if it has Precedence: bulk (or list or whatever), because otherwise my users complain and don't subscribe to poorly-managed lists then is not an acceptable answer for them. Regards, Andy signature.asc Description: Digital signature
Juniper Support pricing.
Hi, Has anyone else seen Juniper support pricing take one hell of a hike in the past twelve months ? We've been quoted a rise of 141% on the costs of supporting our ISG2000 units, and a 114% rise on the costs of supporting our Redline^WJuniper E|X devices. I've been asked to provide a case to evaluate the costs of binning the existing kit and migrating the firewalls to PIX... which I'd prefer to avoid if at all possible, as it is a bad time to take on the extra workload. We have been a model (I hope!) customer in that we've only had one post-sales/operational trouble-ticket case open in the past twelve months for our entire family of Juniper products ! Just wondering whether it's something you guys have seen too. -a
Re: DNS Amplification Attacks
Joseph S D Yao wrote: [...] service except perhaps to their own population, than against what can you compare the DNS service that you are getting, to see whether it is giving you what the world should be seeing? DNS looking glasses, in much the same way that we use web-form based BGP or traceroute looking glasses today.
Re: Last message i'll post for awhile I promise :-) (Need a Time Warner Cable NOC person)
Time Warner Cable is not Time Warner Telecom, two entirely different networks/orgs. If Drew needs to get a hold of Time Warner Cable folks, check out TW GNOC: +1 703 345 3416 --- Andy Johnson - Original Message - From: Mehmet Akcin [EMAIL PROTECTED] To: nanog@merit.edu Sent: Thursday, March 09, 2006 3:35 AM Subject: Re: Last message i'll post for awhile I promise :-) (Need a Time Warner Cable NOC person) On Mar 08, 2006 07:48 PM, Drew Weaver [EMAIL PROTECTED] wrote: Are there any TWC NOC people on list? Thanks, Drew are you member of peeringdb.com ? That's an amazing place to search for people who are in NOC of ISPs/networks etc. Especially for peering purposes. I just searched there and TWC has a contact info there.. I recommend you to register and start using it, so you can get pretty much the contacts you need or they can direct you to the best person , at least Mehmet Akcin
Re: Shim6 vs PI addressing
Roland Dobbins wrote: On Mar 3, 2006, at 10:50 AM, Stephen Sprunk wrote: OTOH, hosts go a lot longer between upgrades and generally don't have professional admins. It'll be a long, long time (if ever) until shim6 is deployed widely enough for folks to literally bet their company on host-based multihoming. This issue alone means that shim6 isn't viable. Besides the already- mentioned security and complexity issues, enterprise IT departments - i.e., the customers who need multihoming and cannot live without it - are not going to be amused when told that the tens and hundreds of thousands of desktops, laptops, PDAs, and other IP-enabled devices on their networks are now essentially routers, with multiple IP addresses and complex middleware required to simply access 'the Internet' . . . We've been here before; we shift a lot of data in the content arena, and our web-head loadbalancers, installed only a year ago, don't even support ipv6 in the current software build. -a
Re: shim6 @ NANOG (forwarded note from John Payne)
Mark Newton wrote: I mean, who accepts prefixes longer than /24 these days anyway? We've all decided that we can live without any network smaller than 254 hosts and it hasn't made a lick of difference to universal reachability. What's to stop someone who wants to carry around less prefixes from saying, Bugg'rit, I'm not going to accept anything smaller than a /18? Hopefully, customers. Furthermore, such a policy will also do little to encourage IPv4 conservation. We're already in a situation where for each routing policy, folk are recommended to use /20 or smaller prefixes (per routing policy) when applying for PI, despite the fact that a /23 might suit their multi-homed, end-site network, in order to help beat-the-filters. -a
Re: Quarantine your infected users spreading malware
On 21 Feb 2006, at 16:26, Jason Frisvold wrote: Key words there.. Large Provider .. I don't think A/V companies have any interest whatsoever in smaller providers.. Just not a big enough customer base I guess... It would be nice to see an A/V provider willing to take that first step and offer something like this to providers, regardless of size. Anti-virus is already offered directly to end users ... for free ! http://free.grisoft.com/ And they don't care ! How is someone else telling them that they need a virus checker going to change anything ? -a
Re: a truly radical proposal
On 15 Feb 2006, at 18:05, Edward B. DREGER wrote: RIRs refuse to grant ASNs to dual-homed leaves. Transit providers _must_ cooperate with each other. Introducing the greater risk of blackholes, and potentially increasing the complexity and size of the routing table. In one of our facilities we work with two upstream telcos supplying IP. IP Connectivity *must work* here or our business will die. We would have to co-ordinate change through two large, uncaring, inefficient bodies, who must make their changes at the same time. What you propose would not work for us. -a
Re: Disaster recovery using as-prepend?
On 16 Feb 2006, at 14:56, Christopher J. Pilkington wrote: We have a PI /24 we'd like to advertise out of our primary data center for production use. (Well, actually, we'll be advertising a more specific from our /21 assignment, so already not too friendly... but I digress.) [...] I'm thinking advertising the same prefix and just doing several as-prepends. However, now I'm not sure if this is a polite thing to do or not. How about advertising all of your PI from all of your perimeter routers, and configuring internal routing to ensure packets get to the rightful live/preferred data centre. Then, in the event of a failover situation, you can change the routing behaviour so that packets for the production /24 end up in the alternative dc. To work, this does imply you have good connectivity between your live and failover environments (but i guess you have this so that you can copy over state/live data between your two environments anyway..), so that you can carry customer/live data over the link too. Double plus good for you if you can get cheap transit delivered to your failover dc - you could use this for your preferred environment too ! cheers -a
Re: Fed Bill Would Restrict Web Server Logs
Suresh Ramasubramanian wrote: On 2/14/06, Jon R. Kibler [EMAIL PROTECTED] wrote: A bill just announced in Congress would require every Web site operator to delete information about visitors, including e-mail addresses, if the data is no longer required for a legitimate business purpose. Original posting from Declan McCullagh's PoliTech mailing list. Thought When no longer required for business purposes Your syslog's logrotate function does that for you already, for all reasonable purposes .. blows away logs that are say a week old. Speaking with my e-commerce vendor hat on, server logs (apache, mail, application audit logs) and other information about visitors (especially those who have conducted a purchase transaction with us, or signed up to our newsletter) never stop having a business purpose - it's called referential integrity. We want to use them to track the behaviour fraudulent users for example. We also want to learn about how people use our site to make it easier. We want to ensure our mail systems are not approaching capacity. We want to know if our spam filtering is working, and how its use changes over time. etc.,etc.,etc. These are all business purposes. It's interesting that the US government is requiring less user data is stored when European politicians are calling for greater data and log retention rules.
Re: Password Security and Distribution
Hi, Embarassingly late reply; I've been away. On Tue, Jan 24, 2006 at 10:48:45AM -0500, Jeremy Stinson wrote: We are in the need for a better mechanism for sharing passwords between our engineers. Most of these passwords are for our client's systems where some of them are controlling the password schemes (aka requiring shared user accounts). [...] In other companies we have used a PGP keyring to secure a text file that contained all of these passwords and then put them onto a shared customer portal. The problem with this strategy is what happens if you are not on your computer where PGP is installed? Encrypted text files are a nice way to go until you grow to the size when people need very different levels of access, and centrally storing a number of these files isn't good enough. http://devel.pluto.linux.it/projects/Gringotts/ is what we use. If an engineer is not at a desk where they have gringotts installed, use the -d flag to use a console/interactive version of the software instead of the usual GTK gubbins. -a
Re: QWest is having some pretty nice DNS issues right now
Steve Gibbard wrote: So from my uninformed vantage point, it looks like they started doing this more or less right -- two servers or clusters of servers in two different facilities, a few thousand miles apart on different power grids and not subject to the same natural disasters. In other words, they did the hard part. What they didn't do is put them in different BGP routes, which for a network with as much IP space as Qwest has would seem fairly easy. I didn't get to play detective at the time of the outage, but configutation (which is automatically replicated) may also have been enough to take out both nameservers. It also makes good management sense to run your nameservers with the same software and versions, but perhaps it doesn't make good continuity sense.. ? cheers -a
Re: Equal access to content
Sean Donelan wrote: Should content suppliers be required to provide equal access to all networks? Or can content suppliers enter into exclusive contracts? Erm .. the content 'belongs' to the supplier, why shouldn't they be allowed to chose who can and can't get access to it. The electronic retailer I work for deny access to all content that they own/supply to several networks, as a matter of policy. Noone should be able to tell us that we have to start supplying it. We also give some third-parties more content based on commercial relationships in place. Similarly, google own all of the data that they've crawled/indexed/archived - why shouldn't they be able to hold that data to ransom. Why shouldn't google be able to supply extra content to networks that it runs ? [...] What rules should exist on how Google operates? Or is it just traditionally lobbying? Google says regulate the other guy, but not itself. The other guys say regulate Google, but not them. So google charge for their data (either by subscription, or forcing users to join GoogleNet to get access to what they want). Fine. If Google do, someone else will be perfectly willing to crawl/index/archive a new set of data. And many webmasters will be quick to deny access to google's spider. -a
Re: [Pr-plan] Public-Root resolution problems and UNIDT (fwd)
Peter Dambier wrote: The Ankara root injected a number of older records into the DNS resulting in false answers to queries. Ankara was also listing as root servers some DNS that pointed back to ICANN data and did not resolve the Public-Root. This was very unprofessional behavior on behalf of UNIDT resulting in a serious violation of their contractual obligations to the Public-Root. Sounds like chaos. If only there was some way of co-ordinating a central root, managed by a trustworthy, established, stable main player. A bit like an internationally organized, non-profit corporation that has responsibility for Internet Protocol (IP) address space allocation, protocol identifier assignment, generic (gTLD) and country code (ccTLD) Top-Level Domain name system management, and root server system management functions. Has anyone considered this ?
Re: Replacing PSTN with VoIP wise? Was Re: Phone networks struggle in Hurricane Katrina's wake
Iljitsch van Beijnum wrote: There are two types of VoIP: voice over a private, tightly controlled IP network, and voice over the public internet. Now obviously the latter is a risky proposition, as it imports all the limitations of the internet into the voice service. I'm not so sure; someone cuts an ISDN-30 into our building and the sky falls down. Someone cuts some fibre carrying IP and life (and communications) carry on .. Perhaps you've made a fair and good comment on the marurity of most off-the-shelf voip products or implementations. But the key, in my mind, is that VoIP across the internet, when done well, imports all of the opportunities of internet routing into voice service. -a
Re: zotob - blocking tcp/445
If you have an offending network that does not respond to abuse/complaints, your best course of action is to no longer communicate with that network. That is your own choice as an end-user/network operator. Complaining to their upstream or transit provider will only get them to switch providers. The traffic will continue. An alternative solution as you mentioned, involves some laywers, and attempt to recover compensation for the damages. Good luck with that one though. From the looks of it, you'll spend more money in court than you would have just blocking them. We can't force other networks to play nice. As we all know, the Internet is an open network. Protect yourself, and make sure you are not one of the internet scum sending out this stuff, but don't depend on others to play nice with you. Transit providers should not be CONTENT filtering their customers (for free anyways, I'm all for selling security services). This does not mean they have no responsibility to keep a proper abuse/security staff. If a transit provider has a customer who is constantly infecting/spamming/etc and fails to act, by all means take action and drop the customer. My main point is, if we depend on our transit providers to act as Internet nannies, we are promoting poor end-user network management. --- Andy Roger Marquis wrote: How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable. Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see from the rest of the net combined. It's eating nontrivial bandwidth and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request. My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers?
Re: zotob - blocking tcp/445
I think the point of many on this list is, they are a transit provider, not a security provider. They should not need to filter your traffic, that should be up to the end user/edge network to decide for themselves. Additionally, content filtering is great for those type of end-user folks, as this solution wouldn't be so difficult to scale for their traffic volumes. However, trying to content filter a transit provider is probably not a great idea. William Warren wrote: I may be off base here. Can't an ips look at the traffic; say on 443 and figure out whether the traffic is malicious or not? If so then let it filter it. I know IPS's aren't perfect, but, i would prefer this router be taken, if available and sensible including network outage or DDOS, than a hard block. A quick block to mitigate and then an IPS rule installed AFTER through investigation of the traffic could lessen the load and maybe eliminate the malicious traffic without having to use a hard block. I know most here prefer not to..i am not saying this is a let's block is all thread, just trying to throw out something i do not see being discussed.
Re: recommendations for 3rd party web site monitoring
Matt Bazan wrote: In need of external 3rd party site monitoring solution. Nothing fancy. Need to be alerted if site (HTTP/S, SMTP, TCP connect based) goes down (email, pager). Off list fine, thanks. http://www.alertsite.com/ give us http availability which we can configure to alert us in a number of ways. Also give us very useful performance statistics aggregated from a day and weekly statistics, by email in human readable and XML form (which means pulling it out of the mail and dropping it into a database is handy.) For maximum offsite monitoring, a colo'd box with nagios is likely to be most flexible, but time consuming to setup and get right (as soon as you have something which can be turned into a powerful monitoring system, you will want it to perform exactly that task !) Let us know what you finally do, -a
Re: Way OT: RE: @Home's 119 domain names up for sale
Hi, With apologies to the topic fairies .. Crist Clark wrote: It matters how you look at income taxes (figures never lie, but liars figure). The top 3% of earners pay about 40% of all income taxes. The top 1/12% pay about 10% of the taxes. Why do the super rich guys want a flat tax? And the other obvious problem, you pay a lot of taxes, probably more than you realize, besides income tax. The top few percent will pay a lower _percentage_ of their income to the government in tax than a middle earner would (a high earner will typically save more, or in other words their marginal propensity to save is higher) - they are also able to save more and afford better accountants who will help them avoid paying tax ! In the UK, income tax is hugely regressive - a middle earner may end up paying 51% of some proportion of their income in direct tax alone (combining NHIS contributions and income tax) - this then falls to 41% (combined) when the NHIS contributions hit a certain level. The tax burden on high earners is further reduced when one considers that indirect sales tax in the UK is 17.5%. -a
Re: fcc ruling on dsl providers' access to infrastructure
All of us independant isp guys are busy polishing up our resumes.. --- Andy interesting that nanog is chattering so seriously about the calea thing (which does concern me), but seems to be unconcerned about another ruling that would seem to be a major anti-competitive change threatening the businesses of a few hundred members of this list http://news.com.com/2061-10785_3-5820294.html. or maybe i am misreading the ruling. randy
Re: /8 end user assignment?
Christopher L. Morrow wrote: will the v6 access really be enough to require LB's? or are they there for other reasons (global lb for content close to customers, regionalized content) perhaps reasons which would matter 'less' in an initial v6 world where you were getting the lb's fixed by their vendor? (or finding a vendor that supports v6 lb?) I am a keyboard jockey for an international online retailer; I picked our loadbalancer solution[0] because of the things it did other than balancing load per se, including cacheing, tcp and ssl session offloading, and content compression. Yes, you could do much of this with apache/mod_proxy but not 'as well'. Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries. [0] Redline Networks E|X, now owned by Juniper of Borg. -a
Re: /8 end user assignment?
Randy Bush wrote: Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries. could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing? My point was that the 'loadbalancers' do so much more than share load, and I don't want to lose this functionality. But to answer your question, the market isn't providing us with enough - or rather *any* interest, and this is what matters. If we reach the point where people can't buy widgets from us until we support IPv6, or that people would rather buy widgets from someone else because they support it, then we have to move. I don't know if there can be other financial incentives for us - if we can buy IPv6 connectivity very cheaply - which helps us squeeze those margins even more of course, then similarly we have to move. Quickly. -a
Re: /8 end user assignment?
Joel Jaeggli wrote: LVS which rather a lot of people use for load balancing supports ipv6 and has since 2002 This is what I binned in favour of Redline. I don't know whether you're balancing HTTP or something else, but if you are balancing web traffic, then you may get much better performance using a reverse proxy (taking advantage of keepalives in your httpd and proxy). We did. -a
Re: Problems at Microsoft?
I am having very poor luck making a successful connection to download.microsoft.com sites as well. When I do, instead of the typical 10mbps, I'm seeing 5kb/sec just as you are. Ping times/traceroutes to them looks normal, so I don't immediately suspect an overloaded link, so I'm not quite sure what the issue is. --- Andy Drew Weaver wrote: Hi there, we’ve had a few complaints about connectivity issues to Microsoft, is anyone else seeing a problem? Usually I get between 2-3MBps when I download from them, at the moment I get 8k/sec downloading http://download.microsoft.com/download/b/6/2/b624b535-644a-41e1-9727-812dcd6bad87/E3SP1ENG.EXE (service pack 1 for exchange 03) from Both my network, and a monitoring server we have in chicago. Anyone else seen this? -Drew
Re: Google DNS problems?!?
On 8 May 2005, at 17:07, aljuhani wrote: Well I am not a DNS expert but why Google have the primary gmail MX record without load balancing and all secondaries are sharing the same priority level. Huh ? [...] 1888 (97%) messages were gated through Gmail's Primary mail server (gmail-smtp-in.l.google.com). gmail-smtp-in.l.google.com is at least two machines, but much more likely to be at least two clusters of machines ... : ;; ANSWER SECTION: gmail-smtp-in.l.google.com. 232 IN A 64.233.185.27 gmail-smtp-in.l.google.com. 232 IN A 64.233.185.114 .. load-balanced in some way. One MX record doesn't mean one machine and no load-balancing by any means. -- Regards, Andy Davidson http://www.fotoserve.com/ Great quality photo prints, gifts and clothing from digital photos.
Re: Acceptable DSL Speeds (ms based)
Luke Parrish wrote: My email was confusing since I said the word speed, I would like to ms roundtrip for the following: *1. CPE to first layer 3 hop 2. CPE to first layer 3 upstream hop 3. CPE to layer 3 exit point of upstream *Example: Trace route to www.yahoo.com http://www.yahoo.com/1. 10.10.10.1 (CPE) 1ms 2. 10.10.10.254 (DSLAM)(cte) 21ms*(first layer 3 hop) *3. 11.1.1.1 (Router)(cte) 24ms 4. 5.5.1.3 (upstream interface)(level3) 68ms*(first layer 3 upstream hop) *5. 5.4.3.2 (exit point of upstream)(handoff from level3 to att) 94ms *(layer 3 exit point of upstream) *Those ms values are what I am curious about. What are other providers seeing and what are, in your opinion, acceptable ms times for a home 1.5M dsl user... Luke The speeds will vary based on the packages built out. When using interleaved mode (for ADSL anyways), you will see somewhere along the lines of 20-30ms from the CPE to the DSLAM. When not using interleaved, I have seen 5-10ms between the CPE and DSLAM. Ofcourse, cable distances play into this as well I'm sure. And different technologies (SHDSL) will have different latency figures. -- Andy
Re: Acceptable DSL Speeds (ms based)
- Original Message - From: Barney Wolff [EMAIL PROTECTED] On Thu, May 05, 2005 at 10:59:04AM +0800, Ong Beng Hui wrote: When I switched from 1600/384 to 3000/768 dsl, download speed went up to very nearly the promised 3Mbps, but latency to the first hop went from 14 ms to 26 ms. Is there a reason for that ? that, latency goes up when bandwidth goes up for your case ? I assume it had to do with different settings for interleaving on the DSLAM, as some prior poster mentioned. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like. Interleaved adds some error correction, allowing the connection to be more resistant to interference (noisy lines), but at the expense of latency. Fast-path is the other way data is sent, which obviously, is much faster, I've personally seen less ~10ms for a loop around 11000ft. -- Andy
RE: Cisco to merge with Nabisco
You mean SNACK engineers, right? - Andy Date: Fri, 1 Apr 2005 13:35:11 -0600 From: Church, Chuck [EMAIL PROTECTED] To: Bill Nash [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: RE: Cisco to merge with Nabisco Yes. According to the Keebler elves, who now are 3rd level TAC engineers... --- Andy Grosser, CCNP, CCDA andy at meniscus dot org ---
Re: IRC Bot list (cross posting)
On Thu, Feb 10, 2005 at 12:09:48AM -0800, william(at)elan.net wrote: However since there was shown enough of the interest from people on nanog@ to help in killing bots and knowing about it, may I suggest that people who are doing the tracking setup the following: For the DNSBLs that list things like proxies, most of them also offer to sent notifications to AS or netblock contacts, so if you're interested in that then contact them too. pgpcRdnOI3nE7.pgp Description: PGP signature
Re: Time to check the rate limits on your mail servers
Nils Ketelsen wrote: Only thing that puzzles me is, why it took spammers so long to go in this direction. Nils I am still confused why people think this is new behavior. The sky is not falling (regardles of how many stories CNET publishes claiming it is), nor should this really be relevant to how I operate my network. This is purely a systems administration issue to tackle, which I believe is beyond the scope of this list. I do find it amazing that we cannot go more than a month without raising some spam-related thread and beating it to death. Andy
Re: NYTimes: Purloined Domain Name Is an Unsolved Mystery
Hank, I copied/pasted that URL from your e-mail, and it asked for a user/pass. When I searched Google, it gave me the same link, but when I clicked on it, it worked. Looks like NYT allow clickthrough from Google only. Andy On Wed, 19 Jan 2005, Hank Nussbacher wrote: On Tue, 18 Jan 2005, John Palmer wrote: I never post links that require subscription. This particular NYTimes URL works w/o registration. Works for me at least and I am not a subscriber. YMMV. -Hank Please do not post links to sites that require registration. Some people dont want to let marketers have their information and its rude to send links that dont work anonymously. - Original Message - From: Hank Nussbacher [EMAIL PROTECTED] To: nanog@merit.edu Sent: Tuesday, January 18, 2005 9:33 Subject: NYTimes: Purloined Domain Name Is an Unsolved Mystery http://www.nytimes.com/2005/01/18/technology/18domain.html -Hank +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
Re: Network Monitoring System - Recommendations?
On Thu, 28 Oct 2004, Charlie Khanna - NextWeb wrote: Hi - I was interested in finding out what software applications other ISPs are using for network monitoring? For example: 1) Overall network health - uptime reports http://www.nagios.org 2) Backup router config automatically http://www.shrubbery.net/rancid/ 3) Bandwidth reporting (or integration with an MRTG-type app) http://cricket.sourceforge.net/ 4) SNMP trap support (BGP/OSPF session drops - emails out) http://www.snmptt.org/ http://www.nagios.org 5) Database back end (port info into or over to other apps) I'm just looking for something well rounded for a small ISP. I've heard about OpenNMS and other apps but I'd like to get everyone's feedback. Thanks! Nothing all in one place, that I'm aware of. But with a little work, you could probably integrate it all into nagios. After all, you can make the host names or descriptions URLs that link to bandwidth and error graphs or other tools. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: why upload with adsl is faster than 100M ethernet ?
On Fri, 15 Oct 2004, Iljitsch van Beijnum wrote: However, the cause can also be rate limiting. Rate limiting is deadly for TCP performance so it shouldn't be used on TCP traffic. Hmm...I'd have to disagree. Are you perhaps assuming a certain threshold (100mbps, for instance)? I use rate limiting for some of my customers, and when correctly configured (you _must_ use the right burst sizes), you will get the exact rate specified, TCP or not. However, I've never had to rate-limit above 30mbps, so perhaps you have some experience that I don't. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: why upload with adsl is faster than 100M ethernet ?
On Fri, 15 Oct 2004, Alex Bligh wrote: I can support what Iljisch said. In a former life I ran extensive tests on the effect of CAR on TCP (no longer have the data to publish, but it's out there), and it's just plain broken - if your purpose is to simulate a lower amount of bandwidth with or without a burst. In a nutshell the problem is that the sliding window algorithm expects RTT to gradually increase with congestion, to find the optimum window size - the increased RTT stops the window growing. With rate-limiting that does not also shape (i.e. buffer the packets - this is true of token based systems such as CAR), the window size just keeps on expanding in leaps and bounds until there's a packet drop, whereupon it shrinks right down, rinse and repeat, so you get a sawtooth effect. Adding burst sizes just moves the problem around - you don't see the effect until later in the stream - because the excess of traffic over committed rate just sits there using up the burst and there is no signal to slow down; it /somewhat/ hides the effect in a lab if you are using short single requests (e.g. short HTTP) but not if you aggregate multiple parallel requests. If you want to simulate lower bandwidths through a high bandwidth interface, and you want to be TCP friendly, you HAVE to use shaping. That means buffering (delaying) packets, and at gigabit line rates, with multiple clients, you need BIG buffers (but set sensible buffer limits per client). You can reasonably trivially do the above test with ftp, ethereal, a bit of perl, and something to graph sequence numbers and throughput. In the testing I have done, it works great. You get the bandwidth configured. Our customers would be outside with burning stakes and pitchforks otherwise. The vast majority of people who complain about CAR have horribly misconfigured limits. If your burst size is off, you get nothing resembling the configured throughput. Yes, there is sawtoothing, but the excessive burst accomodates that to a large degree, allowing for an overall correct transfer rate. The time spent in slow-start is accomodated by dropping packets later than you normally would, resulting in a correct rate over time. The sawtoothing doesn't really matter if you're selling a 512kbps ethernet connection, and the customer can always get both 512kbps in a single stream and aggregated across multiple streams. If the desire is to provide a simulated circuit with x bandwidth, CAR does a great job, IFF you correctly size the burst: 1.5x/8 for the normal burst, 3x/8 for the max burst. The aggregate rate of the transfer is x in all the testing I've done. How can you ask for more than the configured line rate? In my testing, I noticed a pronounced saw-tooth effect with incorrectly configured bursts, but with correctly configured bursts, the saw-toothing affect did not prevent delivery of the configured throughput. This holds up with multiple concurrent transfers. The customer gets whatever bandwidth is available under their cap, and when I look at their bandwidth graphs, they have the ability to saturate their bandwidth to 100% of the configured rate. Works for me and mine. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: SkyCache/Cidera replacement?
On Mon, 20 Sep 2004, Rick Chavez wrote: Does anyone know of one? Hell, has anyone even considered starting one? For that matter, would anyone be interested or willing to pay for their services if someone did or is bandwidth so cheap that it's just not needed anymore? People still use usenet? ;) Seriously though, you'd have to be an awfully large organization for outsourced news to not be a slam dunk financially. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Mega DOS tomorrow?
So, slashdot is linking to some news sites that are reporting that Aleksandr Gostev from Kapersky Labs in Russia has predicted that a large chunk of the net will be shut down tomorrow. I thought the ISC comment was pretty funny: http://isc.sans.org/diary.php -- e-Jihad Begins Thursday, Internet Predicted to Melt Down by Mid-day You should probably starting backing up that gig of gmail to local storage. According to a Russian news site, Kaspersky Labs states that terrorists will launch attacks which will paralyze the Internet this Thursday. This tragically coincides with two weeks of script kiddie attacks (which were scheduled to begin this past Sunday) aimed at disrupting the Republican national convention. In addition, many college students are back on campus this week, which provides the e-terrorists and i-subversives with a veritable candyland of insecure boxes on big pipes. Faced with this triple threat, our beloved Internet will surely fall. The ISC would like to go out on a limb and predict that the Internet will not vaporize into a cloud of nothingness this Thursday, but if it does, it's been our pleasure to help stave off its inevitable annihilation this long. -- Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Re: Weird GigE Media Converter Behavior
On Tue, 24 Aug 2004, J. Oquendo wrote: Hello all, wondering if anyone has seen or experienced this same problem. Currently deploying an OC12 on a campus network and am using Netgear media ^^^ converters. Set up the lines and had lit fiber to the building I needed it Say no more. Not that I have any experience at all with an OC12 GigE media converter, I certainly wouldn't trust anything made by netgear. I refuse to buy anything made by netgear, after having had three different products not have basic functionality (like the ability to turn of NAT, for instance, or the ability to go back out to the internet when connected via VPN). And after having talked to their support department, you could not PAY me to sell YOU a netgear product, under ANY circumstances. You want netgear, you're not buying it from us (and we'll sell just about anything to just about anybody). Perhaps a product made by a company that makes the slightest effort to put out a quality product would serve you better. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
