Re: Ethernet Services cards types queue values
Burak, The idea is that you use the high queue cards as UNI ports terminating customers, where you would have many service instances and complex QOS policies such hierarchical shaping and multiple classes per customer. On the core links you would usually need less queues as you would have a generic aggregated QOS policy. Specifically on the 7600 I think you are looking at the regular LAN modules (as opposed to the ES20/ES+ modules) which have the lower queue numbers per port. These modules (the LAN modules) also have more limited functionality support as they do not have the ability to support many features supported only on the ES modules. For some services/features you would require the ES modules to be on either UNI or NNI (depending on what you want to achieve). For ASR9000 there are also a few module types following the same model above. More queues for UNI and less queues (and thus cheaper) for NNI, but in this case supporting all the different features. Arie On Wed, Jan 27, 2010 at 8:18 AM, Burak Dikici bdik...@gmail.com wrote: Hello, There is different types for the Cisco 7600 Series Ethernet Services cards. ( More expensive cards with high queue values and less expensive cards with low queue values.) http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-549419.html Hardware queues ES Plus XT 40G line cards • 128,000 ingress queues • 256,000 egress queues ES Plus XT 20G line cards *• 64,000 ingress queues* • 128,000 egress queues Hierarchical QoS (H-QoS) http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-570730.html Hardware queues Cisco 7600 Series ES Plus Transport 40G and 20G Line Cards *Supporting up to 16 level 4 queues per physical port* Hierarchical QoS (H-QoS) Low queue cards have got only 4 queues per physical port. High queue cards have got minimum 64.000 queue. This is very huge difference. In what kind of scenario do we have to use the High queue cards ? Could you give some examples please ? Kind Regards. Burak
RE: Using /126 for IPv6 router links
On Wed, 27 Jan 2010, Pekka Savola wrote: :: On Tue, 26 Jan 2010, Igor Gashinsky wrote: :: Matt meant reserve/assign a /64 for each PtP link, but only configure the :: first */127* of the link, as that's the only way to fully mitigate the :: scanning-type attacks (with a /126, there is still the possibility of :: ping-pong on a p-t-p interface) w/o using extensive ACLs.. :: :: Anyways, that's what worked for us, and, as always, YMMV... :: :: That's still relying on the fact that your vendor won't implement :: subnet-router anycast address and turn it on by default. That would mess up :: the first address of the link. But I suppose those would be pretty big ifs. Or, relying on the fact that (most) vendors are smart enough not to enable subnet-router anycast on any interface configured as a /127 (and those that are not, well, why are you buying their gear?).. If a worst-case situation arises, and you have to peer with a device that doesn't properly support /127's, you can always fall back to using /126's or even /64's on those few links (this is why we reserved a /64 for every link from the begining).. -igor
Re: Using /126 for IPv6 router links
The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. hm randy
Re: Using /126 for IPv6 router links
On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. hm randy That would, indeed, work if we weren't short of class B networks to assign. Owen
Re: Using /126 for IPv6 router links
Igor Gashinsky wrote: On Wed, 27 Jan 2010, Pekka Savola wrote: :: On Tue, 26 Jan 2010, Igor Gashinsky wrote: :: Matt meant reserve/assign a /64 for each PtP link, but only configure the :: first */127* of the link, as that's the only way to fully mitigate the :: scanning-type attacks (with a /126, there is still the possibility of :: ping-pong on a p-t-p interface) w/o using extensive ACLs.. :: :: Anyways, that's what worked for us, and, as always, YMMV... :: :: That's still relying on the fact that your vendor won't implement :: subnet-router anycast address and turn it on by default. That would mess up :: the first address of the link. But I suppose those would be pretty big ifs. Or, relying on the fact that (most) vendors are smart enough not to enable subnet-router anycast on any interface configured as a /127 (and those that are not, well, why are you buying their gear?).. If a worst-case situation arises, and you have to peer with a device that doesn't properly support /127's, you can always fall back to using /126's or even /64's on those few links (this is why we reserved a /64 for every link from the begining).. If this is the case, why not just use /64s from the beginning? Why bother with hacking it up if it's only going to be reserved anyway? I'm trying to understand how reserving-and-hacking a /64 makes administration any easier. Even if all ptp are coming out of a single /64 (as opposed to reserving a /64 for each), what benefits are there to that? It seems as though that this is v4 thinking. As someone pointed out off-list (I hope you don't mind): one could argue a bunch of sequential /127s makes it apparent what your infrastructure addresses are. You can just as easily ACL a /48 containing infrastructure /64s as you can ACL a /64 containing infrastructure /127s. ...amen to that, if I can't figure out a way to sink/drop the null addresses first. Steve
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 03:09:11 -0800 Owen DeLong o...@delong.com wrote: On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. hm randy That would, indeed, work if we weren't short of class B networks to assign. And we shrunk the Internet.
Re: Using /126 for IPv6 router links
On Wed, 27 Jan 2010 23:08:36 +1030 Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Wed, 27 Jan 2010 03:09:11 -0800 Owen DeLong o...@delong.com wrote: On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. hm randy That would, indeed, work if we weren't short of class B networks to assign. And we shrunk the Internet. Should have been Or
Re: Using /126 for IPv6 router links
the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. That would, indeed, work if we weren't short of class B networks to assign. Would you clarify? Seriously? we used to think we were not short of class B networks randy
Re: Using /126 for IPv6 router links
In message m2sk9rsobb.wl%ra...@psg.com, Randy Bush writes: the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. That would, indeed, work if we weren't short of class B networks to assign. Would you clarify? Seriously? we used to think we were not short of class B networks Really? Do you have a citation? It should have been clear to anyone that thought about it that IPv4 address where not big enough to support every man and his dog having a network. I know when I was getting my first class B address block in '88 that it was obviously not sustainable but I'll get one while I can because that and class C's were all that were available and it could be justified under the rules as they stood then. CIDR when it came along didn't change my opinion, though it did delay the inevitable as did PNAT. I don't see the same thing with /48 as the basic allocation provided RIR's don't do greenfield all the time but instead re-allocate blocks when they are not maintained. Always doing greenfield allocations will exhaust any allocation scheme in time. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Using /126 for IPv6 router links
On 1/26/2010 23:32, Mark Smith wrote: A minor data point to this, Linux looks to be implementing the subnet-router anycast address when IPv6 forwarding is enabled, as it's specifying Solicited-Node multicast address membership for the all zeros node address in it's MLD announcements when an interface comes up. Yes, I believe you are correct. It appears to be implemented. When I ping the subnet anycast from a Linux or Windows XP box I get a reply from the IPv6 router on my LAN. The router is a Linux box running Kernel 2.6.31. Interestingly, on a Linux box, the ping6 command shows the router's unicast address answering the pings (same goes for ping6 under Cygwin on a Windows box). But on a Windows box ping shows the anycast address answering. However, in both cases packet captures show it actually is the unicast address of the router answering, which I believe is the expected behavior. Windows ping just shows the wrong address for whatever reason. smime.p7s Description: S/MIME Cryptographic Signature
Re: Using /126 for IPv6 router links
On 27-1-2010 2:16, Steve Bertrand wrote: ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well. When OSPFv3 goes down and you are trying to debug, what IPv6 will you ping to check if the second side is accessible? -- Grzegorz Janoszka
Re: L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
Hello, L-Root maintenance is starting in 30 mins ( 2010-01-27 1800 UTC ) Regards Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT Hi As part of staged, incremental deployment of DNSSEC in the root zone L-Root will begin serving a Deliberately Unvalidatable Root Zone (DURZ) after the completion of its scheduled maintenance at 2010-01-27 1800 UTC - 2000 UTC Please contact L-Root NOC via n...@dns.icann.org or T: +1.310.301.5817 if you have any questions. Please contact with roots...@icann.org if you have any questions regarding DNSSEC Deployment at root zone.
Re: Foundry CLI manual?
If you have older foundry gear (IronCore, JetCore, MG8) do a google search for Using Packet Over SONET Modules. Jonas On Sat, 2010-01-23 at 16:51, David Hubbard wrote: Anyone have the Foundry/Brocade CLI reference PDF they could send me? Brocade feels you should have a support contract to have a list of commands the hardware you purchased offers and I'm having difficulty with a oc12 pos module. Thanks, David
Re: Using /126 for IPv6 router links
On 1/27/2010 5:09 AM, Owen DeLong wrote: On Jan 27, 2010, at 2:38 AM, Randy Bush wrote: The general intent of the /48 allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. hm randy That would, indeed, work if we weren't short of class B networks to assign. Owen ITYM --- That would, indeed, work if we weren't so short sighted in our view of how the demand economics term) would expand to exceed the supply. [For the record I do not see any way of foreseeing the unforeseen (and unforeseeable). I ask only that the latest whizbang be marketed as the latest whizbang (which is likely to be be pretty impressive--it always has been), not the answer for all of time.) -- Government big enough to supply everything you need is big enough to take everything you have. Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
RE: Using /126 for IPv6 router links
-Original Message- From: Grzegorz Janoszka [mailto:grzeg...@janoszka.pl] Sent: Wednesday, January 27, 2010 12:10 To: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links On 27-1-2010 2:16, Steve Bertrand wrote: ip address x.x.x.x 255.255.255.252 ipv6 address 2607:F118:x:x::/64 eui-64 ipv6 nd suppress-ra ipv6 ospf 1 area 0.0.0.0 I've found that this setup, in conjunction with iBGP peering between loopback /128's works well. When OSPFv3 goes down and you are trying to debug, what IPv6 will you ping to check if the second side is accessible? FWIW, I like to use static, meaningfully-assigned Link Locals ... regardless of the link type. /TJ
Re: L-Root Maintenance 2010-01-27 1800 UTC - 2000 UTC
Hello World, L-Root has completed it's maintenance and now serving DURZ. You can observe L-Root DSC Stats by visiting http://stats.l.root-servers.org Please contact L-Root NOC via email n...@dns.icann.org or T: +1.310.301.5817 if you have any questions Please contact roots...@icann.org if you have any questions regarding DNSSEC Deployment at root zone. Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT / AS20144 / AS-LROOT Peering info: http://as20144.peeringdb.com On 1/27/10 12:29 PM, Mehmet Akcin meh...@icann.org wrote: Hello, L-Root maintenance is starting in 30 mins ( 2010-01-27 1800 UTC ) Regards Joe Abley / Mehmet Akcin / Dave Knight ICANN DNS Ops / L-ROOT Hi As part of staged, incremental deployment of DNSSEC in the root zone L-Root will begin serving a Deliberately Unvalidatable Root Zone (DURZ) after the completion of its scheduled maintenance at 2010-01-27 1800 UTC - 2000 UTC Please contact L-Root NOC via n...@dns.icann.org or T: +1.310.301.5817 if you have any questions. Please contact with roots...@icann.org if you have any questions regarding DNSSEC Deployment at root zone.
Re: DDoS mitigation recommendations
On Tue, 26 Jan 2010 09:56:14 PST, Gerald Wluka said: To date the company has over-invested in technology and under-invested in sales and marketing. That is changing now: the company is moving to The Bay Area. Hate to say this, but that change is hardly a selling point to this crowd. ;) pgp2dJh9ltuev.pgp Description: PGP signature
Re: Comcast IPv6 Trials
On Wed, Jan 27, 2010 at 11:23, John Jason Brzozowski john_brzozow...@cable.comcast.com wrote: Folks, I am emailing you today to share some news that we hope you will find interesting. Today we are announcing our 2010 IPv6 trial plans. For more information please visit the following web site: http://www.comcast6.net We have also made available a partial, dual-stack version of our portal which can be found at: http://ipv6.comcast.net Incredible news! Very exciting... unfortunately, at least from here (Comcast Business Class in the SF Bay Area), at the moment, both of these links appear to lead to the same portal page without any information visible regarding your IPv6 trial plans. Best, -Bill
Re: Comcast IPv6 Trials
There was an adjustment that was required on our end. It is in place. Do you have any form of IPv6 connectivity? If yes, this is why you are seeing the same portal. This will clear up shortly. John On 1/27/10 3:47 PM, Bill Fehring li...@billfehring.com wrote: On Wed, Jan 27, 2010 at 11:23, John Jason Brzozowski john_brzozow...@cable.comcast.com wrote: Folks, I am emailing you today to share some news that we hope you will find interesting. Today we are announcing our 2010 IPv6 trial plans. For more information please visit the following web site: http://www.comcast6.net We have also made available a partial, dual-stack version of our portal which can be found at: http://ipv6.comcast.net Incredible news! Very exciting... unfortunately, at least from here (Comcast Business Class in the SF Bay Area), at the moment, both of these links appear to lead to the same portal page without any information visible regarding your IPv6 trial plans. Best, -Bill = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 =
Re: Using /126 for IPv6 router links
On 28/01/2010, at 1:51 AM, Randy Bush wrote: the general intent of a class B allocation is that it is large enough for nearly everybody, with nearly everybody including all but the largest of organisations. That would, indeed, work if we weren't short of class B networks to assign. Would you clarify? Seriously? we used to think we were not short of class B networks We also used to have a protocol with less total addresses than the population of the planet, let alone subnets. In 2000::/3, assuming we can use 1 in every 4 /48s because, well, I'm being nice to your point, we still have 1300 /48s per person. http://www.wolframalpha.com/input/?i=%28%282%5E45%29%2F4%29%2Fearth+population And that's /48s. What if say 50% of the address space is /48s and 50% of the address space is /56s? Then we have 675,000 networks per person. If we botch that up then we've done amazingly badly. Then we'll move on to 4000::/3. -- Nathan Ward
Re: Using /126 for IPv6 router links
:: If a worst-case situation arises, and you have to peer with a device that :: doesn't properly support /127's, you can always fall back to using /126's :: or even /64's on those few links (this is why we reserved a /64 for every :: link from the begining).. :: :: If this is the case, why not just use /64s from the beginning? Why :: bother with hacking it up if it's only going to be reserved anyway? :: :: I'm trying to understand how reserving-and-hacking a /64 makes :: administration any easier. :: :: Even if all ptp are coming out of a single /64 (as opposed to reserving :: a /64 for each), what benefits are there to that? It seems as though :: that this is v4 thinking. This really has nothing to do with wanting to use the space more efficiently, it has to do with overcoming potential operational issues. Reserving the whole /64 is what makes administration easier in face of different vendor capabilities, using only /127 is what's operationally safer on PtP links -- you face 2 major issues with not using /127 for PtP-type circuits: 1) ping-ponging of packets on Sonet/SDH links Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP interface, and somebody comes along and ping floods 2001:db8::2, those packets will bounce back and forth between the 2 sides of the link till TTL expires (since there is no address resolution mechanism in PtP, so it just forwards packets not destined for him on). 2) ping sweep of death Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually needed to learn... (and, if an important entry times out, and now can't get re-learned, *really* bad shit happends, trust me on that one) Both of these can be mitigated by either *really* heavy-handed ACLs, or changes to SONET/SDH forwarding semantics, as well as ARP queue prioritization, but very few vendors support those right now. For most people, using /127's will be a lot operationaly easier then maintain those crazy ACLs, but, like I said before, YMMV.. -igor
RE: DDoS mitigation recommendations
Hi, On Tue, 2010-01-26 at 09:56 -0800, Gerald Wluka wrote: I am new to this mailing list - this should be a response to an already started thread that I cannot see: Welcome to NANOG! IntelliguardIT has a new class of network appliance that installs inline (layer 2 appliance). It has no impact on current network capacity and automatically manages flash crowds gracefully. Prove it. As far as I can tell, DDoS mitigation appliances are mostly smoke and mirrors, and I used to work for an IDS vendor. To date the company has over-invested in technology and under-invested in sales and marketing. That is changing now: the company is moving to The Bay Area. LOL. As a testament to this over-investment we have a few customers in Asia who had CiscoGuard and/or Arbor Network solutions deployed - they were failing! IntelliGuard's solution solved their DDoS problems. Can you cite these clients? If you would like to learn more please contact me directly (the IntelliGuardIT website is quite dated at this stage. William
Re: 1/8 and 27/8 allocated to APNIC
leo, This is done, you should see it propogating. regards, darren On Fri, Jan 22, 2010 at 08:58:30AM -0800, Leo Vegoda wrote: On 22 Jan 2010, at 7:16, William Allen Simpson wrote: [...] http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/ Because relying on a blog post for policy really meets everybody's definition of rationality :-( It's not a policy, it's an explanation of the reasoning behind the implementation of the policy. Regards, Leo
Re: Comcast IPv6 Trials
On Wed, Jan 27, 2010 at 12:52, John Jason Brzozowski john_brzozow...@cable.comcast.com wrote: There was an adjustment that was required on our end. It is in place. Great, got it working, thanks! ...partially Safari/OSX's fault, but mostly mine for not realizing what was going on quickly enough. Do you have any form of IPv6 connectivity? If yes, this is why you are seeing the same portal. This will clear up shortly. Yeah... for now that's a Hurricane Electric tunnel, but native v6 over DOCSIS 3 would be way cooler, not to belittle the amazing efforts of HE. -Bill
Re: Comcast IPv6 Trials
On Wed, Jan 27, 2010 at 11:23 AM, John Jason Brzozowski john_brzozow...@cable.comcast.com wrote: Folks, I am emailing you today to share some news that we hope you will find interesting. Today we are announcing our 2010 IPv6 trial plans. For more information please visit the following web site: http://www.comcast6.net We have also made available a partial, dual-stack version of our portal which can be found at: Great work! I hope we see a lot more of these types of announcements! I have my own cooking in the oven :) Cameron
Next Generation Leaders (NGL) programme
All - This program is a nice opportunity for newer entrants to the Internet community. If you know someone who might benefit, please pass this along. Thanks - - Lucy -- Forwarded message -- Date: Wed, 27 Jan 2010 12:48:31 -0500 From: Connie Kendig ken...@isoc.org To: ly...@isoc.org Subject: Re: NGL Outreach Assistance The Internet Society (ISOC) is happy to announce a new programme beginning in 2010: the ISOC Next Generation Leaders (NGL) programme. The NGL was officially launched 6 October 2009 at a youth forum lunch during the ITU Telecom World week in Geneva. The programme is aimed at emerging talents across the globe, between the ages of 20 and 40, and is a unique blend of coursework and practical experience to help prepare young professionals from around the world to become the next generation of Internet technology, policy, and business leaders. Programme entrants will complete a tailored eLearning course, covering the essential topics required for effective interactions and relationships within the Internet ecosystem, as well as key concepts and emerging issues in Internet governance. They will be encouraged to apply for the Internet Society?s representation programmes, such as ISOC Ambassadorships to the Internet Governance Forum (IGF), the World Bank, and OECD, and the ISOC Fellowship to the Internet Engineering Task Force (IETF). At the end of the programme, all Next Generation Leaders programme graduates will be invited to submit a proposal for a project focused on an Internet development issue within their own communities. Of those, three projects will be chosen and the respective project leaders will be invited to Geneva for a final, one-week course in Internet diplomacy. The three project leaders will be recognized as the Next Generation Leaders programme laureates, rewarded with special opportunities to network with some of the Internet?s most respected leaders and to participate in special leadership events, and they may be encouraged to start new Internet Society Chapters in their communities. More information on the programme can be found at www.InternetSociety.org/Leaders You may sign up to receive periodic information on the NGL but visiting the programme site and clicking on Candidates: Register for NGL Information. We will be sharing application details for the eLearning component through the sign up information list in the coming months. If you have any questions or comments about the Next Generation Leaders programme, please contact lead...@internetsociety.org Best wishes, Connie J Kendig Sponsored Programs Grants Manager Internet Society www.isoc.org ken...@isoc.org Tel: (703) 439-2136
Re: Comcast IPv6 Trials
Wonderful! In all seriousness, will any attempt be made to select trial applicants based on (apparent) clue level and/or to receive feedback through channels other than the usual Tier 1 support?
Countries with the most botnets
A colleague needs to know, along with citable sources if possible. Ideally - number of zombified PCs, percentage of zombified PCs, name of nation, source. Threat reports from symantec and macafee suggest the US leads, with China a very close second. Yes, we realize that answers will be imperfect. --Steve Bellovin, http://www.cs.columbia.edu/~smb
RE: Countries with the most botnets
The Conficker data would be one empirical source you can look at. You have a break down by ASN and Country: http://www.shadowserver.org/wiki/pmwiki.php/Stats/Conficker -Original Message- From: Steven Bellovin [mailto:s...@cs.columbia.edu] Sent: Wednesday, January 27, 2010 3:08 PM To: nanog@nanog.org list Subject: Countries with the most botnets A colleague needs to know, along with citable sources if possible. Ideally - number of zombified PCs, percentage of zombified PCs, name of nation, source. Threat reports from symantec and macafee suggest the US leads, with China a very close second. Yes, we realize that answers will be imperfect. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Comcast IPv6 Trials
On Wed, Jan 27, 2010 at 2:50 PM, Steven Bellovin s...@cs.columbia.eduwrote: Wonderful! In all seriousness, will any attempt be made to select trial applicants based on (apparent) clue level and/or to receive feedback through channels other than the usual Tier 1 support? From http://www.comcast6.net/faq.php: *How will you select trial areas?* Some of our trials will not be geographically-bound, meaning a customer from anywhere in our network could participate, while other trials will be bound to particular areas. *How will you select customers to participate in these trials?* Customers can volunteer to participate in a trial by completing an online form at the Comcast IPv6 Information Center, at http://www.comcast6.net/volunteer.php. Once we're ready to start a trial, we will search for customers meeting any applicable criteria for participation (geographic area, home computer OS or equipment, etc.) and invite them to participate in a specific trial. I'm excited to be on the same side as the 500lb gorilla for once, -Nick
Re: Countries with the most botnets
Team Cymru seems to put out a lot of information in their newsletters about where bots are, e.g. this article about the locations of botnet controllers: http://www.team-cymru.org/ReadingRoom/Articles/botnet-cnc-tlds-and-countries.html On Wed, Jan 27, 2010 at 6:07 PM, Steven Bellovin s...@cs.columbia.edu wrote: A colleague needs to know, along with citable sources if possible. Ideally - number of zombified PCs, percentage of zombified PCs, name of nation, source. Threat reports from symantec and macafee suggest the US leads, with China a very close second. Yes, we realize that answers will be imperfect. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Countries with the most botnets
The CBL has stats too - http://cbl.abuseat.org/totalflow.html - total spamtrap flow http://cbl.abuseat.org/country.html - by country (india leads the pack yay?) http://cbl.abuseat.org/domain.html - by ISP On Thu, Jan 28, 2010 at 4:37 AM, Steven Bellovin s...@cs.columbia.edu wrote: A colleague needs to know, along with citable sources if possible. Ideally - number of zombified PCs, percentage of zombified PCs, name of nation, source. Threat reports from symantec and macafee suggest the US leads, with China a very close second. Yes, we realize that answers will be imperfect. -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Comcast IPv6 Trials
Thanks. Initially it would be ideal (even preferred) to target trial subscribers with greater IPv6 awareness. The technical team will absolutely remain engaged as part of the support process. HTH, John On 1/27/10 5:50 PM, Steven Bellovin s...@cs.columbia.edu wrote: Wonderful! In all seriousness, will any attempt be made to select trial applicants based on (apparent) clue level and/or to receive feedback through channels other than the usual Tier 1 support? = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 =
Re: Comcast IPv6 Trials
On 1/27/10 5:00 PM, Bill Fehring li...@billfehring.com wrote: On Wed, Jan 27, 2010 at 12:52, John Jason Brzozowski john_brzozow...@cable.comcast.com wrote: There was an adjustment that was required on our end. It is in place. Great, got it working, thanks! ...partially Safari/OSX's fault, but mostly mine for not realizing what was going on quickly enough. Do you have any form of IPv6 connectivity? If yes, this is why you are seeing the same portal. This will clear up shortly. Yeah... for now that's a Hurricane Electric tunnel, but native v6 over DOCSIS 3 would be way cooler, not to belittle the amazing efforts of HE. [jjmb] native, dual-stack is exactly one of the approaches we will be trialing. -Bill = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 =
Re: Comcast IPv6 Trials
Saw this today too. This is a good step forward for adoption. Without going too far, what was the driving factor/selling point to moving towards this trial? -- William McCall On Wed, Jan 27, 2010 at 1:23 PM, John Jason Brzozowski john_brzozow...@cable.comcast.com wrote: Folks, I am emailing you today to share some news that we hope you will find interesting. Today we are announcing our 2010 IPv6 trial plans. For more information please visit the following web site: http://www.comcast6.net We have also made available a partial, dual-stack version of our portal which can be found at: http://ipv6.comcast.net Please do not hesitate to contact me via email with any questions, comments, or clarifications. If you feel that others will find this information interesting feel free to forward this message. Regards, John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 =
RE: Comcast IPv6 Trials
-Original Message- From: William McCall Sent: Wednesday, January 27, 2010 7:51 PM Subject: Re: Comcast IPv6 Trials Saw this today too. This is a good step forward for adoption. Without going too far, what was the driving factor/selling point to moving towards this trial? SWAG: Comcast is a mobile operator. At some point NAT becomes very expensive for mobile devices and it makes sense to use IPv6 where you don't need to do NAT. Once you deploy v6 on your mobile net, it is to your advantage to have the stuff your mobile devices connect to also be v6. Do do THAT your network needs to transport v6 and once your net is ipv6 enabled, there is no reason not to leverage that capability to the rest of your network. /SWAG My gut instinct says that mobile operators will be a major player in v6 adoption.
Re: Comcast IPv6 Trials
- Original Message - From: John Jason Brzozowski john_brzozow...@cable.comcast.com To: Steven Bellovin s...@cs.columbia.edu Cc: nanog@nanog.org Sent: Wednesday, January 27, 2010 5:12 PM Subject: Re: Comcast IPv6 Trials Thanks. Initially it would be ideal (even preferred) to target trial subscribers with greater IPv6 awareness. The technical team will absolutely remain engaged as part of the support process. HTH, John I filled out the form but nowhere on there does it allow to brag up or differentiate yourself from the typical home user (or select which trial(s) you may be interested in). It appears the differentiators are your PC OS, gaming platform and if you have more than 1 IP. tv
Re: Comcast IPv6 Trials
On 1/27/2010 15:19, John Jason Brzozowski wrote: On 1/27/10 5:00 PM, Bill Fehring li...@billfehring.com wrote: On Wed, Jan 27, 2010 at 12:52, John Jason Brzozowski john_brzozow...@cable.comcast.com wrote: There was an adjustment that was required on our end. It is in place. Great, got it working, thanks! ...partially Safari/OSX's fault, but mostly mine for not realizing what was going on quickly enough. Do you have any form of IPv6 connectivity? If yes, this is why you are seeing the same portal. This will clear up shortly. Yeah... for now that's a Hurricane Electric tunnel, but native v6 over DOCSIS 3 would be way cooler, not to belittle the amazing efforts of HE. [jjmb] native, dual-stack is exactly one of the approaches we will be trialing. Very awesome. If you served my area I would sign up for an account just to try it out. I have IPv6 access and can't see your site, but I did look at it a bit on my phone and I'm quite impressed to see someone of your size doing what you're doing. ~Seth
Re: Using /126 for IPv6 router links
On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote: you face 2 major issues with not using /127 for PtP-type circuits: 1) ping-ponging of packets on Sonet/SDH links Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP interface, and somebody comes along and ping floods 2001:db8::2, those packets will bounce back and forth between the 2 sides of the link till TTL expires (since there is no address resolution mechanism in PtP, so it just forwards packets not destined for him on). Following this, IPv4 /30 would have the same problem vs /31? 2) ping sweep of death Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually needed to learn. Wouldn't this affect *all* /64's configured on a router, not just point to point links? Time for glean rate limiting. If you were really concerned, you could hard code static NDP entries, as I think someone else pointed out. Dale
Re: Comcast IPv6 Trials
Date: Wed, 27 Jan 2010 20:59:16 -0800 From: George Bonser gbon...@seven.com -Original Message- From: William McCall Sent: Wednesday, January 27, 2010 7:51 PM Subject: Re: Comcast IPv6 Trials Saw this today too. This is a good step forward for adoption. Without going too far, what was the driving factor/selling point to moving towards this trial? SWAG: Comcast is a mobile operator. At some point NAT becomes very expensive for mobile devices and it makes sense to use IPv6 where you don't need to do NAT. Once you deploy v6 on your mobile net, it is to your advantage to have the stuff your mobile devices connect to also be v6. Do do THAT your network needs to transport v6 and once your net is ipv6 enabled, there is no reason not to leverage that capability to the rest of your network. /SWAG My gut instinct says that mobile operators will be a major player in v6 adoption. SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and Internet provider, but they don't do mobile (so far). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
RE: Comcast IPv6 Trials
-Original Message- From: Kevin Oberman [mailto:ober...@es.net] Sent: Wednesday, January 27, 2010 9:56 PM To: George Bonser Cc: William McCall; nanog@nanog.org Subject: Re: Comcast IPv6 Trials SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and Internet provider, but they don't do mobile (so far). Ahh, ok. I was fooled by this: http://www.comcast.net/mobile/
