trout

That feature requires you to use a private IP address, so if you have a VPN or Direct Connect to another location you could load balance across locations. In the case of the global load balancers those will be public addresses though.

"The IP addresses that you register must be from the subnets of the VPC for the target group, the RFC 1918 range (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and the RFC 6598 range (100.64.0.0/10). You cannot register publicly routable IP addresses."

[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/netw...

Mistake seems like a harsh word here. There are lots of partners that aren't in the competency tier that do perfectly fine work. But we try to highlight the ones we can somehow quantify as 'top tier', which is competency. It's imperfect just like any other subjective rating.

AWS definitely cares about any bad experiences. It's the way we improve things for customers, so let us (or me, or anyone at AWS) know the details.

AWS keeps a list of vetted partners (business requirements, public references, case studies, good AWS relationship, etc) on the competency page.

You can see the different sorts of competencies here, in case your solution has a specific vertical or technology focus: https://aws.amazon.com/partners/competencies/

You would want to focus on the consulting partners for this type of engagement.

If you're not sure, it sounds like it's more of a migration use case and you can get a short list of folks here: https://aws.amazon.com/migration/partner-solutions/

If you know your AWS account team, they'd like to get that feedback. Otherwise my contact information is in my profile and you can email me and I can try to connect you to some AWS folks responsible for the partner as well.

This link is basically what Socketplane was working on when they got acquired: https://github.com/docker/docker/issues/8951

Basically integrating OVS APIs into Docker so it could use more mature networking code as well as VXLAN forwarding. VXLAN is basically IP encapsulation (a 16-bit ID) that the networking industry has standardized on. It more or less allows for L2 over L3 links. I like to think of it as the next Spanning Tree.

So the unwieldy part is the weight OVS brings as well as the VXLAN encapsulation in software - both of which have momentum towards being more lightweight.

I've been on break/fix and on the Sales Engineer side and know both - there's never a single side to these things.

Sales Engineers in particular don't want to sell something dishonestly - it opens the company up to risk and it hurts their credibility, particularly if you sell multiple products.

There are a few reasons I can think of:

1. The technical people that run the current implementation didn't put their requirements into the sales process.

2. Some of those features really don't matter to the business and were fodder.

3. The requirements were listed, but not accurately or with enough depth.

4. The Sales team didn't have enough knowledge (or training) to know the difference - or inaccurate documentation.

5. It was roadmapped close enough to implementation and including delays to go ahead anyway.

6. The competitor claims to have this feature but theirs is broken also, so it's a race to who can sell broken stuff faster - because nobody can truly do it.

The people and the companies that support this exist certainly - just not for very long.

Skype pulls in a lot of revenue in the OCS/Lync product set. Companies want still largely want to be able to IM MSN, Yahoo, Skype, and AOL users and they're the only ones that have access to all those user groups. They also leverage B2C video/calls to Skype users.

Not a flame - your perspective is very typical for people that don't have a lot of experience with networking past the host or server level. (Very little experience with networking in the core, provider, or putting together network services architecture).

1. In theory the routing table with IPv6 can be smaller. The address design should be hierarchical, which means you should be able to have much fewer routes. It's too early to tell if this is actually true or not, but the addresses themselves are 4x larger - which isn't going to be the determining factor in routing table size.

2. Not everything needs to be publically routable, true. IPv6 has the idea of link local and autonomous system local addressing which IPv4 doesn't have. The RFC 1918 block was used instead. But think for a second - there's only 4 billion addresses (less when you count bogons and multicast ranges), and it's only a matter of time until those are taken up. So we can choose to do it now, 2 years from now, or 5 years from now, but devices are growing faster than ever and it's only a function of time.

3. NAT is not a security feature, is not good for the internet, and the sunk costs spent building an ALG for every protocol to work around it is a significant development sinkhole. It's a workaround often masqueraded as security, and does cause many application problems. It's just not normally the application developers that have to fix those problems - it's the network and security teams.

4. IPv6 was created in the late 90's. People have been waiting for brilliance to supercede IPv6 for a while. I'll admit it's not the easiest, but there are a certain set of problems you have when you expand the address space.

5. I'm familiar with all the IPv4 headers, and nearly all of them are used. ID is used for packet identification, particularly through network services, DSCP is used heavily, DF and other flags are used - they're just obscure. If you look at IPv6 those same headers are basically recreated, though with slightly different names. The ones that aren't included are addressable through the extension headers.

So, yeah. That's another perspective that may help you understand why IPv6 is a bit of a quagmire. The faster people understand this, the sooner we get to a place where the chicken-egg problem fades away.

Here's a report you can see the current projects with a bit of history: http://www.potaroo.net/tools/ipv4/index.html

The potaroo site by Geoff Huston has been running for over a decade tracking address consumption.

Some history for ARIN consumption predictions: Feb 2014 predicts Mar 2015.

Oct 2013 predicts Jan 2015 [0].

Apr 2013 predicts Apr 2014 [1].

Nov 2012 predicts Sept 2013 [2].

Sep 2012 - RIPE out of addresses.

Apr 2011 - APNIC out of addresses.

Feb 2011 - IANA out of addresses.

Dec 2011 predicts July 2013 [3].

July 2011 predicts Nov 2013 [4].

Prior to this it's simply about IANA calculations, though with some algebra some dates could be extracted.

As well, here's a Cisco article from 2005 describing some of the painful parts of trying to predict the address consumption (where they guess 2016 in 2005): http://www.cisco.com/web/about/ac123/ac147/archived_issues/i...

[0] http://web.archive.org/web/20111227105916/http://www.potaroo... [1] http://web.archive.org/web/20111227105916/http://www.potaroo... [2] http://web.archive.org/web/20121122120407/http://www.potaroo... [3] http://web.archive.org/web/20111227105916/http://www.potaroo... [4] http://web.archive.org/web/20110709090704/http://www.potaroo...

If HN was on AWS, where would we go to discuss AWS outages?

It looks like the explain xkcd community finally cracked the codes: http://www.explainxkcd.com/wiki/index.php?title=1286:_Encryp...

Check out the discussion - it took a while to find a solution to the last 3.

Interesting, I'm at 1084 days so I missed a chance at a round-number-blog-post.

I would echo many of the same things. I graduated with a computer science degree (and computer systems engineering) but up until about a year ago I had not written a single program. I've started kicking around with Python again, have signed up for Coursera courses that involve Github, AWS, and programming. As well, it's helping me professionally because I'm gradually moving away from VoIP technologies into datacenter networking where Dev Ops, AWS, IaaS, and the latest programming trends are important. I got an Arduino and started hacking around with it as well.

Even though I'm not at a startup, I try to treat my job with the same type of entrepreneurial spirit as those touted in the Silicon Valley Startup Echo Chamber posts. I try to keep in mind many of the core entrepreneurial concepts - fail fast, iterate, A/B test, get feedback, focus on value, user experience is paramount, etc in mind with my comparatively tame 'cushy' corporate job.

So as much as anything else, thanks HN.

For reference, this is an output of the Stanford startup engineering course (which I also signed up for after it hit the HN front page)

In the homework, this is what they mention the goal of the 'bitstarter' page to be: "Choose a project which you can get to a crowdfunder

People in the class have widely varying backgrounds, ranging from relative neophytes to fairly advanced students. Your goal is to figure out a final project that you can get to the level of a reasonable crowdfunding site. This can mean anything from verbal description and mockups to fully working code, or anything in between: whatever is necessary to make the sale and prove that you have a market. Note that you have control over who's seeing the crowdfunder (e.g. the people in your email list or social circle), so you are also determining the difficulty of the sale itself by choosing the market and the initial crowdfunding audience. Note also that you can just ask for someone to share your content on social media rather than pay you real money for a preorder. Open source projects are ok as well, not just for-profit businesses. The main guideline is to set your success bar at the point that it'll be an achievable challenge for you. That might be a target of $100 or it might be $100,000."

You can see the other projects here: http://startupmooc.org/

It applies if you want to switch schools. We used to call it "failing in".

I'm just hoping I'll be able to drink in a driverless car before I can use electronics in an airplane. If the same safety-at-all-costs model applies to driving these cars, they won't be nearly as fun as we dream.

How many of these P2P overlay networks could run without a centralized head/mapping server? BitTorrent has drastically reduced the size of theirs, but it still needs a mapping of other hosts somewhere. Same thing for Skype. I don't want to sign up for an internet where every connection needs a 'head' in order to determine how to traverse the overlay network.

It's probably also not a coincidence that Skype and Bittorrent are two of the hardest protocols to 'control' inside the network. This sounds good from a 'the internet should be a free democracy' standpoint but bad from a 'let's guarantee the performance of the application' standpoint. In terms of visibility into what is happening, being transferred, and where connections terminate there are more productive rather than draconian reasons for understanding those things.

Today with virtual hosting if the website next to you decides to host illegal content, the entire IP is taken down collateral damages or not. Well, that's part of your choice in choosing a provider as an end host. If the entire next generation internet and application space is based on overlays and other nebulous architectures, much of those same problems are going to exist to larger scales, including at transit points. Except it won't be as optional as changing hosting providers.

Since you've got BGP experience - think about the fun in troubleshooting eBGP neighbor problems when every connection is a GRE tunnel that may actually be tunneling through another BGP AS, which itself may be tunneled again. GRE tunnels are great immediate bandaids and generally awful long term solutions for enterprise networks to say the least. But the application guy gets his green light and thinks everything is great.

When I played Everquest I did a very similar thing, except without the ship component. We found an obscure item that was not in any of the well-known databases, which is fairly difficult considering how far reaching they were.

Then we advertised a 'want to sell' considerably lower than the 'want to buy' we advertised in a different zone, both very high prices. Someone decided to make a quick arbitrage sell and found out I didn't want that item at all.

I'm sure some have learned the risks of arbitrage the hard way through these games, among other things.

This is true - RADIUS and TACACS are the most secure way to access routers. I've found that nearly all routers in nearly all environments still have a local authentication. If you were to remove all network connections (or just the right one) you no longer have access to the authentication server and you would be totally locked out of the box since it doesn't cache any of the authentication. The running configuration of the router IS what you have to secure, and it needs to be stored under lock and key (SFTP, authenticated file share, etc). If you're sending it to non-shared parties you should remove the authentication from the configuration either manually or with 'show run brief'.

The worst part about this is that there is no default password. It's marginally worse than doing nothing - people just voluntarily use cisco/cisco because they don't care about security.

* technically on some of the newer routers and versions cisco/cisco is a default, but after the first login it's no longer valid.

It's not a 'switch' but rather failed implementation.

As well, this is only protecting people that would have otherwise put their saved passwords into insecure locations - like posting to the internet or insecure internal file shares.

For public posting the command 'show run brief' will take out all certificate and password information, at least for IOS-XE. NX-OS, IOS, and security IOS have options as well, use 'show run ?' to confirm.

He's at least 10 years late on multicast networks. Here's the 1985 RFC that's considerably more detailed than his from 1996: http://tools.ietf.org/html/rfc966

Visualizing this conversation..

IT Director to Sales Guy: "We just got $20M in grant money for getting broadband across the state. Can you get me some numbers?"

Sales guy to engineering team (partner or internal): "Hey I need lots of boxes. They've got 1300 sites."

Engineering team: "Ok.. what do they need?"

IT Director: "Pretty sure my network guy says everything has to have redundant power supplies and at least 1 ethernet connection. To do a survey for each site would take over a year due to bureaucracy, and I've got 3 months on this grant"

Engineer to Sales guy: "Ok I built out those routers. Do they really need redundant power supplies everywhere? 3900's seem big."

Sales guy: "Ya, that's what they said. Anyways this came out below budget. Thanks!"

IT Director: "Looks to be under budget, meets our needs, thanks!"

.. meanwhile IT management/engineers aren't involved. Somewhere, someone didn't slow this project down to do due diligence. That or somewhere buried in some document is a requirement for redundant power supplies, but that sounds less likely the case.

I tend to vote against this type of security by opting out of the scanners. If even one quarter of the passengers opted out they would need to reexamine their security - one that would likely not include the expensive scanners or intrusive pat down tests. I just get to the airport 10 minutes earlier. They do seem to intentionally penalize you with delay, and often question why you're opting out.

For the curious, this is a small scale map of what they'll be viewing: http://www.cisco.com/en/US/prod/collateral/wireless/ps5755/p...

I would be really curious to what the wireless spectrum looks like at an event like that. Most football fans won't bring more than a phone, but with 80,000 people there will be some outliers. Maybe someone decides to bring a walkie talkie set that works over the 2.4 Ghz band, lots of people with bluetooth headsets, or other odd bluetooth devices. Wireless cameras can ruin Wifi on the same bands.

Monitoring 'rogue' devices is actually a requirement of all parts of a business that handle credit card transactions (PCI). It's to prevent card card data from leaking out of a planted wireless device (small device plugged into bag of a register/pc, etc). That's one of the main drivers for this technology existing beyond anything else.

Depending on the game (it's been 10 years for me) one 'hack' was to head in one direction, pull the network connection for 3-4 seconds, head in the opposite direction, and plug back in. This allowed you to escape or hide in the terrain fairly reliably.

With higher bandwidths and server capacities I'm guessing these timeouts have been reduced, but never underestimate the player's ability to abuse your trade-offs.

You're really fighting two mantras - 'if it's not broken, don't fix it' vs 'we must build against worst case everything'. The arguments generally come from IT support and legal, respectively.

Realistically things are in the middle. This isn't a surprise. IT shops have to balance current real risks, potential risks, future risks, etc. It's the overly used 'black swan' event in IT that causes problems. It costs $200k per potential problem, and we've got 40, but the business only provides $1M in budget. So the black swan will happen, the business will demand a solution, so now you've got 41 problems - because 2 surfaced while fixing the 1.

To take a step back, it's simply because consumer IT has innovated quicker than both enterprise IT and enterprise security to prevent the takeover. Trying to understand that is a more interesting question, which probably finds its roots in the blossoming technology adoption of a younger generation more willing to consume high tech goods. Eventually enterprises adopt consumer technology, or build really good walls.

Haven't tested, but this says the opposite: http://techcrunch.com/2010/02/10/facebook-chat-launches-xmpp...

There are some other ways to fix the problem.

Last time with the Youtube problem, they advertised more specific routes. If Pakistan was advertising a /24 network (255 IP addresses) Youtube started advertising two /25 networks (2x 128 addresses). Since they are more specific, they are preferred over the more broad routes. This prevents lack of cooperation, but not malicious behavior. As well, it ends somewhere because many networks will not pass routes smaller than say /24 or /28.

Most service providers also do 'inbound route filtering' to filter out any routes that they do not own. This isn't a simple process, which is why PCCW does not do it. Maybe a few more of these incidents and they will.

There's also AS Path filtering. This allows networks to be more granular in which paths they trust, by inspecting which AS's a route has gone through. If certain AS or AS path combinations become problematic, the internet at large could blackhole them or do manual route filtering. This would be laborious, but possible.

That said if someone can maliciously peer with an active BGP router, the damage to be done is significant. I haven't seen any outage reports from this type of attack, but I'm surprised by that.

I don't like how the pitch and the implementation instructions diverge. The pitch uses technology that read 'pop our Considerable Use policy when they connect', 'firewall users so they can't see each other', 'use a separate network so yours doesn't get slower'.

There's an assumption that if you name your SSID openwireless.org that it somehow ties them to the Considerable Use guidelines. Which means that people searching for free wifi will find the SSID, after they connect will go to the website, and then find the little yellow bar and click on it, scroll down, and read a decent sized paragraph that politely asks them not to stream HD movies.

Yet on the page there is only 1 with a setting for QoS (which won't prevent the types of problems you want it to), and one with 'firewalling users' (which doesn't shield users from each other, only prevents them from routing into your subnets). Not to say that it's their fault - most routers don't have the features available to actually segment and properly prioritize different sets of users.

I read the FAQ and thought they figured out how to solve these difficult problems on simple platforms, only to be disappointed with the tutorials that simply opened networks up.

disclaimer: I work for Cisco.

I think there are some legitimate concerns. The other competitors aren't known to have the level of corporate espionage as Huawei has shown, the level of direct government influence, and telecom is gaining importance in national security.

Manufacturing equipment in China and producing Telecom equipment and software are different concepts for security. For example, all telecom equipment in the US has to allow "lawful intercept"[1], and part of LI is it cannot be detected whether it is enabled or not. I think if an issue was to escalate to the level of national security, both the US and China would be willing to make use of these features. I'm more willing to believe that China would build in their own form of LI without publicizing it, since the government is more directly involved in the decisions of ZTE/Huawei. If the next front of war is on the internet, this is a considerable risk.

From what I understand - the Chinese government has the ability to say "If you don't drop the suit against [Chinese Company] we will block your product sales in China". I can't find a source, but I remember hearing a similar incident.

This idea is also not new - India is on a similar path to locally source telecom equipment: http://articles.economictimes.indiatimes.com/2012-08-15/news...

1. http://en.wikipedia.org/wiki/Lawful_interception

I've got a thunderbolt on Verizon and I do 3G and voice as well as 4G and voice at the same time. Some googling seems to show that it uses two antennae to do this, but to me as an end user it works great.