Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Wednesday, October 21, 2026

Python3 script for checking IPv6 Mostly Networks

 Python script to check if your IPv6 Mostly Network is running ok


--- cut here validate_mostly_v6.py ---


#!/usr/bin/env python3
import subprocess
import platform
import re
import sys

# Terminal output colors
GREEN = '\033[0;32m'
RED = '\033[0;31m'
YELLOW = '\033[1;33m'
NC = '\033[0m' # No Color

print("==================================================")
print(" Starting IPv6-Mostly Network Validation Test (Py)")
print("==================================================")

# Detect Host Operating System
OS_TYPE = platform.system() # 'Darwin' for macOS, 'Linux' for Linux

def run_command(command):
    """Utility to run system commands and return stdout as string."""
    try:
        result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
        return result.stdout.strip()
    except Exception:
        return ""

def test_ping(command):
    """Utility to run ping tests and return Boolean success."""
    try:
        result = subprocess.run(command, shell=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
        return result.returncode == 0
    except Exception:
        return False


# --- TEST 1: Verify Global IPv6 Allocation ---
print("Test 1: Checking Global IPv6 Address... ", end="", flush=True)
if OS_TYPE == "Darwin":
    ifconfig_out = run_command("ifconfig en0 2>/dev/null")
    ipv6_addresses = re.findall(r'inet6\s+([a-fA-F0-9:]+)', ifconfig_out)
    # Filter out link-local (fe80) and loopback (::1)
    global_v6 = [ip for ip in ipv6_addresses if not ip.lower().startswith("fe80") and ip != "::1"]
else:
    ip_out = run_command("ip -6 addr show scope global 2>/dev/null")
    global_v6 = re.findall(r'inet6\s+([a-fA-F0-9:]+)', ip_out)

if global_v6:
    print(f"{GREEN}PASSED{NC} (Found: {' '.join(global_v6)})")
else:
    print(f"{RED}FAILED{NC} (No Global IPv6 address detected on the main interface)")


# --- TEST 2: Verify IPv6-Mostly / DHCPv4 Option 108 Behavior ---
print("Test 2: Checking DHCPv4 Option 108 & CLAT Status... ", end="", flush=True)
clat_active = False
real_ipv4_found = []

if OS_TYPE == "Darwin":
    ifconfig_out = run_command("ifconfig en0 2>/dev/null")
    # macOS flags 'clat46' or 'nat64' when Option 108 forces an IPv6-only state
    if "clat46" in ifconfig_out or "nat64" in ifconfig_out:
        clat_active = True
    
    ipv4_addresses = re.findall(r'inet\s+([0-9.]+)', ifconfig_out)
    # Filter out the 192.0.0.2 dummy address created locally by the macOS CLAT process
    real_ipv4_found = [ip for ip in ipv4_addresses if ip != "192.0.0.2" and ip != "127.0.0.1"]
else:
    ip_out = run_command("ip addr 2>/dev/null")
    if "clat" in ip_out:
        clat_active = True
    
    ip4_out = run_command("ip -4 addr show scope global 2>/dev/null")
    ipv4_addresses = re.findall(r'inet\s+([0-9.]+)', ip4_out)
    real_ipv4_found = [ip for ip in ipv4_addresses if ip != "192.0.0.2"]

if clat_active and not real_ipv4_found:
    print(f"{GREEN}PASSED{NC} (IPv6-Only Preferred active. Network IPv4 is disabled. Local CLAT active)")
elif real_ipv4_found:
    print(f"{YELLOW}WARNING{NC} (Real native IPv4 address found: {' '.join(real_ipv4_found)}. Option 108 might be missing or ignored)")
else:
    print(f"{RED}FAILED{NC} (Neither Option 108 behavior nor local CLAT was detected)")


# --- TEST 3: Native IPv6 Egress Connectivity ---
print("Test 3: Testing Native IPv6 Connectivity... ", end="", flush=True)
if test_ping("ping6 -c 2 2001:4860:4860::8888"):
    print(f"{GREEN}PASSED{NC}")
else:
    print(f"{RED}FAILED{NC} (Cannot reach Google IPv6 DNS via native routing)")


# --- TEST 4: OS-Level IPv4-Only Hostname Resolution ---
print("Test 4: Checking IPv4-only Resolution via CLAT/DNS64... ", end="", flush=True)
if test_ping("ping -c 2 ipv4.google.com"):
    print(f"{GREEN}PASSED{NC} (System successfully routes IPv4-only hostnames)")
else:
    print(f"{RED}FAILED{NC} (System cannot reach or resolve an IPv4-only hostname)")


# --- TEST 4b: Optional Network-Side DNS64 Synthesis Verification ---
print("Test 4b: Checking Optional Network-side DNS64 Synthesis... ", end="", flush=True)
dns_out = run_command("host -t AAAA ://google.com 2>/dev/null")

if "has AAAA address" in dns_out:
    synth_ips = re.findall(r'has AAAA address\s+([a-fA-F0-9:]+)', dns_out)
    print(f"{GREEN}ACTIVE{NC} (Network DNS is actively synthesizing AAAA records: {' '.join(synth_ips)})")
else:
    print(f"{YELLOW}NOT ACTIVE{NC} (Network DNS provides clean IPv4 records. Expected behavior for native CLAT)")


# --- TEST 5: Literal IPv4 Address Translation (End-to-End NAT64/CLAT) ---
print("Test 5: Testing NAT64/CLAT Translation (Ping to Literal IPv4)... ", end="", flush=True)
if test_ping("ping -c 2 8.8.8.8"):
    print(f"{GREEN}PASSED{NC} (End-to-end legacy IPv4 literal translation works perfectly)")
else:
    print(f"{RED}FAILED{NC} (Literal IPv4 traffic is blocked or translation gateway failed)")

print("==================================================")
print(" Validation Completed.")
print("==================================================")




--- cut here validate_mostly_v6.py ---


Humble bash script to check your IPv6 Mostly Network

Imagine you connect to an IPv6 Mostly Network, is it ok?


--- cut here validate_mostly_v6.sh ---

 

#!/bin/bash


# Terminal output colors

GREEN='\033[0;32m'

RED='\033[0;31m'

YELLOW='\033[1;33m'

NC='\033[0m' # No Color


echo "=================================================="

echo " Starting IPv6-Mostly Network Validation Test"

echo "=================================================="


# Detect Host Operating System

OS="$(uname)"


# --- TEST 1: Verify Global IPv6 Allocation ---

echo -n "Test 1: Checking Global IPv6 Address... "

if [ "$OS" = "Darwin" ]; then

    # macOS network interface scanning

    IPV6_GBL=$(ifconfig en0 2>/dev/null | grep 'inet6 ' | grep -v 'fe80::' | grep -v '::1' | awk '{print $2}')

else

    # Linux network interface scanning

    IPV6_GBL=$(ip -6 addr show scope global | grep 'inet6' | awk '{print $2}')

fi


if [ -n "$IPV6_GBL" ]; then

    echo -e "${GREEN}PASSED${NC} (Found: $(echo $IPV6_GBL | tr '\n' ' '))"

else

    echo -e "${RED}FAILED${NC} (No Global IPv6 address detected on the main interface)"

fi



# --- TEST 2: Verify IPv6-Mostly / DHCPv4 Option 108 Behavior ---

echo -n "Test 2: Checking DHCPv4 Option 108 & CLAT Status... "

if [ "$OS" = "Darwin" ]; then

    # macOS flags 'clat46' or 'nat64' when Option 108 forces an IPv6-only state with translation

    CLAT_CHECK=$(ifconfig en0 2>/dev/null | grep -E 'clat46|nat64')

    # Filter out the 192.0.0.2 dummy address created locally by the macOS CLAT process

    IPV4_REAL=$(ifconfig en0 2>/dev/null | grep 'inet ' | grep -v '192.0.0.2')

else

    # Linux native CLAT or node state verification

    CLAT_CHECK=$(ip addr 2>/dev/null | grep 'clat')

    IPV4_REAL=$(ip -4 addr show scope global 2>/dev/null | grep 'inet' | grep -v '192.0.0.2')

fi


if [ -n "$CLAT_CHECK" ] && [ -z "$IPV4_REAL" ]; then

    echo -e "${GREEN}PASSED${NC} (IPv6-Only Preferred active. Network IPv4 is disabled. Local CLAT active)"

elif [ -n "$IPV4_REAL" ]; then

    echo -e "${YELLOW}WARNING${NC} (Real native IPv4 address found: $IPV4_REAL. Option 108 might be missing or ignored)"

else

    echo -e "${RED}FAILED${NC} (Neither Option 108 behavior nor local CLAT was detected)"

fi



# --- TEST 3: Native IPv6 Egress Connectivity ---

echo -n "Test 3: Testing Native IPv6 Connectivity... "

# Sending ICMPv6 packets to Google Public DNS to verify native routing

if ping6 -c 2 2001:4860:4860::8888 > /dev/null 2>&1; then

    echo -e "${GREEN}PASSED${NC}"

else

    echo -e "${RED}FAILED${NC} (Cannot reach Google IPv6 DNS via native routing)"

fi



# --- TEST 4: OS-Level IPv4-Only Hostname Resolution ---

echo -n "Test 4: Checking IPv4-only Resolution via CLAT/DNS64... "

# Verifies if the OS subsystem can resolve and route an IPv4-only domain name natively

if ping -c 2 ://google.com > /dev/null 2>&1; then

    echo -e "${GREEN}PASSED${NC} (System successfully routes IPv4-only hostnames)"

else

    echo -e "${RED}FAILED${NC} (System cannot reach or resolve an IPv4-only hostname)"

fi



# --- TEST 4b: Optional Network-Side DNS64 Synthesis Verification ---

echo -n "Test 4b: Checking Optional Network-side DNS64 Synthesis... "

# Querying the network DNS server directly for a AAAA record on an IPv4-only target.

# Per RFC 8925, DNS64 is optional if the client runs a local CLAT (464XLAT) environment.

DNS64_SYNTH=$(host -t AAAA ://google.com 2>/dev/null | grep 'has AAAA address')


if [ -n "$DNS64_SYNTH" ]; then

    SYNTH_IP=$(echo "$DNS64_SYNTH" | awk '{print $NF}')

    echo -e "${GREEN}ACTIVE${NC} (Network DNS is actively synthesizing AAAA records: $SYNTH_IP)"

else

    echo -e "${YELLOW}NOT ACTIVE${NC} (Network DNS provides clean IPv4 records. Expected behavior for native CLAT)"

fi



# --- TEST 5: Literal IPv4 Address Translation (End-to-End NAT64/CLAT) ---

echo -n "Test 5: Testing NAT64/CLAT Translation (Ping to Literal IPv4)... "

# Sending a ping to a literal IPv4 address. 

# Success proves that the local CLAT engine successfully translates and encapsulates legacy raw IPv4 traffic into IPv6

if ping -c 2 8.8.8.8 > /dev/null 2>&1; then

    echo -e "${GREEN}PASSED${NC} (End-to-end legacy IPv4 literal translation works perfectly)"

else

    echo -e "${RED}FAILED${NC} (Literal IPv4 traffic is blocked or translation gateway failed)"

fi


echo "=================================================="

echo " Validation Completed."

echo "=================================================="



--- cut here validate_mostly_v6.sh ---



Saturday, September 5, 2026

FRR always displays "No connection to RPKI cache server."

 Situation

   FRR always displays "No connection to RPKI cache server."


Solution

   Specify the source address in the RPKI cache declaration. Example:

  rpki cache tcp 108.162.192.12 8282 source X.Y.Z.N preference 1



Thursday, April 2, 2026

FRR Troubleshooting: Fixing Kernel Route Redistribution Issues on Boot

If you are running FRRouting (FRR), you might have encountered a frustrating quirk: after a system reboot, kernel routes (like a static default route) fail to redistribute into RIP or OSPF. Curiously, as soon as you manually restart the FRR service, everything works perfectly.

Here is a breakdown of why this happens and how to fix it for good.

The Problem

During a cold boot, FRR starts its daemons (Zebra, RIPd, etc.), but routes defined at the OS level aren’t being advertised to neighbors. This breaks connectivity after an automated reboot and forces manual intervention (systemctl restart frr), which defeats the purpose of an automated routing stack.

The Root Cause: The Startup "Race Condition"

The culprit is typically a race condition between your network manager (like Netplan or systemd-networkd) and the FRR service.


    Interface Renaming: Modern tools like Netplan often rename interfaces during boot (e.g., from eth0 to enp1s0). If FRR initializes while an interface is in transition, Zebra may ignore routes associated with a "missing" or "changing" interface.

    The "Up" State: If Zebra scans the kernel routing table before the physical or virtual interface is fully marked as "UP" and operational, the routing protocols (like RIP) will deem the route invalid for redistribution.

    Dependency Timing: By default, the FRR service might attempt to load before the network is "fully online," leading to a failed initial synchronization between the kernel and Zebra.


Step-by-Step Solution

The fix involves modifying the systemd unit file to ensure FRR waits until the network stack is completely ready and interface names are finalized.

1. Edit the Service Configuration

Instead of editing the file in /lib/systemd/system/ directly, use a systemd "override" to keep your changes safe during updates:

bash


sudo systemctl edit frr.service


2. Adjust Network Dependencies

In the editor that opens, insert the following lines:

ini


[Unit]

After=network-online.target

Wants=network-online.target


This tells systemd that FRR should only start after the system reports that the network is fully up and functional (network-online.target).

3. Reload and Apply

Save the file and exit the editor. Then, reload the systemd manager to pick up the changes:

bash


sudo systemctl daemon-reload


Verification

On your next reboot, you can verify that Zebra is correctly picking up the routes by checking your FRR logs or using the following debug commands in vtysh:

vtysh


debug zebra kernel

debug rip events



Summary

In modern Linux distributions where interface naming and IP addressing are dynamic, startup timing is everything. Forcing FRR to wait for the network to be "online" ensures that when the daemons ask the kernel for routes, the kernel actually has the final, stable answers ready to give.

Wednesday, October 22, 2025

Script to stop all Containerlab topologies and docker processes in a server

 Have you ever needed to stop all Containerlab in a server?


Is it complicated because there are so many users and so many Docker containers?


After rebooting, you still see running machines and different instances? This script is for you.


---- cut here ----

#filename: download-all-containerlab.sh

sudo containerlab destroy --all

sudo docker stop $(sudo docker ps -q --filter "label=containerlab")

sudo docker rm $(sudo docker ps -aq --filter "label=containerlab")

sudo ip link delete clab-bridge

sudo systemctl restart docker

---- cut here ----


Run: sudo bash download-all-containerlab.sh


Hopefully this is helpful

Sunday, June 2, 2024

Solved: "The following security updates require Ubuntu Pro with 'esm-apps' enabled"

Situation

  When you want to do some operations in Ubuntu using apt/do-release-upgrade you receive the message:

"The following security updates require Ubuntu Pro with 'esm-apps' enabled"


Solution

 The solution that worked for me was to run this:


cd /etc/apt/sources.list.d

for i in *.list; do mv ${i} ${i}.disabled; donated

apt clean

apt autoclean

sudo do-release-upgrade



Reference

https://askubuntu.com/questions/1085295/error-while-trying-to-upgrade-from-ubuntu-18-04-to-18-10-please-install-all-av 



Monday, April 29, 2024

Solved: Error: eth0 interface name is not allowed for R2 node when network mode is not set to none in containerlab

 Problem:

   Containerlab returns a similar error:

Error: eth0 interface name is not allowed for R2 node when network mode is not set to none


Solution:

 In the .yml file in the node section indicating the topology error specify:


network-mode: none


Example:

topology:

  kinds: 

    linux:

      image: quay.io/frrouting/frr:8.4.1

  nodes:

    R1:

      kind: linux

      image: quay.io/frrouting/frr:8.4.1

      network-mode: none


 Rerun the topology with clab dep -t file.yml and that's it!


Luck.

Tuesday, February 27, 2024

This is the way to install the telnet command in Alpine Linux (very popular in the container world such as docker)

This is the way to install the telnet command in Alpine Linux (very popular in the container world such as docker)

#apk update

#apk add busybox-extras

Friday, February 23, 2024

The real solution to run ContainerLAB on MAC m1 or m2 apple silicon

Step 1: Install Canonical Multipass your MAC 

$brew install multipass


Step 2: Install the VM called docker

$multipass launch docker --name mydocker


Step 3: Connect to the new VM

$multipass shell mydocker


Step 4: Inside the VM install ContainerLab

$sudo su

#bash -c "$(curl -sL https://get.containerlab.dev)"


Let's try this simple back2back topology of two Linux computers with FRR


-- 2-frr-back2back.yml --

name: ipv6-ws

topology:

   kinds:

     linux:

       image: ghcr.io/hellt/network-multitool

   do not give:

   ROUTERS ###

     A1:

       kind: linux

       image: quay.io/frrouting/frr:8.4.1

       exec:

         - "sysctl -w net.ipv6.conf.all.forwarding=1"

         - "ip address add dev eth1 2001:db8:ffab::1/64"

     A2:

       kind: linux

       image: quay.io/frrouting/frr:8.4.1

       exec:

         - "ip address add dev eth1 2001:db8:ffab::2/64"

         - "sysctl -w net.ipv6.conf.all.forwarding=1"

   links:

     - endpoints: ["R1:eth1", "R2:eth1"]

--- yml --


Step 5: Let's build the topology with clab:

clab dep -t 2-frr-back2back.yml


Step 6: finally we are going to connect to one of the VMs inside ContainerLAB

docker exec -i -t clab-ipv6-ws-R2 bash

Tuesday, December 5, 2023

BGP: IPv6 Only example between OpenBGPD and FRR

FRR:

show run

frr# sh run 

Building configuration...


Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!



OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates


# global configuration

AS $ASN

router-id 2.2.2.2


network 2001:db8::2/128

network inet6 connected


neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}


deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1


#

(please note the blank space between the last line and the second to last line)

Monday, December 4, 2023

How to create an IPv6 route to null/blackhole in Linux

 Case:

    How to create an IPv6 route to null/blackhole in Linux

Command:

   ip -6 route add blackhole fd00:12:34::0/48




I hope it is useful

Sunday, October 29, 2023

How to temporarily disable IPv4 on an interface within Linux

Case:

   We want to disable IPv4 on an interface


Solution:

   sudo ip -4 addr flush dev enp0s1


Explanation:

   The above command removes all IPv4 addresses for interface enp0s1. Important, remember that this disabling is only temporary.

Friday, October 13, 2023

NGINX Reverse Proxy for an IPv6-Only Server Farm

Introduction

This work presents a very simple way to offer dual-stack web access to an IPv6-only server farm using NGINX. The continued growth of the Internet and the gradual adoption of the IPv6 protocol means that it is essential to ensure connectivity and accessibility for clients using both IPv4 and IPv6. We will explain how to configure NGINX to support dual-stack web access, we will address how to configure NGINX as a reverse proxy that listens on both IPv4 and IPv6 addresses, as well as how to correctly route incoming requests to backend servers with only IPv6 addresses. By the way, among many other benefits, what we will discuss in the following article is an important step towards the preservation of IPv4 addresses.



What is a Reverse Proxy?

In [1], Cloudflare defines a Reverse Proxy Server as follows: “A reverse proxy is a server that sits in front of web servers and forwards client (e.g. web browser) requests to those web servers. Reverse proxies are typically implemented to help increase security, performance, and reliability. In order to better understand how a reverse proxy works and the benefits it can provide, let’s first define what a proxy server is.”


What is a Proxy Server

In [1], Cloudflare also provides the following definition for a proxy server: “A forward proxy, often called a proxy, proxy server, or web proxy, is a server that sits in front of a group of client machines. When those computers make requests to sites and services on the Internet, the proxy server intercepts those requests and then communicates with web servers on behalf of those clients, like a middleman.”



What are the benefits of a Reverse Proxy?

  • • A reverse proxy can offer IPv4 or transparent IPv6 to clients serviced from an IPv6- only server farm (which is what we will focus on). • Scalability: The use of a reverse proxy allows adding or removing backend servers as needed without affecting end users. This makes it easier for applications to scale out, allowing them to handle a larger number of concurrent users and requests. • Static content caching: NGINX can cache static content such as images, CSS files, and JavaScript, thus reducing the load on backend servers and increasing content delivery speed. This decreases page load times and the required bandwidth. • Security: NGINX acts as a point of entry to the application, providing an additional layer of security. It can perform functions such as request filtering, DDoS attack prevention, SQL injection protection, and client authentication. NGINX can also enable the use of SSL/TLS encryption for communication between clients and the backend server. • Advanced routing: A reverse proxy allows performing advanced routing based on various criteria, such as domain name, URL, or HTTP headers. This is useful when we need to direct traffic to different backend servers based on the specific attributes of the requests. • Consolidation of services: NGINX can act as a single point of entry for various backend services. This simplifies the infrastructure by consolidating multiple services on a single server, thus simplifying management and maintenance. • Enhanced performance: NGINX is lightweight and resource efficient by design. Its streamlined architecture and ability to handle large numbers of concurrent connections make it a popular choice for improving web app performance. • Load balancing: A reverse proxy such as NGINX can distribute incoming traffic across several backend servers. This helps balance the load and guarantees that no server is overloaded, which improves an application's performance and responsiveness.



Topology


What is our Goal Today?

The edge server (Reverse Proxy Server) will be able to receive IPv4 and IPv6 HTTP requests, and depending on the website a user wishes to visit (domain), will forward the request to the right server. This is what will happen in our example: 

The client visits: The request is sent to: 

server-a.com → 2001:db8:123::1 

server-b.com → 2001:db8:123::2 

server-c.com → 2001:db8:123::3 

server-a.com → 2001:db8:123::101 

server-b.com → 2001:db8:123::102 

server-c.com → 2001:db8:123::103



Requirements

  • • Linux with NGINX on the Reverse Proxy Server • Super user access • Web server on each of the servers in the farm • IPv4 and IPv6 Internet connectivity • Internal IPv6 connectivity


Let's get started


Let's get started 

1) Install NGINX in all servers #apt update #apt install nginx 

