Sky WiFi passerà a MAP-T entro il 2021

edofullo Attenzione che in questo caso oltre a fare SNAT occorre sostituire completamente l'header IPv4 con il v6, le operazioni da fare sono sicuramente più complesse, e spesso i SoC sono ottimizzati per determinate istruzioni e operazioni. Mettici poi magari un'immaturità del software ed ecco che potrebbero esserci penalizzazioni più sensibili che nel solo NAT v4.

mark129 Uovo o gallina? Da qualche parte si deve iniziare, e se non ci sono applicazioni pratiche i produttori che lavorano con l'obiettivo di fare soldi non andranno mai a predisporre una tecnologia che magari mai verrà sfruttata. D'altro canto lato ISP non è che si possa aspettare l'ultimo dei produttori cinesi che si dia una svegliata...

[cancellato] Attenzione che in questo caso oltre a fare SNAT occorre sostituire completamente l'header IPv4 con il v6, le operazioni da fare sono sicuramente più complesse, e spesso i SoC sono ottimizzati per determinate istruzioni e operazioni. Mettici poi magari un'immaturità del software ed ecco che potrebbero esserci penalizzazioni più sensibili che nel solo NAT v4.

Questo sicuramente.

mark129 Eh... e daje che Sky non ha colpa alcuna...

Ricordiamoci che io sono un geek e sto provando a spremere al massimo su un router che costa 100€ e che parliamo comunque di 500 rispettabilissimi Mbps... l'utente comune che usa il WiFi manco se ne accorge.

Certo che se non arriva al Gbps nemmeno sullo Sky Hub allora si, è un problema.

D'altro canto sono rimasto piacevolmente stupito della facilità di installazione, eccetto per la VLAN non c'è da fare assolutamente nulla.

Lascio uno screen di come appare il tutto.

Questo è un traceroute in IPv4, vediamo il bizzarro comportamento che si notava anche dal lab.

Stranamente però anche gli host dopo il dominio MAP-T non sembrano ricevere risposta.

non ho capito ancora tutto questo sbattimento !!! ... puro esercizio di stile ?

da oggi sono in MAP-T anche io

edofullo Sinceramente mi aspettavo di peggio da un dual-core A53. Hai provato anche con iperf oltre al classico ookla?

simonebortolin Beh dai sul 7590 non ci dovrebbero essere così tanti problemi....

Se l'SNAT è implementato HW allora non ci dovrebbero essere problemi ma vai a te a sapere come potrebbero implementare un eventuale MAP-T.

Ricordo che MAP-T lato CPE è diviso in due step:

• SNAT
• Traslation

Quindi per avere un flusso HW acellerato:

• Paccetto entra nella LAN dello switch la regola lo manda alla WAN
• L'HW della WAN applica il MENGLE HW per le regole SNAT del MAP-T, se non cè implementazione HW di MAP serve un IRQ alla CPU perchè il pacchetto non può uscire così.
• Il pacchetto va mandato indietro alla CPU del router per la parte di traslazione. (il ricalcolo header v6 non è generalmente accellerato, ma qui dipende dalla NIC)
  Inoltro il nuovo frame ipv6 sulla wan che esce nuovamente dalla wan.

Ad oggi salvo forse broadcom (stando alla conferenza che ha tenuto Patterson) il passo di translation non viene fatto sulla CPU. e nel 99% dei casi nemmeno il passaggio di SNAT in quanto ad oggi non ho visto nessuna implementazione in grado di accorgersi che il paccchetto a cui è appena stato fatto il SNAT deve tornare indietro. Di sicuro la PPE di mtk non sembra poterlo fare. Inoltre la PPE di mtk non è accellarata ipv6 (manca l'implementazione open, l' HW dovrebbe supportarlo. la PPE però supporta 4rd ma non è implementata)

[cancellato] Perché tu credi che quegli affarini lì tengano un SNAT line speed in software? credighe ai ufo

