Everyone in networking—and beyond networking, in fact—thinks about what the future of work might look like. Jacquelyn Adams joins Eyvonne Sharp, Tom Ammon, and Russ White on this episode of the Hedge to discuss what work might look like based on this era of rapid change, and how you can prepare for that future.
On Christmas Day 2020, an apparent suicide bomb exploded in Nashville, TN. The explosion happened outside an AT&T network building on Second Avenue in Nashville at 1230 UTC. Damage to the AT&T building and its power supply and generators quickly caused an outage for telephone and Internet service for local people. These outages continued for two days.
Looking at traffic flow data for AT&T in the Nashville area to Cloudflare we can see that services continued operating (on battery power according to reports) for over five hours after the explosion, but at 1748 UTC we saw a dramatic drop in traffic. 1748 UTC is close to noon in Nashville when reports indicate that people lost phone and Internet service.
We saw traffic from Nashville via AT&T start to recover over a 45 minute period on December 27 at 1822 UTC making the total outage 2 days and 34 minutes.
Traffic flows continue to be normal and no further disruption has been seen.
TL&DR: If you run multiple IGP protocols in your network, and add BGP on top of that, you might get the results you deserve. Even better, the results are platform-dependent.
One of my readers sent me a link to an interesting scenario described by Jeremy Filliben that results in totally unexpected behavior when using too many routing protocols in your network (no surprise there).
Imagine a network in which two edge routers advertise the same (external) BGP prefix. All other things being equal, it would make sense that other routers in the same autonomous system should use the better path out of the autonomous system. Welcome to the final tie-breaker in BGP route selection process: IGP metric.
TL&DR: If you run multiple IGP protocols in your network, and add BGP on top of that, you might get the results you deserve. Even better, the results are platform-dependent.
One of my readers sent me a link to an interesting scenario described by Jeremy Filliben that results in totally unexpected behavior when using too many routing protocols in your network (no surprise there).
Imagine a network in which two edge routers advertise the same (external) BGP prefix. All other things being equal, it would make sense that other routers in the same autonomous system should use the better path out of the autonomous system. Welcome to the final tie-breaker in BGP route selection process: IGP metric.
George Sadowsky was a pioneer in recognizing the importance of networking technology for economic development, particularly in developing economies. He has worked in over 50 countries to bring training and networking infrastructure to the local population. In this episode of the History of Networking, George recounts some of the early, pre-Internet, work in computer networking, and the development of many of the organizations that make the Internet work today. His web site can be found here.
Hello my friend,
Continuing our discussion about the network troubleshooting tools we can’t pass by one of the most popular and widely used, which is named SpeedTest.
1
2
3
4
5 No part of this blogpost could be reproduced, stored in a
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.
Doing the collection and initial analysis of the information during the troubleshooting could be quite a time-consuming task. On the other hand, the troubleshooting of the live outages should be as quick as possible to minimise the downtime of the affected services. That’s where the automation can help you.
In our network automation training we explain how to use existing open-source tools and create your own with Ansible, Bash and Python. Leveraging them and all possible interfaces (CLI, NETCONF, RESTCONF, gNMI) we teach you how to effectively build, operate and troubleshoot your network.
From the name of the tool, SpeedTest, it is obvious that the main goal is to measure the “speed”. In fact, it measures Continue reading
The Public Interest Registry (PIR) is the non-profit operator of the .ORG, .NGO and .ONG domains. PIR has been a champion for a free and open Internet for more than 15 years with a clear mission to be an exemplary domain name registry, provide a trusted digital identity and help educate those who dedicate themselves to improving our world.
If you or someone you know has the interest and qualifications to help guide the future of PIR, the Internet Society invites you to submit a nomination for a seat on the PIR Board of Directors.
Prior board or senior executive experience is preferred. All directors must have an appreciation for PIR’s Mission and the potential impact of PIR decisions on the customers of PIR and the global community served by .ORG and the other TLDs PIR operates. Directors must be able to read and understand a balance sheet, as well as read and communicate effectively in the English language.
In 2021 there are four positions opening on the PIR Board. The appointed directors will serve staggered terms, with half appointed to two year terms and half to three year terms, with terms beginning mid-year in 2021.
More information about the position, the qualifications, and a link to the Continue reading
In today’s episode we’re talking about IPv6. More specifically, we discuss what it takes to run an IPv6 only network. Why now? And why not dual stack? Well, in the middle of November (2019), the US government put out a memo outlining their updated guidelines and expectations for IPv6. In it, they mandate a future vision of 80% of devices connected to IPv6 only networks by 2025. That’s not that far away. So, as many of our peers who work in US federal organizations are preparing for a world that is IPv6 only, we figured it might be time for us to do the same.
Long story short: ipSpace.net is going on an extended coffee break on June 24th 2021. You can stop reading; the rest of the blog post is full of details you probably don’t care about.
What exactly does that mean? Honestly, we don’t know yet… but we felt that it’s only fair to let engineers considering our subscriptions know months in advance what might happen.
Also, after investing two lifetimes into this project, and a few planned changes coming just before our regular summer hiatus (see below) it’s time for a longer break. ipSpace.net might be back to business-as-usual after a few months (unlikely), or it could be Ivan working on some interesting stuff (most likely) or ipSpace.net slowly disappearing into the sunset (not impossible).
Long story short: ipSpace.net is going on an extended coffee break on June 24th 2021 reducing the scope of activities on July 1st 2021. You can stop reading; the rest of the blog post is full of details you probably don’t care about.
What exactly does that mean? Since this blog post was published in January 2021, we pretty much figured out a way forward, and I’m glad we let engineers considering our subscriptions know months in advance what might happen.
Anyway, after investing two lifetimes into this project, and a few planned changes coming just before our regular summer hiatus (see below) it’s time for a longer break an adjustment. ipSpace.net will revert back to Ivan working on some interesting stuff.
The OSI model is perhaps the best-known—and perhaps the most-loved—model in the networking world. It’s taught in every basic networking course, and just about every blog (other than this one) has some article explaining the model someplace or another (for instance, here is one of the better examples).
The reality is, however, that I’ve been in the networking business for 30’ish years and I’ve never once used the OSI model for anything practical. I’ve used the model when writing books because just about every book on networking has to have a section on the OSI model. I’ve used the model when writing a paper comparing two different protocols, back in the multiprotocol days (VIP versus IPX versus IP), but we don’t have those kinds of arguments very often any longer.
So, we all learn the OSI model, and yet I don’t know of anyone who actually uses the OSI model in understanding how protocols work, or how to troubleshoot a network. There’s the “it’s a layer two problem” statement, and that’s about the end its useful life, it seems.
Let me make a suggestion—learn, use, and teach the RINA model instead. Okay, so what is the RINA model? It is Continue reading