0

i am trying to mirror "all" network traffic from one interface with the help of tc trough an GRE-Tunnel tun0. The GRE-Tunnel is working fine, i can ping and send packets trough it without any problems. I added the tc-qdisc and tc-filter with the following commands:

tc qdisc add dev ens5 ingress

tc filter add dev ens5 parent ffff: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0

and

tc qdisc add dev ens5 handle 1: root prio

tc filter add dev ens5 parent 1: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0

like in this Tutorial

Problem

The Problem is that only ingress traffic is coming through the GRE-Tunnel. When i ping another computer over interface ens5 than i only get the icmp echo replies through the tun0 interface. What am i doing wrong?

Debug

ubuntu@switch:~$ tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:23:28.952197 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 1, length 64
10:23:29.954454 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 2, length 64
10:23:30.952864 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 3, length 64
10:23:31.953207 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 4, length 64
10:23:32.955350 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 5, length 64
10:23:33.957000 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 6, length 64
10:23:34.956313 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 7, length 64
Florian
  • 29
  • 6

2 Answers2

2

Solved the Problem by myself.

tc mirrors the egress traffic with the Ethernet-Header and the ingress traffic without Ethernet-Header The GRE-Tunnel expects only IP-Packets, so there was an header-mismatch. If i am using VXLAN instead of GRE it works fine.

Florian
  • 29
  • 6
  • How did you accomplish sending the mirrored traffic over a tunnel? Every time I apply the egress snippet to a GRE or VXLAN tunnel, the Linux host locks up. Internal snippet works fine. Have tried a couple different distributions. – Astron May 12 '17 at 03:11
  • 1
    I created a VXLAN and thereby i added a tunnel interface tun0. Then i used the exact commands as above. For Example: `ip link add vxlan0 type vxlan id 42 group 1.1.1.1 dev eth0` – Florian May 16 '17 at 08:11
  • Strange, specifying tun0 verse something like vxlan42 for the device name was causing the crash. – Astron May 17 '17 at 15:22
  • I think tunX is reserved for tun/tap devices. Maybe the problem is, that a linux tun device is on OSI-Layer 3 and VXLAN is on Layer 2. But I am not really sure about this. – Florian May 19 '17 at 10:29
  • I believe you are correct. I tried again using vxlan42 and it worked. – Astron May 23 '17 at 00:15
0

I never worked with GRE-Tunnels, but based on the Tutorial link you posted, it has something to do with bridge interfaces? I'm currently also working with Linux Traffic Control (tc) on a bridge interface - in my case it is a bridge created by Docker and I have to manipulating the traffic (not only redirecting it).

Based on my experience, I can tell you that tc is not working like expected when you are adding tc classes/filters to a bridge interface. It is mostly based on the definition of ingress and egress traffic on a bridge, which is (for me) very confusing. I also tested my configuration of tc with the ICMP-Ping functionality and like you I was also only able to manipulate the ICMP reply.

My assumption was that tc is not reacting to the ICMP request, as in my case, it was only switched between the bridge ports and not routed. I was able to handle the ICMP request with tc by dropping it with the ebtables (http://ebtables.netfilter.org) and therefore forced it to being routed instead of being switched between the bridge ports.

Still I’m not sure if this will be the solution to your problem, as I’m not sure how GRE-Tunnels work, or how they are implemented.

Melonski
  • 35
  • 2
  • 5
  • Thanks for the reply, i dug a little deeper and the problem was, that the tc filter was mirroring the packages with the Ethernet-Header. So all missing packets had were corrupted, because there was an Ethernet-Header instead of an expected IP-Header – Florian Dec 15 '16 at 13:01