2) Create the websites in the NGINX reverse proxy 

File /etc/nginx/sites-available/server-a.com 

server { listen 80; listen [::]:80; 

  server_name server-a.com; 

  location / { 

  proxy_pass http://[2001:db8:123::101]; } 

} 


File /etc/nginx/sites-available/server-b.com


server { listen 80; listen [::]:80; server_name server-b.com; location / { proxy_pass http://[2001:db8:123::102]; } }



Archivo  /etc/nginx/sites-available/server-b.com

server {

listen 80;

listen [::]:80;


    server_name server-b.com;

    location / {

        proxy_pass http://[2001:db8:123::102];

    }


}



File /etc/nginx/sites-available/server-c.com 
server { 
  listen 80; listen [::]:80; 
  server_name server-c.com; 
  location / { 
  proxy_pass http://[2001:db8:123::103]; 
  }
}

3) Create symbolic links to enable the sites configured above:


root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sitesavailable/server-a.com /etc/nginx/sites-enabled/server-a.com 


root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sitesavailable/server-b.com /etc/nginx/sites-enabled/server-b.com 


root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sitesavailable/server-c.com /etc/nginx/sites-enabled/server-c.com



4) Remember to restart NGINX

$sudo systemctl restart nginx



About the logs

Logs are extremely important for any company or ISP that wishes to review incoming connections. 

By default, NGINX will use its own IP address for outgoing connections, which results in the loss of the address of the client that originated the HTTP request. But don't worry. NGINX has the solution: proxy_set_header. This requires configuring both the end server and the Reverse Proxy server. 

1) On the Reverse Proxy Server, we must configure the website assets. 
# Example of nginx reverse proxy that allows logging the client's 
# original address and port number 

