Network CI/CD Pipeline – GitLab Variables

Network CI/CD Pipeline - GitLab Variables

Hi all, welcome back to our Network CI/CD blog series. In the previous posts, we covered what CI/CD is and why you need it for Network Automation. We also covered GitLab basics and how to set up your first pipeline. In this post, we’ll look into how to keep your credentials secure by hiding them from the repository and using GitLab variables. Let’s get to it!

GitLab Variables

In GitLab CI/CD, variables play an important role in managing dynamic values throughout your pipeline. These variables can store anything from environment-specific settings to sensitive information like credentials. By using variables, you can easily manage and change values without hardcoding them in your scripts or playbooks.

GitLab provides a secure way to store sensitive data such as passwords or API tokens. You can define these variables in your project’s Settings > CI/CD > Variables section, and they will be securely injected into your pipeline during runtime.

Network CI/CD Pipeline - GitLab Variables

If you recall, in our previous examples, we had the username and password hardcoded in the Ansible variables file. This is not secure at all, and you should never expose sensitive information like credentials directly in your repository. By using GitLab variables, you can securely Continue reading

Free Network Configuration Backup with Netpicker

Free Network Configuration Backup with Netpicker

Netpicker is a tool that brings together config backups, security/compliance checks, and automation in one place. Netpicker supports 130+ network vendors, including Cisco, Juniper, Arista, Palo Alto, and Fortinet. It also integrates well with tools like Netbox, Nautobot, and Infrahub for inventory, and Slurp’it for network discovery. You can also reuse your existing Python scripts to run checks or automate tasks across your network.

In this post, we'll go through how to set up Netpicker and configure device backups for free. We'll also look at how Netpicker stores these backups and how you can compare or view the diff to see what has changed over time.

SPONSORED

Please note that this is a paid article. Netpicker has asked me to write and publish this blog post on their behalf, and I’ve charged a fee for it. As of writing this, Netpicker also sponsors my blog.

Learn more

Netpicker Initial Setup

To get started, head over to the Netpicker website and fill out the form with your name and email. You’ll receive an email shortly with the download instructions. Netpicker comes with a free-for-life license that gives you unlimited device backups and basic automation. You’ll also get a ‘Professional’ license Continue reading

A global assessment of third-party connection tampering

Have you ever made a phone call, only to have the call cut as soon as it is answered, with no obvious reason or explanation? This analogy is the starting point for understanding connection tampering on the Internet and its impact. 

We have found that 20 percent of all Internet connections are abruptly closed before any useful data can be exchanged. Essentially, every fifth call is cut before being used. As with a phone call, it can be challenging for one or both parties to know what happened. Was it a faulty connection? Did the person on the other end of the line hang up? Did a third party intervene to stop the call?  

On the Internet, Cloudflare is in a unique position to help figure out when a third party may have played a role. Our global network allows us to identify patterns that suggest that an external party may have intentionally tampered with a connection to prevent content from being accessed. Although they are often hard to decipher, the ways connections are abruptly closed give clues to what might have happened. Sources of tampering generally do not try to hide their actions, which leaves hints of Continue reading

Bringing insights into TCP resets and timeouts to Cloudflare Radar

Cloudflare handles over 60 million HTTP requests per second globally, with approximately 70% received over TCP connections (the remaining are QUIC/UDP). Ideally, every new TCP connection to Cloudflare would carry at least one request that results in a successful data exchange, but that is far from the truth. In reality, we find that, globally, approximately 20% of new TCP connections to Cloudflare’s servers time out or are closed with a TCP “abort” message either before any request can be completed or immediately after an initial request.

This post explores those connections that, for various reasons, appear to our servers to have been halted unexpectedly before any useful data exchange occurs. Our work reveals that while connections are normally ended by clients, they can also be closed due to third-party interference. Today we’re excited to launch a new dashboard and API endpoint on Cloudflare Radar that shows a near real-time view of TCP connections to Cloudflare’s network that terminate within the first 10 ingress packets due to resets or timeouts, which we’ll refer to as anomalous TCP connections in this post. Analyzing this anomalous behavior provides insights into scanning, connection tampering, DoS attacks, connectivity issues, and other behaviors.

