Archive

Category Archives for "Networking"

IPSEC VPN Site-to-Site — How to and notes for Advanced Networking Certification

< MEDIUM:https://towardsaws.com/ipsec-vpn-site-to-site-how-to-and-notes-for-advanced-networking-certification-35f936b16316 >

https://meteor-honeycup-16b.notion.site/Site-to-Site-VPN-144441a6ac0b4e39a514adc67a8348d5 — This will be updated frequently and has the entire notes on the topics

Lab / Part 1— https://meteor-honeycup-16b.notion.site/Part-1-Building-Customer-VPN-Server-and-a-Client-688eed381f2849dfbe02f5eed740a573

Part 1 — https://youtu.be/h8zFEkVXV24

Lab / Part 2 — https://meteor-honeycup-16b.notion.site/Part-2-Setting-up-VGW-on-AWS-9055cd53a0174f51bd064bb2e3c1f3ac

Part 2 — https://youtu.be/PxJ04myIGJs

Lab / Part 3. — https://meteor-honeycup-16b.notion.site/Part-3-Configuring-Routing-and-verifying-Connectivity-0f2d03eae3474bb897a0f897c927786a

Part 3 — https://youtu.be/mf-Qymz-_Hg

Intro

  • VPN — Virtual Private Network, often used to communicate securely over untrusted networks like the internet.
  • IPSEC is the protocol which is used for securing the data. Some other tunnelling protocols and frameworks are GRE, DMVPN, Wireguard etc
  • Two types of VPNs — Site-to-Site other is Client-to-site /Remote Access VPN, this lab will be a site-to-site VPN.
  • Site-to-Site, as the name suggests usually connects two sites and a Site is typically referred to as a group of devices in a Data-Center. Site-to-Site will enable two sites separated from the internet to communicate privately and securely over the internet.

Site-to-Site

  • Think along the lines of two boundary devices which encrypt and decrypt LAN traffic
  • Design Redundancy and Scalability along these lines for these two end-points
  • It is important to note that you can have VPN to access any services within Continue reading

Cumulus Linux NVUE: an Incomplete Data Model

A few weeks ago I described how Cumulus Linux tried to put lipstick on a pig reduce the Linux data plane configuration pains with Network Command Line Utility. NCLU is a thin shim that takes CLI arguments, translates them into FRR or ifupdown configuration syntax, and updates the configuration files (similar to what Ansible is doing with something_config modules).

Obviously that wasn’t good enough. Cumulus Linux 4.4 introduced NVIDIA User Experience1 – a full-blown configuration engine with its own data model and REST API2.

Cumulus Linux NVUE: an Incomplete Data Model

A few weeks ago I described how Cumulus Linux tried to put lipstick on a pig reduce the Linux data plane configuration pains with Network Command Line Utility. NCLU is a thin shim that takes CLI arguments, translates them into FRR or ifupdown configuration syntax, and updates the configuration files (similar to what Ansible is doing with something_config modules).

Obviously that wasn’t good enough. Cumulus Linux 4.4 introduced NVIDIA User Experience1 – a full-blown configuration engine with its own data model and REST API2.

Troubleshooting VXLAN MTU issues with SR Linux

Giving your network engineers a fighting chance with the industry’s most truly open NOS

VXLAN over UDP adds 50 bytes to every packet

A recent blog reminds us that VXLAN overlay networks can be tricky to troubleshoot, as a typical encapsulation header adds 50 bytes per packet and RFC7348 simply assumes that the network is configured to support such larger payloads. And unlike most other IP packets, typical VTEPs will simply discard frames that are too large — without informing the sender.

Tailored troubleshooting commands in Linux

A common VXLAN underlay network is an IP fabric with IPv4 VTEPs at the leaves, using multiple spines with ECMP for redundancy and capacity. In Netlab such a topology might look like this:

netlab up -d srlinux -p clab vxlan-bridging-leaf-spine.yml
Spine-leaf VXLAN topology with ECMP

To troubleshoot suspected MTU issues in this context — say when a ping from h1 to h2 fails — one would verify the MTU on all paths between the VXLAN VTEPs l1/l2, i.e. l1->s1->l2 and l1->s2->l2. To simplify this task on SR Linux, we can add a custom /tools command for traceroute:

/tools vxlan-traceroute mac-vrf vlan1000
/tools vxlan-traceroute output confirming MTU 1550

As can be seen from the above screenshot, this custom vxlan-traceroute command takes a Continue reading

Why Do We Accept Bad Wireless Clients?

We recorded a fun roundtable discussion last week during Mobility Field Day that talked about the challenges that wireless architects face in their daily lives. It’s about an hour but it’s packed with great discussions about hard things we deal with:

One of the surprises for me is that all the conversations came back to how terrible wireless clients can be. The discussion kept coming back to how hard it is to find quality clients and how we adjust our expectations for the bad ones.

Driven to Madness

