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.
> 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.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
