Re: abuse reporting tools
On Thu, Nov 20, 2014 at 6:44 AM, Paul Bennett paul.w.benn...@gmail.com wrote: Inspired by this thread (and other recent similar ones about how hard it is to report abuse in the right format to the right people), I've decided I'm going to start work on [a] Perl module Well ... preliminary ground work has started. It's not much, yet, but it's out there _just_ enough to (hopefully) prove I'm serious about this https://github.com/PWBENNETT/Net-Abuse-Reporter Patches / collaboration more than welcome, if you think you can glean what's going on inside my head (related to this project, at least). -- Paul W Bennett
determine relationship between the operators based on import and export statements in aut-num object?
Hi, bit weird question, but is it possible to determine relationship(Internet transit, settlement-free peering, etc) between the operators based on import and export statements in aut-num object? Often aut-num objects in RIR database contain the remarks which describe such relationships. However, for example here I have following import and export attributes from an aut-num object of an ISP: import: from AS65133 action pref=100; accept ANY import: from AS65798 accept AS65798 import: from AS65084 accept AS65084 import: from AS65485 action pref=100; accept ANY import: from AS65751 accept AS65751 import: from AS65059 action pref=100; accept ANY import: from AS65128 accept AS65128 export: to AS65133 announce AS-SET export: to AS65798 announce ANY export: to AS65084 announce ANY export: to AS65485 announce AS-SET export: to AS65751 announce ANY export: to AS650835 announce AS-SET export: to AS65128 announce ANY Am I correct that it is safe to say that probably AS65133, AS65485 and AS65059 are the uplink providers and AS65798, AS65084, AS65751 and AS65128 are the customers of this ISP? Last but not least, maybe there is altogether a more reliable way to understand the relationship between the operators than aut-num objects(often not updated) in RIR database? thanks, Martin
How do I handle a supplier that delivered a faulty product?
Hello, We are a small FTTH provider and our main business is selling 1000/1000 internet. Our network is GPON based. We recently made the mistake of buying a large shipment of Zhone 2301 modems (ONU). We did test this device before purchase, but unfortunately we failed to notice a severe fault with the product. Soon after putting it into production we got many complaints from customers that the modem would crash daily. Turns out that the device can not handle download streams at or near 1000 Mbps. Especially if the download originates with a server that is 10G connected. GPON downstream is actually 2.4 Gbps. The modem has to deliver on an ordinary 1 Gbps ethernet port. This means the packets can arrive faster than the modem can hand it off on the ethernet side. And when that happens, it will simply crash. The vendor then told us to limit download speed to 750 Mbps with a small buffer of 50 KB. Any faster and the modem can crash amongst other issues. When I told them I do not think I can sell 1000/1000 Mbps internet if I limit the modems to 750 Mbps, as that would be false advertising, I was simply told that the 2301 is a low cost solution, so deal with it. They are not going to work more on fixing the issue. The website and the datasheet does not say anything that would warn you that this product can only handle 750 Mbps: http://www.zhone.com/products/ZNID-GPON-2301/ZNID-GPON-2301.pdf So what do I do now? I am thinking Zhone needs to resolve this in a satisfactory way, which is to either return my money or switch the product to something, that actually delivers what was promised. We have some of their 24xx series and that works perfectly well. So we know it is just the 2301 that is bad. Unfortunately we are apparently to small a customer to them. As this is an USA supplier, will suing them help me any? Yes I know, don't ask for legal advice on a mailing list, and I am not - I just want to know some opinions if that is even worth considering. Or if I will just have to eat it and drive the whole shipment into the harbor. Regards, Baldur
Re: determine relationship between the operators based on import and export statements in aut-num object?
On Tue, 25 Nov 2014 17:36:47 +0200, Martin T said: bit weird question, but is it possible to determine relationship(Internet transit, settlement-free peering, etc) between the operators based on import and export statements in aut-num object? You can determine who is upstream and downstream from that. You can't tell if it's paid transit or free peering, because technically they're the same on the wire. All that's different is the economic motivations that allow/cause the routing jocks from the two sites involved to connect a pipe and put it in production. pgpLptInRolVd.pgp Description: PGP signature
Re: determine relationship between the operators based on import and export statements in aut-num object?
On Tue, 25 Nov 2014 17:36:47 +0200, Martin T m4rtn...@gmail.com said: Last but not least, maybe there is altogether a more reliable way to understand the relationship between the operators than aut-num objects(often not updated) in RIR database? The first thing to do is look and see if the policy of, e.g. AS65133 is consistent with what you see there. I suspect you'll find a lot of mismatches but I don't know if that has been studied systematically, but it should be simple to do. Next, much more data intensive, is trawl through the route views data and see to what extent the actual updates seen are consistent with the RIR objects, and also see what (topological, not financial as Valdis points out) relationships they imply that are not present in the RIR database. -w pgpyra4iyCZND.pgp Description: PGP signature
Re: How do I handle a supplier that delivered a faulty product?
Baldur Norddahl wrote: Hello, We are a small FTTH provider and our main business is selling 1000/1000 internet. Our network is GPON based. We recently made the mistake of buying a large shipment of Zhone 2301 modems (ONU). We did test this device before purchase, but unfortunately we failed to notice a severe fault with the product. Soon after putting it into production we got many complaints from customers that the modem would crash daily. Turns out that the device can not handle download streams at or near 1000 Mbps. Especially if the download originates with a server that is 10G connected. GPON downstream is actually 2.4 Gbps. The modem has to deliver on an ordinary 1 Gbps ethernet port. This means the packets can arrive faster than the modem can hand it off on the ethernet side. And when that happens, it will simply crash. The vendor then told us to limit download speed to 750 Mbps with a small buffer of 50 KB. Any faster and the modem can crash amongst other issues. When I told them I do not think I can sell 1000/1000 Mbps internet if I limit the modems to 750 Mbps, as that would be false advertising, I was simply told that the 2301 is a low cost solution, so deal with it. They are not going to work more on fixing the issue. The website and the datasheet does not say anything that would warn you that this product can only handle 750 Mbps: http://www.zhone.com/products/ZNID-GPON-2301/ZNID-GPON-2301.pdf So what do I do now? I am thinking Zhone needs to resolve this in a satisfactory way, which is to either return my money or switch the product to something, that actually delivers what was promised. We have some of their 24xx series and that works perfectly well. So we know it is just the 2301 that is bad. Unfortunately we are apparently to small a customer to them. As this is an USA supplier, will suing them help me any? Yes I know, don't ask for legal advice on a mailing list, and I am not - I just want to know some opinions if that is even worth considering. Or if I will just have to eat it and drive the whole shipment into the harbor. If it doesn't deliver to spec, that certainly seems like a warranty claim, followed by a lawsuit (yes - talk to a lawyer). Also, define large shipment and total dollars involved. You might be able to take them to small claims court (much simpler process, but generally for $10,000 or under). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: How do I handle a supplier that delivered a faulty product?
On Tue, 25 Nov 2014, Miles Fidelman wrote: If it doesn't deliver to spec, that certainly seems like a warranty claim, followed by a lawsuit (yes - talk to a lawyer). Also, define large shipment and total dollars involved. You might be able to take them to small claims court (much simpler process, but generally for $10,000 or under). Disclaimer: I am not a lawyer, and I don't play one on TV. Don't be afraid to march this up the chain at Zhone, if you're dealing with a salescritter. You might be able to get better responses from VPs or CxOs. Keep the lawsuit option in your back pocket if you need it. Many companies don't want the PR black eye that comes with a customer filing suit against them, so the threat of beating them with a stick can be just as effective actually carrying out that threat. If you have a lawyer on retainer already, maybe have them on the phone with you when you speak to the CxO at Zhone. If their product is advertised as providing a service that it can't/won't actually provide, whether it's positioned as a low-cost product or not is irrelevant. If their data sheets make no mention of the limitations that have been found, that's more ammunition for the cannon. Before anyone comes back with something like So if I buy an entry level car, but I expect it to perform like a high-end sports car, does that mean I can sue the entry-level car maker for false advertising when it doesn't perform like a high-end sports car? No, it doesn't. There are reasonable expectations. Expecting an entry-level car to perform like a high-end sports car isn't reasonable. Expecting a GPON modem to be able to forward wire-speed gigabit Ethernet in this day and age is perfectly reasonable. jms
Buying IP Bandwidth Across a Peering Exchange
I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible?
Re: Buying IP Bandwidth Across a Peering Exchange
On 11/25/14, 1:47 PM, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible? Depends on the exchange. Some allow it, some don’t. Some don’t have a policy. Some providers offer it, some don’t. Randy
Re: Buying IP Bandwidth Across a Peering Exchange
On 25/11/2014 18:47, Colton Conor wrote: Is this possible? it depends. Some transit providers will decline to do this because it can impact on their margin. Most IXPs don't have a problem with it, but some do - although it's not clear how they can tell which packets are transit and which are peering. Nick
Re: Buying IP Bandwidth Across a Peering Exchange
On Nov 25, 2014, at 10:47 AM, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some IXPs have a rule that explicitly disallows this, others encourage it, most don’t care. I don’t know of any that have a mechanism to enforce a rule prohibiting it. PCH’s guidance in the IXP formation process is to avoid creating rules which are, practically, unenforceable. So we generally counsel IXPs against having a rule precluding transit across the switch fabric. That said, a crossconnect is a _much better idea_. Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible? Yes, it’s possible, but what you describe is a pretty fragile setup. Lots of common points of failure between peering and transit; places where screwing one up would screw both up. If all of this is really tangential to whatever you’re doing, and you don’t mind looking a little out-of-step with best practices, and you don’t mind it all being down at once, any time anything breaks, then it may be a reasonable economy. If you’re planning on actually depending on it, you need to do better engineering, and either spend more money, or allocate your money more conservatively. Doing everything the cheapest possible way, regardless of the fragility or complexity, is very short-sighted, and is unlikely to be an economy in the long run. -Bill signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Buying IP Bandwidth Across a Peering Exchange
I know a couple networks that offer to sell transit over exchanges that permit it, but require that you take a private VLAN on the exchange. Some exchanges offer private VLANs, others don't. Regards, Chris Rogers +1.302.357.3696 x2110 http://inerail.net/ On Tue, Nov 25, 2014 at 1:51 PM, Nick Hilliard n...@foobar.org wrote: On 25/11/2014 18:47, Colton Conor wrote: Is this possible? it depends. Some transit providers will decline to do this because it can impact on their margin. Most IXPs don't have a problem with it, but some do - although it's not clear how they can tell which packets are transit and which are peering. Nick
Re: A case against vendor-locking optical modules
I've found the best method of dealing with vendors like this is to treat them the same way they treat you. If they won't listen to technical arguments and act like stubborn children, then I act the same way. Threaten to take your ball and go home. Or buy everything used or from grey market vendors. It works pretty well. The vendor/client relationship is a two-way street, and they should be reminded of that. Especially when dealing with commodity whitebox switch vendors like Arista...who can easily be replaced with another whitebox switch vendor and $networkOS. -richard On Tue, Nov 18, 2014 at 7:05 PM, Naslund, Steve snasl...@medline.com wrote: They want the ability to buy off the shelf components when they manufacture. They just don't want you to have the same privilege when you purchase. Your switches and routers are made of a bunch of OEM components with some custom programmed ASICS and some secret sauce. If they used non standard interface specs their costs would go through the roof as their power supplies, memory, storage, and NICS would be all custom development. Steven Naslund Chicago IL On Nov 18, 2014, at 12:42 PM, Baldur Norddahl baldur.nordd...@gmail.com wrote: If they really wanted to lock you in, they would have triangular modules instead of square... Or I suppose the vendors like to be able to shop around for modules, before they relabel and sell them to you at a 10x markup.
RE: Buying IP Bandwidth Across a Peering Exchange
I have seen this work well when the exchange allows more than one MAC address to be presented at layer2. This way you can have two separate sub interfaces presented, one for peering and one for your private cross connect/transit. That way the routing all stays clean and manageable. It's still a little messy, but is a much better solution than getting peering and transit over a single layer3 interface. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Chris Rogers Sent: Wednesday, 26 November 2014 7:57 a.m. To: Nick Hilliard Cc: NANOG Subject: Re: Buying IP Bandwidth Across a Peering Exchange I know a couple networks that offer to sell transit over exchanges that permit it, but require that you take a private VLAN on the exchange. Some exchanges offer private VLANs, others don't. Regards, Chris Rogers +1.302.357.3696 x2110 http://inerail.net/
Re: Buying IP Bandwidth Across a Peering Exchange
The exchange in question is Equinix. Their sales team is leading me to believe there are multiple exchange products. One where you can peer with providers (Google, Netflix for example) and then one where you can create virtual private layer 2 vlans between providers. Then there is also the traditional cross connect fee of $350 if you want to go from one cage/rack to the other. So in a situation where we are getting a 10Gig transport wave to Equinix, we would ideally like to split this wave's use to 5Gbps of traffic going to the peering exchange for traffic going directly to Google, Netflix, and other CDN's, and then 5Gbps of pure IP transit going to a low cost provider like HE.net. Of course providers like HE.NET are also peers on the peering exchange, so it seems possible that we could just opening a peering conenction with them. I think the way most providers would do this would be to get a rack and power with Equinix. Pay a cross connect fee from the wave provider to our rack. Pay for an exchange port (which includes a cross connect to the exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then pay for yet another cross connect going to HE.net's cage to get pure IP from them. If I can buy transit directly I avoid the expenses of having to pay for space, power, another router/switch, plus a second cross connect. Thats quite a bit of money saved. Are exchanges really that unreliable compared to a traditional cross connect? On Tue, Nov 25, 2014 at 12:52 PM, Ammar Zuberi am...@fastreturn.net wrote: Hi Conor, I know this is possible since Hurricane Electric does it for IPv6 transit, however, I'm not sure if it violates any exchange rules or if it's even a good idea. On 25 Nov 2014, at 10:47 pm, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible?
RE: abuse reporting tools
On Tue, Nov 18, 2014 at 7:41 PM, Robert Drake rdr...@direcpath.com wrote: On 11/18/2014 8:11 PM, Michael Brown wrote: [snip] amelioration. So I'm left with a very unsatisfactory feeling of either shutting down a possibly innocent customer based on a machines word, or attempting to start a dialog with random_script_user...@hotmail.com. Under those circumstances, how do you know it's not a social-engineering based DoS being attempted? Preferably, take no action to shutdown services without decent confirmation; as malicious reports of a fraudulent, bogus, dramatized, or otherwise misleading nature are sometimes used by malicious actors to target a legitimate user. My suggestion would be table the report of a single SSH connection and really do nothing with it.If there is actually abuse being conducted, you should either be able to independently verify the actual abuse, e.g. by checking packet level data or netflow data, or you should begin to receive a pattern of complaints; more unique contacts, that you can investigate and verify are legit. contacts from unique networks. If you know the destination IP address that the traffic is supposedly going to you can also just ACL it, that way if it's a customer of a customer you don't shut down the customer's entire business over something one person downstream is doing and you 'fix' the issue at the same time. The right answer really depends on how responsive your customer is to the complaints in the first place. -Drew
Seeking IPv6 Security Resources
Hail NANOG! I am looking for IPv6 security resources to add to: http://www.internetsociety.org/deploy360/ipv6/security/ These could be best current practice documents, case-studies, lessons-learned/issues-found, research/evaluations, RFCs, or anything else focused on IPv6 security really. I'm not requesting that anyone do any new work, just that you point me to solid public documents that already exist. Feel free to share on-list or privately, both documents you may have authored and those you have found helpful. Thanks! ~Chris Note: Not every document shared will get posted to the Deploy360 site. -- @ChrisGrundemann http://chrisgrundemann.com
Re: Buying IP Bandwidth Across a Peering Exchange
I agree with Bill...going it on the cheap is risky. DOn't consider it for primary. It may be good for backup. I have sold small amounts of transit to non-ISP companies on exchanges (100-200 meg). It's a good extra backup for ISPs, if you setup your local pref, MED and then prepend your AS an extra time or two to the prefixes you transmit. Then if you ever need to use it, it's sitting there waiting to send and receive traffic. I let ISPs customers do that with us for real low cost backup fees. Bob Evans On Nov 25, 2014, at 10:47 AM, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some IXPs have a rule that explicitly disallows this, others encourage it, most dont care. I dont know of any that have a mechanism to enforce a rule prohibiting it. PCHs guidance in the IXP formation process is to avoid creating rules which are, practically, unenforceable. So we generally counsel IXPs against having a rule precluding transit across the switch fabric. That said, a crossconnect is a _much better idea_. Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible? Yes, its possible, but what you describe is a pretty fragile setup. Lots of common points of failure between peering and transit; places where screwing one up would screw both up. If all of this is really tangential to whatever youre doing, and you dont mind looking a little out-of-step with best practices, and you dont mind it all being down at once, any time anything breaks, then it may be a reasonable economy. If youre planning on actually depending on it, you need to do better engineering, and either spend more money, or allocate your money more conservatively. Doing everything the cheapest possible way, regardless of the fragility or complexity, is very short-sighted, and is unlikely to be an economy in the long run. -Bill
Re: Seeking IPv6 Security Resources
--- cgrundem...@gmail.com wrote: From: Chris Grundemann cgrundem...@gmail.com I am looking for IPv6 security resources to add to: http://www.internetsociety.org/deploy360/ipv6/security/ These could be best current practice documents, case-studies, lessons-learned/issues-found, research/evaluations, RFCs, or anything else focused on IPv6 security really. I'm not requesting that anyone do any new work, just that you point me to solid public documents that already exist. Feel free to share on-list or privately, both documents you may have authored and those you have found helpful. -- http://www.si6networks.com/tools/ipv6toolkit/index.html List of Tools •addr6: An IPv6 address analysis and manipulation tool. •flow6: A tool to perform a security asseessment of the IPv6 Flow Label. •frag6: A tool to perform IPv6 fragmentation-based attacks and to perform a security assessment of a number of fragmentation-related aspects. •icmp6: A tool to perform attacks based on ICMPv6 error messages. •jumbo6: A tool to assess potential flaws in the handling of IPv6 Jumbograms. •na6: A tool to send arbitrary Neighbor Advertisement messages. •ni6: A tool to send arbitrary ICMPv6 Node Information messages, and assess possible flaws in the processing of such packets. •ns6: A tool to send arbitrary Neighbor Solicitation messages. •ra6: A tool to send arbitrary Router Advertisement messages. •rd6: A tool to send arbitrary ICMPv6 Redirect messages. •rs6: A tool to send arbitrary Router Solicitation messages. •scan6: An IPv6 address scanning tool. •tcp6: A tool to send arbitrary TCP segments and perform a variety of TCP-based attacks. scott
Re: Buying IP Bandwidth Across a Peering Exchange
Hi Colton, The primary challenge in buying IP Transit across a Peering Exchange is not so much of a technical configuration challenge, but rather a 'how do we keep track of how much IP Transit you are using' ..a billing challenge. and additionally, one is making the assumption that there is capacity to do so on the IP Transit Providers Peering Port Connection. While it is possible to deal with such issue, but you need someone willing and able to do so, on the other side. I think the way most providers would do this would be to get a rack and power with Equinix. Pay a cross connect fee from the wave provider to our rack. Pay for an exchange port (which includes a cross connect to the exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then pay for yet another cross connect going to HE.net's cage to get pure IP from them. - Yes, you are right, this is the traditional way of doing so, and yes, it can get expensive.. For this exact reason, folks such as us and others who are willing to provide access via their existing resources at different facilities. We are facilitating flexible connectivity needs of folks who are running remote (from major metro areas) such as yours, in Miami, Atlanta, and I know others who are doing so in Equinox Chicago, one in Texas and a couple of the West Coast. Feel free to ping me off list if you are interested in additional details. Regards Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Colton Conor colton.co...@gmail.com To: Ammar Zuberi am...@fastreturn.net Cc: NANOG nanog@nanog.org Sent: Tuesday, November 25, 2014 2:51:47 PM Subject: Re: Buying IP Bandwidth Across a Peering Exchange The exchange in question is Equinix. Their sales team is leading me to believe there are multiple exchange products. One where you can peer with providers (Google, Netflix for example) and then one where you can create virtual private layer 2 vlans between providers. Then there is also the traditional cross connect fee of $350 if you want to go from one cage/rack to the other. So in a situation where we are getting a 10Gig transport wave to Equinix, we would ideally like to split this wave's use to 5Gbps of traffic going to the peering exchange for traffic going directly to Google, Netflix, and other CDN's, and then 5Gbps of pure IP transit going to a low cost provider like HE.net. Of course providers like HE.NET are also peers on the peering exchange, so it seems possible that we could just opening a peering conenction with them. I think the way most providers would do this would be to get a rack and power with Equinix. Pay a cross connect fee from the wave provider to our rack. Pay for an exchange port (which includes a cross connect to the exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then pay for yet another cross connect going to HE.net's cage to get pure IP from them. If I can buy transit directly I avoid the expenses of having to pay for space, power, another router/switch, plus a second cross connect. Thats quite a bit of money saved. Are exchanges really that unreliable compared to a traditional cross connect? On Tue, Nov 25, 2014 at 12:52 PM, Ammar Zuberi am...@fastreturn.net wrote: Hi Conor, I know this is possible since Hurricane Electric does it for IPv6 transit, however, I'm not sure if it violates any exchange rules or if it's even a good idea. On 25 Nov 2014, at 10:47 pm, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible?
Re: Buying IP Bandwidth Across a Peering Exchange
Hi Conor, I know this is possible since Hurricane Electric does it for IPv6 transit, however, I'm not sure if it violates any exchange rules or if it's even a good idea. On 25 Nov 2014, at 10:47 pm, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible?
RE: Buying IP Bandwidth Across a Peering Exchange
Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible? It's been a while since I've checked the Equinix Customer Agreement and Policies documents, but I know at one time they required a physical presence in the in the IDC for an Exchange cross-connect. This may have changed in the past several years. -evt
Re: How do I handle a supplier that delivered a faulty product?
On 25/11/14 09:39, Justin M. Streiner wrote: Before anyone comes back with something like So if I buy an entry level car, but I expect it to perform like a high-end sports car, does that mean I can sue the entry-level car maker for false advertising when it doesn't perform like a high-end sports car? No, it doesn't. There are reasonable expectations. Expecting an entry-level car to perform like a high-end sports car isn't reasonable. Expecting a GPON modem to be able to forward wire-speed gigabit Ethernet in this day and age is perfectly reasonable. Actually, this situation is as if you bought a low-end car that claims it can go 60MPH just like a high-end sports car which also claims to go 60MPH. But when the low-end car fails to achieve 60MPH and in fact blows up when you try to reach that speed, you do have grounds to cry false advertising. According to the spec-sheet pointed to by the OP: GPON Rx - Downstream data rate 2.488Gbps So the fact that the device fails to survive much less achieve the claimed rate is, I would expect, false advertisement... especially when the manufacturer acknowledges the discrepancy and refuses to take measures to remedy the situation. At this point, the OP may be at risk to his customers as well so it would be really in his best interest to pursue this as far as possible which may include legal action. -- /*=[ Jake Khuon kh...@neebu.net ]=+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==*/ signature.asc Description: OpenPGP digital signature
Re: Buying IP Bandwidth Across a Peering Exchange
The way our exchange works is 2 different products in regards to this. 1.Peering on the exchange. This is a BGP exchange. 2.Private VLAN. Each side gets a private VLAN between the two. Either way you buy capacity on the exchange and it¹s up to you how you use it. I have some Equinix documents on their exchange port offerings if you are interested. Justin -- Justin Wilson j...@mtin.net http://www.mtin.net Managed Services xISP Solutions Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering Transit Internet Exchange On 11/25/14, 4:29 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: Hi Colton, The primary challenge in buying IP Transit across a Peering Exchange is not so much of a technical configuration challenge, but rather a 'how do we keep track of how much IP Transit you are using' ..a billing challenge. and additionally, one is making the assumption that there is capacity to do so on the IP Transit Providers Peering Port Connection. While it is possible to deal with such issue, but you need someone willing and able to do so, on the other side. I think the way most providers would do this would be to get a rack and power with Equinix. Pay a cross connect fee from the wave provider to our rack. Pay for an exchange port (which includes a cross connect to the exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then pay for yet another cross connect going to HE.net's cage to get pure IP from them. - Yes, you are right, this is the traditional way of doing so, and yes, it can get expensive.. For this exact reason, folks such as us and others who are willing to provide access via their existing resources at different facilities. We are facilitating flexible connectivity needs of folks who are running remote (from major metro areas) such as yours, in Miami, Atlanta, and I know others who are doing so in Equinox Chicago, one in Texas and a couple of the West Coast. Feel free to ping me off list if you are interested in additional details. Regards Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Colton Conor colton.co...@gmail.com To: Ammar Zuberi am...@fastreturn.net Cc: NANOG nanog@nanog.org Sent: Tuesday, November 25, 2014 2:51:47 PM Subject: Re: Buying IP Bandwidth Across a Peering Exchange The exchange in question is Equinix. Their sales team is leading me to believe there are multiple exchange products. One where you can peer with providers (Google, Netflix for example) and then one where you can create virtual private layer 2 vlans between providers. Then there is also the traditional cross connect fee of $350 if you want to go from one cage/rack to the other. So in a situation where we are getting a 10Gig transport wave to Equinix, we would ideally like to split this wave's use to 5Gbps of traffic going to the peering exchange for traffic going directly to Google, Netflix, and other CDN's, and then 5Gbps of pure IP transit going to a low cost provider like HE.net. Of course providers like HE.NET are also peers on the peering exchange, so it seems possible that we could just opening a peering conenction with them. I think the way most providers would do this would be to get a rack and power with Equinix. Pay a cross connect fee from the wave provider to our rack. Pay for an exchange port (which includes a cross connect to the exchange) for the 5GBPS of traffic going to Netflix, Google, etc. And then pay for yet another cross connect going to HE.net's cage to get pure IP from them. If I can buy transit directly I avoid the expenses of having to pay for space, power, another router/switch, plus a second cross connect. Thats quite a bit of money saved. Are exchanges really that unreliable compared to a traditional cross connect? On Tue, Nov 25, 2014 at 12:52 PM, Ammar Zuberi am...@fastreturn.net wrote: Hi Conor, I know this is possible since Hurricane Electric does it for IPv6 transit, however, I'm not sure if it violates any exchange rules or if it's even a good idea. On 25 Nov 2014, at 10:47 pm, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical
Re: How do I handle a supplier that delivered a faulty product?
On Tue, Nov 25, 2014 at 8:12 PM, Jake Khuon kh...@neebu.net wrote: Actually, this situation is as if you bought a low-end car that claims it can go 60MPH just like a high-end sports car which also claims to go 60MPH. But when the low-end car fails to achieve 60MPH and in fact blows up when you try to reach that speed, you do have grounds to cry false advertising. If we're going to pick analogies, let's pick a good one. This is a car advertised to go 60 mph. But it turns out the car only goes 60 mph down hill... On a 1 degree incline it tops out at 45. And yeah, that's a lemon. If the vendor has not supplied a technically appropriate solution within a reasonable amount of time, they're in breach of the implied contract of fitness for purpose. Unless of course you -signed- a contract which says otherwise or their shrink-wrap contract has effect (only Virginia or Maryland). You may be entitled to more than a refund, such as any business losses from the failure of the product to perform as advertised, including lost customer good will and employee man hours. Baldur, I advise you to consult a lawyer. This is where a -letter- from your lawyer to their lawyer (no lawsuit just yet) will yield action. It'll make it clear to the folks on the business end that the technical end has let them (and you) down more seriously than the normal bug complaints. That letter won't cost you more than a couple hundred bucks. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: Seeking IPv6 Security Resources
On Nov 25, 2014, at 12:32 PM, Chris Grundemann cgrundem...@gmail.com wrote: Hail NANOG! I am looking for IPv6 security resources to add to: http://www.internetsociety.org/deploy360/ipv6/security/ These could be best current practice documents, case-studies, lessons-learned/issues-found, research/evaluations, RFCs, or anything else focused on IPv6 security really. https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf
Re: Buying IP Bandwidth Across a Peering Exchange
Be careful joining an IX just to peer with Google (AS15169) and a few others...especially if your exchange doesn’t have route servers established. Some companies, such as NetFlix, have a truly open peering policy; establishing a bilateral BGP session with them is super-straightforward. On the other hand, Google’s actively-enforced policy requires you already exchange 100Mbps+ w/ their netblocks: upon requesting a session they’ll monitor/check related traffic for a few weeks before following up on your initial request. More details: https://peering.google.com/about/peering_policy.html As for transit across IX fabric, I know that HE.net is at least willing to discuss such a possibility (just started this exact discussion with their NOC last night), although they discourage it for reasons pointed out by others in this thread. On the other hand, with a willing transit provider, if you prepend your AS a few times…an IX's fabric makes a very cost-effective failover. Gregg Berkholtz On Nov 25, 2014, at 10:47 AM, Colton Conor colton.co...@gmail.com wrote: I know typically peering exchanges are made for peering traffic between providers, but can you buy IP transit from a provider on an exchange? An example, buy a 10G port on an exchange, peer 5Gbps of traffic with multiple providers on the exchange, and buy 5Gbps of IP transit from others on the exchange? Some might ask why not get a cross connect to the provider. It is cheaper to buy an port on the exchange (which includes the cross connect to the exchange) than buy multiple cross connects. Plus we are planning on getting a wave to the exchange, and not having any physical routers or switches at the datacenter where the exchange/wave terminates at. Is this possible?
Re: How do I handle a supplier that delivered a faulty product?
At no point does that spec say a single thing about speed. The closest part I could find was Upstream data rate 1.244Gbps, but I think it's pretty clear that that is the link speed, not the actual data rate. It's worth wringing them out over the issue, maybe you can shame them into taking the units back, but I don't think you will have much luck pinning them down legally on some nebulous belief that it would run at wire rate gigabit. Nick On Tue, Nov 25, 2014 at 8:34 PM, William Herrin b...@herrin.us wrote: On Tue, Nov 25, 2014 at 8:12 PM, Jake Khuon kh...@neebu.net wrote: Actually, this situation is as if you bought a low-end car that claims it can go 60MPH just like a high-end sports car which also claims to go 60MPH. But when the low-end car fails to achieve 60MPH and in fact blows up when you try to reach that speed, you do have grounds to cry false advertising. If we're going to pick analogies, let's pick a good one. This is a car advertised to go 60 mph. But it turns out the car only goes 60 mph down hill... On a 1 degree incline it tops out at 45. And yeah, that's a lemon. If the vendor has not supplied a technically appropriate solution within a reasonable amount of time, they're in breach of the implied contract of fitness for purpose. Unless of course you -signed- a contract which says otherwise or their shrink-wrap contract has effect (only Virginia or Maryland). You may be entitled to more than a refund, such as any business losses from the failure of the product to perform as advertised, including lost customer good will and employee man hours. Baldur, I advise you to consult a lawyer. This is where a -letter- from your lawyer to their lawyer (no lawsuit just yet) will yield action. It'll make it clear to the folks on the business end that the technical end has let them (and you) down more seriously than the normal bug complaints. That letter won't cost you more than a couple hundred bucks. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/ May I solve your unusual networking challenges?
Re: How do I handle a supplier that delivered a faulty product?
In message cae7mfijoxo9ybyg4be+f9qm7vnvv1iqfjyjs4h0k0d-jjbw...@mail.gmail.com, Nick B writes: At no point does that spec say a single thing about speed. The closest part I could find was Upstream data rate 1.244Gbps, but I think it's pretty clear that that is the link speed, not the actual data rate. It's worth wringing them out over the issue, maybe you can shame them into taking the units back, but I don't think you will have much luck pinning them down legally on some nebulous belief that it would run at wire rate gigabit. Nick Any router/modem that *crashes* when the input rate exceeds the output rate is broken. A router/modem shouldn't crash regardless of the data input rate. It might drop packets but not crash. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: How do I handle a supplier that delivered a faulty product?
On 11/25/14 10:06 PM, Mark Andrews wrote: Any router/modem that*crashes* when the input rate exceeds the output rate is broken. A router/modem shouldn't crash regardless of the data input rate. It might drop packets but not crash. Maybe the bit-bucket got full?
Re: How do I handle a supplier that delivered a faulty product?
On Wed, Nov 26, 2014 at 12:22 AM, Doug Barton do...@dougbarton.us wrote: Maybe the bit-bucket got full? Then the new packets should be dropped, but this seems like a potential vulnerability. What it seems like to me is that the bit-bucket is not size limited, and proceeds to overwrite other memory, quickly killing the OS.
Re: abuse reporting tools
First please filter the source addr on all egress traffic, please. Please. Second, please don’t be the network admin whom emails: “… To: notourorgabuseem...@tocici.com From: cluelessad...@example.com Subject: An attempt of intrusion comes from your ip . …” Just in case you missed the obvious: message body was empty, $cluelessAdmin didn’t do a basic whois for our OrgAbuseEmail, and $cluelessAdmin ASSumed we knew which of our 2,048 IPs apparently started WWIII while providing absolutely zero collaborating evidence (attaching or linking to raw tcpdump is very nice, “-d” is Ok too). We often receive dozens of these totally useless/blank emails, in clusters of a few minutes. Tricks like that earn an instant 144-hour null route badge for whichever sending company’s entire presumed netblock (if we can’t find an obvious AS), repeat offenses earn longer and more colorful badges. All get a personal voicemail to the $cluelessAdmin company’s exec(s)/admin(s). I deliver these voicemails roughly three times a week now. Teh Stupid leaves burn marks on our NOC techs, and the poor geeks can only take so much! Other suggestions, such as watching and responding to s/NetFlow spikes, or tracking/linking multiple complaining networks before even attempting to look at origins…these sometimes warrant a followup depending upon volume and frequency (easily tracked with an SQLLite + PHP-based tool/api). We’ve found things are more-often just fat fingers, someone more bored than harmful, or someone that hasn’t figured out zmap options yet. As for a genuine DDoS, with a spoofed-source - can you really do much about this? For years we’ve just automatically null-routed (+RTBH) the ingress target (and, if obvious, any egress source) for a shortish random() period, and everyone typically gets bored shortly thereafter. Our current null-route based homegrown DDoS mitigation platform requires barely ~10 seconds from detection/onset to mitigation, so we tend to elimianate most fun and drama pretty quickly. For more business-focused clients, services like CloudFlare typically keeps DDoS attacks off ingress IPs. (BTW: in addition business sites, we host Minecraft, Teamspeak, and other l33t hax0r” targeted services) Gregg Berkholtz On Nov 18, 2014, at 4:58 PM, Mike mike-na...@tiedyenetworks.com wrote: Hello, I provide broadband connectivity to mostly residential users. Over the past few years, instances of DDoS against the network - specfically targeting end users - has been on the rise, and today I can qualify many of these as simple acts of revenge where someone will engage a dos (possibly, services like 'booters' or similar) because they lost an online game or had some interactive in a forum they didn't like. I have good 'consumer broadband' filtering rules in place which make sense and protect against quite a lot of obviously ddos oriented traffic streams. The next step I want to engage, for those types of traffic which I can positively identify as not spoofed, is to send out abuse reports to owners of ip ranges used to launch these attacks. Ideally I'd like to be able to write up some form letter describing the attack, the source ip(s) of note, some disassembled sample packets, and then feed a list of IP source addresses and have it mail it out to the abuse contact at each source network. I am wondering if anyone has a pointer or reference to any tools which might help facillitate this? Thank you. Mike-
Re: It's 7pm. Do you know where *your* domains are? (was Re: Craigslist hacked?)
A half-day with SQLite, memcached and PHP solved this need for us (auto-configures Nagios). Tracking a few hundred domains at this point. Gosh, I really need to cleanup sources, and punt some of these little tools onto GitHub. Gregg Berkholtz On Nov 24, 2014, at 4:52 PM, Mike Hale eyeronic.des...@gmail.com wrote: It's pretty easy to roll out a Nagios box that checks on your domains, NS results and SSL status. On Mon, Nov 24, 2014 at 4:20 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Jay Ashworth wrote: In light of the CL domain hijacking, it seems like a good time to ask if everyone has an inventory system that keeps track of all the details (including renewal dates) for their domain registy and SSL certificate accounts. If you use a tool to keep track of this, which one? Do you have things set up in your monitoring system to watch for changes in this stuff? And a registrar that has an API compatible with the tool! Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
