Your in a bad spot there, because even if you stuff
the pipe to ISP#1, then how much additional bandwidth
you get out of them is entirely dependent on how stuffed THEIR
pipe is to ISP#2. Also, unless ISP#2 has a bigger feed to
the core than you have to them, you won't gain anything.
But, I have
Our old network admin signed a stupid 5 years contract with ISP 1 (the ISP 1
uses ISP 2 for next hop), and we added ISP 2 when the new network admin
arrived (this network admin is smarter becuase he only signed 1 year
contract with ISP 2). We cannot get rid of ISP 1 because of the stupid
contract
Quoting Wai Chan <[EMAIL PROTECTED]>:
> I have two ISPs (two different serial links to my router). I want 50%
> of
> all outgoing traffic go through ISP 1 with ISP 1 provided IP address as
> source address, and the other 50% of all outgoing traffic go through ISP
> 2
> with ISP 2 provided IP add
The rules I had doesn't make anysense (not working). How about the
following "new" rules?
/sbin/ipfw -f flush
/sbin/ipfw add prob 0.5 fwd isp1.ip.address all from 127.0.0.1 8080 to any
/sbin/ipfw add prob 1 fwd isp2.ip.address all from 127.0.0.1 8080 to any
/sbin/ipfw add allow tcp from isp1.ip.
I have two ISPs (two different serial links to my router). I want 50% of
all outgoing traffic go through ISP 1 with ISP 1 provided IP address as
source address, and the other 50% of all outgoing traffic go through ISP 2
with ISP 2 provided IP address as source address.
Will this work if I add th
"Louis A. Mamakos" wrote:
> > Should I be able to "tcpdump -i gif0"? tcpdump indicates it's listening
> > on gif0 but I never capture anything.
Yes, you should. If you send traffic over it, but from what Louis wrote,
maybe you don't.
> Traffic going over an ESP tunnel never actual transits the
On Thu, May 03, 2001 at 04:06:01PM +, Gunther Schadow wrote:
> Hmm, so you are arguing gainst multiple return values and stateful
> inspection? I like simplicity, but wouldn't this impede the ability
> to produce high-performance classifiers?
The approach I'm taking is to have the filters
Jason R Thorpe wrote:
>
> On Thu, May 03, 2001 at 10:15:36AM +0200, Fulvio Risso wrote:
>
> > Not only.
> > BPF does not support:
> > - stateful inspection
> > - multiple return values (only 1/0)
> > - multiple outputs (I want to know, for example the amount of traffic IP
> > *and* TCP)
>
On Thu, May 03, 2001 at 10:15:36AM +0200, Fulvio Risso wrote:
> Not only.
> BPF does not support:
> - stateful inspection
> - multiple return values (only 1/0)
> - multiple outputs (I want to know, for example the amount of traffic IP
> *and* TCP)
My solution to this is to use the classifi
On Thu, May 03, 2001 at 09:50:25AM +0200, Luigi Rizzo wrote:
> wrong. It is an interpreted bytecode, much slower than,
> say, approaches which translate individual filters into
> native machine code (DPT/DPF ? don't remember the exact reference,
> it was some usenix/sigcomm paper).
The fact
>O.K., I have taken the gre-tun.c code and learned how to use the
>tun device. Then, I thought, I would simply build an RFC 1933
>IP over IP(v4) tunnel daemon (iptund). This was all very simple
>and worked using any kind of protocol, except -- BUMMER -- I
>can't open a raw IP socket with the IP
yes you are correct.
netgraph will allow you to write any random data to an
ethernet port. (no headers will be prepended..)
chek out netgraph(3)
and nghook as example code.
also check the various examples in /usr/share/examples/netgraph too.
gotta go.. My flight leaves soon.. (am
in Singapore
>
> Should I be able to "tcpdump -i gif0"? tcpdump indicates it's listening
> on gif0 but I never capture anything.
>
> My gif's look like this:
> gif0: flags=8091 mtu 1440
> inet 10.3.1.1 --> 10.3.2.1 netmask 0x
> physical address inet 207.76.205.83 --> 207.76.205.115
>
In some email I received from Jason R Thorpe, sie wrote:
> On Thu, May 03, 2001 at 10:01:18AM +1000, Darren Reed wrote:
>
> > > BPF "expressions" are literally BPF bytecodes.
> >
> > Well, one of the goals of IPFilter is it can parse (as rules) a textual
> > representation of what's currentl
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Luigi Rizzo
> Sent: Thursday, May 03, 2001 09:50
> To: Gunther Schadow
> Cc: Darren Reed; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROT
On Thu, May 03, 2001 at 09:50:25AM +0200, Luigi Rizzo wrote:
> wrong. It is an interpreted bytecode, much slower than,
> say, approaches which translate individual filters into
> native machine code (DPT/DPF ? don't remember the exact reference,
> it was some usenix/sigcomm paper).
http://www.pd
> is fast, as fast as it gets. It is my understanding that BPF
> is very fast
wrong. It is an interpreted bytecode, much slower than,
say, approaches which translate individual filters into
native machine code (DPT/DPF ? don't remember the exact reference,
it was some usenix/sigcomm paper).
>
Darren Reed wrote:
>
> In some email I received from Jason R Thorpe, sie wrote:
> > On Thu, May 03, 2001 at 08:30:55AM +1000, Darren Reed wrote:
> >
> > > IPFilter 4.0 will, as part of its general increase in kernel bloat,
> > > let you use BPF expressions for matching. There are other things
18 matches
Mail list logo
