Freedom via alleen UDM pro

Uitgaand pingen over IPv4 met 1472 bytes klopt ook. Je hebt een overhead van 20 bytes voor de IP-header en 8 bytes voor de ICMP-header. Dus als je een payload van 1472 bytes hebt plus een header van 28 bytes, kom je uit op een MTU van 1500 bytes.

Wanneer je geen RFC 4638 gebruikt, zou je niet verder komen dan 1464 bytes.

Bij IPv6 is de IP-header 40 bytes, dus kom je op een totaal van 48 bytes aan overhead. Zodoende moet je over IPv6 dus pingen met een payload van 1452 bytes, en zou je anders blijven steken op 1444 bytes.

Oftewel:

ping4 -M do -s 1472 freedom.nl
ping6 -M do -s 1452 freedom.nl

Ga ik daar overheen, dan krijg ik dit:

local error: message too long, mtu: 1500
1 like

1466 staat er ook 2 keer in.

Resultaat

Sending 32 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 750 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1125 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1313 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1407 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1454 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1478 bytes to 185.xxx.xxx.xxx ← FRAGMENTED!

Sending 1466 bytes to 185.xxx.xxx.xxx ← FRAGMENTED!

Sending 1460 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1463 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1465 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1466 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1467 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1468 bytes to 185.xxx.xxx.xxx ← not fragmented

Sending 1469 bytes to 185.xxx.xxx.xxx ← FRAGMENTED!

Sending 1468 bytes to 185.xxx.xxx.xxx ← not fragmented

From the tests we did, we can assume that 1468 bytes is the largest unfragmented packet
size. The MTU size would be 1496, made up from 1468 payload and 28 ICMP/IP Headers
and payload information.

The current maximum payload size is not divisible by 8.
The actual size of the payload (data) will be limited to: 1464
The maximum MTU size for 185.xxx.xxx.xxx is: 1496

je kunt de MTU ook op de UDM Pro testen door het volgende te doen: (op eigen risico)

unifi-os shell
root@ubnt:/# ping ping.xs4all.nl -c3 -s 1472 -M do
PING ping.xs4all.nl (194.109.6.8) 1472(1500) bytes of data.
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=1 ttl=59 time=3.92 ms
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=2 ttl=59 time=3.92 ms
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=3 ttl=59 time=3.93 ms

β€” ping.xs4all.nl ping statistics β€”
3 packets transmitted, 3 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 3.906/3.922/3.934/0.040 ms

(ik had de unifi-shell al eens gebruikt om SNMP aan te zetten)

Ik heb nog een nieuwe vraag voor mijn UDM Pro. hebben jullie nog wat anders gedaan om de lease van IPv6 te krijgen? als ik het aanzet in Internet en networks->[my network]->advanced->IPv6 Interface Type-Prefix Delegation dan gebeurt er niets… (IPv6 Prefix RA staat aan)

Het werkte bij mij pas, nadat ik naast de juiste subnetgrote, ook een id aan het netwerk toekende

Google Photos

Ok, en waar in de interface doe ik dat? (ik heb als ik via de browser het subnet configureer niet de optie die jij daar hebt – ik heb een UDM Pro met 6.2.26)

Dit is vanuit de app op android. Ik draai 6.4.47 op een UDM Pro

draai je dan een beta?

Oh ja, dat klopt. Nog geen issues ervaren om het niet te doen :blush:

Ik heb een USG 3P en heb ook zitten knutselen. Zonder custom configuratie werkt alles overigens prima, behalve dan de MTU van 1492.

Heb ingelogd op mijn USG en de configuratie er uit getrokken:

Originele config
{
    "interfaces": {
        "ethernet": {
            "eth0": {
                "description": "WAN",
                "duplex": "auto",
                "speed": "auto",
                "vif": {
                    "6": {
                        "description": "WAN",
                        "firewall": {
                            // ...
                        },
                        "pppoe": {
                            "2": {
                                // ...
                                "mtu": "1492",
                                "name-server": "none",
                                "password": "1234",
                                "user-id": "fake@freedom.nl"
                            }
                        }
                    }
                }
            },
            "eth1": {
                "address": [
                    "192.168.1.1/24"
                ],
                "description": "LAN",
                "duplex": "auto",
                // ...
                "speed": "auto"
            },
            "eth2": {
                "disable": "''",
                "duplex": "auto",
                "speed": "auto"
            }
        }
    }
}

Aan de hand hiervan, zelf een config.gateway.json gemaakt en op de Cloudkey gezet en force provision gedaan op de USG:

{
    "interfaces": {
        "ethernet": {
            "eth0": {
                "mtu": "1508",
                "vif": {
                    "6": {
                        "mtu": "1508",
                        "pppoe": {
                            "2": {
                                "mtu": "1500"
                            }
                        }
                    }
                }
            }
        }
    }
}

Grappig genoeg werkt dit niet. De USG geeft de volgende fout:

Aug 18 16:49:23 USG mcad: mcad[3651]: ace_reporter.reporter_handle_response(): commit errors, {"DELETE": {"failure": "0", "success": "1"}, "SESSION_ID": "a116530512943256a99bc14e85", "SET": {"error": {"interfaces ethernet eth0 vif 6 mtu 1508": "MTU must be least than or equal to parent interface MTU. Value validation failed"}, "failure": "1", "success": "1"}}#012

Dus ik dacht, prima. Dan zetten de we MTU van eth0.6 eerst gewoon even op 1500, en zodra dat draait, doen we een 2e provision naar 1508.

Echter krijg ik dan precies dezelfde fout.

Heeft iemand enig idee hoe hier omheen te werken is? Heb ook al geprobeerd om het (tijdelijk) vanaf de CLI te doen (ip link set dev eth0.6 mtu 1508 ) maar dan klapt alles er uit.

De volgorde ia belangrijk: eerst eth0, dan eth0.6 en dan de ppp interface. Waarbij de eerste twee 1508 moeten zijn en ppp0 1500

@georgeboot is het mogelijk dat je de settings voor de USG deelt?
Ik heb mijn USG ook aangesloten op de glasvezel via een mediaconverter en PPPoe ingesteld en internet werkt prima. Maar de settings voor de TV krijg ik niet voor elkaar.

Zelf heb ik bovenstaande nog niet kunnen uittesten. Afgelopen week verhuisd, dus nog niet de tijd gehad om te rommelen met de netwerk instellingen. Was allang blij dat ik een enigszins stabiele verbinding had :smiley:

@MVo zeker hoor!

Ik heb uiteindelijk deze handleiding gebruikt: Unifi Security Gateway (USG) met KPN IPTV op een apart VLAN | USG en KPN

Alleen even KPN naar Freedom hernoemd voor de goede orde (en de PPP user/password) maar voor de rest zijn ze meen ik gelijk.