Networks

To build a wpa_supplicant configuration file:

# wpa_passphrase testap >> /etc/wpa_supplicant/testap.conf
  a_password
# cat /etc/wpa_supplicant/testap.conf
  # reading passphrase from stdin
  network={
          ssid="testap"
          #psk="a_password"
          psk=1b97a5c02076ac80739263fb33db49c7c50d3199202872e06097e7baf305f35e
  }

Additional info at How to connect to a WPA/WPA2 WiFi network using Linux command line.

From a mailing list:

One way to avoid knowing or typing the specific LL address is to ping the all-nodes link scoped multicast address, and looking for the address you're after in the response.

E.g. under Linux, the following command will show all IPv6 link local addresses on the link (assuming they reply to an ICMPv6 echo request) that respond within 1 second:

# ping -w 1 -I wlp6s0 ff02::1
ping6: Warning: source address might be selected on device other than wlp6s0.
PING ff02::1(ff02::1) from :: wlp6s0: 56 data bytes
64 bytes from fe80::e54:15ff:fe66:3b9a%wlp6s0: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from fe80::aca7:4aff:fed2:a7dd%wlp6s0: icmp_seq=1 ttl=64 time=3.47 ms (DUP!)
64 bytes from fe80::400:55ff:fe40:5%wlp6s0: icmp_seq=1 ttl=64 time=3.51 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:6709%wlp6s0: icmp_seq=1 ttl=64 time=216 ms (DUP!)
64 bytes from fe80::9e8e:cdff:fe0e:66ff%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::fe90:d8d2:7ec5:3c8%wlp6s0: icmp_seq=1 ttl=64 time=221 ms (DUP!)
64 bytes from fe80::a65d:36ff:fe40:e31c%wlp6s0: icmp_seq=1 ttl=64 time=250 ms (DUP!)

--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +6 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.074/130.707/249.971/111.633 ms

Comment:

Can you write the code which tells you when you have the no IPv4 “thing” without trying the IPv4 thing on a network which by definition should not have the IPv4 thing where you want people not to try the IPv4 thing?

Response:

We've been here before - I don't think there is any way to write an algorithm that can differentiate between "I can see IPv4 chatter and I should join in because this network is completely IPv6 only yet" and "I can see IPv4 chatter and I shouldn't join in because this network is supposed to be IPv6 only but some other nodes don't understand that". If a key part of the algorithm is "there aren't other IPv4 nodes chattering" then you only need one device on the network to prevent everything else shutting down IPv4.

Because ovsdb is a generic database tool, some one may have build other schemas. But for a native open vswitch install, this is the default state:

# ovsdb-client list-dbs
Open_vSwitch
_Server

It is possible to add a tcp connection to gain access to the database:

# ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640
# netstat -antp |grep ovs
tcp        0      0 0.0.0.0:6640            0.0.0.0:*               LISTEN      746/ovsdb-server
tcp        0      0 127.0.0.1:57424         127.0.0.1:6633          ESTABLISHED 397/ovs-vswitchd

But on linux, there is an existing linux stream available:

# lsof|grep ovsdb|grep STREAM
ovsdb-ser   746                   root    5u     unix 0x000000001740f722        0t0   59425581 /var/run/openvswitch/db.sock type=STREAM
ovsdb-ser   746                   root   16u     unix 0x0000000021edd23e        0t0      12914 /var/run/openvswitch/db.sock type=STREAM
ovsdb-ser   746                   root   19u     unix 0x000000001b392a81        0t0      20287 /var/run/openvswitch/ovsdb-server.746.ctl type=STREAM

# ovs-vsctl list open_vswitch
_uuid               : 8cfeb1c0-34ca-4f91-a162-7e9aef141344
bridges             : [e65f5e97-36ec-45e3-b83e-64129dae61d3]
cur_cfg             : 65
datapath_types      : [netdev, system]
db_version          : "7.16.1"
dpdk_initialized    : false
dpdk_version        : none
external_ids        : {hostname="nuc8i7hvk01.burkholder.net", rundir="/var/run/openvswitch", system-id="02700cd5-96f5-4b4e-90b4-5e67fe06abf7"}
iface_types         : [erspan, geneve, gre, internal, "ip6erspan", "ip6gre", lisp, patch, stt, system, tap, vxlan]
manager_options     : []
next_cfg            : 65
other_config        : {}
ovs_version         : "2.10.1"
ssl                 : []
statistics          : {}
system_type         : debian
system_version      : []

# ovs-appctl dpif/show
system@ovs-system: hit:50661581 missed:207452
  ovsbr0:
    eno1 5/3: (system)
    enp5s0 2/1: (system)
    ovsbr0 65534/2: (internal)
    veth-nvpn-v90 6/6: (system)
    vlan110 4/5: (internal)
    vlan90 3/4: (internal)

