Showing posts with label bash. Show all posts
Showing posts with label bash. Show all posts

Wednesday, October 21, 2026

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 ---



Monday, March 2, 2026

MAC OpenVPN client is installed, but it won't run

 Scenario

You have a Mac; the OpenVPN client is installed, but it won't run. A typical scenario is that after restarting the laptop, another user logs into their profile, and then when you try to use your profile, OpenVPN simply won't open.


Solution


Run this bash script with sudo or as root:


-- cut here --


sudo launchctl bootout system /Library/LaunchDaemons/org.openvpn.client.plist


sudo launchctl bootstrap system /Library/LaunchDaemons/org.openvpn.client.plist


# 1. Kill all processes from any user


sudo pkill -9 -f "OpenVPN Connect"


sudo pkill -9 -f "ovpnagent"


# 2. Delete the communication file locked by the other user


sudo rm -f /var/run/agent_ovpnconnect.sock


# 3. Restart the background service


sudo launchctl kickstart -k system/org.openvpn.client


sudo launchctl enable system/org.openvpn.client


sudo launchctl bootstrap system /Library/LaunchDaemons/org.openvpn.client.plist


-- cut here --


I hope this was helpful.

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

Thursday, August 24, 2017

Google DNS --- Figuring out which DNS Cluster you are using

(this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on 
August 23).

This post is being posted with his explicit permission.
I sent this out on the outage list, with a lots of good feedback sent to me. So I figured it 
would be useful to share the information on nanog as well. A couple months ago had to 
troubleshoot a google DNS issue with Google’s NOC. Below is some helpful information 
on how to determine which DNS Cluster you are going to. Let’s remember that Google runs 
DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. Anycast routes your DNS queries to 
the closes DNS cluster based on the best route / lowest metric to 8.8.8.8/8.8.4.4. Google 
has deployed multiple DNS clusters across the world and each DNS Cluster has multiple 
servers. So a DNS query in Chicago will go to a different DNS clusters than queries from 
a device in Atlanta or New York.

How to get a list of google DNS Cluster’s.
dig -t TXT +short locations.publicdns.goog. @8.8.8.8

How to print this list in a table format. 
-- Script from: https://developers.google.com/speed/public-dns/faq -- 

#!/bin/bash
IFS="\"$IFS"
for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8)
do
  case $LOC in
    '') : ;;
    *.*|*:*) printf '%s ' ${LOC} ;;
    *) printf '%s\n' ${LOC} ;;
  esac
done
---------------

Which will give you a list like below. This is all of the IP network’s that 
google uses for their DNS Clusters and their associated locations. 
74.125.18.0/26 iad
74.125.18.64/26 iad
74.125.18.128/26 syd
74.125.18.192/26 lhr
74.125.19.0/24 mrn
74.125.41.0/24 tpe
74.125.42.0/24 atl
74.125.44.0/24 mrn
74.125.45.0/24 tul
74.125.46.0/24 lpp
74.125.47.0/24 bru
74.125.72.0/24 cbf
74.125.73.0/24 bru
74.125.74.0/24 lpp
74.125.75.0/24 chs
74.125.76.0/24 cbf
74.125.77.0/24 chs
74.125.79.0/24 lpp
74.125.80.0/24 dls
74.125.81.0/24 dub
74.125.92.0/24 mrn
74.125.93.0/24 cbf
74.125.112.0/24 lpp
74.125.113.0/24 cbf
74.125.115.0/24 tul
74.125.176.0/24 mrn
74.125.177.0/24 atl
74.125.179.0/24 cbf
74.125.181.0/24 bru
74.125.182.0/24 cbf
74.125.183.0/24 cbf
74.125.184.0/24 chs
74.125.186.0/24 dls
74.125.187.0/24 dls
74.125.190.0/24 sin
74.125.191.0/24 tul
172.217.32.0/26 lhr
172.217.32.64/26 lhr
172.217.32.128/26 sin
172.217.33.0/26 syd
172.217.33.64/26 syd
172.217.33.128/26 fra
172.217.33.192/26 fra
172.217.34.0/26 fra
172.217.34.64/26 bom
172.217.34.192/26 bom
172.217.35.0/24 gru
172.217.36.0/24 atl
172.217.37.0/24 gru
173.194.90.0/24 cbf
173.194.91.0/24 scl
173.194.93.0/24 tpe
173.194.94.0/24 cbf
173.194.95.0/24 tul
173.194.97.0/24 chs
173.194.98.0/24 lpp
173.194.99.0/24 tul
173.194.100.0/24 mrn
173.194.101.0/24 tul
173.194.102.0/24 atl
173.194.103.0/24 cbf
173.194.168.0/26 nrt
173.194.168.64/26 nrt
173.194.168.128/26 nrt
173.194.168.192/26 iad
173.194.169.0/24 grq
173.194.170.0/24 grq
173.194.171.0/24 tpe
2404:6800:4000::/48 bom
2404:6800:4003::/48 sin
2404:6800:4006::/48 syd
2404:6800:4008::/48 tpe
2404:6800:400b::/48 nrt
2607:f8b0:4001::/48 cbf
2607:f8b0:4002::/48 atl
2607:f8b0:4003::/48 tul
2607:f8b0:4004::/48 iad
2607:f8b0:400c::/48 chs
2607:f8b0:400d::/48 mrn
2607:f8b0:400e::/48 dls
2800:3f0:4001::/48 gru
2800:3f0:4003::/48 scl
2a00:1450:4001::/48 fra
2a00:1450:4009::/48 lhr
2a00:1450:400b::/48 dub
2a00:1450:400c::/48 bru
2a00:1450:4010::/48 lpp
2a00:1450:4013::/48 grq