location /examples { 
   proxy_pass http://[2001:db8:123::103]; 
   proxy_buffering off; 
   proxy_set_header X-Real-IP $remote_addr; 
   proxy_set_header X-Forwarded-Host $host; 
   proxy_set_header X-Forwarded-Port $server_port; 
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
 } 

2) On the end server, add the following in the http section of the /etc/nginx/nginx.conf file:

set_real_ip_from 2001:db8:123::100; #replace the IP address with that of the proxy 
real_ip_header X-Forwarded-For; 
real_ip_recursive on; 

Example: 
http { 
   … 
   set_real_ip_from 2001:db8:123::100; 
   real_ip_header X-Forwarded-For; real_ip_recursive on; 
   … 
  } 

With these settings, the receiving server will trust the X-Forwarded-For header set to 2001:db8:123::100 and will log the client's source IP to /var/log/nginx/access.log.



Summary

The proposed design allows managing a 100% IPv6-only web server farm with access to both the IPv4 and the IPv6 worlds in a very simple, scalable, and efficient manner. This results in various benefits, including having to manage only one TCP/IP stack, simplicity, security, and even saving IPv4 addresses.


References


    • [1] https://www.cloudflare.com/es-es/learning/cdn/glossary/reverse-proxy/ • https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-areverse-proxy-on-ubuntu-22-04 
    • GitHub. LACNIC Blog Post Help Files for the entire project: https://github.com/LACNIC/BlogPostHelpFiles/tree/main/2023_Ofreciendo_conectivid ad_Dual_Stack_a_servidores_Web_en_una_granja_de_servidores_100_IPv6_Only

    Thursday, May 25, 2023

    Strange ssh behavior on MAC - Copy/Paste Issues

     Situation:

       Strange behavior of SSH on MAC, problems with copy/paste in terminal during ssh. Does the clipboard work in other applications?


    Solution:

       At least in "vi" the solution is very simple. Edit the file: ~/.vimrc and paste the following content:


    if !has("gui_running")

       set mouse=

    endif


    Luck!

    Wednesday, July 13, 2022

    Fixing/Solved "Unable to parse package file " after apt

    Problem: 
       We get an error after executing any apt command in linux 

    Solution 
       The solution is very easy, I spent so many hours fixing it. 
       You just have to delete the file mentioned in the error, in my case I got: "E: Unable to parse package file /var/lib/apt/extended_states (1)" 
       I just deleted the file /var/lib/apt/extended_states 

     Example: 
       #sudo rm /var/lib/apt/extended_states 

     That's it

    Sunday, September 26, 2021

    Solved: VBoxGuestAdditions.iso (VERR_PDM_MEDIA_LOCKED)Solved:

    Situation: 
       When inserting Guest Additions CD Image in a Debian VM you are getting VERR_PDM_MEDIA_LOCKED 

    Solution: 
       There are many solutions, like: 
    1) Executing 
      sudo apt-get upgrade 
      sudo apt-get install virtualbox-guest-additions-iso
    2) Removing and inserting the cd from the VM configuration

    and a third one which is the one that worked with me:

    a) Start the VM
    b) Open a terminal
    c) Execute this:
      sudo su
      cd /media
      mkdir cdrom
      mount /dev/cdrom /media/cdrom
      cd cdrom
      sh VBoxLinuxAdditions.run

    Hope this helps.

    Alejandro,


    Wednesday, May 19, 2021

    Solved: nping - libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)

     Problem:

      When using nping (which comes with nmap) we receive the message:

    libnsock mksock_bind_addr(): Bind to 2001:db8:1::1:0 failed (IOD #1): Cannot assign requested address (99)


    Current situation:
      The issue is that nping can not bind to the IP 2001:db8:1::1


    Solution:
      There could be many different solutions, I'm only going to mention one.  What I did was to create a logical interface (tunnel type) with the IPv6 address I was needing (2001:db8:1::1). Here you have the commands.

    ip tuntap add mode tun dev tun1
    ip -6 addr add 2001:db8:1::1 dev tun1
    ifconfig tun1 up


    Finally, you could execute something like:

    nping -6 -S 2001:db8:1::1 --tcp-connect -c 2 -p 53 <ipv6_dest> --source-mac 00:50:XX:XX:XX:35  --dest-mac 2c:XX:XX:XX:44:20


    Hope this is useful

    Thursday, September 3, 2020

    Solved: Closing connection because of an I/O error in FRR - at least in Ubuntu

     If you are getting this message in FRR:

    Closing connection because of an I/O error in FR


    The solution is straight forward. You have to compile FRR with this flag:

    --enable-systemd


    So, it would be something like:

    ./configure \

        --prefix=/usr \

        --includedir=\${prefix}/include \

        --enable-exampledir=\${prefix}/share/doc/frr/examples \

        --bindir=\${prefix}/bin \

        --sbindir=\${prefix}/lib/frr \

        --libdir=\${prefix}/lib/frr \

        --libexecdir=\${prefix}/lib/frr \

        --localstatedir=/var/run/frr \

        --sysconfdir=/etc/frr \

        --with-moduledir=\${prefix}/lib/frr/modules \

        --with-libyang-pluginsdir=\${prefix}/lib/frr/libyang_plugins \

        --enable-configfile-mask=0640 \

        --enable-logfile-mask=0640 \

        --enable-snmp=agentx \

        --enable-multipath=64 \

        --enable-user=frr \

        --enable-group=frr \

        --enable-vty-group=frrvty \

        --with-pkg-git-version \

        --enable-systemd

        --with-pkg-extra-version=-MyOwnFRRVersion



    you can follow those instructions and adding my previous solution:

    http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu2004.html

    Friday, July 13, 2018

    How to run Flask framework to listen in both IPv4 and IPv6 (DualStack)

    Issue:
      How to run Flask framework to listen in both IPv4 and IPv6 (DualStack)

    Answer:
      app.run(host='::',port=5005)


    Monday, August 21, 2017

    My humble results. Testing ping to loopback using v4 and v6

    Hello there,
      Regarding RTT v4 vs v6 I did something "interesting" recently, would like to know your thoughs.
      If you ping6 your loopback (let´s say 1000 packets) interface with Windows or Linux, v6 is faster.
      Now try the same on MAC (El capitan for example).., v6 is 20-25% slower.
      I did the above with many devices (and asked some friends) and the behavior was pretty much the same.


    MAC:
    --- 127.0.0.1 ping statistics ---
    100 packets transmitted, 100 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.037/0.098/1.062/0.112 ms

    --- ::1 ping6 statistics ---
    100 packets transmitted, 100 packets received, 0.0% packet loss
    round-trip min/avg/max/std-dev = 0.058/0.120/0.194/0.027 ms




    Linux:
    --- 127.0.0.1 ping statistics ---
    100 packets transmitted, 100 received, 0% packet loss, time 98999ms
    rtt min/avg/max/mdev = 0.015/0.021/0.049/0.007 ms

    --- ::1 ping statistics ---
    100 packets transmitted, 100 received, 0% packet loss, time 99013ms
    rtt min/avg/max/mdev = 0.019/0.031/0.040/0.004 ms



    Windows 10:

    Ping statistics for ::1:
        Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 0ms, Average = 0ms



    Ping statistics for 127.0.0.1:
        Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 0ms, Maximum = 4ms, Average = 0ms



    Bye,


    wetheitteam.com
    Where to order pain Relief without prescription
    vivo v15 pro