Understanding traffic on WAN vs WAN6 (6in4)

Since we didn't ask it, could you post the network config, just in case?
Also I would reset the counters and run some iptraf at the same time to check for consistency.

1 Like
ifconfig -a; uci show network

ifconfig -a; uci show network

6in4-henet    Link encap:IPv6-in-IPv4
          inet6 addr: 2001:470:xx:zzzz::2/64 Scope:Global
          inet6 addr: fe80::8b14:4613/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1280  Metric:1
          RX packets:8180150 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3460167 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:9496385625 (8.8 GiB)  TX bytes:651770369 (621.5 MiB)
                       
br-lan    Link encap:Ethernet  HWaddr xx:xx:xx:3C:69:C3  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::xxxx:xxff:fe3c:69c3/64 Scope:Link
          inet6 addr: 2001:470:xxyy:1::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:171382 errors:0 dropped:11 overruns:0 frame:0
          TX packets:340453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:14475119 (13.8 MiB)  TX bytes:428669991 (408.8 MiB)

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:3C:69:C3  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:5 

eth1      Link encap:Ethernet  HWaddr xx:xx:xx:3C:69:C5  
          inet addr:x.x.x.x  Bcast:x.x.x.255  Mask:255.255.255.0
          inet6 addr: fe80::xxxx:xxff:fe3c:69c5/64 Scope:Link
          inet6 addr: 2001:470:xy:zzzz::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12273968 errors:0 dropped:22929 overruns:281 frame:0
          TX packets:11369625 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1996874844 (1.8 GiB)  TX bytes:1378747354 (1.2 GiB)
          Interrupt:4 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:31 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:3263 (3.1 KiB)  TX bytes:3263 (3.1 KiB)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr xx:xx:xx:3C:69:C4  
          inet6 addr: fe80::xxxx:xxff:fe3c:69c4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:171379 errors:0 dropped:0 overruns:0 frame:0
          TX packets:340518 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:16874407 (16.0 MiB)  TX bytes:437826076 (417.5 MiB)

network.loopback=interface
network.loopback.ifname='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.lan=interface
network.lan.ifname='eth0'
network.lan.force_link='1'
network.lan.type='bridge'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6addr='2001:470:xxyy:1::1/64'
network.lan.ip6prefix='2001:470:xxyy:1::/64'
network.wan=interface
network.wan.ifname='eth1'
network.wan.proto='static'
network.wan.ipaddr='x.x.x.x'
network.wan.netmask='255.255.255.0'
network.wan.gateway='x.x.x.xyz'
network.wan.dns='x.x.x.y x.x.x.z'
network.wan.ip6addr='2001:470:xy:zzzz::1/64'
network.wan.ip6prefix='2001:470:xy:zzzz::/64'
network.@switch[0]=switch
network.@switch[0].name='switch0'
network.@switch[0].reset='1'
network.@switch[0].enable_vlan='1'
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device='switch0'
network.@switch_vlan[0].vlan='1'
network.@switch_vlan[0].ports='0 1 2 3 4'
network.henet=interface
network.henet.proto='6in4'
network.henet.ipaddr='x.x.x.x'
network.henet.peeraddr='216.66.86.114'
network.henet.ip6addr='2001:470:xx:zzzz::2/64'
network.henet.sourcerouting='0'
network.henet.ip6prefix='2001:470:xxyy::/48 2001:470:xy:zzzz::/64'
network.@route6[0]=route6
network.@route6[0].interface='henet'
network.@route6[0].source='2001:470:xy:zzzz::/64'
network.@route6[0].target='::/0'
#/etc/config/network
     
config interface 'loopback'
     option ifname 'lo'
     option proto 'static'
     option ipaddr '127.0.0.1'
     option netmask '255.0.0.0'

config globals 'globals'

config interface 'lan'
     option ifname 'eth0'
     option force_link '1'
     option type 'bridge'
     option proto 'static'
     option ipaddr '192.168.1.1'
     option netmask '255.255.255.0'
     option ip6addr '2001:470:xxyy:1::1/64'
     option ip6prefix '2001:470:xxyy:1::/64'

config interface 'wan'
     option ifname 'eth1'
     option proto 'static'
     option ipaddr 'x.x.x.x'
     option netmask '255.255.255.0'
     option gateway 'x.x.x.xyz'
     option dns 'x.x.x.y x.x.x.z'
     option ip6addr '2001:470:xy:zzzz::1/64'
     option ip6prefix '2001:470:xy:zzzz::/64'

config switch
     option name 'switch0'
     option reset '1'
     option enable_vlan '1'

config switch_vlan
     option device 'switch0'
     option vlan '1'
     option ports '0 1 2 3 4'

