IPv6 deployment at a university and research organization (German slides)

I presented our IPv6 deployment at Karlsruhe Institute of Technology at a meeting of the Benutzergruppe Netzwerke today. I touched the subjects of mentality, security, addressing concepts, and hardware feature sets. No device we use satisfies all our wishes that we have, feature-wise. The slides are available, however be aware that they are in German.

IPv6 neighbor discovery on Nexus 7000

If you attach multiple devices directly to a Nexus 7000 switch and expect them to communicate with each other over IPv6 in the same VLAN, you really want to set no ip igmp snooping optimise-multicast-flood. Otherwise they can communicate with the L3 interface on the switch, but not with the others. All your attempts to do neighbor discovery fail, as this runs over multicast and non-IPv4 multicast is dropped due to this setting. Sadly it's on by default, so you need to apply this fix on any Nexus 7k where you want to do serious IPv6 switching on.

IPv6 PBR on Catalyst 6500

The lesson of the day is: Better avoid IPv6 PBR on Cisco Catalyst 6500. It will be handled in software on Sup720/VSS720 if you assign a policy route-map to a Switch Virtual Interface (SVI) according to the documentation. Which only leaves routed ports as ones where hardware switching is supposed to happen. L3 VLAN interfaces and sub-interfaces are both SVIs and hence all IPv6 traffic that matches the PBR rules will be punted to the RP. The Sup2T supervisor does not support IPv6 PBR at all at this time.

Google's IPv6 blacklist

If you're not seeing AAAA records for Google's main services, then your DNS resolver might be blacklisted. It seems that Google tries to measure the penalty IPv6 imposes on their users and employs retaliation if it's not happy with it. Sadly they won't contact the affected networks and just stuff the address onto this list. There's also no rationale why that happened. It seems that one can ask google-ipv6@google.com and get a reply, though.

It also seems that this list is perused by other entities like Akamai and Facebook, because people on the blacklist report that the AAAA records of those providers vanished for them, too. The whole discussion thread can be found in the ipv6-ops archives.

ECN and D-Link switches

Apparently even today manufacturers of network devices fail to cope with technologies introduced a decade ago. If your host has ECN enabled unconditionally, D-Link switches won't let you connect to their web interface. At least the DGS-1210-16 I have here won't. With the newest firmware, too.

Now of course this is my own fault, given that I've switched the ECN mode away from the default "ECN server mode", i.e. advertise it, but don't use it for client connections, to "Use ECN". Still, given that RFC 3168 dates back to 2001, one would assume that network endpoints can deal with those bits (ECN and CWR) being set now. Especially as the RFC tells how to decline the usage of ECN when being the server. Instead you get back a TCP reset (RST=1, ACK=1). Thank you very much, D-Link.

Linux bridging will drop too big packets marked with DF

It should be obvious, but Linux will drop packets on the floor if you try to bridge packets marked as Don't Fragment (DF) which are too big for the interface. If you set a MTU on a bridge the setting will propagate to all the attached bridge links. A Linux bridge is a simple L2 device, even if you can assign an IP address to a virtual host port on the bridge. Hence, given that it does not actually routes packets, there's no place to generate the ICMP Destination Unreachable error messages that are needed to get Path MTU Discovery to converge to the right value. As long as you route instead, you're fine.

TCP streams like HTTP and SSH data transfers between my laptop and my home workstation have the DF bit set, because that's a part of RFC 1191 used for proper Path MTU Discovery. As my OpenWRT-based router had a lower MTU than the default of 1500, the communication was dropped as soon as there was a bulk of data to transmit. Interactive SSH sessions worked just fine. An easy way to debug this is to run tracepath(6) against the target. It will stop at the first hop that just drops packets instead of emitting proper error messages.

Slots on Cisco ASA 5550

According to the Cisco product description of the ASA 5550 the appliance has a maximal throughput of "up to 1.2 Gbps". It's pretty common for Cisco to measure throughput in interesting ways. Mostly they'll add up RX and TX and mention the combined bandwidth. In this case this means that you're likely to be capped at somewhere around 600 Mbps of bi-directional traffic.

One thing you really have to watch out for, to get more out of that particular appliance, is balancing the traffic across its two slots. You can issue show traffic on the CLI which gives you the current balance at the end of its output. If you're just using one of the two slots and your CPU usage is at 100% you'll experience packet loss despite the fact that there's still some free capacity. It seems that the CPU is blocked too much waiting for the queues to get free at this point, when trying to send back traffic to where it came from. Using both slots the CPU usage went back to 50% which seems much more reasonable.