Re: new clueless security softwhere
LOL On 11/17/12 3:42 AM, Randy Bush wrote: new crapware on the misconfigured loose. did we not just have a thread on frags? how long will it take the amateurs to learn about port 53? sigh randy Date: Sat, 17 Nov 2012 16:15:23 +0800 To: ra...@psg.com From: Security Ops Center secur...@communilink.net Subject: Network abuse from attacker: 147.28.0.39 to 203.124.10.107(ID# 86329) Message-ID: dda9f857e37eff2f1c53e3d60dcb12f6@localhost.localdomain Dear Sir, We detected an attack/abuse to our network that come from an IP owned by your ASN. The IP of your network [ 147.28.0.39 ] was infected and sending attack to our network [ 203.124.10.107 ]. The following is the logs that you can take proper actions. [TimeZone: GMT +8] == 2012-11-17 20:21:30 Fragmented traffic! From 147.28.0.39:53 to 203.124.9.11:56958, 2012-11-17 20:37:56 Fragmented traffic! From 147.28.0.39:53 to 203.124.10.223:39843, 2012-11-17 20:37:56 Fragmented traffic! From 147.28.0.39:3600 to 203.124.10.223:20678, ... hundreds of more lines == Should you have any questions, please call us at +(852) 29980833. Please include the ticket number, ID#86329, in all communications on this issue. Thank you, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Ops Center - CommuniLink Internet Limited. secur...@communilink.net http://www.communilink.net 852.2998.0833 (voice)852.2998.0899 (fax) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Re: Invitation to connect on LinkedIn
I second that. Sent from my HTC on the Now Network from Sprint! - Reply message - From: Brielle Bruns br...@2mbit.com Date: Tue, Nov 16, 2010 19:24 Subject: Invitation to connect on LinkedIn To: nanog@nanog.org On 11/16/10 5:22 PM, Celso Vianna via LinkedIn wrote: LinkedIn Celso Vianna requested to add you as a connection on LinkedIn: -- O_o Dude, seriously, you've got to be kidding me. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Online games stealing your bandwidth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/28/10 3:01 PM, Warren Bailey wrote: Jack, Apologies, I did not realize that you guys were doing so much. Please don't take my last email as anything which was intended to question or insult you guys. Up here (Alaska) we have about 100,000 cable subscribers along with mixed Fiber/DSL/POTS access and nearly 50,000 cellular customers with high speed data around our Metro network. I am an RF Engineer, however the network I run is IP based (satellite) and I run in the neighborhood of 250mbps forward and 30mbps return to most of the State of Alaska. I find that anywhere from 40-65% of our total traffic is questionable, which is why I was asking about an ISP who liked their users downloading torrents. It is very difficult to gauge a users behavior if they are on an all out downloading binge over a weekend. Normally, a user logs in and does what they need to in a relatively short amount of time (hours). In the case of most providers, we oversubscribe our resources and have found this model is beginning to not apply to user behavior changes. Long gone are the days of the user turning off their computers, and our customer base (rural Alaska) have few things to do besides use the internet. This has made a perfect storm of sorts, as we are now seeing most of our users utilizing 70%+ of their allocated (purchased) bandwidth 24 hours a day. The vast majority of the night use is gaming, and bit torrent. It makes things much more complicated when trying to give an experience to people.. //warren -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, September 28, 2010 10:26 AM To: Warren Bailey Cc: Richard Barnes; NANOG Subject: Re: Online games stealing your bandwidth On 9/28/2010 1:00 PM, Warren Bailey wrote: Jack, Forgive me if I'm mistaken, but looking at your website - do you only offer dial up services? This could be the background for a statement like a proper ISP doesn't encourage any type of traffic. We have a couple of OC-192 running to Seattle, so certain types of traffic can make a good day turn very badly without some traffic management. BrightNet itself has ILEC's as customers. We're a turnkey glue for ILECs nearby. Among other things, I provide engineering support and advise for each ILEC. Each has their own levels of service, management, and technologies deployed including wireless, cellular, DSL, FTTH, and cable. I'm currently running around 1.2gbit between us and 4 NSP transits with 3gbit available. Some of the ILECs have additional load shifting with other transits. I estimate the need to go 10Gig ring or split transit in less than 5 years at current growth rates, and the largest problem we've run into is getting infrastructure to handle gig-e speeds out of rural ILECs for the 100+ mile longhauls. I've had issues with gig-e connectivity just getting out of OKC to enough NSP transits and it will become more difficult/expensive when we do hit 10G. As it currently stands, we usually have no problems with event spikes, though we sometimes have to tweek the traffic paths depending on how the NSPs do. The largest issues have always been the last mile. As we resolve last mile costs (which dropping 100% fiber in a rural area today doesn't have the safety nets and guarantees that were provided when copper was dropped in), we'll then have to tackle the longhaul connectivity issues, but hopefully the cost to handle that will drop as well. Jack What is keeping your company from buying more bandwidth? I find the excuse of over subscription to be a fail. If that's your companies business model then it should not be whining when people are using what you sell them. Provision bandwidth accordingly and stop being cheap and squeezing every last dime from the end user for bandwidth that can be had for less than the price of a burger in some places. Manny -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMokBqAAoJEOcnyWxdB1IrGBMH/RCg7zy3L171hwGuilZHRWyA 9B4k+DoTF0Cp8Gt30zamKly90BERKiilryyhxSpAtepUa4wQs4bOGwk5HKx06jkF YJokQpqmNNmY4MU/bwWtUpkjrQjYT6Dt8967iEA3SWBbqdUhRdyejFLaZbDoV43u 61NzEU/JGdxnRvO/MkleP95/+XPCWuQy0EIDAuwlwcWIzr/i9ra9nD5Nf6x9AE/u XTJoTLwY6y2xP93gTBp12MBmzf07AkPxwvpMAbcYIu+94O/twbpWysuceC3EH2bW cMKLPAIROxZaropgSSJYSu8hFNPWlODkOD7MHiY8Ilcv6B4v7XEa6QpCd/lfDxE= =ZPwF -END PGP SIGNATURE-
Re: Raised floor, Solid floor... or carpet?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/1/10 1:15 PM, Brandon Kim wrote: hahaha I fell for it HOOK LINE AND SINKER!!! DAMN YOU GUYS Date: Thu, 1 Apr 2010 12:43:21 -0400 Subject: Re: Raised floor, Solid floor... or carpet? From: j...@crepinc.com To: michael.holst...@csuohio.edu CC: nanog@nanog.org Nice to see smaller companies take the time to put up a good April fool's joke as well. Wow I got totally owned. Retreating to my corner, -Jack Carrozzo On Thu, Apr 1, 2010 at 12:36 PM, Michael Holstein michael.holst...@csuohio.edu wrote: Adding to the recent debate over raised v's solid floor, seem there's another option that wasn't discussed... http://www.iphouse.com/ Nice to see smaller companies take the time to put up a good April fool's joke as well. Its an april fools joke for them. Dare I say that I have actually seen DCs with carpeting. My jaw dropped but it does exist. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLtN/cAAoJEOcnyWxdB1IrBoQH/1gTCRTcqCzsEVLxkxvuRKrb hdMT2YdoEe6L2iw1mbq4Gie1OrPIQdS5WwyraVqhlyL8BfSJ64bxWXj+FnqvK7fd 4ZTrbtWbS9yaPm/IO2CrD6FsVzrAH31czYQkpliJpJ9/V3PpfXFz+Bflq9STYhQR /bAGFbivqhWooGV+pL2dYjej84kTaGfmPxhic8nuiNgGY8b57lusutTtx7CXbsUK 9dQk4o2GUHAYtmQdXe4p6/MyWobsfUxOlEz8O1zGciN8tEBasbf0Vp/QodSUCVAi 3HnDeBOd9UwJO4qViGkZUiUvvMi5V9IcloHOIc7TC6ky9bRDuxedyQrSB76vlKk= =maX4 -END PGP SIGNATURE-
Re: D/DoS mitigation hardware/software needed.
From someone who mostly lerks but has been in network engineering operations biz for 17 years, the only OS that seems to always keel over under a ddos and need a firewall is windows. Linux in its current incarnation can handle a substantially larger attack before needing mitigation by firewall type device. So in the end I believe its the environment dictates the use of products unless you have aformentioned windows os which for me has always necessitated a firewall. Manolo Sent from my BlackBerry -Original Message- From: Roger Marquis marq...@roble.com Date: Sun, 10 Jan 2010 08:55:13 To: nanog@nanog.org Subject: Re: D/DoS mitigation hardware/software needed. Dobbins, Roland wrote: My employer's products don't compete with firewalls, they *protect* them; if anything, it's in my pecuniary interest to *encourage* firewall deployments, so said firewalls will fall down and need protection, heh. Nobody's disputing that Roland, or the fact that different specialized appliances will protect against different perimeter attacks. The only thing you've said that is being disputed is the the claim that a firewall under a DDoS type of attack will fail before a server under the same type of attack. I question this claim for several reasons. * because it doesn't correlate with my 22 years of experience in systems administration and 14 years in netops (including Yahoo netsecops where I did use IXIAs to compile stats on FreeBSD and Linux packet filtering), * it doesn't correlate with experience in large networks with multiple geographically disperse data centers where we did use Arbor, Cisco and Juniper equipment, * it doesn't correlate with server and firewall hardware and software designs, and last but not least, * because you have shown no objective evidence to support the claim. I did this kind of testing when I worked for the largest manufacturer of firewalls in the world Where then, can we find the results of your testing? Here's the thing; you're simply mistaken, and you hurl insults instead of listening to the multiple people on this thread who have vastly more large-scale Internet experience than you do and who concur with these prescriptions. Nobody has hurled insults in this thread other than yourself Roland. Shame on you for such disreputable tactics. To make the case you need more than repeated dismissal of requests for evidence and repeated unsupported claims of vast experience with failing servers and firewalls. We just need some actual statistics. Roger Marquis
Google DNS admin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could someone from google that can assist with a dns issue that originates from their servers please contact me offlist? I have tried normal channels listed on their Arin contact list to no avail. Manolo -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJKnttbAAoJEOcnyWxdB1IrV8MH/3uru0O9tYH4c1jQEZkpbqhP ZoqGMJm7NSSoH8KUKjVN1Vwze1Hp2JbV6sD5LUL7Au9z9+5DZ5VXoXkfIbfxo48f 63iOsRtPLxBim7o7zxAUOeZbI2+RflbwlIGXERrI12oufmTXEKD/9JioiVKLzsV7 +RtvJ0oPjOBXnqR2axs+zsrRygmBZKNDFavwhNsjZ+cXMZrX0XkTEhbWBv7qBdjU +Q7W7MHfURjay7pO0KW8O5kpCUCetS7Gy9Puxy0qEz4oKIbt9zeEneM6vlPs+EII 45+xheAeDzMf3gKixc+YJYyV1JDXgKQdhdLuddUz8mRX7S0JtO4FX7YP7wEPWZw= =pfuQ -END PGP SIGNATURE-
Re: Issues with Gmail
Same here. Complete outage Nathan Anderson wrote: The minute I saw your question, I tabbed over to an open session, and sure enough...
Re: Cogent input
Stephen Kratzer wrote: Should have said And, they have no plans to deploy IPv6 in the immediate future. On Thursday 11 June 2009 10:33:25 Stephen Kratzer wrote: We've only recently started using Cogent transit, but it's been stable since its introduction 6 months ago. Turn-up was a bit rocky since we never received engineering details, and engineering was atypical in that two eBGP sessions were established, one just to advertise loopbacks, and another for the actual feed. The biggest issue we have with them is that they don't allow deaggregation. If you've been allocated a prefix of length yy, they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes deaggregation is necessary or desirable even if only temporarily. And, they have no plans to support IPv6. Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment. Stephen Kratzer Network Engineer CTI Networks, Inc. On Thursday 11 June 2009 09:46:45 Justin Shore wrote: I'm in search of some information about Cogent, it's past, present and future. I've heard bits and pieces about Cogent's past over the years but by no means have I actively been keeping up. I'm aware of some (regular?) depeering issues. The NANOG archives have given me some additional insight into that (recurring?) problem. The reasoning behind the depeering events is a bit fuzzy though. I would be interested in people's opinion on whether or not they should be consider for upstream service based on this particular issue. Are there any reasonable mitigation measures available to Cogent downstreams if (when?) Cogent were to be depeered again? My understanding is that at least on previous depeering occasion, the depeering partner simply null-routed all prefixes being received via Cogent, creating a blackhole essentially. I also recall reading that this meant that prefixes being advertised and received by the depeering partner from other peers would still end up in the blackhole. The only solution I would see to this problem would be to shut down the BGP session with Cogent and rely on a 2nd upstream. Are there any other possible steps for mitigation in a depeering event? I also know that their bandwidth is extremely cheap. This of course creates an issue for technical folks when trying to justify other upstream options that cost significantly more but also don't have a damaging history of getting depeered. Does Cogent still have an issue with depeering? Are there any reasonable mitigation measures or should a downstream customer do any thing in particular to ready themselves for a depeering event? Does their low cost outweigh the risks? What are the specific risks? Thanks Justin In Europe they have been good and stable most of the time. In the US well, they are cogent and I have so many bad experiences with them here I cannot in all honestly recommend them. But if your looking for cheap bandwidth to complement another provider its not an unreasonable thing to do as they price point is competitive. Manolo
Re: Important New Requirement for IPv4 Requests
Joe Greco wrote: Forwarded message: Subject: Important New Requirement for IPv4 Requests From: ARIN Registration Services do-not-re...@arin.net Hello, With the approaching depletion of the IPv4 address free pool, the ARIN Board of Trustees has directed ARIN staff to take additional steps to ensure the legitimacy of all IPv4 address space requests. Beginning 18 May 2009, ARIN will require that all applications for IPv4 address space include an attestation of accuracy from an officer of the organization. For more information on this requirement, please see: https://www.arin.net/resources/agreements/officer_attest.html Whenever a request for IPv4 resources is received, ARIN will ask in its initial reply for the name and contact information of an officer of the organization who will be able to attest to the validity of the information provided to ARIN. At the point a request is ready to be approved, ARIN will send a summary of the request (via e-mail) to the officer with a cc: to the requesting POC (Tech or Admin) and ask the officer to attest to the validity of the information provided to ARIN. The summary will provide a brief overview of the request and an explanation of the required attestation. ARIN will include the original request template and any other relevant information the requestor provided. Once ARIN receives the attestation from the officer, the request can be approved. Attestation may also be provided via fax or postal mail. For further assistance, contact ARIN's Registration Services Help Desk via e-mail to hostmas...@arin.net or telephone at +1.703.227.0660. Let me see if I can understand this. We're running out of IPv4 space. Knowing that blatant lying about IP space justifications has been an ongoing game in the community, ARIN has decided to do something about it. So now they're going to require an attestation. Which means that they are going to require an officer to attest to the validity of the information. So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? ... JG So I wonder if this applies to some of the players who have recently gotten a /19 for dubious purposes and are so large that an officer of the company may be 1500 miles away. It's a sad state of affairs. Are they going to hold the officer liable if the request is not legit? Manny
Fiberlight
All, At the company I work for we are looking to using Fiberlight in south Florida (Miami, Ft. Lauderdale). Any one here use them and can share some pros and cons? Thanks, Manolo
Re: AS 54271
This ip space is from Bahrain 89.148.0.0/19 but some how has ended up in Hungary from an unknown owner. Definitely looks suspicious in my book. Manolo Joel Jaeggli wrote: those prefixes all have ripe route object with origin AS 20922 all the routes I see for a given prefix look like the following: 2914 1299 12301 8696 20922 54271 129.250.0.171 from 129.250.0.171 (129.250.0.12) Origin IGP, metric 1, localpref 100, valid, external Community: 2914:420 2914:2000 2914:3000 65504:1299 2497 3257 12301 8696 20922 54271 202.232.0.2 from 202.232.0.2 (202.232.0.2) Origin IGP, localpref 100, valid, external 7660 2516 3257 12301 8696 20922 54271 203.181.248.168 from 203.181.248.168 (203.181.248.168) Origin IGP, localpref 100, valid, external Community: 2516:1030 etc... Marshall Eubanks wrote: As of this morning, I am seeing BGP from AS 54271 * 62.77.196.0/22 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 62.77.254.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 81.17.184.0/22 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 81.17.190.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 82.131.196.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 82.131.198.0/24 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 82.131.248.0/21 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.64.0/22 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.70.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.72.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.78.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.82.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.96.0/23 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i * 89.148.99.0/24 38.101.161.1166991 0 174 3549 3549 3549 12301 8696 20922 54271 i This ASN has not been assigned to any RIR. Is this a bogon, or does anyone know of a legitimate reason for this ? Regards Marshall
Comcast peering contacts
All, I have misplaced the website that lists the contacts for bgp peering with a provider at a NAP. Does anyone have this link handy or have a email for requesting direct peering with comcast? Thanks, Manolo
Re: [Nanog] Cogent Router dropping packets
Well it had sounded like I was in the minority and should keep my mouth shut. But here goes. On several occasions the peer that would advertise our routes would drop and with that the peer with the full bgp tables would drop as well. This happened for months on end. They tried blaming our 6500, our fiber provider, our IOS version, no conclusive findings where ever found that it was our problem. After some testing at the local Cogent office by both Cogent and myself, Cogent decided that they could make a product that would allow us too one have only one peer and two to connect directly to the GSR and not through a small catalyst. Low and behold things worked well for some time after that. This all happened while we had 3 other providers on the same router with no issues at all. We moved gbics, ports etc around to make sure it was not some odd ASIC or throughput issue with the 6500. Hope this answers the question. Manolo Paul Wall wrote: On Mon, Apr 21, 2008 at 4:02 PM, manolo [EMAIL PROTECTED] wrote: I do have to say that the PSI net side of cogent is very good. We use them in Europe without many issues. I stay far away from the legacy cogent network in US. You still haven't explained the failure modes you've experienced as a result of cogent's A/B peer configuration, only fronted. Inquiring minds would like to know! ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [Nanog] Cogent Router dropping packets
Well it also was the total arrogance on the part of Cogent engineering and management taking zero responsibility and pushing it back everytime valid issue or not. You had to be there. But everyone has a different opinion, my opinion is set regardless of what cogent tries to sell me now. Manolo Joe Greco wrote: Well it had sounded like I was in the minority and should keep my mouth shut. But here goes. On several occasions the peer that would advertise our routes would drop and with that the peer with the full bgp tables would drop as well. This happened for months on end. They tried blaming our 6500, our fiber provider, our IOS version, no conclusive findings where ever found that it was our problem. After some testing at the local Cogent office by both Cogent and myself, Cogent decided that they could make a product that would allow us too one have only one peer and two to connect directly to the GSR and not through a small catalyst. Low and behold things worked well for some time after that. This all happened while we had 3 other providers on the same router with no issues at all. We moved gbics, ports etc around to make sure it was not some odd ASIC or throughput issue with the 6500. Perhaps you haven't considered this, but did it ever occur to you that Cogent probably had the same situation? They had a router with a bunch of other customers on it, no reported problems, and you were the oddball reporting significant issues? Quite frankly, your own description does not support this as being a problem inherent to the peerA/peerB setup. You indicate that the peer advertising your routes would drop. The peer with the full BGP tables would then drop as well. Well, quite frankly, that makes complete sense. The peer advertising your routes also advertises to you the route to get to the multihop peer, which you need in order to be able to talk to that. Therefore, if the directly connected BGP goes away for any reason, the multihop is likely to go away too. However, given the exact same hardware minus the multihop, your direct BGP was still dropping. So had they been able to send you a full table from the aggregation router, the same thing probably would have happened. This sounds more like flaky hardware, dirty optics, or a bad cable (or several of the above). Given that, it actually seems quite reasonable to me to guess that it could have been your 6500, your fiber provider, or your IOS version that was introducing some problem. Anyone who has done any reasonable amount of work in this business will have seen all three, and many of the people here will say that the 6500 is a bit flaky and touchy when pushed into service as a real router (while simultaneously using them in their networks as such, heh, since nothing else really touches the price per port), so Cogent's suggestion that it was a problem on your side may have been based on bad experiences with other customer 6500's. However, it is also likely that it was some other mundane problem, or a problem with the same items on Cogent's side. I would consider it a shame that Cogent didn't work more closely with you to track down the specific issue, because most of the time, these things can be isolated and eliminated, rather than being potentially left around to mess up someone in the future (think: bad port). ... JG ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [Nanog] Cogent Router dropping packets
I do have to say that the PSI net side of cogent is very good. We use them in Europe without many issues. I stay far away from the legacy cogent network in US. Manolo Joe Greco wrote: Joe Greco wrote: For those unfamiliar, Cogent has a system where you set up an EBGP peering with the Cogent router you're connected to, for the purposes of announcing your routes into Cogent. However, these are typically smaller, aggregation class routers, and do not handle full tables - so you don't get your routes from that router. To get a full table FROM Cogent, you need to set up an EBGP multihop session with them, to their nearest full-table router. I believe they actually do all their BGP connections in that manner. Depends on the service you purchase. Fast Ethernet seems to be delivered as eBGP-multihop (the first hop is just a L3 switch), however DS-3 is handled as a single BGP session. I'm not sure if GigE or SONET services are handled as multihop or not. GigE is, though perhaps not in all cases (we had a client buying x00Mbps delivered over gigE, which was definitely multihop). Probably all depends what hardware they have at each POP In part, I'm sure. There is also a certain benefit to having consistency throughout your network, and it sometimes struck me that many of the folks working for Cogent had a bit more than average difficulty dealing with the unusual situation. This is not meant harshly, btw. Generally I like the Cogent folks, but they (and their products) have their faults, just as any of the competition does. It may also help to remember that there's legacy Cogent and then there's PSI/etc. Perhaps there are some differences as a result. The more things you can do using the same template, the less difficult it is to support. On the flip side, the less flexible you are ... ... JG ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [Nanog] Cogent Router dropping packets
Some things just never change at cogent.. fought them for months way back when to get me off their infamous 2 bgp peer setup after many an outage due to this setup, they finally put us on a single bgp session but it took forever. Lets just say cogent didn't last long at the company I worked for. You get what you pay for Manolo Martin Hannigan wrote: It is Saturday after all. We generally are all aware of Cogents 'status'. You're not having a unique experience. Martin On 4/18/08, Mike Fedyk [EMAIL PROTECTED] wrote: (Crossed Fingers) Cogent's network seems OK, for now. I've received several responses asking for details on how I would avoid Cogent. It looks like getting a connection to the ATT network will allow us to serve our customers on their DSLS and use their direct peering to the Time Warner network for our customers with cable Internet. If anyone has any ideas on how this will work, please let me know. For instance, do most networks prefer to keep packets on their network until closest to the end point or might a network just send the traffic through cogent in another part of their network a few hops away? -Original Message- From: Mike Fedyk Sent: Thursday, April 17, 2008 2:59 PM To: [EMAIL PROTECTED] Subject: RE: Cogent Router dropping packets I spoke too soon: Host Loss% Snt Last Avg Best Wrst StDev 1. adsl-63-194-XXX-XXX.dsl.lsan03.pacbell.net 0.0% 1099.2 19.2 8.4 57.9 11.0 2. dist3-vlan60.irvnca.sbcglobal.net 0.9% 1098.4 16.7 8.3 45.6 9.6 3. bb1-p6-7.emhril.ameritech.net 0.0% 1098.6 36.3 8.5 256.6 44.2 4. ex2-p14-0.eqlaca.sbcglobal.net 0.0% 109 10.3 39.4 9.3 209.3 46.2 5. te8-1.mpd01.lax05.atlas.cogentco.com0.0% 108 32.4 34.3 9.3 238.6 45.1 6. vl3491.ccr02.lax01.atlas.cogentco.com 3.7% 108 17.0 23.4 12.9 98.9 13.4 7. te3-4.ccr01.lax04.atlas.cogentco.com 17.6% 108 39.1 28.8 16.4 198.9 22.1 8. vl3805.na21.b002695-2.lax04.atlas.cogentco.com 12.0% 108 34.1 27.6 17.0 68.7 11.2 9. PAETEC_Communications_Inc.demarc.cogentco.com 10.2% 108 22.4 35.3 17.0 168.7 27.8 10. gi-4-0-1-3.core01.lsajca01.paetec.net 18.5% 108 21.2 34.2 21.0 188.6 20.6 11. po-5-0-0.core01.anhmca01.paetec.net10.3% 108 35.7 33.9 20.5 232.7 23.9 12. gi-3-0-0.edge03.anhmca01.paetec.net13.0% 108 21.0 31.6 20.2 157.9 16.6 13. 74.10.xxx.xxx 11.1% 108 25.7 33.9 25.2 55.2 8.9 14. 74.10.xxx.xxx 15.7% 108 26.7 35.7 25.0 70.8 11.7 -Original Message- From: Mike Fedyk Sent: Thursday, April 17, 2008 2:15 PM To: Ryan Harden Cc: [EMAIL PROTECTED] Subject: RE: Cogent Router dropping packets Thank you, the issue seems to be fixed now at Cogent. ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: NANOG 40 agenda posted
william(at)elan.net wrote: On Sun, 27 May 2007, Chris L. Morrow wrote: So, I think I can sum up your reply by saying that your suggestion is to provide a lesser service than we do now (v4 NAT, proxies, etc. sound to me like lesser service), during the transition period. I think you also missed the suggestion that sending out CPE with DD-wrt was a 'good idea'. Honestly DD-wrt/open-wrt are nice solutions for testing or for people willing to fiddle, they are not a good solution for 'grandma'. My parents and brother both have linksys with dd-wrt that I put up. I don't maintain it at all and it just works. No, they are not using v6, but if it was available I don't anticipate any problems as their system os at home all support it now. I am usually just lurk around here but I had to say something. Working for a service provider that has tried to make an entire product around IPV6 it does not work. Since none of the big players (google, yahoo, etc...) have started to atleast provide some IPV6 content the little guys are not going to jump on the bandwagon. Yes it's the chicken or the egg thing but its economics not logic that will get people to move to IPV6. Manolo
