Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
On 2/1/2014 10:40 PM, Jima wrote: +1. Cisco calls them Twinax, HP calls them DACs. I don't know what anyone else calls them as it hasn't come up in conversation for me. I thought Twinax was an IBMish MILSPEC term. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Internet Society survey regarding Network Operator involvement with the IETF
NANOGers - The folks at the Internet Society are looking for input into how network operators are (or are not) involved in IETF standards development. To that end, they've put together a short survey for network operators on this topic and are asking for help in getting the message out about it. The survey is available here: https://internetsociety2.wufoo.com/forms/operators-and-the-ietf/ Some additional background info available here - http://www.circleid.com/posts/20140130_how_do_we_get_more_network_operator_feedback_into_ietf_standards/ If you feel so inclined, please complete the survey; it looks to be relatively short/painless. Thanks! /John
Re: TWC (AS11351) blocking all NTP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While I do not profess to know the cause of your particular NTP sync problem, this *might* be due to knee-jerk reactions to the NTP reflection/amplification DDoS attacks that have been quite an annoyance and operational issue lately. suspect that some operators have found that perhaps they harbored some device inside their own networks are being used (or might be used) to facilitate these attacks: https://www.us-cert.gov/ncas/current-activity/2014/01/10/Network-Time-Protocol-NTP-Amplification-Attacks See also: http://openntpproject.org/ - - ferg On 2/1/2014 8:03 PM, Jonathan Towne wrote: This evening all of my servers lost NTP sync, stating that our on-site NTP servers hadn't synced in too long. Reference time noted by the local NTP servers: Fri, Jan 31 2014 19:11:29.725 Apparently since then, NTP has been unable to traverse the circuit. Our other provider is shuffling NTP packets just fine, and after finding an NTP peer that return routed in that direction, I was able to get NTP back in shape. Spot checking various NTP peers configured on my end with various looking glasses close to the far-end confirm that anytime the return route is through AS11351, we never get the responses. Outbound routes almost always take the shorter route through our other provider. Is anyone else seeing this, or am I lucky enough to have it localized to my region (Northern NY)? I've created a ticket with the provider, although with it being the weekend, I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk response to the monlist garbage. Still, stopping time without warning is Uncool, Man. -- Jonathan Towne - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLubvMACgkQKJasdVTchbK8mwD9HDHJ2YSDciN8k6YkRDu4MbxS r0zEU/8ofP8HaK8YoEYBANhDP+VIhC3Cz/cKc4TI8WeGHqX1ZWN1OwnxLihR3sjx =KEeR -END PGP SIGNATURE-
Re: TWC (AS11351) blocking all NTP?
The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. -- Jonathan Towne On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled: # This evening all of my servers lost NTP sync, stating that our on-site NTP # servers hadn't synced in too long. # # Reference time noted by the local NTP servers: # Fri, Jan 31 2014 19:11:29.725 # # Apparently since then, NTP has been unable to traverse the circuit. Our # other provider is shuffling NTP packets just fine, and after finding an # NTP peer that return routed in that direction, I was able to get NTP back # in shape. # # Spot checking various NTP peers configured on my end with various looking # glasses close to the far-end confirm that anytime the return route is # through AS11351, we never get the responses. Outbound routes almost always # take the shorter route through our other provider. # # Is anyone else seeing this, or am I lucky enough to have it localized to # my region (Northern NY)? # # I've created a ticket with the provider, although with it being the weekend, # I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk # response to the monlist garbage. Still, stopping time without warning is # Uncool, Man. # # -- Jonathan Towne #
Re: Internet Society survey regarding Network Operator involvement with the IETF
On 02/02/2014 07:52 AM, John Curran wrote: NANOGers - The folks at the Internet Society are looking for input into how network operators are (or are not) involved in IETF standards development. To that end, they've put together a short survey for network operators on this topic and are asking for help in getting the message out about it. The survey is available here: https://internetsociety2.wufoo.com/forms/operators-and-the-ietf/ Some additional background info available here - http://www.circleid.com/posts/20140130_how_do_we_get_more_network_operator_feedback_into_ietf_standards/ If you feel so inclined, please complete the survey; it looks to be relatively short/painless. The survey has a problem: the 'Previous' link actually continues on or submits the form. I could not correct a response and the form went on incomplete. I browse without JavaScript so this may be related to the problem.
Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
On 2/2/14, 7:30 AM, Larry Sheldon wrote: On 2/1/2014 10:40 PM, Jima wrote: +1. Cisco calls them Twinax, HP calls them DACs. I don't know what anyone else calls them as it hasn't come up in conversation for me. I thought Twinax was an IBMish MILSPEC term. twinax could refer to a specific technology or to the presence of dual inner conductors e.g. in contrast to coax or triax. signature.asc Description: OpenPGP digital signature
Re: TWC (AS11351) blocking all NTP?
In article 20140202163313.gf24...@hijacked.us you write: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. I'm a Time-Warner cable customer in the Syracuse region, and both of the NTP servers on my home LAN are happily syncing with outside peers. My real servers are hosted in Ithaca, with T-W being one of the upstreams and they're also OK. They were recruited into an NTP DDoS last month (while I was at a meeting working on anti-DDoS best practice, which was a little embarassing) but they're upgraded and locked down now. R's, John
Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
- Original Message - From: joel jaeggli joe...@bogus.com I thought Twinax was an IBMish MILSPEC term. twinax could refer to a specific technology or to the presence of dual inner conductors e.g. in contrast to coax or triax. Rather specifically, Twinax refers to cable with 2 center conductors in it's foam or plastic insulator *both within the same shield* -- generally, I think always, a balanced pair. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
These cables are most commonly known as Direct Attach Copper SFP+ On Sunday, February 2, 2014, Jay Ashworth j...@baylink.com wrote: - Original Message - From: joel jaeggli joe...@bogus.com javascript:; I thought Twinax was an IBMish MILSPEC term. twinax could refer to a specific technology or to the presence of dual inner conductors e.g. in contrast to coax or triax. Rather specifically, Twinax refers to cable with 2 center conductors in it's foam or plastic insulator *both within the same shield* -- generally, I think always, a balanced pair. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com javascript:; Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 -- eSited LLC (701) 390-9638
Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
On 2/2/2014 4:03 PM, Bryan Tong wrote: These cables are most commonly known as Direct Attach Copper SFP+ The big issue appears to be that these are not always consistently functional crossing vendor lines (sometimes product lines within the same vendor). There does not appear to be any standardization in place. Not sure how much of this is picky vendor software looking for branded marks in their transceivers (e.g., Cisco service unsupported-transceiver) versus true incompatibilities. We have had issues in test cases crossing vendor lines (Cisco / Brocade / Dell / HP) with a twinax link that just simply won't work. If anyone has a clear explanation or better understanding, I'm all ears. Personal experience comes from only a few testbed cases. Jeff
Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014 8:35 AM, Jonathan Towne jto...@slic.com wrote: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not knee jerk, it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. And, i agree bcp38 would help but that was published 14 years ago. CB -- Jonathan Towne On Sat, Feb 01, 2014 at 11:03:19PM -0500, Jonathan Towne scribbled: # This evening all of my servers lost NTP sync, stating that our on-site NTP # servers hadn't synced in too long. # # Reference time noted by the local NTP servers: # Fri, Jan 31 2014 19:11:29.725 # # Apparently since then, NTP has been unable to traverse the circuit. Our # other provider is shuffling NTP packets just fine, and after finding an # NTP peer that return routed in that direction, I was able to get NTP back # in shape. # # Spot checking various NTP peers configured on my end with various looking # glasses close to the far-end confirm that anytime the return route is # through AS11351, we never get the responses. Outbound routes almost always # take the shorter route through our other provider. # # Is anyone else seeing this, or am I lucky enough to have it localized to # my region (Northern NY)? # # I've created a ticket with the provider, although with it being the weekend, # I have doubts it'll be a quick resolution. I'm sure its a strange knee-jerk # response to the monlist garbage. Still, stopping time without warning is # Uncool, Man. # # -- Jonathan Towne #
Re: Internet Society survey regarding Network Operator involvement with the IETF
On Feb 2, 2014, at 12:05 PM, Octavio Alvarez alvar...@alvarezp.ods.org wrote: The survey has a problem: the 'Previous' link actually continues on or submits the form. I could not correct a response and the form went on incomplete. I browse without JavaScript so this may be related to the problem. Good to know; I'll forward along to the some of Internet Society folks so that they are aware of the issue. Thanks! /John
RE: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
Most of the switch vendors have an official compatibility list, but I've found that generally the most common compatibility issue is active vs passive twinax. Brocade edge switches and nics are normally active only, which seems to come up a lot - because most short cables are passive unless they are brocade branded. 5m is normally the cutoff for passive twinax. Pretty much everything else I've encountered supports passive. For a while, the intel x520 nics, which are very common, didn't support active connections - but they have since released firmware that fixes this problem. Netapp's lower end gear doesn't support active twinax. From: Jeff Kell [jeff-k...@utc.edu] Sent: Sunday, February 02, 2014 3:15 PM To: Bryan Tong; Jay Ashworth Cc: NANOG Subject: Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) On 2/2/2014 4:03 PM, Bryan Tong wrote: These cables are most commonly known as Direct Attach Copper SFP+ The big issue appears to be that these are not always consistently functional crossing vendor lines (sometimes product lines within the same vendor). There does not appear to be any standardization in place. Not sure how much of this is picky vendor software looking for branded marks in their transceivers (e.g., Cisco service unsupported-transceiver) versus true incompatibilities. We have had issues in test cases crossing vendor lines (Cisco / Brocade / Dell / HP) with a twinax link that just simply won't work. If anyone has a clear explanation or better understanding, I'm all ears. Personal experience comes from only a few testbed cases. Jeff
Re: TWC (AS11351) blocking all NTP?
On Sun, Feb 2, 2014 at 2:17 PM, Cb B cb.li...@gmail.com wrote: On Feb 2, 2014 8:35 AM, Jonathan Towne jto...@slic.com wrote: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not knee jerk, it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. Please note that it's not that UDP is at fault here; it's applications that are structured to respond to small input packets with large responses. If NTP responded to a single query with a single equivalently sized response, its effectiveness as a DDoS attack would be zero; with zero amplification, the volume of attack traffic would be exactly equivalent to the volume of spoofed traffic the originator could send out in the first place. I agree the source obfuscation aspect of UDP can be annoying, from the spoofing perspective, but that really needs to be recognized to be separate from the volume amplification aspect, which is an application level issue, not a protocol level issue. Thanks! Matt PS--yes, I know it would completely change the dynamics of the internet as we know it today to shift to a 1:1 correspondence between input requests and output replies...but it *would* have a nice side effect of balancing out traffic ratios in many places, altering the settlement landscape in the process. ;)
Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014 2:54 PM, Matthew Petach mpet...@netflight.com wrote: On Sun, Feb 2, 2014 at 2:17 PM, Cb B cb.li...@gmail.com wrote: On Feb 2, 2014 8:35 AM, Jonathan Towne jto...@slic.com wrote: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not knee jerk, it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. Please note that it's not that UDP is at fault here; it's applications that are structured to respond to small input packets with large responses. I dont want to go into fault, there is plenty of that to go around. If NTP responded to a single query with a single equivalently sized response, its effectiveness as a DDoS attack would be zero; with zero amplification, the volume of attack traffic would be exactly equivalent to the volume of spoofed traffic the originator could send out in the first place. I agree the source obfuscation aspect of UDP can be annoying, from the spoofing perspective, but that really needs to be recognized to be separate from the volume amplification aspect, which is an application level issue, not a protocol level issue. Source obfuscation is not annoying. Combined with amplification, it is the perfect storm for shutting down networks... whereby the only solution is to shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal, patches boxes, and so on. My point is: dont expect these abbused services on UDP to last. We have experience in access networks on how to deal with abused protocols. Here is one reference http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/ My crystal ball says all of UDP will show up soon. CB Thanks! Matt PS--yes, I know it would completely change the dynamics of the internet as we know it today to shift to a 1:1 correspondence between input requests and output replies...but it *would* have a nice side effect of balancing out traffic ratios in many places, altering the settlement landscape in the process. ;)
Ad Hoc Education Committee Call for Volunteers
Dear NANOG community, In August 2012, Steve Gibbard placed the first call for community volunteers to help establish a NANOG education initiative, which would put together a NANOG-created educational program for junior (and possibly more advanced) network operators. I am happy to report, thanks to the help of those original volunteers, the initial work has proven successful! The Education Series is adopted and an Ad Hoc committee structure has been approved and supported by the NANOG Board. I have agreed to serve as Chair of the Ad Hoc Education Committee and seek volunteers to continue with the committee work. Please consider volunteering your time and effort in support of this NANOG activity. Committee Objectives: * Build a unified branding and message about NANOG's unique position and community * Develop mutually rewarding agreements with instructors and students * Maintain the sense of community and accessibility in class syllabus and instructional materials * Develop and deploy a portfolio of classes that meet the broad range of students. Committee Member Expectations: * Recruit a minimum of 1 instructor per calendar year. * Attend 75% of all scheduled committee calls. * Attend 66% of all NANOG meetings over the course of their two-year term. * Observe two classes over the course of their two-year term. * volunteer up to 10 hours in the 12 weeks leading into a class and an additional 15 hours all year round We are seeking volunteers to fill the following positions: Vice-Chair, Program Director, Instruction Director, and Technical Director, and members at large. If you are interested in participating, please send a short bio to Betty Burke, NANOG Executive Director, be...@nanog.orgmailto:be...@nanog.org. Betty can also answer any and all questions you may have. Betty or I will be sure to follow-up with each volunteer and get our important work underway. Sincerely, Dave Siegel
Re: TWC (AS11351) blocking all NTP?
I'd hate to think that NetOps would be so heavy handed in blocking all of UDP, as this would essentially halt quite a bit of audio/video traffic. That being said, there's still quite the need for protocol improvement when making use of UDP, but blocking UDP as a whole is definitely not a resolution, and simply creating a wall that not only keeps the abusive traffic out, but keeps legitimate traffic from flowing freely as it should. Sent on the TELUS Mobility network with BlackBerry -Original Message- From: Cb B cb.li...@gmail.com Date: Sun, 2 Feb 2014 15:09:55 To: Matthew Petachmpet...@netflight.com Cc: nanog@nanog.org Subject: Re: TWC (AS11351) blocking all NTP? On Feb 2, 2014 2:54 PM, Matthew Petach mpet...@netflight.com wrote: On Sun, Feb 2, 2014 at 2:17 PM, Cb B cb.li...@gmail.com wrote: On Feb 2, 2014 8:35 AM, Jonathan Towne jto...@slic.com wrote: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. And not just your provider, everyone is dealing with UDP amp attacks. These UDP based amp attacks are off the charts. Wholesale blocking of traffic at the protocol level to mitigate 10s to 100s of gigs of ddos traffic is not knee jerk, it is the right thing to do in a world where bcp 38 is far from universal and open dns servers, ntp, chargen, and whatever udp 172 is run wild. People who run networks know what it takes to restore service. And increasingly, that will be clamping ipv4 UDP in the plumbing, both reactively and proactively. Please note that it's not that UDP is at fault here; it's applications that are structured to respond to small input packets with large responses. I dont want to go into fault, there is plenty of that to go around. If NTP responded to a single query with a single equivalently sized response, its effectiveness as a DDoS attack would be zero; with zero amplification, the volume of attack traffic would be exactly equivalent to the volume of spoofed traffic the originator could send out in the first place. I agree the source obfuscation aspect of UDP can be annoying, from the spoofing perspective, but that really needs to be recognized to be separate from the volume amplification aspect, which is an application level issue, not a protocol level issue. Source obfuscation is not annoying. Combined with amplification, it is the perfect storm for shutting down networks... whereby the only solution is to shutdown ipv4 udp. Or wave the magic wand that makes bcp38 universal, patches boxes, and so on. My point is: dont expect these abbused services on UDP to last. We have experience in access networks on how to deal with abused protocols. Here is one reference http://customer.comcast.com/help-and-support/internet/list-of-blocked-ports/ My crystal ball says all of UDP will show up soon. CB Thanks! Matt PS--yes, I know it would completely change the dynamics of the internet as we know it today to shift to a 1:1 correspondence between input requests and output replies...but it *would* have a nice side effect of balancing out traffic ratios in many places, altering the settlement landscape in the process. ;)
Re: Updated ARIN allocation information
On Friday, January 31, 2014 01:58:58 AM Mark Andrews wrote: This range adds a maximum of 245760 (2^18-2^14) routes to the global routing table. Do you really want to go to court for this many routes? There is also a reasonable chance that acceptance of /28's could be strict in the beginning. But at some point, I imagine some operators (either due to lack of clue or just laziness) will simply write everything else up to /28, and then routers on the Internet will start to pick up a lot of the gunk that up to /24 filters have been keeping at bay. Prefixes longer than /24 (or /48) are especially common at exchange points, either by mistake or design. Mark. signature.asc Description: This is a digitally signed message part.
Re: TWC (AS11351) blocking all NTP?
On 2/2/2014 9:17 PM, ryang...@gmail.com wrote: I'd hate to think that NetOps would be so heavy handed in blocking all of UDP, as this would essentially halt quite a bit of audio/video traffic. That being said, there's still quite the need for protocol improvement when making use of UDP, but blocking UDP as a whole is definitely not a resolution, and simply creating a wall that not only keeps the abusive traffic out, but keeps legitimate traffic from flowing freely as it should. We had to burn down the village to save it. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014 7:41 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/2/2014 9:17 PM, ryang...@gmail.com wrote: I'd hate to think that NetOps would be so heavy handed in blocking all of UDP, as this would essentially halt quite a bit of audio/video traffic. That being said, there's still quite the need for protocol improvement when making use of UDP, but blocking UDP as a whole is definitely not a resolution, and simply creating a wall that not only keeps the abusive traffic out, but keeps legitimate traffic from flowing freely as it should. We had to burn down the village to save it. Close. More like a hurricane is landing in NYC so we are forcing an evacuation. But. Your network, your call. CB -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: TWC (AS11351) blocking all NTP?
On 3/02/14 4:45 pm, Cb B cb.li...@gmail.com wrote: On Feb 2, 2014 7:41 PM, Larry Sheldon larryshel...@cox.net wrote: On 2/2/2014 9:17 PM, ryang...@gmail.com wrote: I'd hate to think that NetOps would be so heavy handed in blocking all of UDP, as this would essentially halt quite a bit of audio/video traffic. That being said, there's still quite the need for protocol improvement when making use of UDP, but blocking UDP as a whole is definitely not a resolution, and simply creating a wall that not only keeps the abusive traffic out, but keeps legitimate traffic from flowing freely as it should. We had to burn down the village to save it. Close. More like a hurricane is landing in NYC so we are forcing an evacuation. But. Your network, your call. CB We block all outbound UDP for our ~200,000 Users for this very reason (with the exception of some whitelisted NTP and DNS servers). So far we have had 0 complaints, and 0 UDP floods sourced from us -- Geraint Jones Director of Systems Infrastructure Koding AS62805 (We are hiring) https://koding.com gera...@koding.com Phone (415) 653-0083 -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: TWC (AS11351) blocking all NTP?
On Feb 3, 2014, at 10:49 AM, Geraint Jones gera...@koding.com wrote: We block all outbound UDP for our ~200,000 Users for this very reason Actually, you could've (and should've) been far more selective in what you filtered via ACLs, IMHO. What about your users who play online games like BF4? I'm a big believer in using ACLs to intelligently preclude reflection/amplification abuse, but wholesale filtering of all UDP takes matters too far, IMHO. My suggestion would be to implement antispoofing on the southward interfaces of the customer aggregation edge (if you can't implement it via mechanisms such as cable ip source verify even further southward), and then implement a default ingress ACL on the coreward interfaces of the customer aggregation gateways to block inbound UDP destined to ntp, chargen, DNS, and SNMP ports only. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever)
We've worked through the same issues with Brocade/Intel, although we found that even though Brocade specs active only, our ICX switches don't reject passive cables, although oddly the Intel branded passive cables show up as UNSUPPORTED (but FCI and Molex ones from Digikey show up as the correct length and correct type of cable). If you do decide to go generic make sure you check the sizing. Maybe Brocade SFP+ drive is weak but using some 28 AWG 5M cables we've seen it takes a lot of errors. Switching to 26 AWG or 24 AWG solved the issue. I suspect Brocade requires active just from their storage background. On Sun, Feb 2, 2014 at 5:49 PM, Murphy-Olson, Daniel E. dol...@mcs.anl.govwrote: Most of the switch vendors have an official compatibility list, but I've found that generally the most common compatibility issue is active vs passive twinax. Brocade edge switches and nics are normally active only, which seems to come up a lot - because most short cables are passive unless they are brocade branded. 5m is normally the cutoff for passive twinax. Pretty much everything else I've encountered supports passive. For a while, the intel x520 nics, which are very common, didn't support active connections - but they have since released firmware that fixes this problem. Netapp's lower end gear doesn't support active twinax. From: Jeff Kell [jeff-k...@utc.edu] Sent: Sunday, February 02, 2014 3:15 PM To: Bryan Tong; Jay Ashworth Cc: NANOG Subject: Re: Twinax trivia check (was Re: Is there such a thing as a 10GBase-T SFP+ transciever) On 2/2/2014 4:03 PM, Bryan Tong wrote: These cables are most commonly known as Direct Attach Copper SFP+ The big issue appears to be that these are not always consistently functional crossing vendor lines (sometimes product lines within the same vendor). There does not appear to be any standardization in place. Not sure how much of this is picky vendor software looking for branded marks in their transceivers (e.g., Cisco service unsupported-transceiver) versus true incompatibilities. We have had issues in test cases crossing vendor lines (Cisco / Brocade / Dell / HP) with a twinax link that just simply won't work. If anyone has a clear explanation or better understanding, I'm all ears. Personal experience comes from only a few testbed cases. Jeff
Re: TWC (AS11351) blocking all NTP?
On Feb 3, 2014, at 10:58 AM, Dobbins, Roland rdobb...@arbor.net wrote: I'm a big believer in using ACLs to intelligently preclude reflection/amplification abuse, but wholesale filtering of all UDP takes matters too far, IMHO. I also think that restricting your users by default to your own recursive DNS servers, plus a couple of well-known, well-run public recursive services, is a good idea - as long as you allow your users to opt out. This has nothing to do with DDoS, but with other types of issues. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: TWC (AS11351) blocking all NTP?
The recently publicized mechanism to leverage NTP servers for amplified DoS attacks is seriously effective. I had a friend who had a local ISP affected by this Thursday and also another case where just two asterisk servers saturated a 100mbps link to the point of unusability. Once more - this exploit is seriously effective at using bandwidth by reflection. From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I were in TW position if I was unable to immediately contact the numerous downstream customers that were affected by this, I would take the option to block NTP on a case-by-case basis (perhaps even taking a broad brush) rather than allow it to continue and cause disruptions elsewhere. - Mike On Feb 2, 2014, at 12:44 PM, John Levine jo...@iecc.com wrote: In article 20140202163313.gf24...@hijacked.us you write: The provider has kindly acknowledged that there is an issue, and are working on a resolution. Heads up, it may be more than just my region. I'm a Time-Warner cable customer in the Syracuse region, and both of the NTP servers on my home LAN are happily syncing with outside peers. My real servers are hosted in Ithaca, with T-W being one of the upstreams and they're also OK. They were recruited into an NTP DDoS last month (while I was at a meeting working on anti-DDoS best practice, which was a little embarassing) but they're upgraded and locked down now. R's, John
Re: TWC (AS11351) blocking all NTP?
On Feb 3, 2014, at 12:45 PM, Michael DeMan na...@deman.com wrote: From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I were in TW position if I was unable to immediately contact the numerous downstream customers that were affected by this, I would take the option to block NTP on a case-by-case basis (perhaps even taking a broad brush) rather than allow it to continue and cause disruptions elsewhere. Per my previous post in this thread, there are ways to do this without blocking client access to ntp servers; in point of fact, unless the ISP in question isn't performing antispoofing at their customer aggregation edge, blocking client access to ntp servers does nothing to address (pardon the pun) the issue of ntp reflection/amplification DDoS attacks. All that broadband access operators need to do is to a) enforce antispoofing as close to their customers as possible, and b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic towards their customers at the customer aggregation edge (same for DNS, chargen, and SNMP). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: TWC (AS11351) blocking all NTP?
On Feb 3, 2014, at 1:02 PM, Dobbins, Roland rdobb...@arbor.net wrote: b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic towards their customers at the customer aggregation edge Actually, this can cause problems for ntpds operating in symmetric mode, where both the source and destination ports are UDP/123. Allowing inbound UDP/123 - UDP/123 and then rate-limiting it would be one approach; another would be to block outbound UDP/123 emanating from customers based upon packet size, if one's hardware allows matching on size in ACLs. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: TWC (AS11351) blocking all NTP?
On Feb 2, 2014, at 10:02 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Feb 3, 2014, at 12:45 PM, Michael DeMan na...@deman.com wrote: From a provider point of view, given the choices between contacting the end-users vs. mitigating the problem, if I were in TW position if I was unable to immediately contact the numerous downstream customers that were affected by this, I would take the option to block NTP on a case-by-case basis (perhaps even taking a broad brush) rather than allow it to continue and cause disruptions elsewhere. Per my previous post in this thread, there are ways to do this without blocking client access to ntp servers; in point of fact, unless the ISP in question isn't performing antispoofing at their customer aggregation edge, blocking client access to ntp servers does nothing to address (pardon the pun) the issue of ntp reflection/amplification DDoS attacks. Agreed, and I was not trying to get into arguments about saying whether 'blocking' is appropriate or not. I was simply suggesting that a provider, if they found themselves in a position where this was causing lots of troubles and impacting things in a large, might have had taken a 'broad brush' approach to stabilize things while they work on a more proper solution. All that broadband access operators need to do is to a) enforce antispoofing as close to their customers as possible, and b) enforce their AUPs (most broadband operators prohibit operating servers) by blocking *inbound* UDP/123 traffic towards their customers at the customer aggregation edge (same for DNS, chargen, and SNMP). I certainly would not want to provide as part the AUP (as seller or buyer), a policy that fundamentals like NTP are 'blocked' to customers. Seems like too much of a slippery slope for my taste. In regards to anti-spoofing measures - I think there a couple of vectors about the latest NTP attack where more rigorous client-side anti-spoofing could help but will not solve it overall. Trying to be fair and practical (from my perspective) - it is a lot easier and quicker to patch/workaround IPv4 problems and address proper solutions via IPv6 and associated RFCs? - Michael DeMan --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: TWC (AS11351) blocking all NTP?
On Feb 3, 2014, at 1:54 PM, Michael DeMan na...@deman.com wrote: I certainly would not want to provide as part the AUP (as seller or buyer), a policy that fundamentals like NTP are 'blocked' to customers. Seems like too much of a slippery slope for my taste. The idea is to block traffic to misconfigured ntpds on broadband customer access networks, not to limit their choice of which ntp servers to use. In regards to anti-spoofing measures - I think there a couple of vectors about the latest NTP attack where more rigorous client-side anti-spoofing could help but will not solve it overall. Rigorous antispoofing would solve the problem of all reflection/amplification DDoS attacks. My hunch is that most spoofed traffic involved in these attacks actually emanates from compromised/abused servers on IDC networks (including so-called 'bulletproof' miscreant-friendly networks), but I've no data to support that, yet. Trying to be fair and practical (from my perspective) - it is a lot easier and quicker to patch/workaround IPv4 problems and address proper solutions via IPv6 and associated RFCs? There's nothing in IPv6 which makes any difference. The ultimate solution is antispoofing at the customer edge. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info
On Jan 29, 2014, at 3:03 AM, Jared Mauch ja...@puck.nether.net wrote: Sure, but this means that network is allowing the spoofing :) What I did last night was automated comparing the source ASN to the dest ASN mapped to and reported both the IP + ASN on a single line for those that were interested. This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info
On Jan 29, 2014, at 4:47 AM, Nick Olsen n...@flhsi.com wrote: After a quick phone conversation with Jared. We concluded that at least in the specific case I was speaking about, I was correct in that nothing was Spoofed. Forgive me for being slow, but doesn't this seem to imply that there isn't any antispoofing taking place at the GRE tunnel ingress? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
Re: BCP38.info
On Feb 3, 2014, at 2:22 PM, Dobbins, Roland rdobb...@arbor.net wrote: This is pretty slick, relying upon broken CPE NAT implementations. It's the only way I've heard of to remotely infer whether or not a given network allows spoofing. It would be useful to know whether there are in fact NATs, or are 'DNS forwarders' . . . --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