config interface 'henet'
     option proto '6in4'
     option ipaddr 'x.x.x.x'
     option peeraddr '216.66.86.114'
     option ip6addr '2001:470:xx:zzzz::2/64'
     option sourcerouting '0'
     option ip6prefix '2001:470:xxyy::/48 2001:470:xy:zzzz::/64'

config route6
     option interface 'henet'
     option source '2001:470:xy:zzzz::/64'
     option target '::/0
1 Like

What are these doing under WAN interface?

1 Like

Assigning the WAN interface an IPv6 address from the delegated prefix, and also defining the prefix that is used in that network segment (remember: the box is only connected to my network via the WAN interface and acts solely as an IPv6 gateway. Well, lan/wifi bridge interface is also usable, but that's just bonus). Should the WAN interface not be assigned an IPv6 address?

With whom will the WAN interface communicate with this IPv6?
Moreover I don't see any reason using the ip6prefix option since you are not delegating anything under this interface. The same applies to LAN interface.

2 Likes

Hm, it will communicate with this IP with the internet or other devices in this network segment. For the latter the link-local fe80::/64 will work as well, of course, but assigning an additional IPv6 shouldn't matter.
But I am delegating IPv6 addresses on this interface. The WAN-interface (or eth1 for that matter) is connected to the switch that the other machines that I want to get IPv6 addresses also connect to. So IPv6 is distributed via WAN interface. Another IPv6 subnet/prefix is distributed to clients connected to the LAN interface.
If I remove ip6prefix or even just ip6addr all clients connected to WAN lose IPv6 connectivity (and SLAAC also stops working), even though the gateway on manually configured IPv6 clients is set to the fe80:: address, so also routing is ignored.

First things first. With the current setup you are not delegating anything. In order to delegate some network you need to provide a different prefix and you have defined the same. The same applies to both LAN and WAN.
Second if you have connected clients on WAN interface that use the IPv6 connection to communicate with each other could explain the extra traffic on the HEnet interface.
Third the RA and DHCPv6 are defined in /etc/config/dhcp so if it doesn't work properly maybe you have something wrong there.

Keep in mind that IPv6 (mostly) ignores interface metrics, making the routing decision based on the longest common (prefix-) match instead.

@trendy Ok, the term delegating was wrong. But I am advertising on the interfaces. Since HENET is a virtual interface, you can't physically connect a device, apparently. Let me list the setup of prefixes more simplified:
HENET -> 2001:470:xx:zzzz::/64
WAN -> 2001:470:xy:zzzz::/64 <- this is a different prefix than above, and is routed by HE to my tunnel endpoint.
LAN -> 2001:470:xxyy:1::/64 <- this prefix is out of my additional 2001:470:xxyy::/48

So, I have a /64 and a /48, which both are routed by HE to my tunnel. Then there another /64 which is used for communication between HE and my tunnel endpoint, where HE has 2001:470:xx:zzzz::1/64 and my tunnel endpoint has to be set to 2001:470:xx:zzzz::2/64.

If the clients communicate via HENET interface, they are still first connected to the WAN interface, so traffic still would have to go to WAN first. Also, if they are communicating with each other they should be able to do that directly using link-local addresses or even the public ones, but traffic should flow only through the switch, and not the OpenWrt box.

Yes, you define if you wanna use RA inside dhcp config, but the prefix that is used for RA seems to be taken from network config. At least I don't see any option for odhcpd/dhcp to define the desired prefix.

@slh true. But how would that affect what I observed? It IPv6 traffic goes through the OpenWrt box, it would still need to enter it through the WAN interface first.

You have a point on that. So I guess the only thing left is to sniff the interface and see what is causing all these packets.

You should use the ip6assign to delegate a prefix from the pool you have from HE and ip6hint to add to the subprefix, in your case the :1: for the LAN.
Regardless of that the ip6prefix option is for prefixes routed on this interface for use in other interfaces.

1 Like

I have just updated my LEDE install to the most current LEDE snapshot (17.01). The traffic quota seems to be counted correctly now.

Too soon: after one night it's off again :smiley: I give up. But I also don't really care anymore...

1 Like

Now on 17.01.07 / kernel 4.4.194 the problem really seems gone ^^ WAN counts correctly now :slight_smile:

ARRRG, AGAIN not really...BUT, the problem is not the counting...for some reason, WAN traffic stats got reset (was previously more than 5 GB, now back to 1 GB), but uptime of interface didn't change. So no idea what caused the reset. But in general the counts are getting added correctly.

Now on 19.07-snapshot and a new device (ramips), kernel 4.14.193, WAN doesn't seem to get reset anymore.