IPv6 tunnel langzaam naar overstap connect box

[Ern st]

Na overstap op de connect box (Arris TG2492LG-ZG) in bridge mode is mijn Hurrican Electric IPv6 tunnel traag. Komt nu maximaal ca. 13Mbit/s downstream doorheen. Met het vorige modem Cisco EPC3928 kwam ik hier gewoon op 200+ Mbit/s.

Om even uit te sluiten dat er problemen zijn bij Hurricane Electric heb ik een tunnel naar een machine in AWS opgezet. Als ik hier een 6in4 tunnel maak (proto 41) haal ik hier dezelfde 13Mbit/s downstream. Zet ik deze om naar GRE (proto 47) haal ik de volledige 250mbit/s. Ook IPSEC werkt gewoon naar behoren.

Is het een bekend issue dat protocol 41 verkeer geratelimit wordt op de Arris modems?

Onderstaand testje zoals uitgevoerd hierbij wordt een 6in4 en GRE tunnel opgezet tussen dezelfde machines.

#Opzetten 6in4 en GRE tunnel (ander kant heeft adres :2)

ip tunnel add 6in4 mode sit remote n.n.n.n ttl 255
ip addr add fd00:1::1/64 dev 6in4
ip link set 6in4 mtu 1480 up

ip tunnel add gre mode gre remote n.n.n.n ttl 255
ip addr add fd00:2::1/64 dev gre
ip link set gre mtu 1476 up


# test over sit tunnel ( 6in4 )
root@aws:/# iperf -V -c fd00:1::2
------------------------------------------------------------
Client connecting to fd00:1::2, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 3] local fd00:1::1 port 35622 connected with fd00:1::2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 16.5 MBytes 13.7 Mbits/sec

# test over gre tunnel
root@aws:/# iperf -V -c fd00:2::2
------------------------------------------------------------
Client connecting to fd00:2::2, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 3] local fd00:2::1 port 33472 connected with fd00:2::2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 291 MBytes 243 Mbits/sec

[Paul]

@BrB Fijn dat het nu goed gaat met het nieuwe modem. Laat je het weten als wij je verder nog ergens mee kunnen helpen?
Groeten,
Paul

[Otwin]

Beste @Mark ,

Is het nog mogelijk om een Ubee te ontvangen? Ik zit al maanden mijn GRE performance te troubleshooten en ben erg blij dat ik dit topic tegenkom met precies dezelfde problemen. Nooit verwacht dat de Connectbox hier het probleem zou kunnen zijn.

Groet,

-Otwin

[Paul]

Goedemiddag @Otwin,

Hartelijk dank voor je reactie. Ik zorg ervoor dat je van ons een Ubee 1318ZG modem ontvangt. Het Connectbox modem stuur je kosteloos retour naar onderstaande adres.

XPO/Ziggo
Antwoordnummer 1070
5800VB Venray.

Vergeet niet om het verzendbewijs goed te bewaren. 

Laat je weten wat je bevindingen zijn?
 

Alvast een fijne middag!

Groeten,
Paul

[Otwin]

Super snelle reactie! Dank daarvoor!

[Paul]

@Otwin Heel graag gedaan! Laat maar weten wat je bevindingen zijn met het nieuwe modem.
Alvast een fijn weekend.
Groeten,
Paul

[Paul]

Goedemiddag @Otwin,

Wat zijn je bevindingen met het nieuwe Ubee1318ZG modem wat je onlangs ontvangen hebt? Werkt alles inmiddels volledig naar wens?
Wij zijn erg benieuwd! Alvast bedankt voor je reactie en nog een prettige middag!

Groeten,

Paul 

[mathis]

Na het modem te hebben ontvangen werkte alles top, maar sinds ik het modem (tijdelijk) uit bridge had laten halen werkt de 6in4 tunnel niet meer. De OpenWRT router die erachter hangt verzend wel packets, maar krijgt niks terug van het modem. Ik verwacht dat er nu sinds de levering een andere firmware op het modem is geladen. Kan iemand mij hiermee helpen?

