On Sun, Jun 9, 2013 at 2:36 AM, Reinhard Vicinus <[email protected]> wrote:
> Hi,
>
> I'm by no means an expert, so it can be that there is some nifty trick
> that I'm not aware of. That said, I don't think there is a way you can
> assure the owner of SiteB that in the worsed case you won't use all of his
> inbound bandwidth. The reason is, if you only look at SiteB and his 50mb/s
> connection at the internet: What can he do to prevent that his connection
> isn't flooded with inbound traffic? As far as I know: nothing, because he
> can't influence the inbound traffic through his connection in any way. The
> moment the inbound traffic reaches SiteB and he has control over it, it's
> already to late, because the inbound traffic is already gone through the
> connection (Obviously this isn't that case if he has some control of the
> other side of his internet connection and can prevent packages from
> entering the connection, but normally that isn't the case). So if denial of
> service attacks are a concern, then I fear there is nothing you can do,
> because as soon as an attacker has more then 50mb/s bandwith available to
> attack SiteA it will not only take SiteA offline but also SiteB.
>
> If only legitmate usage of services from SiteA is your concern, then it's
> somewhat differently. Obviously you still can't gurantee that the inbound
> traffic won't be more then 3mb/s but it's very unlikely that it will be
> much more then 3mb/s. Firstly TCP has congestion control to prevent this
> case (
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Congestion_control)
> and secondly normal services do more outbound traffic then inbound traffic
> and your outbound traffic is clearly limited by 3mb/s. So if you only
> provide normal services with lots more outbound traffic then inbound
> traffic then you should be fine without any traffic policing. But as I said
> prior I'm no expert, so if someone can prove me wrong, I'm always happy to
> learn.
>
> Kind regards
> Reinhard
>
> *Gesendet:* Sonntag, 09. Juni 2013 um 03:18 Uhr
> *Von:* "Lee Brown" <[email protected]>
> *An:* "Shorewall Users" <[email protected]>
> *Betreff:* [Shorewall-users] Inbound traffic policing
> Hi everybody,
>
> This is not strictly a Shorewall question, so please feel free to point me
> at the right book, technical something to consume. This will be TCP
> traffic and my TCP knowledge is weak.
>
> I have a possible scenario coming up like this:
>
> SiteA -- MPLS@3mb/s -- SiteB -- Internet@50mb/s
>
> Obviously I want to route traffic between Internet and SiteA.
> The owner of SiteB is concerned that we'll eat up more than our 3mb/s
> allowance because it's impossible to control the amount of requested data.
>
> If I apply policing at SiteB and drop packets going over the 3mb/s limit,
> I understand TCP will retry and get the data there eventually, but does
> that, in real-world terms limit the inbound traffic to a little over 3mb/s
> or can it just go wild on the inbound side.
>
> I have the ability to signal SiteA's firewall from SiteB so I can do
> things like modify rate limiting at SiteA based on SiteB's performance, but
> am clueless as to what will, if anything, work effectively.
>
> Anybody have experience with this?
>
> Thanks -- lee
>
> Thanks Reinhard,
Para 1 - As far as I can tell, SiteB cannot control his inbound, that's
managed by the ISP. My experience for most people's using the web nowadays
is about 10% outbund utilization == 100% inbound. It occurs a horrible
hack would be limit the SiteA outbound to 0.3mb/s. DoS is not a concern,
paying to use their service is.
Para 2 - I think I'm just going to have to give it a go, take a lot of
fine-grained metrics and see how it goes. If it doesn't work out we'll
have to pay for local internet. Remotely that 3mb/s would costs us $15 a
month, locally, erm $750. This ignores infrastructure cost which is fixed
anyway.
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