Beh oddio sono 4 core arm nel router di @edofullo e se non ce la fa quello... i mips non hanno chance

gandalf2016 I problemi di performance ci sono anche con lo Sky HUB, vero?

Nop con quello sky io saturavo la linea (anche in map-t 1:16)

edofullo Non provo con l'hub perchè ogni volta ci passa almeno un quarto d'ora ad aspettare che il server ti dia un nuovo prefisso... se qualcuno che lo ha vuol testare benvenga.

Potrei fare una prova appena ho MAP. Domani chiedo al mitico Patterson di migrare. (ho finito le cose grosse per lavoro)

edofullo Peraltro in NAT 1:1 la regola SNAT è una sola, in 1:16 dove le regole sono di più mi aspetto performance ancora peggiori.

Bah è una lookup table in teoria non dovrebbe perdere troppo tempo nel "cercare" quegli algoritmi sono ben otimizzati. Il grosso è il calcolo vero e proprio dei nuovi header e CRC (SNAT e Traslazione in v6).

edofullo Come pensavo OpenWRT non si prende l'IP del MAP per se, quindi la CPE non sembra essere direttamente raggiungibile (il ping non risponde), serve una regola DNAT.

Cosa corretta altrimenti chi è in MAP 1:X con x != 1 non potrebbe raggiungere gli altri CPE.

edofullo Non so se però questa sia una scelta di OpenWRT oppure no... alla fine pure su OpenWRT MAP-T non mi sembra così tanto testato e l'implementazione è abbastanza scarna.

Beh lato LUCI direi di si. Lato kernel più di cosi non si può fare. MAP non è implementato a livello di netfilter. Alla fine è una interfaccia virtuale.

edofullo D'altro canto sono rimasto piacevolmente stupito della facilità di installazione, eccetto per la VLAN non c'è da fare assolutamente nulla.

Vabbè quella ormai cè dall'alba dei tempo 835/836 sono con noi da almeno 5 anni. ad eccezione di fastweb che in FTTC non la ha.

edofullo Però il protocollo è assolutamente standard, nulla vieta a nessun costruttore di modem libero di fare la stessa cosa (e se Sky si diffonderà dovranno adeguarsi)

IMHO La cosa preoccupante è proprio questa, il protocollo è standard e nessuno ha pensato di implementarlo. A quanto pare in giappone è usato da diversi anni.

simonebortolin Mi chiedo come possono fare un flusso HW acellerato compatibile anche per MAP-E dalla tua descrizione...

Non ho guardato di preciso la RFC di MAP-E ma se non ricordo male è un semplice incapsulamento del frama v4 in v6. In tal caso non c'è SNAT ma solo uno step di incapsulamento, taglio del frame v4 per farcelo stare nel v6. e invio. Nulla di complicato. Una lookup table in HW e un registro a scorrimento.

L'header v6 è già calcolato in HW in molti casi dalla NIC in questo caso dovrebbe essere il chip dello switch a farlo.

Sarebbe interessante capire se con un FPGA si possa creare un accelleratore, ma da quello che ho visto netfilter supporta solo da e verso una interfaccia (DSA o meno). Quindi nada. Forse con un FPGA che emula una NIC impostata come default route per il traffico v4 che fa il loopback dei frame v6 che poi uscirebbero dalla WAN. ma anche così facendo i frame passano sempre dalla CPU.

EDIT: dovrei provare a sperare che Felix o/e blogic mi rispondano ma la vedo molto difficile.
Il secondo ha smesso lo sviluppo di Openwrt in quanto ha iniziato a lavorare e si è messo "sotto".

Qua ci sono un po' di "commit" riguardo a map-t:

https://code.rdkcentral.com/r/q/map-t
https://code.rdkcentral.com/r/q/author:abhishek.sivappa%2540sky.uk
https://code.rdkcentral.com/r/q/SKYH4

