Traceroute support¶

Problem Description¶

The virtual routers in Dragonflow don’t support traceroute well. When a detecting packet of traceroute goes through virtual router, you will most likely get an asterisk from traceroute’s output. That means traceroute doesn’t get the expected response from router. More details will be provided in the following description.

Proposed Change¶

Supporting traceroute is to support the network functionalities behind it. Traceroute mainly depends on the TTL(Time To Live) field in the Internet Protocol. Traceroute will send IP packets with increasing TTL and expect each router in the network path to reply with an ICMP Time Exceeded message. By using that message, traceroute can know the information of router in the network path.

For each router, that will require it to decrease TTL of IP packets when it routes them. Meanwhile, that will also require each router to discard the original IP packet and reply an ICMP Time Exceeded message, when the TTL is invalid. An invalid TTL means its value is not bigger than zero. The details are defined at RFC1812 [RFC1812].

There are 3 kinds of implementations of traceroute. They are based on UDP, TCP and ICMP respectively. Different implementations send different IP packets to detect the network packets. For UDP implementation, traceroute expects the destination to return an ICMP Destination Unreachable Message. For TCP implementation, traceroute expects the destination to return an ICMP Destination Unreachable Message or a SYN/ACK packet. For ICMP implementation, traceroute expects the destination to return an ICMP echo reply.

Since it is distributed virtual routers in Dragonflow, there is no concrete router ports. If the destination of traceroute is virtual router ports, they should response with ICMP Destination Unreachable Message.

The ICMP error message should contain at least 28 bytes of original datagram’s data, according to RFC792 [RFC792]. And traceroute depends on the original datagram’s data to match the detecting IP packets. So the virtual routers in Dragonflow should also copy the data to the ICMP messages mentioned above.

The virtual routers in Dragonflow are also NAT(network address translation) devices. The NAT here refers to one-one NAT, which is floating IP in Dragonflow. As mentioned above, the ICMP error message will contain original datagram’s data. It is an embedded packet. According to RFC5508 [RFC5508], NAT devices should also revert the IP of embedded packet. Or else, it will be an invalid ICMP packet. Since the header embedded packet will change, its checksum will be re-calculated when encoded.

A valid ICMP Time Exceeded message should looks like:

02:58:24.390013 IP (tos 0xc0, ttl 63, id 55039, offset 0, flags [none], proto ICMP (1), length 74)
    172.24.4.1 > 20.0.0.12: ICMP time exceeded in-transit, length 54
        IP (tos 0x0, ttl 1, id 6596, offset 0, flags [DF], proto UDP (17), length 46)
        20.0.0.12.51016 > 192.168.31.94.33438: UDP, length 18

priority=high,icmp,nw_dst=fip,icmp_type=11 actions=mod_dl_src:gw_mac,mod_dl_dst:vm_mac,dec_ttl,mod_nw_dst:vm_ip,(packet-in controller)
priority=high,icmp,nw_dst=fip,icmp_type=3 actions=mod_dl_src:gw_mac,mod_dl_dst:vm_mac,dec_ttl,mod_nw_dst:vm_ip,(packet-in controller)

priority=high,icmp,metadata=network_uid,nw_src=vm_ip,icmp_type=11 actions=mod_dl_src:fip_mac,mod_dl_dst:br-ex_mac,mod_nw_src:fip,(packet-in controller)
priority=high,icmp,metadata=network_uid,nw_src=vm_ip,icmp_type=3 actions=mod_dl_src:fip_mac,mod_dl_dst:br-ex_mac,mod_nw_src:fip,(packet-in controller)

priority=high,tcp,metadata=network_uid,nw_dst=router_port_ip actions=(packet-in controller)
priority=high,udp,metadata=network_uid,nw_dst=router_port_ip actions=(packet-in controller)

Implementation¶