# ovs-appctl dpctl/show -s
system@ovs-system:
  lookups: hit:50661616 missed:207458 lost:0
  flows: 6
  masks: hit:211426886 total:10 hit/pkt:4.16
  port 0: ovs-system (internal)
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1428 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:177489 (173.3 KiB)
  port 1: enp5s0
    RX packets:19439356 errors:0 dropped:0 overruns:0 frame:0
    TX packets:30374161 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:10608677166 (9.9 GiB)  TX bytes:29950322693 (27.9 GiB)
  port 2: ovsbr0 (internal)
    RX packets:333032 errors:0 dropped:29829 overruns:0 frame:0
    TX packets:1428 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:23060625 (22.0 MiB)  TX bytes:177489 (173.3 KiB)
  port 3: eno1
    RX packets:6037565 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5719808 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:4726094728 (4.4 GiB)  TX bytes:3277870100 (3.1 GiB)
  port 4: vlan90 (internal)
    RX packets:0 errors:0 dropped:274558 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:0
  port 5: vlan110 (internal)
    RX packets:0 errors:0 dropped:274101 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:0  TX bytes:0
  port 6: veth-nvpn-v90
    RX packets:5000388 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5788139 errors:0 dropped:0 aborted:0 carrier:0
    collisions:0
    RX bytes:3055006377 (2.8 GiB)  TX bytes:4647166781 (4.3 GiB)

IPv6 Transition and Coexistence IPv6 - only and IPv4 as - a - Service

You can use Jool for both 464XLAT and just NAT64.

Question:

Thanks... that is what I don't understand: Why is NAT64 such a difficult concept to put into routers and firewalls? We already do NAT with IPv4 just fine.

I feel like IPv6 adoption would be much faster if there was a transition mechanism other than dual stacking.

Think: Corporate offices. Rather than renumbering everything inside, they just turn on NAT64 and now they can begin a slow and controlled transition.

Answer:

This document, which is already in the IESG review, may answer your question: draft-ietf-v6ops-transition-ipv4aas

Also take a look into this one: draft-ietf-v6ops-nat64-deployment.

Remember that if your enterprise network has apps that use literals, or they don't support IPv6, you still need dual-stack in the LANs, but access IPv6-only is just fine.

Other comments:

It’s not s difficult concept but you need to remember NAT44 breaks stuff and NAT64/NAT46 breaks more stuff.

Dual stacking is SIMPLE. REALLY. Turn on IPv6 with the M bit set and configure the DHCPv6 server. If you don’t need that level of control of address assignments leave the M bit off. 99.99% of your machines will just add a second address to the interface without you having to do anything more.

Getting to IPv6 resources from IPv4 address is a *much* harder problem that getting to IPv4 resources from IPv6 which is what you are describing here with the “no renumber everything as they already have a IPv4 address” requirement. NAT64 allows IPv6 devices to get to legacy IPv4 servers. To allow IPv4 devices to get to IPv6 servers you need to map the IPv6 addresses you want to talk to in to a pool of IPv4 addresses and push that mapping to a NAT46 (not NAT64) device.

Go dual stack then, once IPv6 is stable, turn off IPv4 if you want to be single stacked. You are then no longer dependent on the services you want want to access continuing to be offered over IPv4. 464XLAT will only work as a stop gap for IPv4 clients while services are offered over IPv4. After ~20 years of IPv6 being available (Windows XP had IPv6 support and it was not the first major OS to have it) just turn on IPv6.

Some ideas from a mailing list:

quick and dirty:

jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time"
;; Query time: 16 msec
jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time"
;; Query time: 3 msec

Indeed. For instance, the delay depends wether the cache it hot or cold (measuring response time for an authoritative server is easier).

also could use ripe atlas ...

Which embeds clients for ICMP Echo, DNS, NTP, TLS, arbitrary TCP (with some hacks), and, with serious limitations, HTTP.

use dig -u to get microsecond resolution, e.g.

$ dig -u @131.111.8.42 nanog.org | grep time:
;; Query time: 611 usec

I recommend that eyeball networks don't run any external recursive server for optimal CDN performance. Yes, some CDNs support other methods, but not all. If not all do, then the requirement remains. See On Firefox Moving DNS to a Third Party

freeware GRC tool for benchmarking DNS performance

• PacketLife's Armory - encryption, exploitation, intrusion detection, forensics, vulnerability scanning, system monitoring, packet crafting, spoofing, ...
• IpCisco's Network Tools - packet analyzers, security audit, simulators, intrusion detection, ...
• packages found in Debian Linux for generating packets and sending, useful for testing openflow controllers: packeth, ostinato, netexpect, tgn (simpler netexpect), sendip, 4g8 (l2 interception)

• Telegeography.com
• Hurricane Electric
• Cablemap
• Submarine Cable Map

... from the mailing list:

//You can verify that OVS supports deletion by cookie specification by checking these tests:

 932: ofproto.at:1746    ofproto - del flows based on cookie
 933: ofproto.at:1767    ofproto - del flows based on cookie mask

// Run the tests using “make check” like this:
sudo make check TESTSUITEFLAGS='932-933' -C _gcc