Magari c'è qualcosa di interessante da riciclare per openwrt

Questo è interessante:
https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/Utopia/+/58220/1/source/firewall/firewall.c

#ifdef NAT46_KERNEL_SUPPORT
    // TCP MSS RULE - SKYH4-5123 - To improve IPv4 Downstream traffic performance
    fprintf(mangle_fp, "-A FORWARD -p tcp --tcp-flags SYN,RST SYN -o %s -j TCPMSS --set-mss %d\n", NAT46_INTERFACE, NAT46_CLAMP_MSS);
#endif //NAT46_KERNEL_SUPPORT

handymenny
Questo mi fa pensare che loro passano il traffico v4 direttamente all WANc he fa MAP-T in hw.
https://code.rdkcentral.com/r/plugins/gitiles/rdkb/components/opensource/ccsp/Utopia/+/refs/changes/20/58220/1/source/firewall/firewall.c#1078

Anche se questo è molto simile a OpenWRT

#ifdef FEATURE_MAPT
#define SYSEVENT_MAPT_CONFIG_FLAG "mapt_config_flag"
#define SYSEVENT_MAPT_IP_ADDRESS "mapt_ip_address"
#define MAPT_NAT_IPV4_POST_ROUTING_TABLE "postrouting_towan"
#define SYSEVENT_MAPT_RATIO "mapt_ratio"
#define SYSEVENT_MAPT_IPV6_ADDRESS "mapt_ipv6_address"
#define SYSEVENT_MAPT_PSID_OFFSET "mapt_psid_offset"
#define SYSEVENT_MAPT_PSID_VALUE "mapt_psid_value"
#define SYSEVENT_MAPT_PSID_LENGTH "mapt_psid_length"
#define ETH_MESH_BRIDGE "br403"
#if defined(NAT46_KERNEL_SUPPORT)
#define NAT46_INTERFACE "map0"
#define NAT46_CLAMP_MSS  1440
#endif //IVI_KERNEL_SUPPORT
BOOL isMAPTSet(void);
static int do_wan_nat_lan_clients_mapt(FILE *fp);
#ifdef FEATURE_MAPT_DEBUG
void logPrintMain(char* filename, int line, char *fmt,...);
#define LOG_PRINT_MAIN(...) logPrintMain(__FILE__, __LINE__, __VA_ARGS__ )
#endif
#endif //FEATURE_MAPT

Uhm...
https://code.rdkcentral.com/r/c/rdkb/components/opensource/ccsp/Utopia/+/58220

Molte modifiche sono relative alla Ui

handymenny Hai provato anche con iperf oltre al classico ookla?

No, non saprei dove provare.

Ho provato un paio di questi ma mi danno risultati infimi anche in IPv6 quindi penso ci sia qualcos'altro da qualche parte, sta sera non ho tempo per investigare.

hitech95 Ad oggi salvo forse broadcom (stando alla conferenza che ha tenuto Patterson) il passo di translation non viene fatto sulla CPU.

In che senso? E dove viene fatto?

hitech95 sono 4 core arm

due

hitech95 Domani chiedo al mitico Patterson di migrare. (ho finito le cose grosse per lavoro)

Se vuoi chiedigli anche se è atteso il comportamento dei traceroute in IPv4 (usciti dalla parte MAP-T)... non so se loro o MAP-T semprerebbero filtrare gli ICMP TTL exceeded.

hitech95 Bah è una lookup table in teoria non dovrebbe perdere troppo tempo nel "cercare" quegli algoritmi sono ben otimizzati.

Io ricordavo che le regole di firewall fossero processate in sequenza, finchè non se ne trova una che fa match.

hitech95 Cosa corretta altrimenti chi è in MAP 1:X con x != 1 non potrebbe raggiungere gli altri CPE.

Si ma per il NAT 1:1 è una gran rottura di cocomeri... forse si potrebbe mettere un bel if e in caso si sia in 1:1 assegnarlo?