Re: Capture problems with Intel quad cards?
Hello John , On Sun, 15 Feb 2009, John A. Kilpatrick wrote: Has anyone had problems with using current Intel quad ethernet cards for packet capture? As a proof-of-concept test we bought an Intel PWLA8494GT and hooked it up to some Network Critical taps. There was a very strange issue with corruption of the captured packets. The *only* issue (but it's a big one) is that the source IP on some captured packets is munged. As far as I can tell that's the *only* issue with the packet captures - no other data is corrupted. Oh, and to rule out other issues: 1. Corruption seen both when using network taps and when using a port span/mirror (so it's not the taps). 2. Corruption *not* seen using the on-board broadcom nics of the test host (so it's not the box). So I'm pretty sure we narrowed it down to the card. We tried the card in an indentical host and saw the same problems. I thought it might be a driver issue - I tried both gentoo and FreeBSD (not sure how different the drivers are) just to see if it mattered at all and it didn't. Much googling didn't show this to be a known issue - just wondering if anyone else has seen it? Other recommendations welcome - the next step is, I suppose, a broadcom-based PCI-X card. (I've got some old pizza boxes I'm trying to repurpose as network probes.) Thanks, John Does this device provide 4 unique mac-addresses ? Reason for the question is some old(I mean old) multiport cards presented a single mac-address because the were driven by a single 'Switch chip' . Just a thought . I've been looking a the Intel site gandering over the overview have not seen anything to relieve my concern . But one Hopes they have learned not to create themselves such a problem . Hth , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+
Re: 97.128.0.0/9 allocation to verizon wireless
I have trouble understanding why an ARIN record for a network regularly receiving new, out-sized IPv4 allocations on the order of millions of OrgName:Cellco Partnership DBA Verizon Wireless CIDR: 97.128.0.0/9 Comment:Verizon Wireless currently has 44.3 Million Comment:subscribers with 2.097 Million IP addresses allocated. RegDate:2008-04-14 If they have immediately allocated 2.097 million out of 8.388 million, then they have satisfied the 25% immediate utilization requirement. In fact, 2.097 million is exactly how many they would need immediate use for in order to justify an allocation of 8 million IPs according to ARIN policy. I expect the 2.097 million figure applies only to this particular range, this comment in whois does not indicate that Verizon has _only_ assigned that many across all its various ranges; I would fully expect they have massively more IPs in use. I would expect ARIN would have followed policy, and so Verizon had to show to ARIN their well-founded projection that within one year, at least 50% of the new assignment would be allocated. And also that they met the additional requirements for ISPs; 80% utilization over all previous allocations, and also 80% of their most recent allocation. -- -Jimmy
Re: v6 DSL / Cable modems
DHCP items are end system considerations, not routing network considerations. The network operations staff and router configuration engineers do not generally concern themselves with end systems. End systems generally are managed quite independently from the routing network. And, they are more subject to the vagaries of day to day business variability. Note the one place in the quoted message below. The only overlap is broadcast forwarding for DHCP initiation. Besides, configuration control is hard enough for router engineers without adding the burden of changing end system requirements. Adding the forwarding entries is almost too much already! ;) So, for routing network operators to denigrate DHCP is probably due to lack of consideration of the end user system requirements. And those who denigrate DHCP and say just hard code it make end system management that much more difficult. I still conclude that DHCP is a useful tool for both IPv4 and IPv6 systems. Cutler On Feb 6, 2009, at 12:22 PM, sth...@nethelp.no wrote: The problem is that DHCP seemed like a good idea at the time but it doesn't make any sense today. We know that parsing complex binary data formats is asking for security problems. And parsing complex text data structures is better? What we need is a simple, fast, efficient way to distribute the basic information that a host needs to start sending and receiving packets and a pointer to a place where additional location dependent configuration information can be found. That would be: address +prefix, gateway and (arguably) DNS and then something like a URL for a server that has the config info. The system and applications can then load information from the config server over HTTP in XML format or some such. No, this information must be available in *one* place. It's called a DHCP server. As an operator, this is clearly what I want, both for IPv4 and IPv6. Steinar Haug, Nethelp consulting, sth...@nethelp.no James R. Cutler james.cut...@consultant.com
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Feb 5, 2009, at 5:42 PM, Iljitsch van Beijnum wrote: ...An IPv4 DHCP server gives me five things: ...DNS addresses and a domain... == Actually, lots more than five. E.g., NTP servers, preferred WINS servers (sorry, AD servers) and many other interesting (to some) items. And, the DNS domain my laptop joins depends on the network where it is connected in accordance with business policies in effect. Thus, DHCPv6 is of great interest for portable systems. I have previously noted that many clever technicians are well versed in what we do not need - without considering all the business management requirements that end user systems must meet. They are all correct, but not right. James R. Cutler james.cut...@consultant.com
Re: Private use of non-RFC1918 IP space
Clarification here: 1/8 was never on the EDS backbone. Was only used locally in one site, as far as I can determine. On Feb 4, 2009, at 7:29 PM, Randy Bush wrote: I see you've never done business with EDS. They've been using 1/8 for over a decade. Also, over the years, I've seen a number of universities and supercomputing facilities number nodes out of 1/8 -- however, those systems are never supposed to see the internet anyway, so they could technically number them however they want. Personally, I've used 1/8 in lab setups. brilliant! i think all my competitors should do that. randy James R. Cutler james.cut...@consultant.com
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore patr...@ianai.netwrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft m...@internode.com.auwrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers well, you might get renumbered randomly isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+
Re: Inauguration streaming traffic
Arbor had a good writeup on the traffic that they saw. http://asert.arbornetworks.com/2009/01/the-great-obama-traffic-flood/ Regards, James Pleger On Jan 21, 2009, at 7:14 PM, Ong Beng Hui wrote: Is there a general study done on the overall impact of inauguration streaming traffic ? any summary on what is the overall gain of bandwidth, etc.
RE: Test
Yes :) James -Original Message- From: Dennis Dayman [mailto:den...@thenose.net] Sent: Thursday, January 08, 2009 5:30 PM To: Nanog Subject: Test this still working?
RE: List Help
Final-Recipient: rfc822;den...@thenose.net Action: failed Status: 5.5.0 Diagnostic-Code: smtp;550 failed to meet SPF requirements I wish I could help :) -Original Message- From: Dennis Dayman [mailto:den...@thenose.net] Sent: Thursday, January 08, 2009 5:48 PM To: Nanog Subject: List Help So I apologize for that test, but I can no longer see posts to the list. I can send to the list, but I don't get a copy of my posts or anyone else's. My MTA is not blocking anything nor does it ever get a connection from MERIT mail servers to send me a copy of the posts. I also don't receive PSWD reset emails. Anyone know who I can talk to? -Dennis
Re: Ethical DDoS drone network
On Sun, Jan 4, 2009 at 10:27 PM, bmann...@vacation.karoshi.com wrote: On Sun, Jan 04, 2009 at 09:55:20PM -0600, Gadi Evron wrote: A legal botnet is a distributed system you own. A legal DDoS network doesn't exist. The question is set wrong, no? kind of depends on what the model is. a botnet for hire to red-team my network might be just the ticket. You probably don't have to entirely own the distributed system for it to be legal. You could just control it with proper authorization. A legal botnet is one whose deployment and operations doesn't break any laws in any of the relevant jurisdictions.The ways to achieve this are legal considerations, not technical considerations. I'm not thinking this list is really a good place to ask a question about legality and get an answer you can rely on. You need to confer with your lawyers about how exactly your botnet can or can't be built and still be legal. This may depend on what country your botnet operates in, where you are, where your nodes are, etc. But thoroughly control and restrain every possible factor that could ever make your botnet illegal, and the result should (imho) be legal... This is not an exhaustive enumeration, but some situations that often make illegal botnets illegal are: (A) The botnet operator runs code on computers without authorization, or the botnet software exploits security vulnerabilities in victim computers to install without permission i.e. operator gains unauthorized access to a computer to deploy botnet nodes, or the software is a worm. This problem is avoided if you take measures to guarantee you own every node, or if you guarantee you have full permission for every computer you will possibly run botnet software on, to the full extent of the botnet node's activities. And you ensure botnet software used never automatically spreads itself like a worm. This way, all access you gain to node PCs is authorized. (B) Botnet node software conducts unauthorized activities after it is installed on the host PC. e.g. Theft of services. Perhaps an authorized user of the PC did install the software, but they installed it for an entirely different purpose, the botnet node is hidden software, not noted in the product brochure or other prominent information about the software. This problem is avoided if you make sure the person giving permission to install the software is aware of the botnet node and all its expected activities, before a botnet node can be brought up. (C) Traffic generated by a botnet could be illegal. For example, traffic in excess of agreements you have in place, or in violation of your ISP's TOS, TOU, or AUP, may be questionable. Ethically: You need permission from owners of the source and destination networks the botnet generates traffic on, not just the source and destination computers. For example, you have agreements for 10 gigs, but your botnet test accidentally sends 50 gigs towards your remote site, or one of the thousands of nodes saturates a shared link at its local site that belongs to someone else. An attempt to simulate a DDoS against your own network could inadvertently turn out to be a real DoS on someone else's network as well as yours, for example one of your providers' networks. This is best avoided by maintaining tight control over any distributed stress testing, and massively distributed stress testing should be quarantined by all available means. The destination of any testing must be a computer you have permission to blow up. And the amount of traffic generated by any botnet node on its LAN need be acceptable. Always retain rigid controls over any traffic generated, and very strong measures to prevent an unauthorized third party from ever being able to make your nodes generate any traffic. At a bare minimum, strong PKI (no MD5 or SHA-1) and digitally-signed timestamped commands for starting a test, with some mechanism to prevent unauthorized creation or replay of commands. Plus multiple failsafe mechanisms to allow a test to be rapidly halted. i.e. all nodes ping a control point once every 30 seconds. if two pings are dropped, the node stops in its tracks. So you can kill a runaway botnet by unplugging your control hosts. -- -J
Re: What to do when your ISP off-shores tech support
Matthew Black wrote: I've had difficulties reaching anyone with a brain at my DSL provider Verizon California. I can reliably ping the first hop from my home to the CO with a 25ms delay. But if I ping any other location, packets get dropped or significantly delayed. To me, this sounds like Verizon has an internal routing problem rather than a problem with my phone line. Note that it rained recently in our area and the cable vault in front of my is usually covered with stagnant water because the gutters don't drain it away. I have tried to explain this to tech support but they refuse to go off script, even the supervisors. They keep insisting on sending a tech to my home when I suggest this should be escalated to their network operations team. Anyhow, if I can reliably ping the first hop from my home, would that eliminate my telephone connection as part of the problem? Just a sanity check on my part. Thanks. matthew black california state university, long beach Are you seeing drops or slow response times for the Verizon hops but not for the last hop destination? If so, remember that most of the larger ISPs will be rate limiting non-admin (ie from their support network ranges) traffic directed to the enterprise equipment. This means they will either ignore or delay responding to ICMP requests directed to their own IP addresses vs forwarding traffic. If your seeing about the same for the destination and for the intermediate hops then it's more likely an issue on the Verizon network. -- James Michael Keller
RE: unsubscribe
nanog-requ...@merit.edu?body=unsubscribe To Unsubscribe. James Thomas -Original Message- From: Murphy, Jay, DOH [mailto:jay.mur...@state.nm.us] Sent: Monday, December 29, 2008 5:31 PM To: Springer, Dennis D; nanog@nanog.org Subject: RE: unsubscribe Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 Bus. Ph.: 505.827.2851 We move the information that moves your world. -Original Message- From: Springer, Dennis D [mailto:dennis.sprin...@chartercom.com] Sent: Monday, December 29, 2008 3:07 PM To: nanog@nanog.org Subject: unsubscribe Dennis Springer Network Engineer III Charter Communications 12405 Powerscourt Dr. 2nd floor St. Louis, MO 63131 Phone: (314) 288-3425 Cell: (314) 607-9824 -Original Message- From: Murphy, Jay, DOH [mailto:jay.mur...@state.nm.us] Sent: Monday, December 29, 2008 12:26 PM To: marco; nanog@nanog.org Subject: RE: Level 3 issues Duly meditated upon. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fe, New Mexico 87502 We move the information that moves your world. -Original Message- From: marco [mailto:ma...@zero11.com] Sent: Monday, December 29, 2008 11:20 AM To: nanog@nanog.org Subject: Re: Level 3 issues I think that most of the anger was directed at the wanna-be reporters/journalists that visit this list. Todd Vierling wrote: On Mon, Dec 29, 2008 at 11:33 AM, Murphy, Jay, DOH jay.mur...@state.nm.us wrote: You know, it gets pretty thick through here, when all you people slam on someone, to justify pent up angst or whatever the cause may be. I worked for Level 3 as a NOC engr, and they follow standards as other companies do, and for that matter a standard that I AM SURE all of you follow in some form, degree, or another within the employ you are with, so shut up already won't you. Give me a 10-minute break already. Half of the crap that you guys serve up is crap, just that, CRAP! Get to talking real 'net stuff, not filler, fodder, just facts man. Oh yeah the other thing, quit your whining. ironylol/ __ This inbound email has been scanned by the MessageLabs Email Security System. __ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. __ This inbound email has been scanned by the MessageLabs Email Security System. __
Re: Christmas spam from RESERVED IANA adressblock ?
On Wed, Dec 24, 2008 at 11:38 AM, Scott Morris s...@emanon.com wrote: I would guess (hope?) that most, if not all, providers filter the RFC1918 space addresses from entering or leaving their networks unchecked. But just my two cents there... All sites (not just providers) should, but many just don't do what they should. In some cases it may not even be practical for people to do what they should (due to poor software/hardware, or the poor availability of IPv4 addresses) RFC1918 addresses should also never be found in mail headers of any messages being exchanged over the internet.. For the very reason that it creates this confusion. Another case of many implementations not doing anything close to what they should. RFC1918 says on page 4: Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. Private IPs in mail headers are just fine inside the enterprise, but messages with headers referencing private IPs should not be exchanged over the internet. RC1918 specifically says indirect references should not leave the enterprise. The only thing that would be worse or more confusing to other sites would be to not add a mail header at all, or to use a real IP address shared by other hosts that use 1918 addresses on the LAN. Mail servers that deal with internet mail should always add headers that contain a distinct public IP address that belongs to that mail server, for distinctively showing any abuse or mail server problem, even if all access to that public IP is actually blocked by a firewall. Not sharing mail server public IPs isn't part of the RFC1918 though, it's just the right way(TM). -- -J
Re: Anyone on a Virgin Media UK broadband connection?
FWIW, I'm on a Virgin Media connection in South London (former CWC network), and I'm not experiencing any problems with Wikipedia or the gamer site Drew was having trouble with. Friends in North London are complaining of very slow connections. On Mon, Dec 8, 2008 at 10:09 AM, Simon Waters [EMAIL PROTECTED] wrote: On Sunday 07 December 2008 14:10:02 Drew Linsalata wrote: Drop me a note off-list if possible. We have a business line from them Urm no Wikipedia this morning - hmm - I think the IWF is self destructing. -- James Enck Senior Associate Telco 2.0 Initiative http://telco2.net +44 7971 263 796 http://eurotelcoblog.blogspot.com Skype: jimiinc Google Talk: james.enck
Re: godaddy spam / abuse suspensions?
It's also not effective in various situations. The bad behavior is not disabling abused domains, it's the method used to do it (by giving no answer instead of actively giving a negative answer). When a http client asks recursive resolver A for an A RR, and no response is received, the client will then go to recursive resolver B and make the very same query again, and possibly on to recursive resolver C. One of the secondary/tertiary recursive resolvers may hand the client a cached response that had been obtained before the registrar took any action. If instead recursive resolver A returned a NXDOMAIN, that would be the end of it, no new queries, the answer has returned name does not exist. The impact of the additional queries can be significant as well. -- -J On Sun, Nov 16, 2008 at 4:38 PM, Andrew Fried [EMAIL PROTECTED] wrote: Chances are if the domain has been sandboxed, it was because it was involved in some kind of phishing scheme, not spam. This is the typicaly way of mitigating fast flux botnets. So I don't agree with the assessment that this is bad behavior on the part of GoDaddy - to the contrary, they are acting quite responsibly. AF
RE: routing around Sprint's depeering damage
How about: If there is a need, somebody will provide at a suitable price? If no body steps up, we don't need it. There seems to be ample evidence, in many arenas, that naked capitalism can have disastrous results. And there are lot of examples and ample evidence in history, in many areas, that complete regulation, complete socialism can have disastrous results as well. If you want to have a good idea on how the internet will look like in the US after regulation, simply look at Australia. The government imposed regulation early on in internet infrastructure market caused nothing but raising the entry barrier for small ISPs, only creating government-approved monopoly for major telcos/carriers. Only such regulation creates a situation where it is cheaper and affordable for a smaller ISP to route traffic from .AU to .US, then back to .AU than interconnect directly with incumbent carrier in their own country. So yes, more regulations definitely help the internet indeed (by adding extra 300ms into the process). Instead of calling for socialist/communist policies to regulate the transit industry, the single-homed networks can simply multihome. Because of Cogent, the cost of transit has come down to single-digit per megabit that even after adding transport costs, it's now affordable to add a 2nd internet connection for practically most organizations out there, especially in the continental US (the same capitalism that you call 'disatrous results' is the same capitalism that brought cheap dollars/meg pricing, allowing smaller companies to multihome now when they couldn't afford to do so in the past). As much as we blame Cogent and Sprint for breaking the internet, I also have no sympathy for individual single-homed downstream customers on either networks. If you are complaining about Sprint-Cogent depeering and have customers demanding for your mission-critical services, then you are just as negligent to not have multihomed before all of this happened. If you need that 100% uptime guarantee, you shouldn't rely on single carrier, nor should you rely on government for more regulation. No one can help you but yourself in ensuring your uptime-- so perhaps look at your own setup and decide that you need that 2nd connection to back you up when first one fails. This is a simple business logic. James
RE: routing around Sprint's depeering damage
But seriously, it shouldn't be necessary to have two connections at work, two connections at home, two connections for each mobile device, just to ensure that when large providers stop working together you can still reach what you need to reach. I think you're misinterpreting what I'm trying to say. The consumers/end-users don't necessarily have to multihome. The problem is the content providers/web hosters sitting single-homed on either networks, when most of them are physically sitting in better environment to multihome (i.e. a datacenter) than consumers. A consumer can be single homed to Sprint or Cogent, but when the other side (the content) is multihomed, you'll simply take new route to get to that content. My point is, any business providing services over internet (this excludes mobile devices, end-user/consumers) should be multihoming themselves if they are serious about uptime. James
Re: Sprint / Cogent dispute over?
On Sun, Nov 2, 2008 at 8:29 PM, Martin Hannigan [EMAIL PROTECTED] wrote: But according to Sprint, this isn't a peering spat. This is a customer who didn't pay their bill. Probably useful to keep that in perspective. -M I would say it's a peering spat, because Cogent's press releases stated Sprint failed to meet Sprint's contractual obligation to peer with them on a settlement-free basis. That's a political issue that (I expect) remains to be mediated by the courts. The disconnection should have been eminently forseeable by Cogent, if the entire peering was indicated by Sprint as being on a trial basis. To maintain connectivity, Cogent should have had a contingency in place and taken it, when Sprint rejected their request for settlement-free peering. There is something a bit worst for a single-homed customer than a Tier 1 provider that gets in peering spats;that IS: being single-homed to a provider who wants to say they're Tier 1 when in fact: they may _really_ be a Tier 2 in disguise. And who as a result of wanting to market themselves Tier 1 refuses to pay their paid peering fees. Because it means your provider _could_ have taken actions to preserve connectivity, but something else was so much more important to them than providing the product you their customer expect, that they intentionally allow it to get in the way. In other words, if you want to be single-homed, a Tier 2 or 3 upstream that admits they're a Tier 2 or 3, and provides you redundancy and excellent connectivity, seems like the thing to find.. Because a Tier 2 posing and marketing as a Tier 1 might prioritize their continued marketing themselves as a Tier 1 over actually providing Tier 1 connectivity. - Government regulation of peering relationships would be a disaster... I fear regulatory organizations are too easily influenced by the largest players. One can imagine per-megabit peering taxes imposed by the feds on interconnections between different networks that only large providers would have carved out rules to exempt themselves from. And artificial government interfering with small networks wanting to peer. Requiring reams of paperwork, registrations, design documents, waiting periods, etc -- -J
RE: the Intercage mess
No, but forcing them offline now that they are taking a new approach to handling abuse is ridiculous. Intercage are reaching out to the anti-abuse community and yet some people on NANOG keep interfering with the cleanup process. How do you expect them to clean up their network and return to normal operations (with considerably less abuse) if it keeps being disconnected? The shit isn't even there anymore. These kids have moved it elsewhere. Intercage have learned their lesson, just leave them alone and let the people who have *real* problems (e.g. me, Andrew Kirch of AHBL, Spamhaus, Gadi, etc.) with Intercage deal with this. If anyone has any issue with Atrivo/Intercage that still needs rectification: please contact me or Andrew Kirch offlist and we will bring it to their attention. We have contact with these people, and they are listening and taking action to clean up their network. If not, then please stop with this thread. It's not helpful, and it's certaintly counter-productive. William William, This above email is a bit off. It sounds a bit like you feel that Nanog is your (Gadi/you/Andrew/Spamhaus) stick to force Intercage to fall in line. Not that they have been whacked with the stick you want the rest of us to leave them along so YOU can deal with it. But it is NOT your place to deal with it any more than it is mine. It is a community issue dealt with by the community and if the community (I.E. those who have killed intercage's connectivity) choose to keep it that way as opposed to taking the chance that this company, with a LONG history, will continue to spew unwanted traffic, well... That's not your call. It is not your place to tell someone else how to run their network and it is not your place to deal with the intercage issue on behalf of anyone else. James
RE: YAY! Re: Atrivo/Intercage: NO Upstream depeer
Very well said. James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2008 5:23 AM To: nanog@nanog.org Subject: RE: YAY! Re: Atrivo/Intercage: NO Upstream depeer It is clear to me -- at least -- that this entire criminal operation is being operated out of Eastern Europe, and their foothold in the U.S. is the major issue here. If you believe that this is a criminal operation then you should keep this discussion OFF THE LIST and discourage anyone from taking any action against the bad guys that might disrupt evidence gathering. If this is a criminal matter, then it is best to keep quiet, collect good evidence, and go to court. Better to get a court injunction ordering them to stop sending malware, and then collect evidence showing that they violated the injunction. To do this, they need to have functioning upstream connections to your network. NANOG is not the place to discuss these things. None of this is network operational. The whole discussion amounts to a shouting match between vigilantes and their victims. Some of those victims might also be bad guys, but a shouting match on NANOG does not prove this one way or the other. --Michael Dillon
RE: hat tip to .gov hostmasters
To digress on IPv6 momentarily.
The airline magazine engineering memorandum* from OMB left two terms
undefined in the mandate; backbone network and IPv6 compatible. The
Intra-agency IPv6 Federal Working Group wisely defined backbone
network as (paraphrasing) the wire exiting the first publicly-reachable
network perimeter router and entering the router next in the line of
traffic and all devices attached to that wire between those two points
as follows:
{Internet}-|router|-connecting wire---IPV6-[firewall, IDS,
etc.]-IPV6--connecting wire-|next router in line|-NO IPV6-...
NIST is still working on compatible.
*Airline Magazine Engineering Memorandum: a mandate issued by an
executive who can. The memorandum has four characteristics; 1) It
mandates a technology not well understood by either the issuer or the
recipient of the memo, 2) it sets a date certain by which the technology
must be implemented, 3) it provides no funding, and 4, it contains one
or more undefined terms whose exact meanings are absolutely crucial to
actual implementation of the mandate. Source of the inspiration that
originally convinced the issuing executive that they actually understood
the scope and technology of the mandate is inherent in the title of this
paragraph.
JimL
James R Lindley
Senior Computer Engineer
Advanced Technical Analysis Team
IT Security Architecture and Engineering
Internal Revenue Service
An unquenchable thirst for Pierian waters.
-Original Message-
From: Kevin Oberman [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 12:54
To: Goltz, Jim (NIH/CIT) [E]
Cc: nanog@nanog.org
Subject: Re: hat tip to .gov hostmasters
Date: Mon, 22 Sep 2008 11:42:33 -0400
From: Goltz, Jim (NIH/CIT) [E] [EMAIL PROTECTED]
nice to see a wholesale DNSSEC rollout underway (I must confess to
being a little surprised at the source, too!). Granted, it's a much
more manageable problem set than, say, .com - but if one
US-controlled TLD can do it, hope is buoyed for a .com rollout
sooner rather than later (although probably not much sooner :)).
It ain't done yet.
I don't speak for the hostmasters of .gov or any subdomain thereof.
But I'll believe it when I see it.
I am pretty sure that you will see it. Unlike things like the IPv6
requirement, there are no waivers available for this. '.gov' must be
signed early next year and all zones delegated from the '.gov' GTLD must
be signed in early 2010. I doubt that many will sign until '.gov' is
signed, so you won't see much change for a few months.
Now, if the DOC people responsible for root would just catch a clue, we
could get that signed and have DNSSEC actually usable (except for Mr.
Metcalf) in a significant part of the US network before I retire.
Remember, they've also mandated IPv6 support on all backbones.
Yes, and the goal, relatively insignificant that it was, was met. It was
not a requirement that anyone actually use IPv6, only that the agency
backbone networks be able to carry IPv6. In fact, the wording was such
that doing proper routing was not even really needed.
Our backbone has offered IPv6 as a production service since 2002, so it
was a non-effort for us. Most other agency backbones were pretty trivial
to make IPv6 capable.
The problem is that only the backbone currently needs IPv6. No facility
network or end host needs it, No network service needs it. No IPv6
packets, even routing updates, need to be delivered in any useful way.
It was a pretty trivial goal and was met with very little effort.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Atrivo/Intercage: NO Upstream depeered at 2:25am est
Hmmm Seems Pacific bit the bullett around 2:25 est all annoucements were dropped. http://cidr-report.org/cgi-bin/as-report?as=AS27595v=4view=2.0 I would ask for comment by Intercage staff but they don't have email. Emil is unresponsive via phone, James
RE: Atrivo/Intercage: NO Upstream depeer
Emil, You have a lot of loyal legit customers. What's your plans? Seems like your taking action against the bad clients which is great. Where does this leave Intercage? You seeking alternative routes currently? Offering refunds to those loyal clients? James -Original Message- From: Emil Kacperski [mailto:[EMAIL PROTECTED] Sent: Sunday, September 21, 2008 3:20 PM To: nanog@nanog.org Subject: Re: Atrivo/Intercage: NO Upstream depeer Hello, It's true that David from PIE disconnected our link approx 9pm or so yesterday. Things were going perfect, no complaints for a few weeks now. The only thing I believe is that NTT gave lots of pressure to PIE. For some unknown reason when I tried to reach out to the security guy at NTT he basically said our contract is with PIE. So in a time like this you really get to know who your friends are and who should be avoided. Onward and upward! What doesn't kill you only makes you stronger ;-). Just feel bad for the customers for which I am truly sorry for right now ;-(. Thanks! Contact: Emil Kacperski Company: Intercage Inc. - Atrivo Dedicated Servers San Francisco Datacenter E-Mail: [EMAIL PROTECTED] Phone: 925-550-3947 ICQ: 23531098
RE: Atrivo/Intercage: NO Upstream depeer
Russell, I really think Atrivo/Intercage has been doing great after reports and community public action. I'm still puzzled as to the why they are still targetting you? I have a few friends who have machines with you so and they run legitimate companies with over 4 machines. Emil has done everything in his power to bring his network back to normal operations. Looks great the past 2 weeks, I wish both of you the best of luck its hard to determine who is a solid friend and who is not. Like emil said... It only will make you stronger. James -Original Message- From: Russell Mitchell [mailto:[EMAIL PROTECTED] Sent: Sunday, September 21, 2008 5:54 PM To: nanog@nanog.org Subject: Re: Atrivo/Intercage: NO Upstream depeer Hello all, Andrew: It is truly enlightening, to say the least, that you want to talk about all of the SBL Listings, all of the DNSBL Listings, and all of the abuse on our network has never had action taken. - In Spamhaus' article, they did a history of more then ?350? SBL Listings for our company. Today, we have 6 ACTIVE Listings in the SBL. If we haven't acted on abuse claims, why do those numbers not match up? So, sometime over the weekend, Spamhaus listed our ONLY Upstream's /22 IP Block.. There's NO Evidence of any abuse from PIE for the listing. How can they be labeled as a SPAM or Abuse Supporter after routing us for such a short time? That's ethical, legitimate, and reasonable to you? We have ALL of our IP Space listed with Spamhaus because we have a Reseller named Esthost. While their customer track record may not be a straight arrow, they've ALWAYS taken action on abuse we've received for machines leased to them (Just like every other customer we have!). We enacted a zero tolerance policy in light of the community delivering false information and giving false reports to news media. What did that do? It gave us the opportunity to cancel service on EVERY Machine that an abuse was reported on. What happened shortly after? No more reports, no more abuse. Esthost's Registrar entity, EstDomains launched a great campaign to work with the public and take in reports against Malware Customers, as that is what the news media was reporting was the issue. Over 20,000 Domains get suspended by EstDomains in a period of about a week. Your going to come back and say, Well Directi did it in about 2 days!. Yeah? Directi had it placed right on their desk! They didn't have to launch any campaign or go out and ask the COMMUNITY for it. The people behind those false reports on our company gave them a set of Data to allow them to act that fast. So, we see Esthost turning a corner and going out to the community with an outreach program. Community is giving support for it. We enact a zero tolerance policy for our entire network, this isn't made public aside to a GOOD and TRUTHFUL Editor from TheRegister, Dan Goodin. We gave ourselves 1 month to see what is going to happen between the community, and Esthost. In the final stretch of that 1 month, we get blind-sided by Spamhaus. So now, an apparently level-headed James Thomas brings the happenings from last night into the light, and here we are. All of the claims about us being the RBN, Emil being some Russian named Igor, and Atrivo being the epicenter with such partners like InterCage. Did you forget? Emil has a split-personality, that's how they got their claim of InterCage being partnered with Atrivo. As though they're 2 seperate entities! Good Research Matt, Jart, Garth, and all the others who've written about us recently! Thank you all for your time and responses. Good or bad, we're reading them. Have a great day. --- Russell Mitchell InterCage, Inc. - An un-orgranized eCrime ring based out of San Francisco, CA. We would only be so lucky!
Re: Creating a visual Map of a network?
Hello Subba , On Tue, 16 Sep 2008, [EMAIL PROTECTED] wrote: I am being tasked to map a network. In the past I have used nmap to find the systems on the local LAN and remote LANs (same enterprise). This time I want to create a visual map of the LAN. With cheops, I reasonably good results but cannot be documented for managers with certainty. What are some good tools now that will create visual maps of the networks? nmap can do this now , so I've been told . What is the best way to map a network when ICMP echo has been turned off? Thank you in advance for any help. Subba Rao Hth, JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 2133McCullam Ave | Give me Linux | | [EMAIL PROTECTED] | Fairbanks, AK. 99701 | only on AXP | +--+
RE: BCP38 dismissal
i suggest you go back to the mail to which you responded obscenely vilifying the poster who was specifically saying he worried about his host before bcp38. that was specifically the subject. host in that context was his router, which makes your comment make less sense. (having never seen a big iron router become a client in a botnet, myself) He was talking about big iron control plane policy controls. You must have missed the context. Actually, Randy is right. We were discussing in context of routers and botnets themselves. Host in my context was about the botnets sending attack from legitimate IP sources that BCP38 will not be able to defeat. You want to stop being rude, and start making positive assertations about things you know? I'd love to be wrong, but I've got a whole lot of experience on this topic. If you know better, educate the rest of us. No, you have demonstrated that the only jerk in this entire forum is no one but you with limited bounds of intelligence. Before you go on and call someone a jerk, idiot and falsely accuse him of ~not wanting to deploy BCP38[1]~, read your own posts and start making positive assertions about things that you know yourself. [1]: Almost every network that I help manage is operated with BCP38 either with uRPF or even with automatic-scripted SAV (source address verification/filtering)/ ACL's. james
Re: InterCage, Inc. (NOT Atrivo)
On Mon, Sep 8, 2008 at 10:59 AM, Scott Weeks [EMAIL PROTECTED] wrote: --- [EMAIL PROTECTED] wrote: Well, perhaps you can share any information with us on a legitimate client you have? -- Now why do you have to go there? Just to fan the flames for fun and profit? :-( scott Scott, I am unsure how it is fun or profitable to ask this question which has been on everyones mind. I haven't personally seen anything worth noting that wasn't malicious from Intercage or Hostfresh. I can tell you the only thing that was even remotely legitimate from a report of all Hostfresh/Intercage traffic from my network was a couple porn sites. Everything else was malicious communication. I am sure if I looked into it more I could find some exploits related to the sites. Thanks, James
Re: InterCage, Inc. (NOT Atrivo)
When I worked at an ISP I can say that my house was very clean. Takedowns were done in hours and we had a very large customer base. I will take on the clean house topic any time... I have done hundreds if not thousands of takedowns while I have worked at hosting companies, it isn't that hard to keep the house clean. However, what you have said in this topic has not been useful or brought anything that might be interesting to light at all. Please come back when you have something useful or productive to say. Thanks, James On Mon, Sep 8, 2008 at 11:20 AM, Scott Weeks [EMAIL PROTECTED] wrote: --- [EMAIL PROTECTED] wrote: I am sure if I looked into it more I could find some exploits related to the sites. - Why software piracy might actually be good for companies. Folks should clean their own house before pointing fingers at others... scott
RE: Force10 Gear - Opinions
uRPF strict as a configuration default, on customers without possible asymmetry (multihoming, one-way tunneling, etc) is not a bad default. But when the customers increase in complexity, the time might come to relax things some. It's certainly not a be-all-end-all. And it's been demonstrated time after time here that anti-spoof/bogon filtering isn't even a factor in most large-scale attacks on the public Internet these days. Think massively sized, well connected, botnets. See also CP attacks (which, again, the F10 can't even help you with). Indeed... In today's internet, protecting your own box (cp-policer/control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets). james
RE: BCP38 dismissal
I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else. Indeed it is important. And we were discussing about the fact that Force10 does not even offer this critical feature. Anyone else want to stand up and join the I am an asshole club? You are falsely claiming that somehow we're dismissing BCP38 or otherwise writing it off as some kind of non-important hassle. You are confused and misinformed as to the concurrent nature of the ongoing discussion and your assumptions are far from what I personally think about BCP38. It appears you are the first member of I am an asshole club by the strict title definition. james
Re: BCP38 dismissal
On Sep 4, 2008, at 7:24 AM, James Jun wrote: Indeed... In today's internet, protecting your own box (cp-policer/ control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets). I'm sorry, but nonsense statements such as these burn the blood.Sure, yes, protecting yourself is so much more important than protecting anyone else. Anyone else want to stand up and join the I am an asshole club? OK, I'm an asshole. I'm sure BCP38 can prove to be useful, but I'll never drop my shields. I guess being an asshole is not so bad given that I have plenty of company.
Re: BCP38 dismissal
On Sep 4, 2008, at 10:14 AM, james wrote: OK, I'm an asshole. I'm sure BCP38 can prove to be useful I guess being an asshole is not so bad given that I have plenty of company. It is unfortunately true that you do have lots of company. If I could get away with dropping all routes from people like you I'd be a lot happier. (and we'd all be a lot safer) Let me put this another way. Calling people names doesn't promote your interests. It starts flame wars.
RE: Force10 Gear - Opinions
Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/ Router 7600 series perform both of these features in hardware. The article mentioned in this thread compares Force10 E against the 6500 series. Sorry, I was on an installation with 6500s and 720s trying to do uRPF and it kept falling back to software and killing the units. What your reading has no reality in my experience. uRPF was problematic back in PFC2 based platforms (i.e. SUP2) where it is further dependent upon unicast routes in FIB TCAM. uRPF currently works fine enough on PFC3 based sups, the only problem however is currently only one or the other mode is supported for the entire box, as opposed to per interface. For example, configuring loose-mode uRPF in one interface, then configuring a strict-mode in another will result in entire box behaving as strict-mode interface for all uRPF enabled interfaces. Other than this caveat, I never had problems with it. However, these uRPF issues are fully documented. Reading manuals and documentation should help you avoid getting into operational problems such as kept falling back and killing the units scenario. Control plane policing via cp-policer works quite well on pfc3 based 6500's. This is ofcourse a very important feature (more important than uRPF in today's internet IMO) that appears to be missing in f10 gear which is what Paul was saying earlier. james
RE: Using 32 bit ASN numbers
These are the dates I have for Cisco platforms: IOS XR 3.4 - September 2007 IOS 12.0(32)S11 - November 2008 IOS 12.2SRE - December 2008 IOS 12.5(1)T - April 2009 -Original Message- From: andy lam [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 11:29 AM To: [EMAIL PROTECTED]; Brian Raaen Subject: Re: Using 32 bit ASN numbers Cisco IOS XR Software Release 3.4.0 adds support for BGP Authentication Key Chaining, BGP 4-Byte Autonomous System Number (ASN), and BGP Next Hop tracking enhancements. http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.4/general/release/notes/reln_34.html#wp239046 BGP 4-Byte ASN-Increases the range of supported autonomous systems from 2 bytes to 4 bytes to scale with expected Internet growth. 12.2SR* is supposed to be in late 2008, but has not yet been announced publicly. Juniper it's in JUNOS 9.1 as farr as I can tell. --- On Fri, 8/29/08, Brian Raaen [EMAIL PROTECTED] wrote: From: Brian Raaen [EMAIL PROTECTED] Subject: Using 32 bit ASN numbers To: [EMAIL PROTECTED] Date: Friday, August 29, 2008, 11:04 AM I am doing some research for our company regarding 32 bit ASN numbers. I am trying to locate information about vendor and service provider support. In particular I have not been able to find what Cisco IOS image I would need to load on our router to support 32 bit ASN's. I also want to know what experience people have had with service provider support of 32 bit ASN's -- Brian Raaen Network Engineer [EMAIL PROTECTED]
Re: interger to I P address
Perl provides some cleaner methods for interpreting/displaying IPs.
There isn't a formal standard notation for an IP that looks like a string of
decimal digits with no dots though.
I.e. no RFC will define the host byte order and tell you that 127.0.0.1
corresponds to the decimal integer 2130706433;
I might be little-endian and argue that the right human-readable integer
to call that ip is 16777343.
There are a vast number of different numerical representations the
very same ip address could be converted to, because a string of bits has
no inherent representation. Displaying an IP in a novel format seems dangerous.
Ips have only a binary notation and.. in recent years
dots-and-decimals are formalized.
In general, rather than just in the context of SMTP.
Still conflicting conventions exists that haven't been fixed, for example
try pinging 127.1 (hint: it's an old abbreviation mechanism not
merely a bug)
In any case, to get from quad-octet notation to a decimal integer
representation you may be thinking of
(if you interpret those octets in the network byte order used for
other items such as port numbers):
$ perl -e 'use IO::Socket; print unpack(N,inet_aton(127.0.0.1)).\n'
2130706433
$ perl -e 'use IO::Socket; print inet_ntoa(pack(N,2130706433)).\n;'
127.0.0.1
$ perl -e 'use IO::Socket; print inet_ntoa(pack(N,2066563929)).\n;'
123.45.67.89
And of course...
$ perl -e 'print ,(12324)|(4516)|(898),\n'
2066569472
Or if you don't like one-liners, 3 separate short scripts:
ipv4-to-hex:
#!/usr/bin/perl
use IO::Socket;
printf(%x\n, unpack(N,inet_aton($ARGV[0])));
ipv4-to-integer:
#!/usr/bin/perl
use IO::Socket;
printf(%d\n, unpack(N,inet_aton($ARGV[0])));
hex-to-ipv4:
#!/usr/bin/perl
use IO::Socket;
print inet_ntoa(pack(N,hex($ARGV[0])));
On Wed, Aug 27, 2008 at 9:13 AM, Michael Holstein
[EMAIL PROTECTED] wrote:
ls it possible t convert the interger to ip
#!/usr/local/bin/perl
# Perl script to convert between numeric and dotted quad IPs.
# give credit to Paul Gregg for this one
while (STDIN) {
chomp; $input = $_;
if (/\./) {
($a, $b, $c, $d) = split(/\./);
$decimal = $d + ($c * 256) + ($b * 256**2) + ($a * 256**3);
} else {
$decimal = $_;
$d = $_ % 256; $_ -= $d; $_ /= 256;
$c = $_ % 256; $_ -= $c; $_ /= 256;
$b = $_ % 256; $_ -= $b; $_ /= 256;
$a = $_;
}
if ( ($a255) || ($b255) || ($c255) || ($d255) ) {
print $0: Invalid input: $input\n;
} else {
printf (Address: %d.%d.%d.%d is %u (Hex:%02x%02x%02x%02x)\n,
$a,$b,$c,$d, $decimal,$a,$b,$c,$d);
}
}
RE: Force10 Gear - Opinions
As a box designed with the enterprise datacenter in mind, the E- series looks to be missing several key service provider features, including MPLS and advanced control plane filtering/policing. Ah, because Cisco does either of these in hardware? Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/Router 7600 series perform both of these features in hardware. The article mentioned in this thread compares Force10 E against the 6500 series. james
Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html Well, on reading it, it's more an IPv6: It's great -- ask for it by name! piece. IPv6 gives me brain ache. I hear I'm not alone in that. I'd v6 tomorrow if I didn't have to think about it so hard.
Re: Hardware capture platforms
There are several things that you can do with open source solutions, however looking at the data may be a bit more difficult than something like Network Generals or Solera Networks capture appliances. It is still doable and is definitely much much cheaper... Something you might want to look into is traffic aggregation with a switch or hub. You can buy an Allied Telesyn switch and basically turn it into a hub by disabling switchport learning. Just an idea. You can use regular old tcpdump with the -C option to rotate logs tcpdump -i blah -s0 -C filesize to rotate, etc. or you can use Daemonlogger which does pretty much the same thing... http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html On Tue, Jul 29, 2008 at 6:45 PM, Network Fortius [EMAIL PROTECTED] wrote: Richard's blog @ http://taosecurity.blogspot.com/search?q=taps and especially his books (Tao of Network Security Monitoring and Extrusion Detection) are the best sources I have ever found, concerning [not only] taps and[/but] so much more on the subject - proper usage and best methodologies and practices for network monitoring (and not only for security!!!) Stefan On Tue, Jul 29, 2008 at 7:12 PM, Christopher Morrow [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 12:35 AM, Jared Mauch [EMAIL PROTECTED] wrote: Check out packet forensics depending on what your ultimate requirements are. I would also add a 'see packet forensics'... On Jul 29, 2008, at 7:10 PM, John A. Kilpatrick [EMAIL PROTECTED] wrote: We've deployed a bunch taps in our network and now we need a platform on which to capture the data. Our bandwidth is currently pretty low but I've got 8 links to tap, which means I need 16 ports. Has anyone done any research on doing accurate packet capture with commodity hardware? -- John A. Kilpatrick [EMAIL PROTECTED]Email| http://www.hypergeek.net/ [EMAIL PROTECTED] Text pages| ICQ: 19147504 remember: no obstacles/only challenges
Re: Possible explanations for a large hop in latency
Deep Packet Inspection engine delay. G On Jun 26, 2008, at 6:51 PM, Frank Bulk wrote: Our upstream provider has a connection to ATT (12.88.71.13) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22) comes in with a RTT of 85 msec. Unless ATT is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank James R. Cutler [EMAIL PROTECTED]
Re: smstools and CDMA
Hello Kevin , On Sat, 21 Jun 2008, Kevin Blackham wrote: And in my experience (many years back), a nokia handset would start draining its ups as soon as it got a full charge, requiring daily reseat of the supply cord. YMMV so test and retest. On 6/21/08, Phil Regnauld [EMAIL PROTECTED] wrote: Douglas K. Rand (rand) writes: PhilAlternatively, have you considered a Nokia handset with Gnokii ? No, not really. I was thinking that a modem would be a little more robust and easier to deal with in the rack than a handset would be. If I'm given a choice, I think I'd stay away from a handset, but I may not have a choice. :) Think about it: mobile handsets have built-in UPSes :) If that s/b the case try using a Power Timer ie: something like , http://www.simplyhydroponics.com/24hr_digital_timer.htm , And program it to turn off once a week for 2-3 minutes . Hth , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 2133McCullam Ave | Give me Linux | | [EMAIL PROTECTED] | Fairbanks, AK. 99701 | only on AXP | +--+
Re: If bandwidth wasnt already cheap (!) enough ..
Suresh Ramasubramanian wrote: Service providers who buy between one Gigabit and 10 gigabits will enjoy a three-year contract rate of $5 a meg, and those that consume a full 10 gigabit port can pay as little as $4 a meg on a three-year contract. A cynic would say that they are trying to book the revenues to raise some finance... J -- COO Entanet International T: 0870 770 9580 W: http://www.enta.net/
Call for Presentations - AusNOG-02
Call for Presentations - AusNOG-02 - AusNOG-02 is to be held in Sydney, Australia between 21st and 22nd of August 2008 The AusNOG meeting provides the Australian community with a forum to exchange information and experiences on a number of issues relating to the operation and support of networks, with a specific focus on the coming 6-12 months. The conference is expected to have a strong technical representation companies operating networks in Australia. Soon information will be posted at http://www.ausnog.net with further details, we will post back out to this list once that is done. Submissions Please read the below carefully. Send you proposed topics and details to [EMAIL PROTECTED] Be sure to specify which part of the conference best suits your proposal (Topic Sessions, Panel Discussions, Keynote Address or Peering Forum), include a detailed overview including the expected length of your presentation. The program committee will confirm your application and may get back to you with questions. Please remember this is a technical event for network operators and presentations should be representative of this. If you feel that you have a relevant presentation please also send that through, while we are attempting to get a certain theme running those who attended last would recall the diversity of presentations we received. Important Dates --- - 6 June 2008- Call for Presentations Opens - 4 July 2008- Deadline for Proposals - 11 July 2008- Response to presentation proposals - 18 July 2008- Draft program published to website - 25 July 2008- Final program published Presentations are Required for the Following: - Topic Sessions - Required Speakers: Variable - Number of Topics: 4 The conference will consist of 4 Topics Sessions, each running for approximately 90 minutes. There are no fixed requirements on length of presentation, speakers will have the opportunity to present a longer formal presentation or a smaller lightening talk. This is your chance to share your experiences with the industry. The Topics Sessions selected for AusNOG-02 are. 1. Moving to higher speed. With the coming of many new submarine cable systems in the next 12 to 18 months there will soon be a glut of cheaper high quality bandwidth. This will bring its own issues in dealing with the larger traffic flows in the core and at the access edge. We need talks from people involved with routing high capacity flows, how this occurs, lessons that were learnt, things to avoid etc. 2. Scaling services to meet demand. Broadband penetrations is reaching its growth peak, while new user numbers will not be as high in the past improved data plans and open ADSL2+ ports mean that users can do more - how can services (mail, web, caching (?), NNTP etc) be scaled to meet this rising demand. We are seeking talks from people experienced in deploying services for growing user bases and how they have dealt with many of these issues. 3. Back to a virtual world. Many operators currently use the outsourced Layer 2 ports of other providers be it either dial or DSL. With FTTN a lot more may be forced to, this will also open the door back up to the 'ISP in box' operations where ISPs head back to being infrastructure light. We are seeking talks from people of the issues in deploying mass LNS - good ways to do it, does open source work, etc ? 4. Regulatory, Market Data and Overseas Trends (Regulatory and Industry Bodies Updates, Market Data and Statistics, Trends from Overseas Markets) Panel Discussions - - Required Panellists: 8-10 - Panel Length: 45 mins - Number of Panels: 2 Panels are the interactive part of the conference. The job of Panellists will be to stimulate and moderate the discussion. Whether you are on the panel or in the audience your input would be appreciated. The two Panel Topics will be related to the industry at the time of the conference. Propose a topics that you think will be interesting, or if you think you are interesting, propose yourself for inclusion to the panel :-) Keynote Addresses - - Required Speakers: 2 - Presentation Length: 45 mins - Number of Topics: 2 We are seeking 2 speakers for Keynotes Addresses. Each Keynote will be of 45 mins in length, including time for input from the industry. If you would like to be considered for a Keynote topic, please email [EMAIL PROTECTED] with details of yourself and your topic. Peering Forum - We would like to meld the peering sessions into the main conference this year as we believe that it fits well with the general higher speed mature of the requests above, as such there will be no separate peering forum at AusNOG-02. We still welcome speakers from the peering industry to put together a relevant topic for the audience. The Organisers. ___
Splitting ARIN assignment
Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James
Re: [Nanog-futures] Announce list: Re: Hughes Network
The announcement was made to nanog-announce, but not to nanog. I would expect that there are scads more readers of nanog than of nanog announce. For some, that could cause unexpected results, especially with the 24 hour notice. Corroborative detail below. (Oops, top posting) Regards. On May 22, 2008, at 10:45 PM, Jim Popovitch wrote: On Thu, May 22, 2008 at 9:35 PM, someone wrote: Add me to the list of never-saw-that. In addition, I just checked the nanog archives, and there isn't an announcement of that type in the archives. Below is the full email, with headers, from Monday. Hopefully it will put this issue to rest but somehow I doubt that. ;-) -Jim P. snip/ MIME-Version: 1.0 To: [EMAIL PROTECTED] X-Enigmail-Version: 0.95.6 Authentication-Results: hkg-dkim-1; [EMAIL PROTECTED]; dkim=pass ( snip philip (for the SC) -- ___ NANOG-announce mailing list [EMAIL PROTECTED] http://mailman.nanog.org/mailman/listinfo/nanog-announce James R. Cutler [EMAIL PROTECTED]
[NANOG] Nortel Core Switching Experience
Would anyone be willing to share their experience with Nortel as a core switch platform off list? I am building out a small campus core and have received proposal with dual ERS 8300s at the core but I have no experience, anecdotal or otherwise, with Nortel in a switching capacity. I'll be happy to provide more information regarding our environment and other systems we're looking into. Thanks James Baldwin ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: [Nanog-futures] reply-to
So, in economic terms, the list will be more costly to maintain, as well as less pleasant to maintain. Who is going to pay? James R. Cutler [EMAIL PROTECTED] On May 8, 2008, at 11:35 AM, Jim Popovitch wrote: In the end everybody wins... except the guys/gals who have to maintain it. ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [NANOG] OSPF minutia, and, technote publication venues
Hello All , On Mon, 5 May 2008, Paul Vixie wrote: [EMAIL PROTECTED] (Steve Gibbard) writes: ...snip... But yes, Joe's ISC TechNote is an excellent document, and was a big help in figuring out how to set this up a few years ago. and now for something completely different -- where in the interpipes could a document like that have been published, vs. ISC's web site? the amount of red tape and delay involved in Usenix or IETF or IEEE or ACM are vastly more than most smart ops people are willing to put in. where is the light / middle weight class, or is every organization or person who wants to publish this kind of thing going to continue to have the exclusive and bad choice of blog it, or write an article for ;login:/ACM-Queue/Circle-ID, or write an academic paper and wait ten months? isn't this a job for... NANOG? ^^ Hear , Hear ! I second the motion . Sorry about the 1-2 line response , But I beleive it was needed . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkSystem Engineer | 2133McCullam Ave | Give me Linux | | [EMAIL PROTECTED] | Fairbanks, AK. 99701 | only on AXP | +--+ ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: potential hazards of Protect-America act
Well, it could affect the equipment required, floor space, real estate cost, log retention, bandwidth requirements, equipment addressing, procedures, training, trouble desk, employee count and, probably, more. So, I would think it would affect network operations. I would suggest that it is on topic. There are business and legal hazards along with the technical hazards. Compliance with differing data privacy and retention laws are not the least of these. On Jan 29, 2008, at 3:46 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I wonder if this is on topic? http://www.crypto.com/papers/paa-ieee.pdf Among other things, it discusses technical hazards of the act. --Michael Dillon James R. Cutler [EMAIL PROTECTED]
Re: Assigning IPv6 /48's to CPE's?
On Jan 4, 2008 6:02 PM, Rick Astley [EMAIL PROTECTED] wrote: I know large mostly unused pools of client IP's make it more difficult to use traditional worm propagation methods in IPv6[1], but if customers move from IPv4 firewalls to IPv6 routers, we still lose an important layer of security. Seems like an understatement. Ipv6 addressing doesn't merely make them more difficult, they make traditional propagation methods and attack techniques that rely on 'scanning' a network from outside impossible to execute. If every subnet (end site) has a /64, and you can guess 16 of those bits (say most networks set the top 16 bits to zero and generate the rest using a true random number generator, for security's sake), there are so many IPs that random scanning has a probability of finding hosts so small, it is negligible It would take 9 years to probe 10% of the addresses of a single end site, assuming you can scan 100,000 ips per second. If the host id is sufficiently random or opaque to the outside world, then this is every bit as good as a well chosen password; it is essentially private, except to nodes on the local subnet(who can monitor and ping multicast addresses). I don't believe a worm can't effectively propagate and spend 10 years trying to find the IP address of the one or two computers at site X before moving to site Z that has 4 computers in a /64 some where... A worm that has to connect to a remote machine would definitely have to discern the IP through some method other than brute force scanning. Such as a clean system contacting an infected system to make a request (i.e. download a webpage) At which time the infected system stores requestor's ip in a database to probe later. On the other hand, an IPv6 host could in theory bind a new IP address for each group of web requests, not attach any listeners to that IP, and make that IP cease to exist after the web requests complete. Since the /64 is so large... this essentially accomplishes what NAT does for IPv4 users... the IP address is private, by virtue of the fact, that the host primary interface address cannot be guessed. Even if it is guessed, firewall rules may block traffic from the probing address long before they get close to randomly hitting a live IP :) -- -J
Re: Assigning IPv6 /48's to CPE's?
On Dec 31, 2007 3:26 PM, Church, Charles [EMAIL PROTECTED] wrote: like a natural choice, leaving 80 bits for network addressing. This waste of space seems vaguely familiar to handing out Class A netblocks 20+ years ago. We'll never run out... Maybe it's just me though. The comparison is mistaken. Not without a major fundamental change in the way ip addresses are used (ridiculous waste of addresses by end-sites causing them to require numerous subnets and request additional /48s) IPv6 provides ample room for growth at end sites, and giving out /32s or so to ISPs and telling them to hand out /48s and /56s seems reasonably conservative. 64-bits maximum length network address. It's not much a waste for every end-user to get a /56 Think of it as IPv4, but instead of everyone having gotten a Class A, every end site got on average 0.0006 of an IPv4 /32 (host address), no matter how large their site. 1 IPv4 Class A is approximately 0.39% of available IPv4 space 1.67*10^7/(4.29*10^9) 1 IPv6 /48 is approximately 0.827% of available IPv6 space. You need a calculator for that second one :) But assignable space in V6 could be exhausted without end-site IPs running out. The place where major problems could be run into is deciding how big a block your ISPs and LIRs get, or if the registries are entertaining the concept of PI space for v6.. how large those blocks are. Does a small ISP ever get such a small block that they may run out of /48s to assign? Does a large ISP ever get such a large block, the RIRs may run out of ISP blocks to assign? Both situations would be extremely undesirable. In the former case, they need multiple blocks, but RIR policy for v6 might not provide a way for them to get that the utilization of additional allocations also add undesirable complexity to networks, which is very bad: design of IPv6 is supposed to avoid such things. In the latter case... IPv6 IP addresses have not been 'exhausted', but now, there can now be no new ISPs or PI allocations; everything having been assigned to some major provider who has not given out very many of their /48s yet, or who is giving out /56s and hording the rest of the address space, never to be assigned. -- -J
Re: Can P2P applications learn to play fair on networks?
Possible scenario... Subscriber bandwidth caps are in theory too high, if the ISP can't support it -- but if the ISP were to lower them, the competition's service would look better, advertising the larger supposed data rate -- plus the cap reduction would hurt polite users. In the absence of the P2P applications, the limits were fine, so hurting the P2P application may be a preferable solution to the ISP charging everyone more to support the excessive bandwidth usage of the 2-3% of subscribers who use P2P applications, or dropping that 6m bandwidth cap to a 256 kilobit cap just to be able to guarantee everyone can use it all at the same time. Many ISP customers might thank them for blocking P2P, if it keeps their subscription costs low --- in the absence of sufficient customer demand for P2P, it will be throttled, or filtered; if they're paying for a 1.5m connection (not a 6m) and it costs half the price of a normal 1.5m connection, but blocks P2P, many customers might like to make that tradeoff. That's the ONLY thing they have to give us. Forget looking at L4 or alike, that will be encrypted as soon as ISPs start to discriminate on it. Users have enough computing power available to encrypt everything. I'm afraid the response could then be for providers that limit P2P to begin treating everything encrypted as suspicious. The source and destination address are enough to do a lot in theory If the first packet exchanged between two hosts was sourced from a subscriber, then ISP monitoring mechanism can record a session... Session started from inside to outside; just like a stateful firewall. The ratio of bytes a customer sends to an address versus number of bytes they receive from that address can be used: anything above 1.0 is an upload, anything below 1.0 is a download; high ratio = reduced bandwidth cap. Very poor treatment could be given to sessions started from outside to inside. An address that only one or two subscribers exchange traffic with is probably a P2P app. An address that many subscribers try to exchange traffic with is probably an E-commerce site. Thus the whitelists could be built through automated means, just by counting the number of distinct inside sources per outside destination. ( if 1000 different customer source addresses send encrypted port 443 to one host, then that host could be automatically listed as probably not a P2P host) -- a second possibility is the ISP could examine SSL certificate of remote destination -- f a site has gone through the trouble of having a high-grade X509 certificate signed by a for-fee official CA, then it's probably not a P2P peer. If a user tries to connect to a site that has no certificate signed by a recognized CA, then it's probably either a possible phisher a P2P peer --- these could in theory be blocked as a stop phishing measure. Security measure Only if P2P shared network resources with other applications well does increasing network resources make more sense. If your network cannot handle the traffic, don't offer the services. Exactly what they would seem to be doing. By blocking P2P uploads or throttling them, they are choosing to not offer full P2P access. Some ISPs may block P2P and be very quiet about it, and it's unfortunate, as customers would want to know about extra restrictions on the use of their X-megs connection. Generally warnings that excessive-bandwidth applications may be limited will be mentioned in ISPs' existing Acceptable Usage policies, they're probably just not outright saying we block Xyz. P2P applications seem to be a valuable tool; however, it would be an ISP's available choice to refuse to offer it -- or require P2P users to pay extra, in proportion to the additional usage of their networks that are required to function with the service. When P2P usage is a burden on their network. Their network, their rules. The bigger issue I would say, is that in many areas, provider monopolies exist on affordable residential access services. So if Provider A happens to be the cable company in a local area, that owns all that infrastructure, and the rights to hang cable -- there's no opportunity for a Provider B to satisfy the demand, if they can't get a wire between them and their would-be customer No competition and no cost-effective alternative access path gives Provider A too much free reign. Free reign in terms of limiting consumer choice and forcing customers to accept substandard or partial services, when customers are tricked by shiny advertising into thinking they are buying high-grade fully featured services. -- -J
Re: dotted AS numbers in asn.txt
Andreas Ott wrote: Hi, since when does ftp://ftp.arin.net/info/asn.txt contain dotted AS numbers? Where is the new formatting documented, asn.h ? It just broke a scriptology we use to generate AS lookups for 'offline' customers (please don't ask :) ). http://www.google.co.uk/search?q=32+bit+asn J -- COO Entanet International T: 0870 770 9580 W: http://www.enta.net/ L: http://tinyurl.com/3bxqez
Re: DNS Hijacking by Cox
On 7/22/07, Steven M. Bellovin [EMAIL PROTECTED] wrote: I would suggest not underestimating the ingenuity and persistence of the bad guys to escalate the neverending war, when a new weapon is invented to use against them. If there's a way around it, history has shown, the new weapon quickly becomes worthless, you get to use it maybe for a month or two. Maybe that's enough, if you can be assured of constantly coming up with new improvements. It's really tiresome stuff, and if ISPs do it, they'll find themselves having to get more and more invasive for each new and improved anti-bot weapon. Much more likely than not the bad guys even read the list (if not the other few security lists where the events of reported DNS mangling by Cox have been mentioned) and now know how to proceed to minimize the disruption to their annoying botnets. Hint: the common ways to try to remove a bot are not hard for bots to detect; kiddies often scripted the things to not allow removal, anyways. End result: Legitimate IRC users get blocked, script kids quickly adapt, and get their well-hidden botnets back into place and patched against DNS-based hacks in the future. Conclusion: Everybody loses (ISP and legit IRC users), except the script kiddies now have more robust junk (and another victory). So -- I think that DNSSEC, if deployed, will protect users who care, even against their ISP. It won't protect the clueless; I'm not sure I would suggest the protection you get with DNSSEC is not so solid, even for the non-clueless. I see DNSSEC alone as no protection by itself, even with the additional assumptions. An ISP can possibly instead of changing the DNS, redirect traffic destined for the actual target IP address (from their own users), or push traffic through transparent proxies that accomplish the same end.. In fact, it will be less visible to the user what is occuring (at least with DNS manipulations, the user can _SEE_ that what happened, if they are not among the clueless, and maybe get around DNS mangling, by skipping DNS and going to the _right_ IP) IRC traffic is much like SMTP in certain respects -- it is not encrypted, there is no digital certificate that can be used to verify the peer legitimately uses the ip address (or dns name) you think it does when you connect. And spammers are a problem (Unauthorized bot nets logging on to IRC networks are really just a very bad type of spammer, a type that is often very difficult for IRC networks to detect and eliminate; and IRC networks risk all their IRC servers being DDoSed later in retaliation, just for trying to kill off a botnet -- the d*** things may just autoconnect to the next network, and switch secret channels, from a list with God knows how many entries). - I am doubting most of the world sees DNSSEC implementations as the ideal solution to any current problem -- compared to the current DNS, it seems like overkill to digitally sign everything.. Considering the excessive bloat and overhead of DNSSEC implementations, when there is a bigger hole in the security of the underlying protocol (TCP/IP itself) The canonball-sized hole (Your ISP can pretend to be any IP address they want) should have priority to be be plugged, it should be way ahead on the list of the pinhole (Your ISP can pretend that a given name is associated with any IP address they want instead of the correct one). OTOH, universally deployed IPSEC seems even farther off. If it is even a workable plan for a netizen (to distrust the ISP), considering the ISP can always, after all, block instead of redirect. -- -J
Vericenter Denver Outtage
Does anyone have further information on the Vericenter Denver outtage? Support is aware of the issue, however, they could not feed me a problem description at the time of ticket creation or an ETR? James Baldwin
Re: Vericenter Denver Outtage
Outtage with the primary sprintlink connection. Still no ETR. James Baldwin On Jul 9, 2007, at 2:09 AM, James Baldwin wrote: Does anyone have further information on the Vericenter Denver outtage? Support is aware of the issue, however, they could not feed me a problem description at the time of ticket creation or an ETR? James Baldwin
Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)
On 6/4/07, David Schwartz [EMAIL PROTECTED] wrote: I posit that a screen door does not provide any security. A lock and deadbolt provide some security. NAT/PAT is a screen door. This is a fine piece of rhetoric, but it's manifestly false and seriously misleading. Hi, David I think the essence of what prior post is suggesting is that NAT itself is not necessarily a security feature, but there is a popular method of using NAT to get a feature that comes with it and has security benefits, that really goes by the name SPI, and which can be decoupled from what it means to have a NAT, and that feature can and should perhaps be implemented alone, on its own right, instead of NAT. In other words In IPv4 we got a security gain that happened to be packaged with NAT, but in ipv6 we have another way of getting almost the very same gains, except without the disadvantages of NAT. It should be cheaper to implement SPI than full blown NAT capabilities. However, that greatly depends on what consumers (end users) will demand, and a handful of hardware manufacturers will provide, if/when some inexpensive gateway type hardware becomes available for end users that has IPv6 support. If IPv6 allows them to not buy the NAT box, then the typical end user won't necessarily instead buy a SPI box, they may buy no box at all, other than say, a $10 switch or hub, or it might be on the same box as their access equipment, it will be less expensive. Therefore they might have fewer protections in the real world, unless upstream provider's routing equipment provides them with SPI: that's not very likely. NAT-less SPI may strangely have a higher price tag than NAT+SPI. A hardware vendor selling an IPv4 SPI box might typically have labelled that product as a security appliance, making it cost more, because SPI/security/firewall was considered an enterprise feature, NAT was considered a commodity functionality. For SPI without translation to replace NAT, it needs to become a commodity functionality that every end user IPv6 gateway supports and has enabled by default, setup with no holes (i.e. ports open) by default, out of the box. It is understandable that end users rely on the cheapest boxes they can get, that best suited their immediate needs -- it was convenient for the equipment to have secure defaults; I would hope that hardware makers would continue to provide security by default with IPv6, since all too many OSes have insecure defaults. Should users want it badly enough, nothing forces hardware makers to stick with the best known solutions -- HW makers may specify NAT or other hacks all on their own... if the transport protocol standards don't specify it. I think some hardware maker is probably going to just invent and patent IPv6 NAT, since noone thought to specify it, and implement in their products just to list [brand name] IP Version 6 private addressing in their marketing materials, for said premium device(s). Today's IPv4 NAT box may well be the next decade's SOCKS6 proxy box, even if there is no technical need whatsoever for it; there is a comfort factor here, since some users of IPv4 have become accustomed to certain hacks, and they will not be forgotten easily. IPv6 users may not like that in case an internal machine is compromised to some extent, , without NAT, the actual ip addresses of other machines behind the gateway may have become known in advance of the initial compromise, but if the addresses were private, extra effort would normally be required to discover what exactly the private addresses were, only possible after the compromise, while the timer is ticking for the incursion to be discovered. I can give you the root password to a Linux machine running telnetd and sshd. If it's behind NAT/PAT, you will not get into it. Period. That might be so, but the assurance may not be 100%. In practice, your NAT box, even if properly configured may well have a number of different types of holes, and it may be possible for an outsider to open a session you didn't anticipate. I would suggest that implementations of NAT and SPI suffer the same type of deficiencies in that respect. Are there things most stateful inspection firewalls can do that NAT/PAT does not do? Definitely. Are those things valuable and in some cases vital? Definitely. So why lie and distory what NAT/PAT actually does do? A large class of security vulnerabilities require the attacker to reach out to the machine first, and NAT/PAT stops those attacks completely. If there's something remaining a NAT is good for, that doesn't have a much better replacement technology, or hasn't been mentioned yet anywhere, then it should be spelled out, to the ipv6 wg, so it can be ascertained... whether a NAT is still necessary to offer that advantage, or whether NAT is merely the box that capability happened to come in for IPv4. Is a car alarm useless because some professtional theives can disable it? Is a lock useless because
RE: 6bone space used still in the free (www.ietf.org over IPv6 broken) (Was: why same names, was Re: NANOG 40 agenda posted)
I think what's going on is that packets from www.ietf.org don't make it back to my ISP. A ping6 or traceroute6 doesn't show any ICMP errors and TCP sessions don't connect so it's not a PMTUD problem. So it's an actual timeout. I also just started noticing this, that is, that it does not work. And there is a very simple explanation for this: 6bone space. We (OCCAID) had recently turned up peering with a few networks (including HE and others) and as a result our outbound path to HEAnet and other networks had changed. Some of the abrupt route changes are being corrected today evening and hopefully should resolve pMTU problems in reaching www.ietf.org. If you continue to experience trouble in reaching thru OCCAID via IPv6, please don't hesitate to drop me a line in private. Regards, James
RE: qwest backbone
we are seeing big issues between sbc/att and anything connected to level3... James -Original Message- From: Gregori Parker [EMAIL PROTECTED] Subj: RE: qwest backbone Date: Mon May 21, 2007 1:36 pm Size: 676 bytes To: NANOG list nanog@nanog.org Savvis is also reporting severed fiber, unclear as to whether it's their own or upstream -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of prue Sent: Monday, May 21, 2007 1:12 PM To: [EMAIL PROTECTED] Cc: nanog Subject: Re: qwest backbone Hi, I believe I can offer some insight into this outage. I have gotten a report which is affecting another network: Level3 fiber cut between Seattle and Olympia Olympia is a city south of Seattle about 50 miles or so, for those who don't know the area. I imagine, based on your reports, that Qwest is also being affected by the fiber cut. Walt
