Customers who pay for WiFi expect it to work. Marriott wanted to make that guarantee. But wireless spectrum is shared, uncontrolled, unregulated and unpredictable. You can't give a viable guarantee. Then you add lawyers ......
The post Analysis: Marriot Court Case Highlights the Problems of WiFi Services appeared first on EtherealMind.
Sometimes, it’s not what you know, it’s who you know. Today we launch a new method of support to the Cumulus Networks family, a community question and answer site. This is a place where you can ask either a simple question for which you couldn’t find an answer, or maybe something you’ve always wanted to know. It’s also a place to engage in conversation with other users that may be experiencing things you have seen in the past or may encounter in the future.
To be sure, Cumulus Networks employees will be on hand to assist and direct you to the documentation and knowledge base as appropriate. If a question is too complex, we will assess your needs based upon your support entitlements and work with you to open a ticket so our excellent support team can assist you in figuring out your issue. The community portal is a supplement to the support team, not a replacement.
Our growth is directly related to you, our community, and in that vein, we want to offer more ways that you can be involved — this is just the beginning. Look for more to come in upcoming blog posts.
The post Cumulus Networks Continue reading
Dear BGPmon.net user,
I’m excited to announce that BGPmon has been acquired by OpenDNS. OpenDNS is a leading cloud-delivered network security company known for engineering predictive intelligence technology that stops malicious activity before it can threaten a network.
Over the last few years BGPmon has grown from a community service into a successful business that helps thousands of network engineers from around the world monitor their networks. Throughout this journey, we’ve developed close relationships with many of you and together, worked on some truly fascinating cases.
Becoming a part of OpenDNS is a logical next step for BGPmon. With its engineering resources, massive scale and cloud delivery model, OpenDNS is the right direction to continue growing the BGPmon service. I’m confident that moving forward BGPmon will only get better.
The transition plan is straightforward. OpenDNS will invest in building out the service even more but also is committed to keeping the free features free. Simply put, nothing regarding the service will change other than we’ll continue adding new functionality.
On a personal note, I’d like to thank all of you for your continued support and encouragement. I am excited for the changes ahead and personally being a part of Continue reading
Over-opinionated analysis on data network and IT Infrastructure. And virtual doughnuts.
The post Network Break 31 appeared first on Packet Pushers Podcast and was written by Greg Ferro.
OpenStack Congress, a project aimed at providing “policy as a service” for OpenStack clouds, is a project I’ve had the privilege of being involved in from very early days. I first mentioned Congress almost a year ago, and since then the developers have been hard at work on the project. Recently, one of the lead developers posted a summary of some pretty impressive performance improvements that have been made with Congress.
I won’t repeat all the sordid details here; for all the details, I encourage you to go read the full post over at ruleyourcloud.com. Just to give you a quick highlight of some of the performance gains they’ve been able to realize, consider these numbers:
Given the nature of Congress—that it must, by its very definition, import data from multiple cloud services and perform queries across that data to determine policy violations—the performance improvements seen in query performance and data import speeds are quite significant.
For the detailed explanation of how the developers were able to see such incredible performance improvements, see the full post. If you’re interested in Continue reading
This morning, users of Google around the world were unable to access many of the company’s services due to a routing leak in India. Beginning at 08:58 UTC Indian broadband provider Hathway (AS17488) incorrectly announced over 300 Google prefixes to its Indian transit provider Bharti Airtel (AS9498).
Bharti in turn announced these routes to the rest of the world, and a number of ISPs accepted these routes including US carriers Cogent (AS174), Level 3 (AS3549) as well as overseas incumbent carriers Orange (France Telecom, AS5511), Singapore Telecom (Singtel, AS7473) and Pakistan Telecom (PTCL, AS17557). Like many providers around the world, Hathway peers with Google so that their customers have more direct connectivity with Google services. But when that private relationship enters the public Internet the result can be accidental global traffic redirection.
Last fall, I wrote two blog posts here and here about the issues surrounding routing leaks such this one. Routing leaks happen regularly and can have the effect of misdirecting global traffic. Last month, I gave a talk in the NANOG 63 Peering Forum entitled “Hidden Risks of Peering” that went over some examples of routing leaks like this one.
Below is a graph showing the Continue reading
If you’ve ever done a traceroute from one IOS box to another, you’ve undoubtedly seen output like this:
R8# traceroute 192.168.100.7
Tracing the route to 192.168.100.7
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.0.1 4 msec 3 msec 4 msec
2 192.168.100.7 4 msec * 0 msecThat “msec * msec” output. Why is the middle packet always lost?? And why only on the last hop??
This was always something curious to me but not something I ever bothered to learn about. Well it turns out that IOS has a rate limiter that meters the generation of ICMP Unreachable messages. The default setting for the rate limiter is 1 ICMP Unreach every 500ms. Since IOS’s traceroute doesn’t put a delay between its probe packets, the delay between when 192.168.100.7 receives the first and second probe packets is much less than 500ms. The second packet violates the rate limiter and so 192.168.100.7 drops it.
Why isn’t the third packet also dropped? Because the traceroute command waits for 3 seconds (by default) before deciding that a probe packet was lost and Continue reading
(This post was written by Tim Hinrichs, Shawn Hargan, and Alex Yip.)
Policy is a topic that we’ve touched on before here at Network Heresy. In fact, policy was the focus of a series of blog posts: first describing the policy problem and why policy is so important, then describing the range of potential solutions, followed by a comparison of policy efforts within OpenStack, and finally culminating in a detailed description of Congress: a project aimed at providing “policy as a service” to OpenStack clouds. (Check out the OpenStack wiki page on Congress for more details on the Congress project itself.)
Like other OpenStack projects, Congress is moving very quickly. Recently, one of the lead developers of Congress summarized some of the performance improvements that have been realized in recent builds of Congress. These performance improvements include things like much faster query performance, massive reductions in data import speeds, and significant reductions in memory overhead.
If you’re interested in the full details on the performance improvements that the Congress team is seeing, go read the full post on scaling the performance of Congress over at ruleyourcloud.com. (You can also subscribe to the RSS feed Continue reading
There are 10 basic questions below. Most of them relatively basic networking questions. This test can be taken only one time, so take your time, provide your Name and Email so you can be in Leaderboard. If you like this networking basics test,please leave a comment, so I continue to prepare similar tests. After solving this test… Read More »
The post Networking Basics – Test 1 appeared first on Network Design and Architecture.
You’ve set up your website and secured it with an SSL certificate that you bought through your ISP. Everything works fine and the chain of trust is just fine in your browser, but when you try accessing your secured site using a command line tool, the connection fails. Why? There’s a good chance that you are not sending your intermediate certificate(s) along with the server certificate.
As a quick reminder, the whole point of SSL certificates and the Public Key Infrastructure is to prove that the site you connected to is the one it says it is. How do we know? The server sends you a certificate with its name in it, digitally signed by an Issuer. If you choose to trust that Issuer’s honesty and believe that they made sure they issued to the right site, you implicitly trust that the end site is the right one; it’s a “Chain of Trust.”
In reality, we don’t typically trust many Issuers. Look in the Trusted Root certificates for your browser, or on a Mac, open Keychain Access and look in System Roots, and you’ll see that for Yosemite in this case, globally – to establish SSL Continue reading