Network Break 31
Over-opinionated analysis on data network and IT Infrastructure. And virtual doughnuts.
Author information
The post Network Break 31 appeared first on Packet Pushers Podcast and was written by Greg Ferro.
Topology Challenge Winners
Firstly on behalf of the entire GNS3 team - WOW! We are always so impressed with how far people are pushing the software but thisProduction Designs Are Compromise – And That’s Okay
During a bout of stress & jet lag induced insomnia, I logged onto Twitter in the wee hours to see what folks were saying. I found a number of twitpisses in my timeline. Twitpisses are arguments in which people assert that Someone On The Internet Is Wrong in 140 characters or less. After […]A Quick Update on OpenStack Congress
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:
- A 500x improvement in query performance
- A 20,000x increase in data import speed
- A 6x reduction in memory overhead
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
Routing Leak briefly takes down Google
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
What the *, traceroute?
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
Scaling Congress
(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
Networking Basics – Test 1
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.
When SSL Certificates Go Wild
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.
PKI Trust Review
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
What caused the Google service interruption?
This morning people on twitter reported that they were unable to reach Google services. Businessinsider followed up with a story in which they mentioned that the Google service interruption primarily involved European and Indian users.
In this blog we’ll take a quick look at what exactly happened by looking at our BGP data. The first clue comes from David Roy and Franck Klopfenstein on twitter who noticed traffic was re-routed towards AS9498 in India. Digging through our BGP data we are able to indeed confirm that routing paths for many google prefixes changed to a path that includes the Indian AS 9498 between 08:58 UTC and 09:14 UTC.
Let’s take a look at an example. In my case www.google.com resolves to the following addresses:
www.google.com has address 74.125.226.19
www.google.com has address 74.125.226.20
www.google.com has address 74.125.226.17
www.google.com has address 74.125.226.16
www.google.com has address 74.125.226.18
www.google.com has IPv6 address 2607:f8b0:4006:806::1014
The IPv4 addresses are all in the 74.125.226.0/24 range. If we now look at the BGP announcements for that Continue reading