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.
Does someone have any idea what is causing this ? even why the hell an invalid MAC address could made it so far.
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
there is no ipv6 involved, not on dns nor on the server its a physical machine with an MSI Board i even see sometimes doubled packets. 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 ?
btw, here Embratel changed existing client to CGN and broke there securitycams System (not reachable from the road) 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.
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 swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
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 swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
-
Jeroen Massar -
Roger