Networks

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

• 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).

The question:

What is the best way to model quota through ovs? Right now the best thing we could come up with is to periodically poll a flow stat and install a drop flow when the flow stat goes past the quota.

The answer given (which provides some food for thought on better mechanisms):

Open vSwitch includes sFlow / NetFlow instrumentation. Using flow data to drive your quota controller reduces the complexity of the OpenFlow rules since you no longer need granular rules to provide the traffic measurements.

The following article describes building a quota controller using sFlow:

Real Time Visibility and Control

Bypassing OpenFlow controller and injecting flow table entries via a code call:

> Can someone refer to the code where a  new flow is inserted to
> openflow tables in the OVS, as a consequence action of a received
> message from a controller?

handle_flow_mod() in ofproto.c

Another similar request:

> My project was previously calling system commands like ‘ovs-ofctl add-flow’ directly from C, 
> but we would like to do this programmatically now, by calling into the openvswitch library. 
> After looking at this for a bit and what methods I would have to call, I’ve realized this is 
> non trivial, and I can’t find any easily exposed methods to add and delete flows. 
> Does anyone have an example anywhere of calling into openvswitch methods 
> directly to add/remove flows? So far the best way I can find is calling into 
> ovn/controller/ofctrl.h:ofctrl_add_flow(…), but this will require quite a bit of legwork.

One way:

There are plenty of controllers out there, including a couple in C - libfluid

Another way:

Here’s how I do it.  It’s essentially the same as what the ‘ovs-ofctl add-flow’ command does under the hood.

1. Build a string formatted as the “ovs-ofctl” command would do, 
         for example “table=1,cookie=0xdeadbeef,in_port=1,actions=resubmit(,2)”
2. Pass this to parser_ofp_flow_mod_str().  The parser will magically parse the string in to a rich struct.
3. Pass the struct to ofputil_encode_flow_mod().  This returns a struct with a serialized OpenFlow message buffer.
4. Send this buffer on the wire either via a socket you manage yourself or let OpenVswitch do it for you.

Added 2017/11/13, the second link shows a terrific example usage for ovs-dpctl

> I have a problem that when i use the ovs-dpctl to add a flow into datapath, 
> it occurs "ovs-dpctl: parsing flow key (Invalid argument)"
>
>     example:
>    root@jlt:~# ovs-dpctl add-flow system@myDP "in_port(1),eth_type(0x800),ipv4
> (src=172.31.110.4,dst=172.31.110.5)" 2
> ovs-dpctl: parsing flow key (Invalid argument)

You may be able to use 'dmesg' to see which key is missing.

See the talk by Joe Stringer:
Youtube

And the blogpost (shameless plug for myself):
Direct Kernel OVS Flow Programming

A follow up from Ben indicated though:

I believe that this particular error comes from the userspace parser, not the kernel.

Another addition on 2017/11/13:

> For us, newbies, examples are extremely valuable, more than a thousand
> words.
> If some kind soul has an example on how to insert a new interface (s1-eth3)
> in a single switch (s1) with two interfaces (s1-eth2 and s1-eth3) please
> share with me.

If you run something like this:
        ovs-vsctl -vjsonrpc -- add-bond s1 s1-eth3 s1-eth2 s1-eth3
then you will see what ovs-vsctl does to insert such a bond, logged as
the jsonrpc module.

2017/11/25 Addition 1:

ovs-save is a shell script, using `ovs-ofctl dump-flows br` to write flows
into a file, and then use `ovs-ofctl add-flows br FILE` to add them.

2017/11/25 Addition 2:

The OpenFlow Spec does not directly provide the mechanism for the multi-path load balancing and also Ryu does not provide it. I guess it is depending on your application design...

But for the beginning, how about using the Group action(the "select" type)? The selection algorithm is depending on your switch though, it provides an easy way to do load balancing.

Please refer to the section "5.6.1 Group Types" in the OpenFlow Spec 1.3.5 for the details: https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.3.5.pdf

2017/12/07 dpctl: Support flush conntrack by 5-tuple

