From owner-freebsd-net@FreeBSD.ORG Tue Aug 16 05:28:28 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCA6F16A41F for ; Tue, 16 Aug 2005 05:28:28 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: from mail.lrtc.lt (pegasus.lrtc.lt [217.9.240.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id F014F43D5A for ; Tue, 16 Aug 2005 05:28:27 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 1714 invoked from network); 16 Aug 2005 05:27:31 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (d.gendvilas@[217.9.241.242]) (envelope-sender ) by mail.lrtc.lt (qmail-ldap-1.03) with SMTP for ; 16 Aug 2005 05:27:31 -0000 Message-ID: <000d01c5a223$53799840$0500a8c0@donatas> From: "Donatas" To: "Julian Elischer" , References: <026001c59e7a$c6ca69c0$9f90a8c0@donatas> <42FBC0AE.8020803@elischer.org> <027701c59f02$0eb808a0$9f90a8c0@donatas> <42FCF148.5010400@elischer.org> Date: Tue, 16 Aug 2005 08:28:24 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: Subject: Re: routing problem (with corrected scheme) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2005 05:28:28 -0000 Hello Julian, > Do the users have to have real IP addresses or can they have > NAT'd addresses? In other words, do they have INCOMING sessions > or just outgoing sessions? actualy there are hundreds of users with registered(real) IP's. So = nat'ing, looking the most logical solution, in this case can't be = realized. =20 > If the latter then you could put a NATD on each of the vlan > interfaces on the user router, so that the return packets will > automatically go back to the vlan from which they came. > Why do you need DIFFERENT VLANS between the two routers for > data that will eventually go to different places? > Why can't that decision be made on the core router? > Is it just so you can shape traffic between the two routers? > why not do the shaping on the core router? as far as shaping of unsecure zone cannot be realized on the core router = (due tu enormous load of machine), we must put those options on = user-router. We need to shape USA and EUROPE traffic separately and = differently per user. Using ipfw that traffic can be recognized only = using two different interfaces. We can't avoid usage of vlan's by adding = aditinal physical interface on core router, but it won't solve = inbound-routes problem. > actually you should be able to do it with ipfw's 'fwd' rule > without NAT. > ipfw add 1000 fwd ip4 ip from any to ${USER_NETWORK} in recv em0 > ipfw add 1001 fwd ip3 ip from any to ${USER_NETWORK} in recv em1 yes, i've been thinking of "fwd" rules, but as I have allready mentioned = - there are hundreds of real IP's behind the user router, all of them = are in differen (mixed) subents. Core router's average cpu load (running = on dual xeon 2.8) is 80%.We can't describe all inbound traffic with two = ipfw rules because of subnet difference. If we put several hundred of = fwd rules on core-router, it will simply fail. And the number of these = rules has a tendence to increase in about 40/month. So, the only solution in this case seems to be routing-back to those two = USA and EUROPE vlan's.=20