Problem on ccr1036 ppoeserver

İm using ccr1036 for ppoeserver with 510 pppoe client and dynmic que, and sending ppoe clients to pppoeserver over eoip with auto mtu(1458mtu) both side.. Problem is on videos, when customer enter speedtest.net and test internet they can take full speed without problem. But when try to watch video from youtube or another site, video not loading. İts stop and start again. What can be the problem ?

Thanks

no any answer ?

Possibly your MTU is too high - because you’re doing encapsulation within encapsulation.
Path MTU Discovery is supposed to handle this situation, but unfortunately, blocking all ICMP is still a common practice so it doesn’t always work.

I’m sure you’ve checked CPU utilization, etc.

Thnkx ZeroByte,

Possibly your MTU is too high

which mtu is high ? eoip mtu is at auto. for sending customers ppoe connections to pppoe server from omniTiK, i create eoip tunnel betwen ppoeserver and omnitik then i bridge eoip tunnel and wlan interface. after this I create new pppoe service on ppoe server and selecet interface eoip for this.

If you control your network end-to-end (no carrier-provided circuits) and your L2MTU is big enough everywhere, you could raise the IP MTU by the amount of the overhead introduced by EoIP (I forget the exact number now, but I’m sure a quick google / forum / wiki search could answer that). You could also add the 4 bytes of PPPoE and deliver true 1500-byte MTU all the way to the customers - but only if all of your network supports it.

A quick way to test whether this is even the issue would be to configure a test “customer” connection to use a smaller MTU and make sure that clamp-mss is enabled. If this “customer” doesn’t have any more problems, then this is the issue. If nothing changes, then it’s probably not an MTU issue.

Hİ,
here is what im doing on ppoe server;
/interface pppoe-server server
service-name="BaseOmniTiK" interface=172.17.30.21 max-mtu=1480 max-mru=1480 mrru=1600 authentication=pap keepalive-timeout=10 one-session-per-host=no max-sessions=unlimited pado-delay=0 default-profile=default

/interface eoip
name="172.17.30.21" mtu=auto actual-mtu=1458 l2mtu=65535 mac-address=02:8C:F6:FB:A2:8F arp=enabled local-address=172.17.30.1 remote-address=172.17.30.21 tunnel-id=3021 keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=no

/ppp profile
name="default" local-address=172.17.30.1 remote-address=NewPool use-mpls=no use-compression=default use-encryption=default only-one=yes change-tcp-mss=yes use-upnp=default queue-type=wireless-default address-list="" dns-server=8.8.8.8,8.8.4.4 on-up="" on-down=""

On Omnitik;
/interface eoip
R name="ppp301" mtu=auto actual-mtu=1458 l2mtu=65535 mac-address=02:7E:C3:E9:A1:6F arp=enabled local-address=172.17.30.21 remote-address=172.17.30.1 tunnel-id=3021 keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes

/interface bridge
0 R name="bridge1-LocalNetwork" mtu=1500 actual-mtu=1500 l2mtu=1594 arp=enabled mac-address=4C:5E:0C:70:AD:ED protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m

1 R name="bridge2-PPPoE" mtu=auto actual-mtu=1458 l2mtu=1598 arp=enabled mac-address=02:7E:C3:E9:A1:6F protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m

/interface bridge port

INTERFACE BRIDGE PRIORITY PATH-COST HORIZON

0 ether2-AP-4 bridge2-PPPoE 0x80 10 none
1 wlan1 bridge2-PPPoE 0x80 10 none
2 ppp301 bridge2-PPPoE 0x80 10 none
3 ether3-AP-3 bridge2-PPPoE 0x80 10 none
4 ether4-AP-2 bridge2-PPPoE 0x80 10 none
5 ether5-AP-1 bridge2-PPPoE 0x80 10 none
6 ether1-Link bridge1-internet 0x80 10 none

After a quick glance across the settings, it appears that the MTU of the PPPoE sessions is higher than the MTU of the EoIP interfaces. This means that there is going to be fragmentation of the EoIP packets.

The fully-encapsulated IP packet is going to look like this:
[802.11/ethernet: [EoIP: [PPPoE: [IP] ] ]

You’ve configured the PPPoE sessions to negotiate an MTU of 1480.

  • This means that the inner (customer) IP packet (which includes inner IP header + ICMP/TCP/UDP/whatever headers + payload) may be up to 1480 bytes.
    The PPPoE header adds 6 bytes to the IP packet, so whatever carries the traffic must support at least 1486 bytes.
    The EoIP interface, however, has set the MTU at 1458, which is 28 bytes too small.
    The routers can (and will) simply fragment a PPPoE frame into two separate EoIP packets when the PPPoE frame is > 1458 bytes.
    This is so that the resulting EoIP packet does not exceed the IP mtu of 1500.

You may be surprised to discover that they will do this even if the IP Don’t Fragment flag (on the inner IP packet) is set to yes!
Why? Because the EoIP interface is not encapsulating IP traffic. It’s encapsulating PPPoE traffic, which doesn’t have any such thing as a do-not-fragment flag.
So the EoIP interface is chopping up the PPPoE frames into two EoIP packets and sending those along the way.

Why is the EoIP interface using 1458? Because the EoIP header is 42 bytes. (8byte GRE + 14 byte Ethernet + 20 byte IP) The actual IP interface MTU of the routed interfaces between your network nodes is almost certainly set to 1500, so the EoIP interface sees that it cannot send a tunnel packet whose contents are larger than 1458 because 1458+42=1500, the actual IP mtu between nodes.

If you were to determine the IP MTU that is truly available to your customer so that no fragmentation is required at the EoIP level:
1500 - 42(eoip) - 6(pppoe) = 1458 - 6 = 1452

So option 1 is to set the max mtu of your PPPoE sessions to be 1452 (with clamp-mss=yes)

Option 2 might be better for you - if your network has an L2MTU that’s large enough, you can increase the IP MTU of your backbone routers’ interfaces to carry the overhead and leave 1500 bytes for the customers.
How much is that?
1500 + 42 + 6 = 1548
The ethernet header of the outermost IP packet (the one carrying the EoIP packet) will add another 14 bytes, for a grand total L2MTU of 1562 bytes.
If all of your links allow L2MTU >= 1562, then you can just set the MTU of your IP interfaces on the backhaul network to be 1562, which will raise the MTU of the EoIP interfaces to 1506 which will allow the PPPoE sessions to use the MTU = 1500.



at this options, I check some ethernet interfaces of links and ppoeservers and see that max L2MTU are some of 1590 and some of 1598, so should i change the ethernet interfaces mtu ? and also all eoip’ Mtu ?

Thanks

Yes. Exactly.

Also verify any wireless p2p links in your infrastructure

Thanks ZeroByte,

So using option1 easier then option 2 :slight_smile: i will try option1 and give u the results.
ThNks

One other thing to point out about the differences between the two options is that lower MTU means more % overhead on your connections’ speeds. Full 1500 MTU will give faster speeds. (Not a BIG difference in your specific case, but a difference nonetheless)

it will take a time to finish it :slight_smile: but im going to strat to change MTU of ethernet’s and wireless p2p Links 1548 and 1506 to eoip tunnels and at the ppoe sesion 1500 for mtu.. but what will be the MRU and MRRU at ppoe session ? Im going to write at below if you can check..

/interface pppoe-server server
add authentication=pap disabled=no interface=eoipxxx max-mru=1480 max-mtu=1500 mrru=1600 service-name=XPoint