With this patch, "flush-conntrack" in ovs-dpctl and ovs-appctl accept a conntrack 5-tuple to delete the conntrack entry specified by the 5-tuple. For example, user can use the following command to flush a conntrack entry in zone 5.

$ ovs-dpctl flush-conntrack zone=5 \
    'ct_nw_src=10.1.1.2,ct_nw_dst=10.1.1.1,ct_nw_proto=17,ct_tp_src=2,ct_tp_dst=1'
$ ovs-appctl dpctl/flush-conntrack zone=5 \
    'ct_nw_src=10.1.1.2,ct_nw_dst=10.1.1.1,ct_nw_proto=17,ct_tp_src=2,ct_tp_dst=1'

2018/06/11: "I suggest using ofproto/trace to figure out what's going on. See ovs-vswitchd(8) if you're not already familiar with it."

2018/06/11: "You can see the history of the configuration database by running "ovsdb-tool -mm show-log" on it. This might reveal what is happening, too."

"ovs-vsctl --may-exist add-port {{ info.ovs_bridge }} {{ interface }} {{ info.ovs_options }} -- set interface {{ interface }} type=internal"

A Check_MK plugin which is supplied as part of the standard install but not 'turned on' is the 'smart' agent. It is a plugin which resides on the target with hard-drives to be monitored. Temperatures and other useful statistics can be collected.

The plugin can be found in the share/check_mk/agents/plugins/ directory amongst a number of other useful plugins.

It needs to be copied to the /usr/lib/check_mk_agent/plugins/ directory on the target to be monitored.

In order to be useful, the 'smartmontools' package needs to be installed as a pre-requisite.

On one of my systems, I get output some output similar to:

SMART WDC_WD1003FZEX-00K3CA0_WD-WCC6Y3PN9XKC Stats
  OK - Powered on: 3529 hours, Power cycles: 51, Reallocated sectors: 0, 
  Reallocated events: 0 (was 0 during discovery: normalized value looks OK), 
  Spin retries: 0, Pending sectors: 0, UDMA CRC errors: 0
Temperature SMART WDC_WD1003FZEX-00K3CA0_WD-WCC6Y3PN9XKC
  OK - 30 °C

Values are charted as well.

To get at various hardware sensors like temperatures and voltages, it is typically necessary to install the 'lm-sensors' package. Once the package is installed, sensors can be auto-detected with:

sensors-detect --auto

A variation of that is:

yes | sensors-detect

At the end of the output, this will probably generate an output similar to:

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
coretemp
#----cut here----

'modprobe coretemp' can be used to obtain instant gratification by loading the module interactively, instead of at the next reboot.

On a simple system, some values can be seen:

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +27.8°C  (crit = +105.0°C)
temp2:        +29.8°C  (crit = +105.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +50.0°C  (high = +105.0°C, crit = +105.0°C)
Core 0:        +49.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:        +48.0°C  (high = +105.0°C, crit = +105.0°C)

For obtaining an output suitable for scraping by a check_mk agent, a different format can be emitted:

# sensors -u
acpitz-virtual-0
Adapter: Virtual device
temp1:
  temp1_input: 27.800
  temp1_crit: 105.000
temp2:
  temp2_input: 29.800
  temp2_crit: 105.000

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:
  temp1_input: 49.000
  temp1_max: 105.000
  temp1_crit: 105.000
  temp1_crit_alarm: 0.000
Core 0:
  temp2_input: 48.000
  temp2_max: 105.000
  temp2_crit: 105.000
  temp2_crit_alarm: 0.000
Core 1:
  temp3_input: 48.000
  temp3_max: 105.000
  temp3_crit: 105.000
  temp3_crit_alarm: 0.000

While writing this article, a few interesting web sites were encountered:

• Arch Linux' Sensors Page
• Plugins for Check_MK
• Check_MK plugin: lmsensors: a place to which I need to return and try installing his plugin for more information display in Check_MK.
• Earlier Article I wrote doing something similar but different.

I use an app called 'psensor' for watching system temperatures in a chart form.