Routers and DNS - sgml/signature GitHub Wiki

+-------------------------------------------------------------+
| NETWORK PLAYGROUND: ROCK, PAPER, SCISSORS OVERLAY           |
+-------------------------------------------------------------+

PROBLEMS TO SOLVE:
  - Latency      (the ball is slow)
  - Jitter       (the ball is bouncy)
  - Packet Loss  (the ball disappears)

SOLUTIONS (ROUTER SETTINGS THAT HELP):

  LATENCY (make the ball faster):
    * Give important balls a fast lane (QoS)
    * Use smaller balls if big ones are too slow (MTU size)
    * Clean up messy waiting lines (bufferbloat fix)
    * Draw better maps so balls take shorter paths (routing table)
    * Remember names so you don’t ask every time (DNS caching)

  JITTER (make the ball steady):
    * Take turns nicely in line (fair queuing)
    * Don’t throw too many balls at once (traffic shaping)
    * Check the playground often (polling interval)
    * Group throws so they don’t bump (interrupt tuning)
    * Keep all clocks in sync (NTP)

  PACKET LOSS (keep the ball from vanishing):
    * Use smart rules for sharing (congestion control)
    * Try again if the ball drops (retry settings)
    * Fix holes in the net (error correction)
    * Make sure both ends talk the same way (duplex match)
    * Don’t block good throws (firewall rules)

TOOLS TO USE:
  ROCK = ALGEBRA
    Role: Counts the problems

    Latency:
      [Send] ---> ---> ---> ---> ---> [Receive]
              ^    ^    ^    ^    ^
           Time  Time  Time  Time  Time
      => Count how long the ball takes

    Jitter:
      [Send] -->--->----->-->---> [Receive]
              ↑     ↑      ↑   ↑
           Fast  Slow   Faster Laggy
      => See if the throws are bumpy

    Packet Loss:
      [Send] ---> X ---> ---> ---> [Receive]
               (Oops!)
      => Count how many balls got lost

  PAPER = HEURISTICS
    Role: Learns the rules

    Tricks:
      * Try a different kid if one keeps dropping
      * Wait if it’s windy
      * Pick a smoother path

  SCISSORS = GEOMETRY
    Role: Draws the map

    Diagram:
      [Kid A]---[Kid B]
         \       /
          \     /
         [Kid C]

    => See who’s close, who’s far, and where the ball might get stuck

TRIAD SUMMARY:
  ROCK     = Count the steps
  PAPER    = Learn the patterns
  SCISSORS = Draw the map

TOGETHER:
  => Fix slow balls, bumpy throws, and missing passes
  => Like a good game of Rock, Paper, Scissors

+-------------------------------------------------------------+
| SYMBOLIC OVERLAY FOR NETWORK DIAGNOSTICS                    |
| Use in classrooms, audits, or reproducible playground maps  |
+-------------------------------------------------------------+

+-------------------------------------------------------------+
| KINDERGARTEN GUIDE: BUILDING YOUR OWN NETWORK FILES         |
| (DNS Cache, Routing Table, Firewall)                        |
+-------------------------------------------------------------+

WHAT WE'RE MAKING:
  - A DNS cache file: remembers names and numbers
  - A Routing table file: shows where to send things
  - A Firewall file: decides what gets in or out

HOW WE LEARN: TRY, TEST, FIX, REPEAT!

-------------------------------------------------------------
1. DNS CACHE FILE (Who’s Who on the Playground)
-------------------------------------------------------------

GOAL:
  Match names to numbers so we don’t have to ask every time.

TRY:
  Write down a few known friends:
    name: "apple.com" -> number: "17.253.144.10"
    name: "school.local" -> number: "192.168.1.5"

TEST:
  Ask your computer to visit "apple.com"
  If it uses your number, it worked!

FIX:
  If it asks someone else (like a big DNS server), add it to your file next time.

REPEAT:
  Keep adding new names and numbers as you meet them.

-------------------------------------------------------------
2. ROUTING TABLE FILE (Who’s Standing Where)
-------------------------------------------------------------

GOAL:
  Draw a map so messages know where to go.

TRY:
  Write down paths:
    destination: "192.168.1.0/24" -> next hop: "192.168.1.1"
    destination: "0.0.0.0/0" -> next hop: "10.0.0.1"

TEST:
  Send a message to a friend.
  If it goes the right way, your map works!

FIX:
  If it gets lost, check if the next hop is reachable.

REPEAT:
  Add new paths when you meet new friends.

-------------------------------------------------------------
3. FIREWALL FILE (Who’s Allowed to Play)
-------------------------------------------------------------

GOAL:
  Decide who can come in, who can go out, and who must wait.

TRY:
  Write simple rules:
    allow: "tcp port 80 from 0.0.0.0/0"
    deny: "udp port 123 from 10.0.0.0/8"
    allow: "icmp from 192.168.1.0/24"

TEST:
  Try sending a message from each type.
  If it gets through or blocked correctly, your rules work!

FIX:
  If something sneaks through or gets stuck, adjust the rule.

REPEAT:
  Add new rules when new games start.

-------------------------------------------------------------
REMEMBER:
  - Trial means trying something.
  - Error means learning from what didn’t work.
  - Aggregating means collecting all your good tries into one file.

