Right after Cisco SD-WAN devices are onboarded, how are the control and data plane tasks started? In this section, David Penaloza covers how Cisco SD-WAN solution makes the most of its SDN nature: single point of policy application and centralized management platform. The types of policies, the plane on which they act, their application and the actions that can performed are the main focus in this part of the series.
Right after Cisco SD-WAN devices are onboarded, how are the control and data plane tasks started? In this section, David Penaloza covers how Cisco SD-WAN solution makes the most of its SDN nature: single point of policy application and centralized management platform. The types of policies, the plane on which they act, their application and the actions that can performed are the main focus in this part of the series.
In January 1996, I entered for the first time in the configuration of a Cisco 2501 router. This was the beginning of my career as a network engineer. That was just 25 years ago! Here’s a quick look back and a few tips for junior engineers who are at the beginning of their careers. 25 years as a Network Engineer! In 25 years, I had the opportunity to change several times my working environment and specialty as a network engineer: I went from network engineer and peering-manager for regional…
The post 25 years as a Network Engineer! appeared first on AboutNetworks.net.
In late 2020, a major Fortune Global 500 company was targeted by a Ransom DDoS (RDDoS) attack by a group claiming to be the Lazarus Group. Cloudflare quickly onboarded them to the Magic Transit service and protected them against the lingering threat. This extortion attempt was part of wider ransom campaigns that have been unfolding throughout the year, targeting thousands of organizations around the world. Extortionists are threatening organizations with crippling DDoS attacks if they do not pay a ransom.
Throughout 2020, Cloudflare onboarded and protected many organizations with Magic Transit, Cloudflare’s DDoS protection service for critical network infrastructure, the WAF service for HTTP applications, and the Spectrum service for TCP/UDP based applications -- ensuring their business’s availability and continuity.
I spoke with Daniel (a pseudonym) and his team, who work at the Incident Response and Forensics team at the aforementioned company. I wanted to learn about their experience, and share it with our readers so they could learn how to better prepare for such an event. The company has requested to stay anonymous and so some details have been omitted to ensure that. In this blog post, I will refer to them as X.
Initially, Continue reading
This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.
A couple of months ago I had the pleasure to publish my first guest post here and, as to be expected from ipspace.net, it triggered some great discussion.
With this input and some open thoughts from the last post, I want to dive into a few more topics.
One trigger for the initial post was the question whether host-based firewalls (HBFs), potentially combined with solutions to learn rulesets based on flows, are intrinsically better than central firewalls. While we discussed the mileage around that already, comments and questions emphasized how often we have to handle a “software engineering vs. network engineering” mentality – which should not involve any blame in either direction as this mindset is usually enforced by organizational structures.
For whatever it is worth, I can only stress the point that a strong collaboration between software and network engineering will resolve way more issues than any technology. I award myself a “Thanks, Captain Obvious” here, but I still want to make the point to try Continue reading
This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.
A couple of months ago I had the pleasure to publish my first guest post here and, as to be expected from ipspace.net, it triggered some great discussion.
With this input and some open thoughts from the last post, I want to dive into a few more topics.
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.