[Paul]

@mathis Fijn dat je dit forum gevonden hebt voor het stellen van je vraag. Goed dat het nieuwe modem naar wens werkt. Ik begrijp dat je nu problemen ervaart met je OpenWRT router sinds het nieuwe modem is aangesloten.Hier kort op inhakend; kan het zijn dat de configuratie van je router mogelijk nog aangepast moet worden i.c.m. het nieuwe modem?

Om het voor iedereen overzichtelijk te houden raad ik aan hiervoor een eigen topic te starten. Zo krijg je van de experts en moderators de volledige aandacht en focus op jouw eigen vraag. 

[mathis]

@Paul Ik merk dat je mijn bericht niet snapt, excuus, ik kan soms best onduidelijk zijn. Ik zal het even opnieuw uitleggen.

Na het nieuwe modem te mogen ontvangen werkte de (Hurricane Electric) 6in4 tunnel perfect. Ik heb toen de klantenservice tijdelijk de bridgemode eraf laten halen, maar toen deze eenmaal weer aan stond werkte de tunnel niet meer (terwijl er 6in4 packets worden verzonden, komt er geen response terug van de endpoint).

Ik denk persoonlijk dat er door de bridgemode wissel een andere firmware op het modem is geladen waardoor de packets er dus niet meer doorheen komen. Als dat het geval is, kan ik daar zelf niks aan doen.
Ter clarificatie, er is niks veranderd aan mijn router configuratie vanaf het moment dat de tunnel werkte. Dit is lijkt mij dan echt een probleem met de Ubee. Ik verwacht dat een vervangende Ubee ook een simpele oplossing zou kunnen zijn.

[Mark]

Hi @mathis, ik heb even een aantal modems uit dit topic bekeken. De firmware op jouw modem is exact dezelfde als die op de andere Ubee's van Zakelijke abonnee's in bridge en in router mode (namelijk 12.5.3208), daarin is niets veranderd. Ik denk daarom niet dat de firmware er iets mee te maken heeft.

[Otwin]

Dag Paul,

Het heeft even geduurd ivm corona en wat technische issues, maar er is vooruitgang. Allereerst moet ik complimenten geven over het gemak waarmee de modems gewisseld konden worden: ene eruit, andere erin, kwartier wachten en klaar. Automatisch kwam de modem weer in bridgemodus en zelfs het ip bleef ongewijzigd.

De snelheid van de tunnel is sinds het omwisselen omhoog gegaan, helaas nog niet de volledige bandbreedte maar dat kan ook aan de andere kant van de tunnel liggen.

Dank voor de service!

[Mark]

Hoi allemaal! We zien enkele klachten dat IPv6 tunnels op de Ubee niet meer werken na een reset+firmwareupdate van het modem. (De Ubee die we juist hebben geleverd omdat de tunnels op de Connectbox zo traag werken).

• Hebben jullie allemaal het modem al gereset sinds 12 april?
• Zo ja, ervaren jullie hetzelfde probleem?
• Zo nee, wacht even met resetten en post hier een reply svp zodat wij kunnen vergelijken.

Of de firmwareupdate samen met de snelheidsverhoging is gegaan weet ik niet, kan ook zijn dat de update al een tijdje beschikbaar was en dat die door de reset toevallig samenvalt met de snelheidsverhoging.

[Otwin]

Ik heb recent mijn tunnel gesloopt, maar ik heb zojuist deze weer proberen te fixen zonder succes. Er is afgelopen tijd hier wat onderhoud geweest (ik gok ivm giganet) dus de modem is meerdere keren opnieuw gestart. Ik heb wat getest met een externe vps om aan beide zijde te kijken wat er binnenkomt en uitgaat. 

Zowel op mijn router als op de vps: $ tcpdump "proto 41 or proto 47"
(41 is 6in4, 47 is GRE)

