A practical learning path for operating BGP safely before requesting public Internet number resources or a FreeTransit tunnel.
A public ASN, an IP prefix and a BGP session are production Internet resources. They are not a first BGP laboratory. A mistake can make your own network unreachable, leak routes learned from one provider to another, or announce address space that does not belong to you.
FreeTransit helps community networks obtain and use Internet number resources. We also expect applicants to understand the basic operational responsibility that comes with those resources. You do not need to be an expert, but you should be able to build, filter, verify and monitor a simple BGP setup before it is connected to a public network.
Free non-commercial IP transit by tunnel or IXP, plus RIPE sponsorship for people who need an ASN or independent resources first.

Alles zum ASN-Registrierungsprozess bei der RIPE NCC: LIR-Sponsoring, Multihoming-Anforderung, Dokumentation und was nach der Zuteilung zu tun ist.
Wenn Sie eigene IP-Prefixe per BGP ankündigen, an einem Internet Exchange peeren oder ein multihomed Netzwerk betreiben möchten, benötigen Sie eine Autonomous System Number. Diese Anleitung führt Sie durch den ASN-Registrierungsprozess bei der RIPE NCC: Voraussetzungen, das LIR-Sponsoring-Modell, Kosten, Dokumentation, Zeitrahmen und die nächsten Schritte nach der Zuteilung.
fully automated tunnelbroker, peering and transit platform - happy networking
based on sponsors, the great community and love - get it for free!

nREPL is a Clojure network REPL that provides a REPL server and client, along with some common APIs of use to IDEs and other tools that may need to evaluate Clojure code in remote environments.
The RouterKit mission is to provide a plattform to deploy software defined routers and firewalls. This goal is supported by providing…
In diesem Artikel gebe ich euch einen Überblick, was Network Bound Disk Encryption (NBDE) ist und beschreibe einen konkreten Anwendungsfall. Am Ende des Artikels führe ich einige Verweise auf, mit deren Hilfe ihr NBDE bei Interesse selbst implementieren könnt.
Aruba Central Python Package Index SDK
Aruba Central is an unified cloud-based network management and configuration platform for campus, branch, remote and data center networks. There are various needs for automation and programmability like automating repetitive tasks, configuring multiple devices, monitoring and more. This python package is to programmatically interact with Aruba Central via REST APIs.
This series of BGP hands-on labs will help you master numerous aspects of EBGP, IBGP, and BGP routing policy configuration on a platform of your choice1, including:
- Arista EOS
- Aruba AOS-CX
- Cisco ASAv, IOSv, IOS XE, IOS XR and Nexus OS
- Cumulus Linux and FRR
- Dell OS10
- Juniper vSRX, vMX and vPTX
- Mikrotik RouterOS
- Nokia SR OS and SR Linux
- Vyatta VyOS
Dozens of labs are already waiting for you (with more coming soon), but if this is your first visit to this site, you should start with the Installation and Setup documentation or run BGP labs in GitHub codespaces.
FD.io's Vector Packet Processor (VPP) is a fast, scalable layer 2-4 multi-platform network stack. It runs in Linux Userspace on multiple architectures including x86, ARM, and Power architectures.
VPP's high performance network stack is quickly becoming the network stack of choice for applications around the world.
VPP is continually being enhanced through the extensive use of plugins. The Data Plane Development Kit (DPDK) is a great example of this. It provides some important features and drivers for VPP.
VPP supports integration with OpenStack and Kubernetes. Network management features include configuration, counters, sampling and more. For developers, VPP includes high-performance event-logging, and multiple kinds of packet tracing. Development debug images include complete symbol tables, and extensive consistency checking.
Some VPP Use-cases include vSwitches, vRouters, Gateways, Firewalls and Load-Balancers, to name a few.
In this talk, Pim will demonstrate high performance routing using open-source VPP and its underlying Data Plane Development Kit. This talk highlights the authors work on integrating the Linux Control Plane which makes BGP, OSPF, etc available with VPP. We’ll then turn to a popular DPDK based network load testing tool TRex, and discuss performance benchmarking results from the field using the author’s AS8298 as a practical example.
About the speakers
Pim van Pelt is known for SixXS, a global IPv6 tunnelbroker which ran from 2001-2017. In this journey, he found that IPv4/IPv6 routing at scale (many interfaces, many prefixes or many packets/sec) was better handled in user space rather than the kernel (both for FreeBSD and Linux). Today, Pim operates IPng Networks, a small ISP in Switzerland, using AMD64 based routers running VPP, which will give silicon-based routers a run for their money.
vNOG blog: https://virtualnog.net/posts/2022-06-24-vpp/
In this talk, Pim will demonstrate high performance routing using open-source VPP and its underlying Data Plane Development Kit. This talk highlights the authors work on integrating the Linux Control Plane which makes BGP, OSPF, etc available with VPP, including smart ways to automate configuration of the router's data- and controlplane layers.
We’ll then turn to a popular DPDK based network load testing tool TRex, and discuss performance benchmarking results from the field using the author’s AS8298 as a practical example. This will demonstrate that a fully open source router can seriously compete with silicon based router vendors.
passt implements a translation layer between a Layer-2 network interface and native Layer-4 sockets (TCP, UDP, ICMP/ICMPv6 echo) on a host. It doesn't require any capabilities or privileges, and it can be used as a simple replacement for Slirp.
Thoroughly detailed information and continually updated instructions on how to best operate pfSense® software.
Welcome