//Look at what is being tested here:
tests/ofproto.at

Maybe you want to check what Ryu is sending the switch

http://www.openvswitch.org//support/dist-docs/ovs-ofctl.8.pdf

“OpenFlow Switch Monitoring Commands:
monitor switch [miss-len] [invalid_ttl] [watch:[spec...]]
Connects to switch and prints to the console all OpenFlow messages received. Usually, switch
should specify the name of a bridge in the ovs−vswitchd database.“

eg) ovs-ofctl monitor br0 65534 invalid_ttl --detach --no-chdir --pidfile 2> ofctl_monitor.log

• Routing In Fat Trees (rift): addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'. RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.
• Network Virtualization Overlay Solution using EVPN explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures
• Interconnect Solution for EVPN Overlay networks

For Android:

wifianalyzer for Android, shows what station IDs are on what channels, handles 2.4g and 5G connections, etc. Doesn't provide mapping, just shows "from where I am right know, what channels have which stations as what strengths?"

Nanobeam:

NanoBeam® AC is a directional antenna/radio integrated unit and is intended as a point to point or point-to-multipoint WISP client radio. The one feature you can get from it very cheaply is a directional, 2x2 MIMO 5.x GHz band spectrum analyzer that sees things *which are not 802.11 or wifi based. sample images

Highly useful for tracking down a specific source of non-wifi 5 GHz band interference. There's all sorts of random consumer grade things people can buy and introduce into an environment which do not broadcast MAC addresses or SSIDs, and do not show up on purely 802.11(abgn/ac) based tools.

It will of course also see hidden SSIDs and standard+non-standard 802.11abgn(ac) emitters.

There are also 2.4 GHz versions of similar products which will let you find non-802.11 emitters in the 2300 to 2500 MHz band. At $79 a lot less expensive than a "real" spectrum analyzer.

You can get DC PoE injectors for them which will connect to a Makita drill battery if you want to make it portable and wander around with a laptop.

Some entries on DDNS (Dynamic Domain Name Service). Standards based DDNS makes use of RFC 2136 as a specification.

• Updating DNS Entries (with nsupdate or alternative implementations) – Run Your Own DynDNS Service, with links to other related sites about DDNS. But dated back to 2013.
• SaltStack DDNS State: SaltStack is Python based, and uses a python library called dnspython to handle ddns updates.
• dnspython s a DNS toolkit for Python. It supports almost all record types. It can be used for queries, zone transfers, and dynamic updates. It supports TSIG authenticated messages and EDNS0.
• dnsupdate.py: a python successor to nsupdate.

As a side note, I need to keep this handy for another project: DNS in OpenVPN: a better approach, which discusses using multiple copies of dnsmasq, spread over several sites, for maintaining zone based queries. The most interesting aspect is that of including reverse .in-addr.arpa entries in the configuration files, something into which I need to look.

• Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose
• draft-palet-v6ops-p2p-from-customer-prefix-01: Using /64 from Customer Prefix for the Inter-Router Link
• Jool: an Open Source SIIT and NAT64 for Linux

From a listgroup:

• Paris Traceroute
• tcptraceroute

Traceroute on Linux/Unix boxes is generally using UDP by default. Try using ICMP, by adding the -I (capital i) option to traceroute:

traceroute -I 52.74.124.136

A TCP connection is uniquely identified by the combination of four numbers: The source IP address, the source port, the destination IP address and the destination port. You used the word session, but sessions happen above TCP in the stack and may use more than one TCP connection. Every packet in the connection contains all four numbers and no packet from any other connection contains the same four numbers.

If you want to track the connections, you capture the packets at each point in the path (router products have vendor-specific ways of doing this) and see which unique sets of the four numbers went through which router and router interface.

If you want to -test- which path a TCP connection -would- take, Ruairi's afore-mentioned tcptraceroute is the way to go. The regular traceroute with modern Linux servers also supports the "-T" flag which does the same thing. It works just like regular traceroute but uses synthetic TCP SYN packets instead of ICMP or UDP packets, allowing the packets to pass firewalls which would otherwise block the trace.

Bear in mind that in each case you will likely only see the path taken at the IP level. Underlying transits at the Ethernet or MPLS level are intentionally invisible to the endpoints.

In the data center context, enabling sFlow continuously captures packets from all paths and can be used to trace multi-path packet flows, whether layer 2 (MLAG/LAG), or layer 3 (ECMP). sFlow reports physical switch ports and captures Ethernet packet headers, so you can relate paths to MPLS labels, Ethernet headers, IP headers, TCP/UDP headers, VxLAN tunnels, etc.

The following article provides an example: Troubleshooting Connectivity Problems

Since I plan on using this similar combination in some upcoming configurations, I'll keep the reference here, and hopefully add details once I've worked through them.

• Using VLANs with OVS and libvirt by Scott Lowe back in 2012, referenced in an Replace Linux Bridge with Openvswitch on Ubuntu (an OVS mailing list entry).