1

R3--R1--Internet--R90

R3: ip addr 10.123.0.3
R1:

sudo ip l2tp add tunnel tunnel_id 699 peer_tunnel_id 699 encap udp local 5.254.174.8
remote 5.254.174.90 udp_sport 699 udp_dport 699
sudo ip l2tp add session tunnel_id 699 session_id 699 peer_session_id 699
sudo ip link set l2tpeth0 up mtu 1446
sudo ip link add brvlan699 type bridge
sudo ip link set l2tpeth0 master brvlan699
sudo vconfig add eth1 699
sudo ip link set eth1.699 master brvlan699
sudo ip link set brvlan699 up
sudo ip a add 10.123.0.1/24 dev brvlan699


R90:

ip l2tp add tunnel tunnel_id 699 peer_tunnel_id 699 encap udp local 5.254.174.90 remote 5.254.174.8 udp_sport 699 udp_dport 699
ip l2tp add session tunnel_id 699 session_id 699 peer_session_id 699

ip link set l2tpeth0 up mtu 1446
ip link add brvlan699 type bridge
ip link set l2tpeth0 master brvlan699
vconfig add eth1 699
ip link set eth1.699 master brvlan699
ip link set brvlan699 up
ip a add 10.123.0.90/24 dev brvlan699


So we have R1 10.123.0.1, R90 10.123.0.90, R3 10.123.0.3
every host can ping every. But R3->R90 or R90->R3 can ping only max ICMP packet size 1446 as mtu l2tpeth0 interface.
Why it dont fragment and send more packets? R1 can send even 15 000B ICMP to R3 or R90 through tunnel, but ping end-to-end through R1 only 1446, more is timeout. How to optimalise mtu and mss values for this tunnel with inside vlan and how to make it work for bigger packets with fragmentation?

  • ip link add brvlan699 type bridgev : what is type bridgev ? – philippe lhardy Sep 15 '14 at 20:08
  • is it something like : http://linuxexchange.org/questions/3390/bridge-drops-fragmented-packets ? – philippe lhardy Sep 15 '14 at 20:27
  • It is of course just "ip link add brvlan699 type bridge" I change in post above, I just made letter misstake here, in config it was good – Nico Zyrtec Sep 15 '14 at 20:29
  • i guess that problem is just that bridging interface with different mtu does not work well in general. http://linux-kernel.2935.n7.nabble.com/Revert-462fb2af9788a82a534f8184abfde31574e1cfa0-bridge-Sanitize-skb-before-it-enters-the-IP-stack-td863283.html ( see last posts ) : ' This problem wouldn't occur if all devices in a bridge were required to be compatible media; particularly identical MTU. ' – philippe lhardy Sep 15 '14 at 20:37

1 Answers1

0

http://wiki.openwrt.org/doc/howto/pseudowire

There is something for you there :

The bridge for the L2TPv3 contains devices with different MTU3 . Furthermore, as the connection is bridged no routing happens and the MTU is not automatically adjusted by the router. All devices in the LAN usually use a MTU of 1500. The MTU of the L2TPv3 devices is about 1400. As the tunnel itself can not fragment packets all packets bigger than the MTU are lost. (...) To solve the problem bridge firewalling and TCP MSS Clamping is used. Bridge firewalling means the iptables rules are used when a packet passes a bridge. Normally this should not work, as a bridge only works in Layer 2. However, if bridge firewalling is enabled in the kernel a bridge can work in Layer 2 as well as Layer 3.

  • Looks like nothing works... I add this: iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu or this iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1448:1536 -j TCPMSS --set-mss 1448 to /etc/sysctl.conf this: net.bridge.bridge-nf-filter-vlan-tagged = 1 and it didnt solve problem. When I change every interface to mtu 1500, max ping that I can send is 1472data + 8header = exactly 1500B. 1501 already is timeout – Nico Zyrtec Sep 15 '14 at 21:46
  • 1
    I made it work with: net.bridge.bridge-nf-filter-vlan-tagged = 0 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0
    And set on every interface mtu 1500. There is bug in debian/ubuntu with load this paramets, and after every restart I need to run command "sysctl -p" after this it starting to send big packets... http://serverfault.com/questions/431590/how-to-make-sysctl-network-bridge-settings-persist-after-a-reboot
    – Nico Zyrtec Sep 16 '14 at 00:04