On 2016-02-06 19:00, Roger wrote: > there is no ipv6 involved, not on dns nor on the server
Of course not, otherwise there would not be any NAT issue. > its a physical machine with an MSI Board > i even see sometimes doubled packets. Explain 'double packets', did you do a non-CGN test for that, do you see them then. > I will have a talk with the Hoster as well ;) > but question is why it does only happen when there is CGN in the game ? Likely as they balance their outbound load. And then the source address changes maybe even in the middle of a session. The only way to find out what happens is to be on both sides of that CGN and monitor packets coming in/out of it. Or better: ask the people who operate the CGN (and then also ask if they are deploying IPv6...) > btw, here Embratel changed existing client to CGN and broke there > securitycams System (not reachable from the road) Same is happening to UnityMedia all over Europe. And the people who are signing up to new contracts with Cablecom do not even have the word "IP" in their contacts, these will soon have a nice 500/10mbit CGN'd pipe too. > There are several complain already pending at the Regulators office ;) > it was asked to investigate and even reduce the monthly fee for the time > of non 100% working Service. > It seems the regulator will soon add some rules regarding CGN. That is a good precedent. Unfortunately as I note above, they already have changed the contracts, hence folks "changing" their subscription agree with the new one which does not even do "IP", just "Internet" which is rather vague. Greets, Jeroen > > Roger > > > > > > On 06/02/2016 12:58, Jeroen Massar wrote: >> On 2016-02-06 16:45, Roger wrote: >>> >>> Hi Swinogers >>> since a few weeks i see following messages >>> on a server in Europe >>> kernel:nf_ct_sip: dropping packetIN=eth0 OUT= >>> MAC=00:23:54:d7:7c:12:80:71:1f:e2:71:81:08:00 SRC=191.189.9.153 >>> DST=62.75.177.146 LEN=513 TOS=0x00 PREC=0x00 TTL=115 ID=27879 PROTO=UDP >>> SPT=29012 DPT=5060 LEN=493 >>> >>> There are various IP´s causing this problem. >>> In common: all IP´s causing those Messages are originating from a CGN >>> Gateway >>> The example above is an Brazilian Cableprovider. >>> >>> Client behind those networks complaining getting sometimes dropped >>> calls, or one way speech in some cases not able to Register some of >>> Sip-devices while others work. mostly in times the Kernel drop packets. >> SIP requires state, well, the RTP part of a SIP call requires state. >> >> Some device is dropping state somewhere for you. >> >> Welcome to the wonderful world of forced NAT. >> >> Did you deploy IPv6 already? It is 2016, aka 201_IPv6_.... >> >> >>> Does someone have any idea what is causing this ? even why the hell an >>> invalid MAC address could made it so far. >> Linux tends to show all the MAC addresses in a stack of packets, eg >> 802.1Q >> >> 00:23:54:d7:7c:12 is likely the switch you are connected to. >> >> 00:23:54 ASUSTek COMPUTER INC -- the VM bridge you are using? >> >> 80:71:1f:e2:71:81 >> 80:71:1f Juniper Networks -- your actual router >> >> 08:00 just shows it is IPv4. >> >> Greets, >> Jeroen >> >> >> >> _______________________________________________ >> swinog mailing list >> [email protected] >> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog > > > > _______________________________________________ > swinog mailing list > [email protected] > http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog _______________________________________________ swinog mailing list [email protected] http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
