Re: conntrack generates UDP 'ghost traffic'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2009-10-15 at 18:23 +0200, Roderick Groesbeek wrote:
> Hi list,
> 
> We have a situation where the result is that UDP traffic is flooded to all our ports on our switch infrastructure.
> 
> Situation:
> ==========
> Android <-> {wifi} <-> Linux Nat <-> Tiss (Triple streaming server product)
> 
> We have an ESTABLISHED TCP connection...
> 
> [root@pollux conntrack-tools-0.9.13 ]# conntrack -L -p tcp --dport 554
> tcp      6 405224 ESTABLISHED src=192.168.14.57 dst=93.187.9.29 sport=54148 dport=554 packets=11 bytes=1733 src=93.187.9.29 dst=213.132.176.3 sport=554 dport=54148 packets=7 bytes=1877 [ASSURED] mark=0 secmark=0 use=1
> conntrack v0.9.13 (conntrack-tools): 1 flow entries have been shown.
> 
> And running UDP connections with it...
> [root@pollux conntrack-tools-0.9.13 ]# cat nf_conntrack|grep 93.187.9.29|grep udp
> ipv4     2 udp      17 178 src=192.168.14.57 dst=93.187.9.29 sport=8634 dport=13104 packets=3 bytes=120 src=93.187.9.29 dst=213.132.176.3 sport=13104 dport=8634 packets=100514 bytes=34886806 [ASSURED] mark=0 secmark=0 use=1
> ipv4     2 udp      17 179 src=192.168.14.57 dst=93.187.9.29 sport=8632 dport=13102 packets=3 bytes=120 src=93.187.9.29 dst=213.132.176.3 sport=13102 dport=8632 packets=333066 bytes=266119819 [ASSURED] mark=0 secmark=0 use=1
> ipv4     2 udp      17 28 src=93.187.9.29 dst=213.132.176.3 sport=13105 dport=8635 packets=6251 bytes=525064 [UNREPLIED] src=213.132.176.3 dst=93.187.9.29 sport=8635 dport=13105 packets=0 bytes=0 mark=0 secmark=0 use=1
> ipv4     2 udp      17 29 src=93.187.9.29 dst=213.132.176.3 sport=13103 dport=8633 packets=28080 bytes=2358680 [UNREPLIED] src=213.132.176.3 dst=93.187.9.29 sport=8633 dport=13103 packets=0 bytes=0 mark=0 secmark=0 use=1
> [root@pollux conntrack-tools-0.9.13 ]# 
> (Btw the RTCP are UNREPLIED, that's probably because the android is not sending RTCP back? At least not on the same ports?)
> 
> But the SOURCE is dead!
> [root@pollux conntrack-tools-0.9.13 ]# ping  -w 3 192.168.14.57
> PING 192.168.14.57 (192.168.14.57) 56(84) bytes of data.
> --- 192.168.14.57 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 2999ms
> [root@pollux conntrack-tools-0.9.13 ]#
> [root@pollux conntrack-tools-0.9.13 ]# arp -na |grep 192.168.14.57
> [root@pollux conntrack-tools-0.9.13 ]#
> 
> Problem:
> ========
> In this situation the UDP traffic is flooded through our SWITCH infrastructure!
> 
> 
> Question:
> =========
> How can we avoid this?

Not that I fully understand your setup from your description, but unless
you are doing something with broadcasts/multicasts (which I don't see
from your post):

Assuming that pollux is the NAT router, Tiss has IP 192.168.14.57, the
public IP of your NAT router is 213.132.176.3  and the Anroid device has
IP 93.187.9.29, the most likely cause of the flood is that the standard
algorithm of Ethernet switches is sending your packets out to all ports
because the switch has not learned a source port for the MAC you are
sending your packets to (i.e. the MAC of pollux), which 
usually only happens when the switch does not receive any packets from
that MAC (i.e. your NAT router). This should be visible in the station
table of your switch. 

And since you cannot even do ARP resolution for Tiss from pollux, there
is definitely something blocking communications. You should investigate
what that something is...


Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux