Category: Uncategorized

IPv6 + Flow labels

Recently a teammate and I have come across a frame forwarding issue with ECMP on a hardware ASIC in a device I work on where the use of Flow labels are used in the ECMP hash. This was interesting as we found iperf was not setting the Flow label at all, unless you specify the -L option and due to this we saw TCP traffic taking different paths, contradictory to what we thought we had configured in our FIB and what we actually wanted.

This sparked interest in me then wondering how popular platforms set the IPv6 Flow label for the different protocols; that being, ICMPv6, TCP and UDP. The Flow label being at Layer 3, I would expect it used the same for each protocol, but I could not find literature to back this theory up. So I fired up Wireshark on Mac, Linux and Windows to find out what they do. Here are my results I found.

If you want to know more about what Flow Labels are I would reccomened the following links:

  • Wikipedia: https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header
  • RFC: https://tools.ietf.org/html/rfc6437

Summary

With each protocol the client and the server maintained consistent Flow labels for the ‘session’ as expected, except for Windows with ICMPv6 Requests! Here Windows set the Flow label to 0 (0x00000000).

Tests Performed

To get my results I ran:

  • ping6 -c 2 us.cooperlees.com
    (ICMPv6)
    – ping -6 us.cooperlees.com on Windows
  • ssh -6 us.cooperlees.com
    (TCP)
    – Used putty on Windows
  • Raw NTP UDP Query
    Python 3 Code: https://pastebin.com/RDBRqG0G
    (UDP)

Linux

Test Distro: Ubuntu 18.04
Test Kernel: 4.15.0-23-generic

ICMPv6
– Different Flow label, but consistent for the 2 ping packets on each ICMPv6 Type 128/129 packet from sender and receiver

TCP
– Different Flow label for sender and receiver but consistent across the SSH connection.

UDP
– Different Flow label for sender and receiver for each UDP packet as expected.

Mac OS X

Test Version: 10.13.6 17G65
Test Kernel: Darwin Kernel Version 17.7.0

ICMPv6
– Different Flow label, but consistent for the 2 ping packets on each ICMPv6 Type 128/129 packet from sender and receiver

TCP
– Different Flow label for sender and receiver but consistent across the SSH connection.

UDP
– Different Flow label for sender and receiver for each UDP packet as expected.

Windows

Test Version: Microsoft Windows [Version 10.0.16299.371]

ICMPv6
– Windows sets the ICMPv6 Type 128 (request) IPv6 Flow label to 0x00000000!
(I also noticed different DSCP for traffic class)

TCP
– Different Flow label for sender and receiver but consistent across the SSH connection.

UDP
– Different Flow label for sender and receiver for each UDP packet as expected.

NXOS Simple IPv6 BGP Peering

It took me far to long to find out how to config this, so I’m sharing it to be more searching on the Internets.

Scenario:

– NXOS BGP ‘upsteam’ / ‘north bound’ peer sharing the default route only
– Linux box runs Quagga sharing it’s /56 routable behind it

Nexus Conf

feature bgp

router bgp 65170
  router-id 69.69.69.70
  address-family ipv6 unicast
    network 0::/0
  neighbor 69::69 remote-as 65169
    address-family ipv6 unicast

 

Quagga Conf

bgp.conf:

router bgp 65169
 bgp router-id 69.69.69.69

 neighbor 69::1 remote-as 65170

 address-family ipv6 unicast
  network 2400:0000:0000:6900::/56

 neighbor 69::1 activate

log file /var/log/bgpd.log
log stdout

Python pip ‘editable’ installing

From time to time I get asked (and I even have to ask a coworker) for the best way to install a Python modules (especially ones with entry points) into a virtualenv and still edit / develop with them. It seems ​pip install‘s ‘-e’ is very unknown.

pip install -e /path/you/are/editing

Will allow you to develop and run with all dependencies install in your virtualenv.

Happy dev’in!

 

GitHub + Rebasing from upstream/master to origin/master

So, every now and then on a PR I need to rebase and fix things so I can retest etc. – I always forget this so blogging it to remember.

Scenario:

I have a diff on origin/master on my forked repo and I need a rebase from upstream/master (where I forked from).

Process:
Github recommends merging (https://help.github.com/articles/syncing-a-fork/), this is not always the best way. I do the following:

  1. git remote add upstream https://github.com/python/cpython.git
  2. git fetch upstream master
  3. git rebase upstream/master (no space here ‘/’ instead)

I hope this saves you some time as I continually waste time here.