Met behulp van scapy netwerkpakketten gemaakt:
> p41 = IP(dst="vps-ip")/IPv6()
> send(p41)
> p47 = IP(dst="vps-ip")/GRE()
> send(p47)

Beide pakketjes komen aan bij de vps. Wanneer ik dit herhaal vanaf de vps naar mijn eigen ip toe komt alleen het GRE pakket aan. Ik krijg het idee dat de modem de inkomend protocol 41 niet doorgeeft.

Zien meer mensen dit gedrag? Of heeft er nog iemand tips dit verder uit te lopen?

[Roeller]

Zelfde probleem hier.  Wat begon met een klacht dat Google Assistant niet meer op tijd antwoord gaf, moesten we via dit topic de bevestiging krijgen dat onze ExtraIP en HurrucaneElectric (TunnelBroker) tunnels niet meer werken.

Wij zijn dus zakelijk klant, hebben een winkeltijden SLA, hebben geen actieve  communicatie gehad  en hebben nu dus een productie probleem omdat we geen IPv6 Connectiviteit meer hebben omdat Ziggo een firmware update heeft gedaan op modems.

DRAAI AUB ZSM DEZE. FIRMWARE IODATE TERUG!

[qqq]

Ik zie dit probleem ook. Ik heb zojuist ook gereageerd in het ander topic dat @Mark al linkte.

Ik kan de conclusies van @Otwin bevestigen dat protocol 41 outbound (mijn netwerk -> modem -> Ziggo -> HE.net) goed gaat, maar inbound niet meer wordt ontvangen. Ik kan niet zien of dit een issue is op het modem of in het Ziggo-netwerk.

[qqq]

@OtwinIk ben nog een stap verder gegaan met scapy door de ttl langzaam op te laten lopen en het gedrag tussen UDP en protocol 41 te vergelijken.

>>> udp = IP(dst="Y.Y.Y.Y", ttl=8)/ICMP()
>>> send(udp)

tcpdump icmp or proto 41

14:11:36.861581 IP X.X.X.X > Y.Y.Y.Y: ICMP echo request, id 0, seq 0, length 8
14:11:36.863255 IP 213.51.64.65 > X.X.X.X: ICMP time exceeded in-transit, length 76

>>> udp = IP(dst="Y.Y.Y.Y", ttl=9)/ICMP()
>>> send(udp)

tcpdump icmp or proto 41

14:08:31.194699 IP X.X.X.X > Y.Y.Y.Y: ICMP echo request, id 0, seq 0, length 8
14:08:31.196593 IP 213.51.5.31 > X.X.X.X: ICMP time exceeded in-transit, length 36

>>> p41 = IP(dst="Y.Y.Y.Y", ttl=8)/IPv6()
>>> send(p41)

tcpdump icmp or proto 41

14:12:51.996928 IP X.X.X.X > Y.Y.Y.Y: IP6 ::1 > ::1: no next header
14:12:51.998871 IP 213.51.64.65 > X.X.X.X: ICMP time exceeded in-transit, length 76

>>> p41 = IP(dst="Y.Y.Y.Y", ttl=9)/IPv6()
>>> send(p41)

tcpdump icmp or proto 41

14:14:12.118736 IP X.X.X.X > Y.Y.Y.Y: IP6 ::1 > ::1: no next header

(geen response)

waarbij

X.X.X.X = ip vps

Y.Y.Y.Y = ip ziggo verbinding

213.51.5.31 = mnd-rc0001-cr101-et2-2.core.as33915.net. (router 1, AS33915, Vodafone Libertel B.V.)

213.51.64.65 = asd-rc0001-cr101-be64.core.as9143.net. (router 2, AS9143, ZIGGO)

Wat je hier ziet is dat UDP-verkeer zowel van router 1 als van router 2 nog een ttl exceeded krijgt, maar protocol 41 alleen van router 1. Mogelijk filtert router 2 op protocol 41.

@Mark Ik neem aan dat het Ziggo NOC daar makkelijk en snel uitsluitsel over moet kunnen geven.