Continue reading

MSS, MSS Clamping, PMTUD, and MTU

Maximum Segment Size (MSS) and MSS clamping are concepts that can be confusing. How do they relate to the MTU (Maximum Transmission Unit)? Before we setup a lab to demonstrate these concepts, let’s give some background. Note that this entire post assumes a maximum frame size of 1518 bytes, the original Ethernet definition, and does not cover jumbo frames.

Ethernet frame

Almost all interfaces today are Ethernet. The original 802.3 standard from 1985 defined the minimum size- and maximum size frame as the following:

  • minFrameSize – 64 octets.
  • maxFrameSize – 1518 octets.

With a maximum frame size of 1518 octets (bytes), that leaves 1500 bytes of payload as the Ethernet frame adds 18 bytes, 14 bytes of header and 4 bytes of trailer. The Ethernet frame is shown below:

IP header

An IPv4 IP header adds at least 20 bytes to the frame. The IPv4 header is shown below:

Note that more than 20 bytes can be used if the header has IP options. With no options in the IP header, there’s 1480 bytes remaining for the L4 protocol such as UDP or TCP.

TCP header

TCP also adds a minimum of 20 bytes, meaning that the maximum payload Continue reading

TACC Fires Up “Vista” Bridge To Future “Horizon” Supercomputer

The Texas Advanced Computing Center at the University of Austin is the flagship datacenter for supercomputing for the US National Science Foundation, and so what TACC does – and doesn’t do – is a kind of bellwether for academic supercomputing. …

TACC Fires Up “Vista” Bridge To Future “Horizon” Supercomputer was written by Timothy Prickett Morgan at The Next Platform.

D2DO250: The Realities of Responsible Disclosure in the Cloud

Cloud security and responsible disclosure are the focus of today’s conversation with guest Kat Traxler. Kat shares her insights on identifying vulnerabilities in cloud services, particularly Google Cloud, and the importance of curiosity in her research. The episode explores the role of bug bounty programs and the shift towards issuing CVEs for cloud vulnerabilities. Lastly,... Read more »

Routing Table and BGP RIB on SR Linux

Ages ago, I described how “traditional” network operating systems used the BGP Routing Information Base (BGP RIB), the system routing table (RIB), and the forwarding table (FIB). Here’s the TL&DR:

  1. Routes received from BGP neighbors are stored in BGP RIB.
  2. Routes redistributed into BGP from other protocols are (re)created in the BGP RIB.
  3. BGP selects the best routes in BGP RIB using its convoluted set of rules.
  4. Best routes from the BGP RIB are advertised to BGP neighbors
  5. Best routes from the BGP RIB compete (based on their administrative distance) against routes from other routing protocols to enter the IP routing table (system RIB)
  6. Routes from the system RIB are copied into FIB after their next hops are fully evaluated (a process that might involve multiple recursive lookups).
Read more …

HW035: The Experience Paradox

In this episode of Heavy Wireless, host Keith Parsons and guest Tom Hollingsworth delve into the “experience paradox” in the tech industry: to get experience, you need to have experience. They highlight the disconnect between job requirements and candidates’ actual experience. Tom emphasizes the importance of hands-on learning, home labs, and making mistakes as essential... Read more »

Tech Bytes: Smarter Networking and Automation With SuzieQ’s Network Observability (Sponsored)

Today on the Tech Bytes podcast: network observability. SuzieQ is an open-source project that collects, normalizes, stores, and analyzes multi-vendor network data. This data becomes a foundation for network observability and automation. We talk with Dinesh Dutt, creator of SuzieQ and founder of Stardust Systems, which makes a commercial version of SuzieQ. Stardust Systems is... Read more »

PP029: Translating Security Objectives into Business Outcomes

On today’s Packet Protector we talk about how to talk about security objectives in ways that resonate with business and non-technical leaders in your organization. Tying security objectives to business outcomes can help you maintain (or increase) budgets, build trust and credibility with executives, and better align your risk management efforts with the organization’s broader... Read more »
1 … 109 110 111 112 113 … 3,839