Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: netfilter@lists.netfilter.org
Subject: Re: 1. Switch Flooding 2. Chains traversal
Date: Wed, 14 Sep 2005 11:27:04 -0500	[thread overview]
Message-ID: <43284F58.5020702@riverviewtech.net> (raw)
In-Reply-To: <acf1defa050913213555e04129@mail.gmail.com>

venkata subramanian wrote:
> Hi,
> 1. Switch Flooding
>        We have a nice problem in our organisation. Due to viruses,
> some windows machine or the other starts flooding the network with
> packets. And, in the end, one of our switches comes down making us to
> manually restart the switch.
>        I don't (intuitively) see how iptables can help in this
> scenario.... But, I want to know whether any solution exists to this?
> If I make all the machine's gateway as a linux system, and rate limit
> the packets there will it help?
>     
> 2. Chain traversal
>        Why is this chain traversal looking complicated? if there is
> atleast one rule in every inbuilt chain, it seems that there are many
> possible permutations of the chain traversal. How do you guys manage
> with it?

Basically you are dealing with a different issue when a switch can not handle things.  Seeing as how the switch is (usually) the device that all your client computers are connected to and then uplinked in to your firewall / router the firewall / router will not be able to do much for you at all if the problem is in the physical path before the traffic reaches it.  The best thing that I can think of would be to find out why the switch failed and possibly replace it.

If it was b/c of the ARPing issue mentioned by lst_hoe01 you may want to see if you could not have a process run on your firewall / router (or another system) that would answer all the ARP requests and receive the traffic so that the switch did not get confused and thus crash.  But that is not a very nice thing to do to a system any way.  In short sniff the traffic and see if it is something that can be mitigated.  You may want to look at putting an IDS in place to detect the traffic and respond to it before your switch goes down (presuming that there was a degradation period before the switch crashed).  You may be able to have an IDS detect that a port is going nuts and shut it down via SNMP management to the switch that it is connected to.



Grant. . . .


      parent reply	other threads:[~2005-09-14 16:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-14  4:35 1. Switch Flooding 2. Chains traversal venkata subramanian
2005-09-14  6:05 ` /dev/rob0
2005-09-14  9:42 ` lst_hoe01
2005-09-14 19:42   ` R. DuFresne
2005-09-15  8:56     ` lst_hoe01
2005-09-15 12:02       ` /dev/rob0
2005-09-14 16:27 ` Taylor, Grant [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43284F58.5020702@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox