Strano problema di rete.
Andrej Sossi <[email protected]> Fri, 5 Jun 2015 15:56:28 +0200
| Newsgroups | gmane.os.freebsd.italian.esperti |
|---|---|
| Organization | DOTCOM S.R.L. |
| Message-ID | <[email protected]> |
Salve a tutti.
Sto perdendo un sacco di tempo su un problema molto strano e a prima
vista molto aleatorio. Dopo parecchi giorni di verifiche e prove sono
finalmente riuscito a inquadrare il problema, ma non la causa.
Provo a spiegare in maniera concisa lo scenario:
Ho un server con installato FreeBSD 10.0-RELEASE-p10 con indirizzo IP
pubblico nel quale sono installate N macchine virtuali mediante JAIL con
indirizzi privato sulla scheda loopback1. Per accedere ad Internet le
macchine virtuali vengono NAT-tate con l'IP pubblico via ipfw:
nat 1 config ip X.Y.Z.W if igb0 unreg_only same_ports
add 60000 nat 1 ip from 192.168.250.0/24 to any out xmit igb0 keep-state
add 60001 nat 1 ip from any to X.Y.Z.W in recv igb0
In più ci sono dei portforwarding dalla macchina reale verso le virtuali
per fornire il servizio pubblico (apache, basi di dati, etc.)
La scheda di rete è:
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
ether 00:45:80:dd:32:30
inet X.Y.Z.W netmask 0xffffff00 broadcast X.Y.Z.W
inet6 XX::YY:ZZ:WWW:VVV%igb0 prefixlen 64 scopeid 0x1
inet6 XX:YY:ZZ:WWW::1 prefixlen 64
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
Anche la scheda di loopback1 dove sono assegnati gli indirizzi IP delle
macchine virtuali ha il MTU a 1500.
Fino a qua tutto bene, nel senso che funziona tutto come previsto, o
quasi. Sporadicamente ci sono delle richieste da parte della macchine
virtuali verso server presenti in Internet che vanno in timeout (http,
sftp, etc.). Le medesime richieste eseguite dalla macchina reale vengono
concluse correttamente. Dopo innumerevoli prove sono riuscito a
riprodurre deterministicamente il problema.
Mediante tcpdump avviato sul server al quale è destinata la richiesta ho
notato che tutti i pacchetti TCP con il payload grande tra 101 e 106
byte (estremi inclusi arrivano con il checksum TCP sbagliato e di
conseguenza vengono scartati. Le successive ritrasmissioni continuano ad
avere il checksum sbagliato fino a raggiungere il timeout della
connessione. Il checksum IP invece risulta corretto. I pacchetti più
piccoli di 101 byte vengono trasmessi e ricevuti con checksum corretto.
Anche i pacchetti con payload maggiore di 116 vengono trasmessi e
ricevuti con checksum corretto.
Ho provato a disabilitare il TOS4 e il TOS6 dalla scheda di rete, ma non
ha risolto il problema.
Lo stesso comportamento sono riuscito a riprodurlo su un'altra macchina
con lo stesso HW e la medesima configurazione. Quest'ultima ha
installato FreeBSD 10.0-RELEASE-p1 .
Quindi il problema del checksum errato avviene solo se viene eseguito il
NAT e se il pacchetto ha determinate dimensioni.
Sinceramente a me quei numeri non mi dicono nulla. Qualcuno ha qualche
idea? Bug di ipfw, dello stack TCP, della scheda di rete o c'è qualcosa
nella configurazione che ho sbagliato?
Ringrazio dell'aiuto.
--
Cordiali saluti
Sossi Andrej
-------------------------
DOTCOM Information technology
Via Machiavelli, 28
34132 - Trieste (TS)
Italy
tel: +39 040 9828090
fax: +39 040 0641954
E-mail: [email protected]
----------------------------
Ai sensi del D.lgs n. 196 del 30.06.03 (Codice Privacy) si precisa che
le informazioni contenute in questo messaggio sono riservate e ad uso
esclusivo del destinatario. Qualora il messaggio in parola Le fosse
pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non
inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie
This message, for the D.lgs n. 196 / 30.06.03 (Privacy Code), may
contain confidential and/or privileged information. If you are not the
addressee or authorized to receive this for the addressee, you must not
use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please
advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
_______________________________________________
Esperti mailing list
[email protected]
http://mailman.gufi.org/mailman/listinfo/esperti