Re: Comcast IPv6 Trials
John Jason Brzozowski 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: I was privileged enough to visit the Comcast DOCSIS3/IPv6 implementation demo setup at nanog46 in Philly last year, here are some pics I managed to snap: http://www.convergence.cx/cgi-bin/photview.cgi?collection=comcast6newformat=yay Apologies for the lack of descriptions, but from what I recall, there was a CMTS setup with DOCSIS3 CMs and Laptops attached, streaming media over IPv6. Dave.
Strange Cisco 6503 problem
Hi all, We experienced a strange problem with one of our Cisco 6503 routers - right after the terminal PC connected to the router via console is rebooted the router reboots itself. Even when there is no Eth connection to the PC the situations is the same - reboot follows. I tried to check the messages the router sends: *: %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 31 seconds [1/0] :: No EOBC input, dump debuginfo, interval 10, times 3 : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 60 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 90 seconds [1/0] : %FIB-3-FIBDISABLE: Fatal error, slot/cpu 1/0: IPC Failure: timeout : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 120 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 150 seconds [1/0]* All the possible reasons according to Cisco that may caused that case will be checked soon because the router is in operational mode although some of them looks strange: /*CPU_MONITOR-3-TIMED_OUT or CPU_MONITOR-6-NOT_HEARD Problem The switch reports these error messages: CPU_MONITOR-3-TIMED_OUT: CPU monitor messages have failed, resetting system CPU_MONITOR-6-NOT_HEARD: CPU monitor messages have not been heard for [dec] seconds Description These messages indicate that CPU monitor messages have not been heard for a significant amount of time. A time-out most probably occurs, which resets the system. [dec] is the number of seconds. The problem possibly occurs because of these reasons: * Badly seated line card or module * Bad ASIC or bad backplane * Software bugs * Parity error * High traffic in the Ethernet out of band channel (EOBC) channel The EOBC channel is a half duplex channel that services many other functions, which includes Simple Network Management Protocol (SNMP) traffic and packets that are destined to the switch. If the EOBC channel is full of messages because of a storm of SNMP traffic, then the channel is subjected to collisions. When this happens, EOBC is possibly not able to carry IPC messages. This makes the switch display the error message. Workaround Reseat the line card or module. If a maintenance window can be scheduled, reset the switch in order to clear any transient issues. # Error Message %ERR_DET-5-ERR_DET_NO_EOBC_INPUT: No EOBC input, dump debuginfo, interval %u, times %u ExplanationNo Ethernet Out-of-Band Channel (EOBC) input was received. Debugging information will be dumped. Recommended ActionNo action is required.*/ I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. Here is some brief info about the router: *Supervisor:* Mod Ports Card Type Model --- - -- -- --- 19 Supervisor Engine 32 8GE (Active) WS-SUP32-GE-3B *Processor:* cisco WS-C6503-E (R7000) processor *IOS:* IOS (tm) s3223_rp Software (s3223_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF8, RELEASE SOFTWARE (fc2) Thank you in advance for all your replays. Best~
Re: DDoS mitigation recommendations
-Original Message- From: David Freedman [mailto:david.freed...@uk.clara.net] Sent: Tuesday, January 26, 2010 8:17 AM To: nanog@nanog.org Subject: Re: DDoS mitigation recommendations Arbor stuff comes to mind and works very well in our experiences Arbor++ We've already done an initial trial with the Arbor device, and it does work well. Our biggest sticking point with it is that it lacks the granular level of visibility and control that we've been used to and often needed to tweak profiles. Basically, it does what it's supposed to well, but you really can't tell what that is, and if it's not catching all of a DDoS you have little insight as to what's being missed or control to correct it. Thank you, Tom Sands Chief Network Engineer Rackspace Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
Re: Comcast IPv6 Trials
What I've heard is that the driver is IPv4 exhaustion: Comcast is starting to have enough subscribers that it can't address them all out of 10/8 -- ~millions of subscribers, each with 1 IP address (e.g., for user data / control of the cable box). On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman ober...@es.net wrote: 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
Strange Cisco 6503 problem
Hi all, I experienced a strange problem with one of our Cisco 6503 routers - right after the terminal PC connected to the router via console is rebooted the router reboots itself. Even when there is no Eth connection to the PC the situations is the same - reboot follows. I tried to check the messages the router sends: *: %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 31 seconds [1/0] :: No EOBC input, dump debuginfo, interval 10, times 3 : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 60 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 90 seconds [1/0] : %FIB-3-FIBDISABLE: Fatal error, slot/cpu 1/0: IPC Failure: timeout : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 120 seconds [1/0] : %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 150 seconds [1/0]* All the possible reasons according to Cisco that may caused that case will be checked soon because the router is in operational mode although some of them looks strange: /*CPU_MONITOR-3-TIMED_OUT or CPU_MONITOR-6-NOT_HEARD Problem The switch reports these error messages: CPU_MONITOR-3-TIMED_OUT: CPU monitor messages have failed, resetting system CPU_MONITOR-6-NOT_HEARD: CPU monitor messages have not been heard for [dec] seconds Description These messages indicate that CPU monitor messages have not been heard for a significant amount of time. A time-out most probably occurs, which resets the system. [dec] is the number of seconds. The problem possibly occurs because of these reasons: * Badly seated line card or module * Bad ASIC or bad backplane * Software bugs * Parity error * High traffic in the Ethernet out of band channel (EOBC) channel The EOBC channel is a half duplex channel that services many other functions, which includes Simple Network Management Protocol (SNMP) traffic and packets that are destined to the switch. If the EOBC channel is full of messages because of a storm of SNMP traffic, then the channel is subjected to collisions. When this happens, EOBC is possibly not able to carry IPC messages. This makes the switch display the error message. Workaround Reseat the line card or module. If a maintenance window can be scheduled, reset the switch in order to clear any transient issues. # Error Message %ERR_DET-5-ERR_DET_NO_EOBC_INPUT: No EOBC input, dump debuginfo, interval %u, times %u ExplanationNo Ethernet Out-of-Band Channel (EOBC) input was received. Debugging information will be dumped. Recommended ActionNo action is required.*/ I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. Here is some brief info about the router: *Supervisor:* Mod Ports Card Type Model --- - -- -- --- 19 Supervisor Engine 32 8GE (Active) WS-SUP32-GE-3B *Processor:* cisco WS-C6503-E (R7000) processor *IOS:* IOS (tm) s3223_rp Software (s3223_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF8, RELEASE SOFTWARE (fc2) Thank you in advance for all your replays. Best~
Re: Comcast IPv6 Trials
On Jan 28, 2010, at 7:47 AM, Richard Barnes wrote: What I've heard is that the driver is IPv4 exhaustion: Comcast is starting to have enough subscribers that it can't address them all out of 10/8 -- ~millions of subscribers, each with 1 IP address (e.g., for user data / control of the cable box). But then that begs the question of why lots of other very large retail Internet access providers have not indicated that they're committed to the same course of action (?). They're certainly not the only provider that employs a public IP address-intensive access model, so where are the other retail IPv6 trial announcements/pre-announcements? If they start appearing with some frequency real soon now, then maybe it's just a time-until-overflow issue. If not, then maybe there are other/better explanations. TV On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman ober...@es.net wrote: 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
That really makes sense - on an incredibly smaller scale (and I mean MUCH smaller scale), we operate cable modem in two small communities - currently we use 3 IP addresses per subscriber. One for the cable modem itself, one for the subscriber (or more depending on their package), and one for voice delivery (packetcable). If we moved even two of three IP assignments to native V6 we'd reclaim a lot of V4 space - I can only imagine someone their size and what this means... Paul -Original Message- From: Richard Barnes [mailto:richard.bar...@gmail.com] Sent: Thursday, January 28, 2010 7:47 AM To: Kevin Oberman Cc: nanog@nanog.org Subject: Re: Comcast IPv6 Trials What I've heard is that the driver is IPv4 exhaustion: Comcast is starting to have enough subscribers that it can't address them all out of 10/8 -- ~millions of subscribers, each with 1 IP address (e.g., for user data / control of the cable box). On Thu, Jan 28, 2010 at 12:55 AM, Kevin Oberman ober...@es.net wrote: 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 The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
RE: Comcast IPv6 Trials
-Original Message- From: Richard Barnes [mailto:richard.bar...@gmail.com] Sent: Thursday, January 28, 2010 07:47 To: Kevin Oberman Cc: nanog@nanog.org Subject: Re: Comcast IPv6 Trials What I've heard is that the driver is IPv4 exhaustion: Comcast is starting to have enough subscribers that it can't address them all out of 10/8 -- ~millions of subscribers, each with 1 IP address (e.g., for user data / control of the cable box). ++1, reference: http://www.apricot.net/apricot2006/slides/conf/wednesday/Alain_Durand-Archit ecture-external.ppt /TJ
RE: Comcast IPv6 Trials
They'll need to be soon to keep up with others in their space (not that they generally compete directly thanks to franchise laws), although I'm not sure how the data side of things is handled for MVNO's, normally they don't have any network of their own: http://news.cnet.com/8301-1035_3-10215445-94.html http://unbelievablyfair.com/ -Scott -Original Message- From: George Bonser [mailto:gbon...@seven.com] Sent: Thursday, January 28, 2010 1:56 AM To: Kevin Oberman Cc: nanog@nanog.org Subject: 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/
Re: Comcast IPv6 Trials
* Paul Stewart (pstew...@nexicomgroup.net) wrote: That really makes sense - on an incredibly smaller scale (and I mean MUCH smaller scale), we operate cable modem in two small communities - currently we use 3 IP addresses per subscriber. One for the cable modem itself, one for the subscriber (or more depending on their package), and one for voice delivery (packetcable). If we moved even two of three IP assignments to native V6 we'd reclaim a lot of V4 space - I can only imagine someone their size and what this means... Paul Excuse the newbie question: Why use public IP space for local CPE management and VoIP? Doesn't DOCSIS support traffic separation? /J
RE: Comcast IPv6 Trials
-Original Message- From: tv...@eyeconomics.com [mailto:tv...@eyeconomics.com] Sent: Thursday, January 28, 2010 08:12 To: Richard Barnes Cc: NANOG Subject: Re: Comcast IPv6 Trials SNIP But then that begs the question of why lots of other very large retail Internet access providers have not indicated that they're committed to the same course of action (?). They're certainly not the only provider that employs a public IP address- intensive access model, so where are the other retail IPv6 trial announcements/pre-announcements? Other providers are moving in that direction, atleast a couple are (as a swag) 6-18 months behind Comcast ... /TJ
Re: Comcast IPv6 Trials
On Jan 28, 2010, at 9:07 AM, TJ wrote: -Original Message- From: tv...@eyeconomics.com [mailto:tv...@eyeconomics.com] Sent: Thursday, January 28, 2010 08:12 To: Richard Barnes Cc: NANOG Subject: Re: Comcast IPv6 Trials SNIP But then that begs the question of why lots of other very large retail Internet access providers have not indicated that they're committed to the same course of action (?). They're certainly not the only provider that employs a public IP address- intensive access model, so where are the other retail IPv6 trial announcements/pre-announcements? Other providers are moving in that direction, atleast a couple are (as a swag) 6-18 months behind Comcast ... /TJ I have no particular reason to to doubt that claim, and lots of reasons to actively hope that you are right. That said, the appearance of more public commitments like this -- and sooner rather than later -- could make a large difference, e.g., by reducing the general level of uncertainty (and uncertainty-amplifying speculation) during the terminal stages of IPv4 allocation. While no commercial entity would (and none should) willingly make such a public commitment before they're ready, it would be prudent to consider the potential downsides of that looming uncertainty when making judgements about how ready (or perhaps ready enough) should be defined. TV
Re: DDoS mitigation recommendations
IntruGuard is highly customizable both from the GUI and CLI with the engineer's assistance. Its the highest performance, reasonably priced box that we've tried so far. Jeff On Jan 28, 2010 7:02 AM, Tom Sands tsa...@rackspace.com wrote: -Original Message- From: David Freedman [mailto:david.freed...@uk.clara.net] Sent: Tues... We've already done an initial trial with the Arbor device, and it does work well. Our biggest sticking point with it is that it lacks the granular level of visibility and control that we've been used to and often needed to tweak profiles. Basically, it does what it's supposed to well, but you really can't tell what that is, and if it's not catching all of a DDoS you have little insight as to what's being missed or control to correct it. Thank you, Tom Sands Chief Network Engineer Rackspace Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intend...
Re: Comcast IPv6 Trials
On Thu, Jan 28, 2010 at 8:44 AM, Joakim Aronius joa...@aronius.com wrote: Excuse the newbie question: Why use public IP space for local CPE management and VoIP? Doesn't DOCSIS support traffic separation? /J Probably because rfc1918 is only 2^24+2^20+2^16 = 17,891,328 (assuming I got them all and my math is right.) That makes it tough to manage unique devices across a large deployment. -- Tim: Sent from Brooklyn, NY, United States
Re: Using /126 for IPv6 router links
- Original Message From: Dale W. Carder dwcar...@wisc.edu 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 Following this, IPv4 /30 would have the same problem vs /31? No, because IPv4 has the concept of Broadcast, while IPv6 does not. Remotely sending packets to an IPv4 broadcast address is a directed broadcast and that is generally denied by default on modern kit. 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. This is, of course, one of the reasons why some of us didn't like the ultra-mega-mega ranges used to address handfuls of hosts, but that ship sailed long ago. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Rogers wireless outbound mailservers have no reverse (SORBS please help?)
Can I get a rogers engineer who not only cares but has power to crush problems to respond to this please? Opening tickets with RNS seems to just get a null responce, we'll look at it with a hint of disbelief a customer ticket could uncover a large network-wide issue. It's an old problem that was temporarily fixed for a while, but is now back. Jan 28 06:46:00 cust1 postfix/smtpd[416]: NOQUEUE: reject: RCPT from unknown[74.198.8.2]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [74.198.8.2]; from=sa...@customer.com to=tr...@customer.com proto=ESMTP helo=to5email1.gprs.rogers.com $ host 74.198.8.2 8.8.8.8 Using domain server: Name: 8.8.8.8 Host 2.8.198.74.in-addr.arpa. not found: 3(NXDOMAIN) Maybe we can get them registered on SORBS. The irony would be very tasty. Maybe then they'll start caring. (Too much to hope for?) Solution right now is to get all of my customers to tell their employees to not trust outgoing rogers mailservers to get their mail out, and find alternates. I'm not the only one who filters by lack of reverse. I'm also trying to figure out the Rogers angle here. Ideas? /kc -- Ken Chase - k...@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.
Re: DDoS mitigation recommendations
On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon jeffrey.l...@blacklotus.net wrote: IntruGuard is highly customizable both from the GUI and CLI with the engineer's assistance. Its the highest performance, reasonably priced box that we've tried so far. 'highest performance' == 100mbps on a 1gbps copper interface? or sessions setup/second? or remote-addresses tracked? or ? -chris Jeff On Jan 28, 2010 7:02 AM, Tom Sands tsa...@rackspace.com wrote: -Original Message- From: David Freedman [mailto:david.freed...@uk.clara.net] Sent: Tues... We've already done an initial trial with the Arbor device, and it does work well. Our biggest sticking point with it is that it lacks the granular level of visibility and control that we've been used to and often needed to tweak profiles. Basically, it does what it's supposed to well, but you really can't tell what that is, and if it's not catching all of a DDoS you have little insight as to what's being missed or control to correct it. Thank you, Tom Sands Chief Network Engineer Rackspace Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intend...
Re: Comcast IPv6 Trials
steve pirk: Does G4 count? I have seen fliers from Comcast talking about mobile G4 Comcast is using Clearwire for 4G. Seattle 4G rolled-out about 2 weeks ago. Many more markets to be turned-up this spring. No IPv6 in the configs at this time, but most of the core seems capable. Clear is layer-2 up to the major market POPs so it would seem to be mostly a config/firmware change on the network side. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
Keeping up with New European IXP participants
The Euro-IX ASN database now has more than 5.100 entries in it of which almost 3.000 are unique ASNs. In an effort to make it a little easier for those peering or looking to peer at European IXPs to keep up the latest IXP participant additions, we have created a page that lists the latest entries to the Euro-IX database. This page also displays all ASNs that peer at more than 9 IXPs across Europe. Hope you find it useful. https://www.euro-ix.net/newasns.php Regards, Serge Oh BTW we also have a RSS feed of this page available
Re: Comcast IPv6 Trials
From: tv...@eyeconomics.com Date: Thu, 28 Jan 2010 09:34:52 -0500 On Jan 28, 2010, at 9:07 AM, TJ wrote: -Original Message- From: tv...@eyeconomics.com [mailto:tv...@eyeconomics.com] Sent: Thursday, January 28, 2010 08:12 To: Richard Barnes Cc: NANOG Subject: Re: Comcast IPv6 Trials SNIP But then that begs the question of why lots of other very large retail Internet access providers have not indicated that they're committed to the same course of action (?). They're certainly not the only provider that employs a public IP address- intensive access model, so where are the other retail IPv6 trial announcements/pre-announcements? Other providers are moving in that direction, atleast a couple are (as a swag) 6-18 months behind Comcast ... /TJ I have no particular reason to to doubt that claim, and lots of reasons to actively hope that you are right. That said, the appearance of more public commitments like this -- and sooner rather than later -- could make a large difference, e.g., by reducing the general level of uncertainty (and uncertainty-amplifying speculation) during the terminal stages of IPv4 allocation. While no commercial entity would (and none should) willingly make such a public commitment before they're ready, it would be prudent to consider the potential downsides of that looming uncertainty when making judgements about how ready (or perhaps ready enough) should be defined. Might be worth noting that Comcast has been using IPv6 heavily for internal connectivity (including router access) for some time and already had substantial experience with IPv6, so I suspect that they are ahead of others on this. -- 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: Using /126 for IPv6 router links
On Wed, 27 Jan 2010, Dale W. Carder wrote: :: :: 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? As has been said before, IPv4 has a concept of broadcast, and no ip directed broadcast (or simmilar) to prevent it -- IPv6 does not. :: 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. While I don't disagree on smarter ARP gleaning, rate limiting by itself is not an answer (rate limiting means that legit requests get limited too), so a better approach is to prioritize arp/NDP refresh for anything already in cache, as opposed to new requests, which we've suggested to our vendors. Also, for a core network, you don't really need /64's in most places, and, if you do need them, their numbers are quite small compared to the number of PtP links.. (how many lan/host segments do you have connected to core routers, as compared to number of PtP links, and then, how many of those show up in a traceroute?) :: If you were really concerned, you could hard code static NDP :: entries, as I think someone else pointed out. Or, you can use /127's -- to me, that's operationally easier (especially if you have to replace hardware in the future) :) Like I said before, using /127's is our suggestion of what has worked best for us in both architectural and operational roles, and since my network isn't the same as yours, YMMV, just sharing our experience.. Thanks, -igor
Re: Comcast IPv6 Trials
Typically the CPE address is private, not sure why they would use a public IP. The MTA (VoIP) part of the modem would need a public IP if it was talking to a SIP server that was not on the same network. Most smaller cable system outsource their VoIP to a reseller with a softswitch. Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | ch...@uplogon.com On 1/28/2010 7:44 AM, Joakim Aronius wrote: * Paul Stewart (pstew...@nexicomgroup.net) wrote: That really makes sense - on an incredibly smaller scale (and I mean MUCH smaller scale), we operate cable modem in two small communities - currently we use 3 IP addresses per subscriber. One for the cable modem itself, one for the subscriber (or more depending on their package), and one for voice delivery (packetcable). If we moved even two of three IP assignments to native V6 we'd reclaim a lot of V4 space - I can only imagine someone their size and what this means... Paul Excuse the newbie question: Why use public IP space for local CPE management and VoIP? Doesn't DOCSIS support traffic separation? /J
Re: Comcast IPv6 Trials
On Thu, Jan 28, 2010 at 4:42 PM, Chris Gotstein ch...@uplogon.com wrote: Typically the CPE address is private, not sure why they would use a public IP. The MTA (VoIP) part of the modem would need a public IP if it was talking to a SIP server that was not on the same network. Most smaller cable system outsource their VoIP to a reseller with a softswitch. It's not necessarily public, just globally unique. Some companies have more than 17,891,328 devices they want to manage in a centralized fashion. -- Tim:
IPv6 security ops panel and PGP key signing
Hi folks, I'm helping Barry Greene out with the ISP sec BoF this year and at least one of the items planned for that session is an IPv6 security operations panel/audience discussion. If the ISP sec BoF and IPv6 operations, particularly related to security, is of interest to you, I'd be interested in hearing about it off list. I'm also very interested in a couple more people volunteering to join the panel and help lead the discussion. You don't have to have all the answers, questions are OK too. I'll take any of those in advance so your's truly to can better perform the moderator role. Additionally, there is probably going to be at least a small handful of PGP key signing geeks wanting to exchange signatures during the meeting. I believe the PC will have something official scheduled, but you can exchange sigs at anytime. Usually there is a sticker on the badge (usually red if I recall) which marks someone as a PGP geek. If nothing else, for those that have never participated its a decent way to meet some new people face to face and see how well their ID photo came out. Add your public key to the keyring here: http://biglumber.com/x/web?keyring=4670 John
Re: Rogers wireless outbound mailservers have no reverse (SORBS please help?)
In message 20100128164654.gz16...@sizone.org, Ken Chase writes: Can I get a rogers engineer who not only cares but has power to crush problem s to respond to this please? Opening tickets with RNS seems to just get a null responce, we'll look at it with a hint of disbelief a customer ticket could uncover a large network-wide issu e. It's an old problem that was temporarily fixed for a while, but is now back. Jan 28 06:46:00 cust1 postfix/smtpd[416]: NOQUEUE: reject: RCPT from unknown[74.198.8.2]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [74.198.8.2]; from=sa...@customer.com to=tr...@customer.com proto=ESMTP helo=to5email1.gprs.rogers.com $ host 74.198.8.2 8.8.8.8 Using domain server: Name: 8.8.8.8 Host 2.8.198.74.in-addr.arpa. not found: 3(NXDOMAIN) Maybe we can get them registered on SORBS. The irony would be very tasty. Maybe then they'll start caring. (Too much to hope for?) Solution right now is to get all of my customers to tell their employees to not trust outgoing rogers mailservers to get their mail out, and find alte rnates. I'm not the only one who filters by lack of reverse. I'm also trying to figure out the Rogers angle here. Ideas? /kc -- Ken Chase - k...@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Fron t St. W. Perhaps you should re-think your filtering policies. They are obviously wrong because they are not allowing through the email you want to be let through. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Strange Cisco 6503 problem
Dean Belev wrote: I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. I once managed to send a BREAK signal to a 3640 by plugging in a console cable. At the time, it was a pretty key router in the network and sat at the rommon prompt :) I had that down to static somewhere, as it's the only explanation I could find. Peter
Re: Strange Cisco 6503 problem
- Original Message From: Peter Hicks peter.hi...@poggs.co.uk To: Dean Belev dbe...@gmail.com I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. I once managed to send a BREAK signal to a 3640 by plugging in a console cable. At the time, it was a pretty key router in the network and sat at the rommon prompt :) I had that down to static somewhere, as it's the only explanation I could find. Certain serial speed mismatches get interpreted as BREAK - I routinely use space bar at 1200 to password crack routers where they are expecting 9600. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Strange Cisco 6503 problem
On Jan 28, 2010, at 6:15 PM, Peter Hicks wrote: Dean Belev wrote: I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. I once managed to send a BREAK signal to a 3640 by plugging in a console cable. At the time, it was a pretty key router in the network and sat at the rommon prompt :) I had that down to static somewhere, as it's the only explanation I could find. Actually, it's not at all surprising, but it depends on the UART or equivalent. A serial line has two states, mark -- a 1-bit -- and space (guess). Normally, the line is at mark, which corresponds to a voltage of -3V:-25V at the receiver. Space is +3V:+25V; -3V:+3V is undefined. (http://www.lammertbies.nl/comm/info/RS-232_specs.html is pretty good, and as far as I remember quite accurate, though it's ~20 years since I used a breakout box.) Now -- a break signal is normally a long space, a 0 signal that lasts too long, often about .25 seconds. It originally got the name because it looked like a break in the teletype line; teletypes used a current loop standard (don't ask). More precisely -- an asynchronous byte is followed by a stop bit, which isn't so much a bit as a time interval -- one bit-time -- during which the signal must be in the mark state. If you're sending at the wrong speed or send break -- something that's holding the line at space for long enough that it will run into the stop bits at any speed -- the UART will detect the problem; this is sometimes known as a framing error. So -- when you disconnect the cable, the voltage at the pin goes to 0. How should that be interpreted? If the board has a pull-up resistor to a +5V line, it will appear as a space signal; if it doesn't, it's up to the UART or equivalent, since it's undefined by the spec. --Steve Bellovin, http://www.cs.columbia.edu/~smb
RE: Strange Cisco 6503 problem
Please make sure you config register is set to x2102. You shouldn't see any issues if you the correct config register. Regards Abdul -Original Message- From: Peter Hicks [mailto:peter.hi...@poggs.co.uk] Sent: Thu 1/28/2010 3:15 PM To: Dean Belev Cc: nanog@nanog.org Subject: Re: Strange Cisco 6503 problem Dean Belev wrote: I'm curious if some of you faced such a problem - reboot of the router caused by the console connection. I once managed to send a BREAK signal to a 3640 by plugging in a console cable. At the time, it was a pretty key router in the network and sat at the rommon prompt :) I had that down to static somewhere, as it's the only explanation I could find. Peter
RE: DDoS mitigation recommendations
-Original Message- From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Thursday, January 28, 2010 11:56 AM To: Jeffrey Lyon Cc: nanog@nanog.org Subject: Re: DDoS mitigation recommendations On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon jeffrey.l...@blacklotus.net wrote: IntruGuard is highly customizable both from the GUI and CLI with the engineer's assistance. Its the highest performance, reasonably priced box that we've tried so far. 'highest performance' == 100mbps on a 1gbps copper interface? or sessions setup/second? or remote-addresses tracked? or ? sessions setup/second = ddos mitigation fail ;) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D
Re: DDoS mitigation recommendations
On Thu, Jan 28, 2010 at 9:22 PM, Stefan Fouant sfou...@shortestpathfirst.net wrote: -Original Message- From: Christopher Morrow [mailto:morrowc.li...@gmail.com] Sent: Thursday, January 28, 2010 11:56 AM To: Jeffrey Lyon Cc: nanog@nanog.org Subject: Re: DDoS mitigation recommendations On Thu, Jan 28, 2010 at 10:00 AM, Jeffrey Lyon jeffrey.l...@blacklotus.net wrote: IntruGuard is highly customizable both from the GUI and CLI with the engineer's assistance. Its the highest performance, reasonably priced box that we've tried so far. 'highest performance' == 100mbps on a 1gbps copper interface? or sessions setup/second? or remote-addresses tracked? or ? sessions setup/second = ddos mitigation fail ;) 'unqualified adjectives == fail' ... or 'lies, damned lines and statistics' or 'pls to be qualifying your statement with some useful data' :) -chris
Re: DDoS mitigation recommendations
- Original Message - From: Tom Sands tsa...@rackspace.com Cc: nanog@nanog.org Sent: Thursday, January 28, 2010 6:01 AM Subject: Re: DDoS mitigation recommendations -Original Message- From: David Freedman [mailto:david.freed...@uk.clara.net] Sent: Tuesday, January 26, 2010 8:17 AM To: nanog@nanog.org Subject: Re: DDoS mitigation recommendations Arbor stuff comes to mind and works very well in our experiences Arbor++ We've already done an initial trial with the Arbor device, and it does work well. Our biggest sticking point with it is that it lacks the granular level of visibility and control that we've been used to and often needed to tweak profiles. Basically, it does what it's supposed to well, but you really can't tell what that is, and if it's not catching all of a DDoS you have little insight as to what's being missed or control to correct it. Thank you, Tom Sands Chief Network Engineer Rackspace Out of curiousity, what's your baseline or that we've been used? tv
Re: DDoS mitigation recommendations
On Jan 29, 2010, at 10:04 AM, Jonathan Lassoff wrote: Something utilizing sflow/netflow and flowspec to block or direct traffic into a scrubbing box gets you much better bang for your buck past a certain scale. This is absolutely key for packet-flooding types of attacks, and other attacks in which unadulterated pathological traffic can be detected/classified in detail, with minimal collateral damage. Everyone should implement S/RTBH and/or flow-spec whenever possible, this cannot be emphasized enough. Operators have made significant investments in high-speed, ASIC-powered routers at their edges; there's no reason not to utilize that horsepower, as it's already there and paid for. For situations in which valid and invalid traffic are highly intermixed, and/or layer-4/-7 heuristics are key in validating legitimate traffic and invalidating undesirable traffic, the additional capabilities of an IDMS which can perform such discrimination can be of benefit. As mentioned in a previous thread, it's possible to construct a base-level capability using open-source software, and commercial solutions from various vendors [full disclosure: I'm employed one of said vendors] are available, as well. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