There are
IPv4 Networks: 68
IPv6 Networks: 20
DNS Cluster’s Identified by POP Code’s: 20
DNS Clusters identified by POP Code to City, State, or Country. Not all 
of these are 
Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). 
https://peering.google.com/#/infrastructure and 
https://www.google.com/about/datacenters/inside/locations/ 


Most of these are airport codes, it did my best to get the location correct.
iad          Washington, DC
syd         Sydney, Australia
lhr          London, UK
mrn        Lenoir, NC
tpe         Taiwan
atl          Altanta, GA
tul          Tulsa, OK
lpp          Findland
bru         Brussels, Belgium
cbf         Council Bluffs, IA
chs         Charleston, SC
dls          The Dalles, Oregon
dub        Dublin, Ireland
sin          Singapore
fra          Frankfort, Germany
bom       Mumbai, India
gru         Sao Paulo, Brazil
scl          Santiago, Chile
nrt          Tokyo, Japan
grq         Groningen, Netherlans

Which Google DNS Server Cluster am I using. I am testing this from Chicago, 
IL
# dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 "173.194.94.135" 
<<<<<<DNS Server IP, reference the list above to get the cluster, Council 
Bluffs, IA 
"edns0-client-subnet 207.xxx.xxx.0/24" <<<< Your Source IP Block Side note, 
the google 
dns servers will not respond to DNS queries to the Cluster’s Member’s IP, 
they will 
only respond to dns queries to 8.8.8.8 and 8.8.4.4. So the following will 
not work.

dig google.com @173.194.94.135 Now to see the DNS Cluster load balancing 
in action. 
I am doing a dig query from our Telx\Digital Realty POP in Atlanta, GA. 
We do peer 
with google at this location. I dig a dig query about 10 times and received 
the 
following unique dns cluster member ip’s as responses. 

dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
"74.125.42.138"
"173.194.102.132"
"74.125.177.5"
"74.125.177.74"
"74.125.177.71"
"74.125.177.4"

Which all are Google DNS Networks in Atlanta.
74.125.42.0/24

atl

74.125.177.0/24

atl

172.217.36.0/24

atl

173.194.102.0/24

atl

2607:f8b0:4002::/48

atl



Just thought it would be helpful when troubleshooting google DNS 
issues.



(this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on 
August 23 2017).
 This post is being posted with his explicit permission.

Tuesday, February 17, 2015

Solution to quagga vtysh "Exiting: failed to connect to any daemons."

Description:
   When you run the command in the linux shell vtysh to connect to the quagga daemons (such as bgpd, ospfd, etc) returns  the following error "Exiting: failed to connect to any daemons"

Just like this:

alejandro @ miserver: ~ $ vtysh -d bgpd
Exiting: failed to connect to any daemons.

alejandro @ miserver: ~ $ vtysh
Exiting: failed to connect to any daemons.


Solution:
   The solution is to add the user that is executing vtysh to the quagga group. To do this edit the /etc/group file.
   After editing /etc/group should be something like:

quagga:x:1003:alejandro

You can specify multiple users doing:

quagga:x:1003:alejandro, john


   This is necessary because vtysh tries to connect to the daemons using UNIX domain sockets and not all users (for security reasons) have access to these sockets.

Another solution:
   Another solution might be during the compilation phase where you can specify the linux/unix group for sockets mentioned above. Example:

./configure --enable-vty-group = group


   Good luck, I hope this helped,