| To: | EKC <webmaster@generalsynthesis.com> |
|---|---|
| Subject: | Re: [LARTC] Ingress qdisc bypassed on SNAT'ed traffic? |
| From: | Mohan Sundaram <mohan.tux@gmail.com> |
| Date: | Mon, 06 Nov 2006 09:35:08 +0530 |
| Cc: | lartc@mailman.ds9a.nl |
| Delivered-to: | sp-com-lists@consult.net |
| Delivered-to: | lartc-list@securepoint.com |
| Delivered-to: | lartc@outpost.ds9a.nl |
| Domainkey-signature: | a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=b7G/6Dbpz0g8YJM4w42tQa9M3/8uFhqJV6KchEj+KnlvarfnDJvzcuW8FMHBp+AHDmm7QP2NYedSEXkeDfUgwxoVyCi05zxDp6cRnLi9gvAqQGHTiEAbAu47Xi4mboG498pVYsddnBGxVkbZW9FTLXR7WD7grssXm6z/aTf42gg= |
| In-reply-to: | <355a4e960611051946s4759a7c2k5e8dbe9aa3755342@mail.gmail.com> |
| List-archive: | <http://mailman.ds9a.nl/pipermail/lartc> |
| List-help: | <mailto:lartc-request@mailman.ds9a.nl?subject=help> |
| List-id: | "Mailinglist of the Linux Advanced Routing & Traffic Control project" <lartc.mailman.ds9a.nl> |
| List-post: | <mailto:lartc@mailman.ds9a.nl> |
| List-subscribe: | <http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc>, <mailto:lartc-request@mailman.ds9a.nl?subject=subscribe> |
| List-unsubscribe: | <http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc>, <mailto:lartc-request@mailman.ds9a.nl?subject=unsubscribe> |
| References: | <355a4e960611051946s4759a7c2k5e8dbe9aa3755342@mail.gmail.com> |
| Reply-to: | smohan@vsnl.com |
| Sender: | lartc-bounces@mailman.ds9a.nl |
| User-agent: | Thunderbird 1.5.0.7 (Windows/20060909) |
EKC wrote: Hello, The QoS processing is done just before the device queue for egress or immediately after ingress from the device. Thus using the 192.168.x.x addresses for tc filters will not work. Using the gateway address works as that is the IP on the incoming packet's header.However, the same lartc ingress filter rules work fine when run on the NAT gateway address (10.32.4.2). I suppose this means that the ingress filter is being run too early in the PREROUTING chain to catch the NAT'ed destination address. Is there a patch to change this behaviour? I've not seen one. I've also tried using connmark to no avail. Ingress QoS works much before packet hits all this stuff. I would rather avoid using IMQ since my ingress QOS needs are pretty simple. AFAIK, there is no other choice/way here. One wa of doing this is to use one NAT IP per subnet and shape based on that NAT IP for ingress. However, this assumes you have as many addresses on the gateway as the subnet. I'm using you do as the NAT'ted IP is also a RFC1918 address. That leads to a more basic question - why NAT when both are RFC1918 addresses?Any suggestions? Mohan _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [LARTC] Ingress qdisc bypassed on SNAT'ed traffic?, EKC |
|---|---|
| Next by Date: | Re: [LARTC] Ingress qdisc bypassed on SNAT'ed traffic?, EKC |
| Previous by Thread: | [LARTC] Ingress qdisc bypassed on SNAT'ed traffic?, EKC |
| Next by Thread: | Re: [LARTC] Ingress qdisc bypassed on SNAT'ed traffic?, EKC |
| Indexes: | [Date] [Thread] [Top] [All Lists] |