Did you know that 70% of Windows crashes are caused by third-party drivers? That’s Microsoft’s own research saying it. That doesn’t mean that Windows is any better or more stable with their OS design compared to Linux or MacOS. However, I’ve fiddled with drivers on Linux and I can tell you how horrible that experience can be1. Windows is quite tolerant of hardware that wouldn’t work anywhere else. As long as the manufacturer provides a driver you’re going to get something that works most of the time.

Apply that logic to a wireless networking card. You can buy just about anything and install it on your system and it will mostly Continue reading

Assembly within! BPF tail calls on x86 and ARM

Assembly within! BPF tail calls on x86 and ARM
Assembly within! BPF tail calls on x86 and ARM

Early on when we learn to program, we get introduced to the concept of recursion. And that it is handy for computing, among other things, sequences defined in terms of recurrences. Such as the famous Fibonnaci numbers - Fn = Fn-1 + Fn-2.

Assembly within! BPF tail calls on x86 and ARM

Later on, perhaps when diving into multithreaded programming, we come to terms with the fact that the stack space for call frames is finite. And that there is an “okay” way and a “cool” way to calculate the Fibonacci numbers using recursion:

// fib_okay.c

#include <stdint.h>

uint64_t fib(uint64_t n)
{
        if (n == 0 || n == 1)
                return 1;

        return fib(n - 1) + fib(n - 2);
}

Listing 1. An okay Fibonacci number generator implementation

// fib_cool.c

#include <stdint.h>

static uint64_t fib_tail(uint64_t n, uint64_t a, uint64_t b)
{
    if (n == 0)
        return a;
    if (n == 1)
        return b;

    return fib_tail(n - 1, b, a + b);
}

uint64_t fib(uint64_t n)
{
    return fib_tail(n, 1, 1);
}

Listing 2. A better version of the same

If we take a look at the machine code the compiler produces, the “cool” variant translates to a nice and tight sequence of instructions:

Continue reading

How SASE might improve worker productivity and make CFOs happy

What justifies network spending?  Two things, according to CIOs.The first is the money to maintain the infrastructure that was justified by projects in the past. The other is money for new projects, and they must deliver benefits large enough to meet the CFO’s target return on investment.The top business justification for any new tech project is productivity improvement. My data says that only about two-thirds of workers in jobs that could be empowered by network improvement have actually been given optimal access to information. In some job classifications, only 40% of workers have been empowered. Mobile workers, ones who regularly operate away from offices, are often empowered only part of the time.To read this article in full, please click here

Worth Reading: VXLAN Drops Large Packets

Ian Nightingale published an interesting story of connectivity problems he had in a VXLAN-based campus network. TL&DR: it’s always the MTU (unless it’s DNS or BGP).

The really fun part: even though large L2 segments might have magical properties (according to vendor fluff), there’s no host-to-network communication in transparent bridging, so there’s absolutely no way that the ingress VTEP could tell the host that the packet is too big. In a layer-3 network you have at least a fighting chance…

For more details, watch the Switching, Routing and Bridging part of How Networks Really Work webinar (most of it available with Free Subscription).

Worth Reading: VXLAN Drops Large Packets

Ian Nightingale published an interesting story of connectivity problems he had in a VXLAN-based campus network. TL&DR: it’s always the MTU (unless it’s DNS or BGP).

The really fun part: even though large L2 segments might have magical properties (according to vendor fluff), there’s no host-to-network communication in transparent bridging, so there’s absolutely no way that the ingress VTEP could tell the host that the packet is too big. In a layer-3 network you have at least a fighting chance…

For more details, watch the Switching, Routing and Bridging part of How Networks Really Work webinar (most of it available with Free Subscription).

Heavy Networking 650: Whether And How To Adopt Whitebox Switches

On today’s Heavy Networking podcast, Kevin Myers joins us for a whitebox conversation. Kevin helps Internet Service Providers build their networks, and has noticed increased adoption of whitebox switches. Why? Are the problems whitebox solves for these ISPs the same you might have at your company? Should you consider whitebox instead of Cisco, Juniper, or Arista? Maybe…and maybe not.

The post Heavy Networking 650: Whether And How To Adopt Whitebox Switches appeared first on Packet Pushers.

Heavy Networking 650: Whether And How To Adopt Whitebox Switches

On today’s Heavy Networking podcast, Kevin Myers joins us for a whitebox conversation. Kevin helps Internet Service Providers build their networks, and has noticed increased adoption of whitebox switches. Why? Are the problems whitebox solves for these ISPs the same you might have at your company? Should you consider whitebox instead of Cisco, Juniper, or Arista? Maybe…and maybe not.

Intel details FPGA roadmap

Seven years after its $16.7 billion acquisition of FPGA maker Altera, Intel is expanding the technology it gained into new areas.While the primary use for an FPGA processor has been for smartNICs that offload tasks from server CPUs, Intel is now looking to broaden its application from the data center to remote, edge computing, and embedded systems.It’s not as if the Altera processors languished over the last several years, however. One major change is manufacturing. When Intel purchased Altera, its chips were made by TSMC. Now they are made by Intel, so hopefully that’s one less supply-chain headache to worry about.To read this article in full, please click here