-------------------------------------------------------------
SYMBOLIC OVERLAY:
  DNS Cache   = Memory of names
  Routing     = Map of paths
  Firewall    = Rules of the game

-------------------------------------------------------------
USE THIS GUIDE TO BUILD YOUR OWN NETWORK PLAYGROUND FILES!
+-------------------------------------------------------------+

router_settings:
  RTS_threshold:
    best_practice:
      description: >
        Set just below average packet size in hidden node environments to trigger RTS/CTS only when needed.
      rationale: >
        Reduces collisions without excessive control overhead.
    worst_practice:
      description: >
        Set too low (e.g., 0–500 bytes) or too high (e.g., >2300 bytes).
      risks:
        - Excessive RTS/CTS overhead
        - Hidden node collisions
        - Reduced throughput
        - Increased latency

  DTIM_interval:
    best_practice:
      description: >
        Use interval of 1–3 for multicast-heavy environments like VoIP or IP cameras.
      rationale: >
        Balances timely delivery with battery conservation for sleeping clients.
    worst_practice:
      description: >
        Set too high (e.g., 5–10) or too low (e.g., 1 in low-traffic environments).
      risks:
        - Delayed multicast delivery
        - Jitter and packet loss
        - Wasted airtime
        - Battery drain

  beacon_interval:
    best_practice:
      description: >
        Use default 100 ms for general-purpose networks.
      rationale: >
        Keeps clients synchronized without excessive airtime usage.
    worst_practice:
      description: >
        Set too low (e.g., 20–50 ms) or too high (e.g., >1000 ms).
      risks:
        - Airtime flooding
        - Reduced data throughput
        - Missed beacons
        - Unnecessary roaming or disconnects

+----------------+        +----------------+
|   CAMERA       |        |    ROUTER      |
|                |        |                |
|  "I talk fast!"|<------>|"I talk slow..."|
|  (Full Duplex) |        | (Half Duplex)  |
+----------------+        +----------------+
        |                        |
        |                        |
        v                        v
   [Collisions!]         [Dropped Packets!]


+----------------+        +----------------+
|   CAMERA       |        |    ROUTER      |
|                |        |                |
| "I shout to ALL!"|----->| "Who asked for this?" |
| (Multicast)     |        | (No IGMP Snooping)   |
+----------------+        +----------------+
        |                        |
        v                        v
[Too many listeners!]     [Confused devices!]

{
  "ToyBox": [
    {
      "name": "Messy Settings",
      "tag": {
        "makesTrouble": ["Things stop working", "Devices don’t agree"],
        "happensBecause": ["Fast talker vs slow talker", "Everyone hears everything"]
      }
    },
    {
      "name": "No Watchdog",
      "tag": {
        "makesTrouble": ["No one sees the problem", "No clues left behind"],
        "happensBecause": ["Fast talker vs slow talker"]
      }
    },
    {
      "name": "Too Many Listeners",
      "tag": {
        "makesTrouble": ["People hear secrets they shouldn’t", "No one takes turns"],
        "happensBecause": ["Everyone hears everything"]
      }
    },
    {
      "name": "Secret Leaks",
      "tag": {
        "makesTrouble": ["Secrets go to the wrong place", "Too much shouting"],
        "happensBecause": ["Everyone hears everything"]
      }
    }
  ]
}

sudo iwconfig wlp1s0 rts 900
sudo iwconfig wlp1s0 frag 900

iperf3 -c 142.250.82.1 -u -b 3m -t 60 -l 1200 -i 5 -S 0xb8

google_meet_network:
  ip_blocks:
    ipv4:
      - 142.250.0.0/15
      - 172.217.0.0/16
      - 108.177.0.0/17
      - 209.85.128.0/17
      - 64.233.160.0/19
      - 66.102.0.0/20
      - 66.249.80.0/20
      - 72.14.192.0/18
      - 74.125.0.0/16
      - 173.194.0.0/16
      - 207.126.144.0/20
      - 216.58.192.0/19
      - 216.239.32.0/19
    ipv6:
      - 2001:4860:4000::/36

  ports:
    udp:
      - 19302
      - 19303
      - 443
    tcp:
      - 443
      - 80

  qos:
    dscp_values:
      expedited_forwarding: 0xb8
      default: 0x00

  notes:
    - All media traffic is encrypted and uses TLS/DTLS.
    - UDP preferred for low-latency video communication.
    - Traffic may traverse different Google infrastructure regions.

  reference: https://support.google.com/a/answer/1279090

tcpdump -i eth0 -l | awk '{print strftime("[%Y-%m-%d %H:%M:%S]"), $0}' | grep -v "ARP" > packet_log.txt

static_routes:
  - name: throttle_example_com
    description: Route traffic for example.com through shaping gateway
    resolved_from: example.com
    destination_ip: 93.184.216.34     # IP address resolved from DNS
    subnet_mask: 255.255.255.255      # /32 to target only this host
    gateway_ip: 192.168.1.100         # IP of the throttling machine (not the router itself)
    interface: LAN                    # Interface through which the route applies
    metric: 1                         # Route priority; lower = higher preference
    notes:
      - "Requires the throttling gateway to be reachable on LAN"
      - "Must re-resolve domain periodically due to DNS TTL"