Hi,
Some times I don't need addition of host route when I'm setting iface's
address like in this case :
xl0: flags=8943 mtu 1500
options=3
inet 212.36.9.113 netmask 0xfe00 broadcast 212.36.9.255
ether 00:04:76:1b:cb:72
media: Ethernet autoselect (100baseTX
> Here is an configuration example:
>
> vmbsd# routed
> vmbsd# ifconfig
> lnc0: flags=8843 mtu 1500
> inet 192.168.201.143 netmask 0xff00 broadcast
> 192.168.201.255
> ether 00:50:56:ac:c9:7a
> lnc1: flags=8843 mtu 1500
> inet 192.168.202.143 netmask 0xff00 broadc
> You might want to take a look at Marko Zec's VIPA patches that he posted to
> -net a few days ago. You should be able to find it in the mailing list
> archives under the subject "Patch for review: source VIPA".
> If you have the time to review/test his patches, then perhaps we can get
> i
On Thu, 6 Jun 2002, Marko Zec wrote:
> Iasen Kostov wrote:
>
> > > You might want to take a look at Marko Zec's VIPA patches that he posted to
> > > -net a few days ago. You should be able to find it in the mailing list
> > > archives under the
On Thu, 6 Jun 2002, Marko Zec wrote:
> "Vladimir B. Grebenschikov" wrote:
>
> > [snip]
> > first try to specify source address to ping
> >
> > # ping -S 1.1.1.1 dest
> >
> > where 1.1.1.1 - address on fxp0
> >
> > and you can set on your vlanX interfaces same addreses ad on your fxp0
> > with n
On Thu, 6 Jun 2002, Marko Zec wrote:
> "Vladimir B. Grebenschikov" wrote:
>
> > ÷ Thu, 06.06.2002, × 18:48, Marko Zec ÎÁÐÉÓÁÌ:
> >
> > > > # ifconfig fxp0 1.1.1.1/24
> > > > # ifconfig vlan0 1.1.1.1/32
> > > > # ifconfig vlan1 1.1.1.1/32
> > > > # ifconfig vlan2 1.1.1.1/32
> > >
> > > This will
I think it's possible to use SIOCSIFCAP to tell the kernel not to set
host route via IFCAP_NOROUTE or something similar which will set
IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit()
and if it is set no host route will be added. And ofcourse there should be
a way to set
On Fri, 7 Jun 2002, Iasen Kostov wrote:
>
> I think it's possible to use SIOCSIFCAP to tell the kernel not to set
> host route via IFCAP_NOROUTE or something similar which will set
> IFCAP_NOROUTE in uif_capenable. This flag will be checked in in_ifinit()
> and if it
Here is the patch. I'm now looking in the code to see where kernel
replays to the interface table requests. I hope there are not a lot
of places where it sets ifm_flags.
> This certainly seems to make sense. Could you generate a patch and send
> it to me ? I can test & commit it, and then may
...
On Sat, 8 Jun 2002, Brian Somers wrote:
> On Sat, 8 Jun 2002 21:53:59 +0300 (EEST), Iasen Kostov <[EMAIL PROTECTED]> wrote:
> > Here is the patch. I'm now looking in the code to see where kernel
> > replays to the interface table requests. I hope there are not a l
Hi,
I'm now using a MP system (dual opteron) to do NAT for about 1500
clients at once at speed above 200Mbit/sec full-duplex (e.g about
400Mbit/sec) and I'm using PF to do the NAT. Bad thing is that the
second CPU is idle. As I can see from top - about 50% of the cpu is used
by irq handler
On Thu, 2006-03-02 at 15:26 +0200, Iasen Kostov wrote:
> Hi,
> I'm now using a MP system (dual opteron) to do NAT for about 1500
> clients at once at speed above 200Mbit/sec full-duplex (e.g about
> 400Mbit/sec) and I'm using PF to do the NAT. Bad thing is that the
>
On Fri, 2006-03-03 at 01:35 +, Robert Watson wrote:
> On Thu, 2 Mar 2006, Iasen Kostov wrote:
>
> > I'm now using a MP system (dual opteron) to do NAT for about 1500 clients
> > at
> > once at speed above 200Mbit/sec full-duplex (e.g about 400Mbit/sec) and I&
On Wed, 2006-03-15 at 18:16 +0800, Chih-Chang Hsieh wrote:
> We have a FreeBSD 6.1-PRELEASE box.
>
> It runs with 2 em NICs and uses if_bridge + IPFW + ipfilter + pf.
>
> This box usually gets a very high interrupt rate >90%.
>
> By using netstat -I em0 1, we see:
>
> input (em0) output
> packe
Hello
A friend of mine has Compaq nx6125 with onboard wireless BCM9 4318
MPG. (pciconf -lv :
[EMAIL PROTECTED]:2:0: class=0x028000 card=0x1356103c chip=0x431814e4 rev=0x02
hdr=0x00
vendor = 'Broadcom Corporation'
class= network
)
When I create KLD with ndisgen (everything works p
On Sun, 2006-04-30 at 15:57 +0200, Paolo Pisati wrote:
> I just released a new revision of my libalias+ipfw work as a
> patchset for 6.x, get it here:
> http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz
>
> To apply it:
>
> cp libalias_ipfw.patch /usr/src
> cd /usr/src
> patch
On Tue, 2006-05-02 at 12:04 -0400, Scott Ullrich wrote:
> On 5/2/06, Iasen Kostov <[EMAIL PROTECTED]> wrote:
> [snip]
> > Btw what is the status of the multi-session to the same
> > point PPTP NAT (e.g call ID tracking) ?
>
> PF's NAT has the same problem.
On Tue, 2006-05-02 at 18:24 +0200, Paolo Pisati wrote:
> On Tue, May 02, 2006 at 02:38:35PM +0300, Iasen Kostov wrote:
> > Have you done any performace comparisons with pf's NAT ? I realy would
> > prefer libalias based kernel NAT than pf because libalias works better
>
On Tue, 2006-05-16 at 01:04 +0200, OxY wrote:
> hi!
>
> i have a little irregular problem with default route..
> here are the details:
>
> have two interfaces with the same ip, em0 connected to another server with
> crosslink,
> em1 is the public, can be reached from the internet connected to a
On Wed, 2006-05-17 at 13:33 +0200, Unix-Solutions - Steven wrote:
> I'm need a point-to-point link between 2 servers
> with just a crossover cable between the servers.
>
I've got no poblem:
box1:
ifconfig em0 10.0.0.1 netmask 255.255.255.255
route add -net 10.0.0.2/32 -iface em0 -clonin
On Tue, 2 Jul 2002, Bosko Milekic wrote:
...
> > > Here's what happens:
> > >
> > > Consumers A and B each keep their own "pools" of mbufs+clusters.
> > > ...
> >
> > look, this is exactly what happens with network interfaces. If
> > they fail to allocate a new mbuf, they keep recycling
I've tested our LAN when I come to this:
I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing
"All mbufs exhausted, see tuning(7)".
if you cancel execution of nbtscan - everything is ok but:
10112/10112/10112 mbufs in use (current/peak/max):
9822 mbufs allocated to da
the kernel) which is called from nfs_lookup and so on ...
Mbufs exhaustion is just condition for this panic as I saw.
On Mon, 4 Nov 2002, Lefteris Tsintjelis wrote:
> You need to increase kern.ipc.nmbufs
>
> sysctl -w kern.ipc.nmbufs=...
>
> Iasen Kostov wrote:
> >
> >
As I experience system crushes at time of mbufs exhaustion I've compiled
a debug kernel and traced the problem. I seems the NFS functions
(nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have
allocated memory by MGET macro.
First problem that I saw was in nfsm_reqh at nfs/nfs_subs.c
On Tue, 5 Nov 2002, Archie Cobbs wrote:
> Iasen Kostov writes:
> > As I experience system crushes at time of mbufs exhaustion I've compiled
> > a debug kernel and traced the problem. I seems the NFS functions
> > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they
On Wed, 6 Nov 2002, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Archie Cobbs wri
> tes:
> >Oops, you're right.. sorry for the misinformation.
> >
> >Sounds like a bug to me (did Iasen file a PR?)
>
> kern/38872 already exists, and I'm sure there is a much older PR
> that also describes th
On Wed, 29 Jan 2003, Dave Cornejo wrote:
> We have this running on Linux, but it's my belief that we're actually
> exploiting a bug or flaw in the Linux routing. The closest I've
> gotten is to set add a route like this on .1:
>
> .1 has a netmask of 0x
>
> route add 192.168.1.2 -interf
Use :
route add -net 10.17.47.37/32 -cloning -iface xl0
that sould work.
On Wed, 5 Mar 2003, J. W. Ballantine wrote:
>
> Sorry, my typo. I did try
> route add -net 10.0.0.0 -interface xl0
> and
> route add -net 10.17.47.37 -interface xl0
>
> As I recall both didn't respond with a error messa
netstat -s -p ip
.
.
.
3575124 datagrams with bad address in header
Could it be this that drops "bad" packets before they enter the IPFW ?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe,
Andrew Riabtsev wrote:
Привет Iasen,
Wednesday, February 25, 2004, 3:37:25 PM, you wrote:
IK> netstat -s -p ip
IK> .
IK> .
IK> .
IK> 3575124 datagrams with bad address in header
IK> Could it be this that drops "bad" packets before they enter the IPFW ?
To me it would be also interes
Gleb Smirnoff wrote:
On Wed, Feb 25, 2004 at 04:47:03PM +0300, Andrew Riabtsev wrote:
A> To me it would be also interesting to know where this traffic comes
A> from. I have same on my local net:
A>
A> # tcpdump -neifxp0 src or dst 127.0.0.1
A> tcpdump: listening on fxp0
A> 16:26:23.280737 0:50:fc
Andrea Venturoli wrote:
** Reply to note from Gleb Smirnoff <[EMAIL PROTECTED]> Wed, 25 Feb 2004 17:21:34 +0300
P.S. This is really off-topic already. We should move to -isp@ may be.
I don't really think so, why would it be?
It's concerning ipfw, netstat, traffic and the IP stack in gener
The problem is that there is a route in zebra's conf like this "ip route
192.168.100.0/24 tun0" and when zebra first starts there is still not
tun0. In the moment of setting up the tun0 interface (creating or
associating IP) it looks like zebra tries to add this route which until
this moment is
Iasen Kostov wrote:
The problem is that there is a route in zebra's conf like this "ip
route 192.168.100.0/24 tun0" and when zebra first starts there is
still not tun0. In the moment of setting up the tun0 interface
(creating or associating IP) it looks like zebra tries to add th
Iasen Kostov wrote:
Iasen Kostov wrote:
The problem is that there is a route in zebra's conf like this "ip
route 192.168.100.0/24 tun0" and when zebra first starts there is
still not tun0. In the moment of setting up the tun0 interface
(creating or associating IP) it looks like
Pawel Malachowski wrote:
On Mon, Oct 25, 2004 at 07:12:18PM +0300, Iasen Kostov wrote:
This is the segment of code:
if ((rt->rt_flags & RTF_HOST) == 0 &&
SIN(rt_mask(rt))->sin_addr.s_addr != 0x)
rt->rt_flags |=
Pawel Malachowski wrote:
Hello,
I would like to ask people using mpd about performance on particular hardware
setups. I am interested in the numbers of sessions (probably PPTP with weak
encryption) and total bandwith, that can be achieved with, e.g.:
. 300MHz CPU,
. 1GHz CPU,
. 2GHz CPU.
Won't PPPo
Pawel Malachowski wrote:
On Thu, Oct 28, 2004 at 03:38:08PM +0400, Gleb Smirnoff wrote:
I'd suggest to choose PPPoE, not PPTP, because the latter is quite
complicated and violated by some client implementation. You will
not find any problems with PPPoE, since ng_pppoe is compatible with
all know
Hi,
if I understand next code correctly maximum number of MACs is bound to
maximum number of ports ?!?. Why is that ?
code from net/bridge.c:
c[n_clusters].my_macs = (struct bdg_addr *)
malloc(BDG_MAX_PORTS * sizeof(struct bdg_addr),
M_IFADDR, M_NOWAIT | M_ZERO);
T
Iasen Kostov wrote:
Hi,
if I understand next code correctly maximum number of MACs is bound to
maximum number of ports ?!?. Why is that ?
code from net/bridge.c:
c[n_clusters].my_macs = (struct bdg_addr *)
malloc(BDG_MAX_PORTS * sizeof(struct bdg_addr),
M_IFADDR
Hi,
this is a small patch which will make bridge stats
look nicer (or at least look some way :) ), because
this is current situation:
-- Bridging statistics (bdg) --
Name In Out Forward DropBcastMcastLocal
Unknown
vlan5:1 709303965749269168687899969 123884 1390
Iasen Kostov wrote:
Hi,
this is a small patch which will make bridge stats
look nicer (or at least look some way :) ), because
this is current situation:
-- Bridging statistics (bdg) --
Name In Out Forward DropBcastMcast
Local Unknown
vlan5:1
Robert Watson wrote:
On Sat, 27 Nov 2004, Kevin Day wrote:
I recently upgraded to 5.3 on a system, and manually upgraded
src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of if_em.c)
I'm able to reproduce problems using the below configuration is 6.x also,
and am investigating.
Iasen Kostov wrote:
Robert Watson wrote:
On Sat, 27 Nov 2004, Kevin Day wrote:
I recently upgraded to 5.3 on a system, and manually upgraded
src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of
if_em.c)
I'm able to reproduce problems using the below configuration is 6.x
hem to reboot the machine :).
On Tue, Dec 07, 2004 at 04:22:16PM +0200, Iasen Kostov wrote:
Iasen Kostov wrote:
Robert Watson wrote:
On Sat, 27 Nov 2004, Kevin Day wrote:
I recently upgraded to 5.3 on a system, and manually upgraded
src/sys/dev/em/* to the latest RELENG
Iasen Kostov wrote:
Tony Ackerman wrote:
What is the purpose of putting em1 in promiscuous mode below? Is
the required or did you just notice the issue with this configuration?
There was a change added some months ago in order to allow the
bridging of vlans. In order for vlan briding to work the
Iasen Kostov wrote:
Iasen Kostov wrote:
Tony Ackerman wrote:
What is the purpose of putting em1 in promiscuous mode below? Is
the required or did you just notice the issue with this configuration?
There was a change added some months ago in order to allow the
bridging of vlans. In order for vlan
Sorry for that much posts but something weird is going on ... I left
bridge for a while (more than route/arp cache period) and then the stopped.
Same happens when you clear the arp cache as I find out. And as I
expected arps didn't get from the bridge to the host (wherever who-has
ot is-on).
A
Robert Watson wrote:
On Tue, 7 Dec 2004, Iasen Kostov wrote:
Is there an update on this case or I should find a way to disable
all hw "things" in the driver ?:) (because things are getting hot here
:).
Try the attached patch? The vlan header in promisc mode was getting
inse
Robert Watson wrote:
On Wed, 8 Dec 2004, Iasen Kostov wrote:
The patch generates .rej against this version:
/*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40
rwatson Exp $*/
should I use the version from -CURRENT or it is possible (adjusted
patch) to work with this
Iasen Kostov wrote:
Robert Watson wrote:
On Wed, 8 Dec 2004, Iasen Kostov wrote:
The patch generates .rej against this version:
/*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40
rwatson Exp $*/
should I use the version from -CURRENT or it is possible (adjusted
patch) to
Iasen Kostov wrote:
Iasen Kostov wrote:
Robert Watson wrote:
On Wed, 8 Dec 2004, Iasen Kostov wrote:
The patch generates .rej against this version:
/*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40
rwatson Exp $*/
should I use the version from -CURRENT or it is possible
Hi,
I'm running some pptp servers using poptop+ppp and now I'm trying
how the situation will look like with mpd. I'm comparing two pptp ACs -
one using poptop+ppp and one using mpd. Both have 250 connected users
who are generating about 1MByte/sec.
poptop+ppp :
CPU states: 13.6% user, 0.0%
Iasen Kostov wrote:
Hi,
I'm running some pptp servers using poptop+ppp and now I'm trying
how the situation will look like with mpd. I'm comparing two pptp ACs
- one using poptop+ppp and one using mpd. Both have 250 connected
users who are generating about 1MByte/sec.
p
IMHO proxy arp should only replay on specified interface not on every
arp capable interface which recieved request for the proxied address.
If lets say host A have arp capable if0 and if1 interfaces and U set:
route add -host 1.0.0.2 -iface if1 -proxy
and then a request is recieved
On Mon, 2005-10-10 at 14:32 +0400, Gleb Smirnoff wrote:
> Iasen,
>
> On Fri, Oct 07, 2005 at 05:58:55PM +0300, Iasen Kostov wrote:
> I>IMHO proxy arp should only replay on specified interface not on every
> I> arp capable interface which recieved request for the pro
On Fri, 2005-10-07 at 11:52 -0400, Chuck Swiger wrote:
> Iasen Kostov wrote:
> > IMHO proxy arp should only replay on specified interface not on every
> > arp capable interface which recieved request for the proxied address.
>
> This is an interesting idea, but shouldn&#x
When will if_em support 82572EI (and 82572 in general).
I saw this
http://archives.neohapsis.com/archives/openbsd/cvs/2005-10/0235.html
from which is this quote:
"Sync up to Intel's latest FreeBSD em driver which adds
support for the 82571 and 82572 PCI Express chips."
but I can't find s
On Wed, 2005-11-16 at 09:40 -0800, Julian Elischer wrote:
> Iasen Kostov wrote:
>
> > When will if_em support 82572EI (and 82572 in general).
> >I saw this
> >http://archives.neohapsis.com/archives/openbsd/cvs/2005-10/0235.html
> >
> >from which is this
On Wed, 2005-11-16 at 14:39 -0800, Julian Elischer wrote:
> >
> The latest Intel version is 3.2.18 I have a copy of it I got directly.
> but we are under NDA etc. It has a regular BSD copyright header on it
> so it looks like it should be ok for them to commit it but
> they may not be ready yet. i
On Sat, 2005-11-26 at 17:31 +0300, Gleb Smirnoff wrote:
> On Wed, Nov 16, 2005 at 07:00:14PM +0200, Iasen Kostov wrote:
> I>When will if_em support 82572EI (and 82572 in general).
> I> I saw this
> I> http://archives.neohapsis.com/archives/openbsd/cvs/2005-10/0235.html
>
61 matches
Mail list logo