Traefik is an open-source Edge Router that makes publishing your services a fun and easy experience. It receives requests on behalf of your system and finds out which components are responsible for handling them.
What sets Traefik apart, besides its many features, is that it automatically discovers the right configuration for your services. The magic happens when Traefik inspects your infrastructure, where it finds relevant information and discovers which service serves which request.
Traefik is natively compliant with every major cluster technology, such as Kubernetes, Docker, Docker Swarm, AWS, Mesos, Marathon, and the list goes on; and can handle many at the same time. (It even works for legacy software running on bare metal.)
With Traefik, there is no need to maintain and synchronize a separate configuration file: everything happens automatically, in real time (no restarts, no connection interruptions). With Traefik, you spend time developing and deploying new features to your system, not on configuring and maintaining its working state.
Developing Traefik, our main goal is to make it simple to use, and we're sure you'll enjoy it.
This guide demonstrates the most common aspects of libvirt networking, whether running virtual machines (VMs) on a dedicated server or within a home lab.
How to choose a network type
On a dedicated server — where VMs often need to be publicly accessible — a Bridged network is ideal and allows each VM to bind to its own public IPv4 and IPv6 addresses. If bridging is not possible, create a Routed network. If the server has limited public IPv4 addresses, a NAT-based network that forwards incoming connections may be the only option.
Inside an intranet or home lab, a NAT-based network gives VMs outbound network access. If VMs are running services that must be accessible from other systems on the LAN, create a Bridged network (for an Ethernet connected libvirt host) or a Routed network (for a wirelessly connected libvirt host).
If you want to prevent libvirt from automatically inserting iptables rules, create a Bridged network, Custom routed network, or Custom NAT-based network.
Contents
Our research shows that network-based cache side-channel attacks are a realistic threat. Cache attacks have been traditionally used to leak sensitive data on a local setting (e.g., from an attacker-controlled virtual machine to a victim virtual machine that share the CPU cache on a cloud platform). With our attack called NetCAT, we show this threat extends to untrusted clients over the network, which can now leak sensitive data such as keystrokes in a SSH session from remote servers with no local access. The root cause of the vulnerability is a recent Intel feature called DDIO, which grants network devices and other peripherals access to the CPU cache. Originally, intended as a performance optimization in fast networks, we show DDIO has severe security implications, exposing servers in local untrusted networks to remote side-channel attacks.
Increased peripheral performance is causing strain on the memory subsystem of modern processors. For example, available DRAM throughput can no longer sustain the traffic of a modern network card. Scrambling to deliver the promised performance, instead of transferring peripheral data to and from DRAM, modern Intel processors perform I/O operations directly on the Last Level Cache (LLC). While Direct Cache Access (DCA) instead of Direct Memory Access (DMA) is a sensible performance optimization, it is unfortunately implemented without care for security, as the LLC is now shared between the CPU and all the attached devices, including the network card.
In this talk, we present the first security analysis of DDIO. Based on our analysis, we present NetCAT, the first network-based cache attack on the processor’s last-level cache of a remote machine. We show that NetCAT can break confidentiality of a SSH session from a third machine without any malicious software running on the remote server or client. The attacker machine does this by solely sending network packets to the remote server. netcat is also a famous utility that hackers and system administrators use to send information over the network. NetCAT is a pun on being able to read data from the network without cooperation from the other machine on the network. However, we received very mixed reactions on that pun. More details on this in the talk.
The vulnerability was acknowledged by Intel with a bounty and CVE-2019-11184 was assigned to track this issue. The public disclosure was on September 10, 2019.
OpenBGPD is a FREE implementation of the Border Gateway Protocol, Version 4. It allows ordinary machines to be used as routers exchanging routes with other systems speaking the BGP protocol.
Started out of dissatisfaction with other implementations, OpenBGPD is a fairly complete BGP implementation, powering many sites. Users often praise its ease of use and high performance, as well as its reliability.
OpenBGPD's companions, ospfd(8), ospf6d(8), ripd(8) and dvmrpd(8) add support for the respective protocols. ldpd(8) and mpe(4) add MPLS support. rpki-client(8) facilitates validation of the Route Origin of a BGP announcement.
OpenBGPD is primarily developed by Henning Brauer, Peter Hessler, and Claudio Jeker. All of these daemons are part of the OpenBSD Project.
The portable version, maintained by Claudio Jeker, is available via periodic tarball releases. Contributions are welcome to both the OpenBGPD core and the portable build framework.
The software is freely usable and re-usable by everyone under a BSD license.

Podman uses two different means for its networking stack, depending on whether the container is rootless or rootfull. When rootfull, defined as being run by the root (or equivalent) user, Podman primarily relies on the containernetworking plugins project. When rootless, defined as being run by a regular user, Podman uses the slirp4netns project.
#Networking and Podman pods
By definition, all containers in a Podman pod share the same network namespace. This fact means that they will have the same IP address, MAC addresses, and port mappings. You can conveniently communicate between containers in a pod by using localhost.
