On 4-2-2011 15:06, Stuart Henderson wrote:
On 2011/02/04 14:37, Camiel Dobbelaar wrote:
On 4-2-2011 13:32, Henning Brauer wrote:
* Camiel Dobbelaar c...@sentia.nl [2011-02-04 13:21]:
With hundreds of (vlan) interfaces, a shutdown takes quite a while.
Fix below.
hmm. this relies on all carp
On 5-2-2011 2:15, Ted Unangst wrote:
On Fri, Feb 4, 2011 at 7:21 AM, Camiel Dobbelaar c...@sentia.nl wrote:
With hundreds of (vlan) interfaces, a shutdown takes quite a while.
# bring carp interfaces down gracefully
- ifconfig | while read a b; do
On 5-2-2011 11:02, Henning Brauer wrote:
on the other side, fixing ifconfig very slow with lots of interfaces
deserves to be fixed anyway. looking at the code - either getifaddrs is
slow (which in turn wouldn't be ifconfig only), or the ioctls ifconfig
does in getinfo(). that's just 5 tho.
The valid range for vlan tags in OpenBSD is 0-4095 (inclusive). Fix
both checks.
Makes vlan0 autoconfig work (obj/ifconfig has the diff):
# ifconfig vlan0 vlandev fxp0
ifconfig: invalid vlan tag and device specification
# obj/ifconfig vlan0 vlandev fxp0
and gives a better error message on
On 16-2-2011 14:27, Reyk Floeter wrote:
My previous change to vlan(4) allows to change the vlandev and vlan id
on-the-fly without re-creating the vlan interface.
I hesitated to ask this simple question, because I might be overlooking
something, but what exactly is the advantage over just using
inet6 pf rules that rdr-to ::1 do not work currently. Matching
packets just disappear and the counter packets that violated scope
rules from a netstat -s -p ip6 gets incremented.
It came up before on misc@:
http://marc.info/?t=12680425912r=1w=2
The attached diff removes the check (let's
Mark ARP request broadcasts as such in the mbuf flags. FreeBSD and NetBSD
both have this.
Without this, bridge_output() drops ARP request broadcasts on interfaces
without the discover flag:
if ((p-bif_flags IFBIF_DISCOVER) == 0
(m-m_flags
vlandev (parent) does not need to be physical, and can be changed on the
fly now.
Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.216
diff -u -r1.216 ifconfig.8
--- ifconfig.8 13 Mar 2011
This diff changes the if_bridge pointer of an interface (struct ifnet) to
not point to the bridge but to its own bridge interface configuration.
Should be safe because an interface can only be part of one bridge.
This way all the LIST_FOREACH lineair searches in the bridge code can be
replaced.
When svlan(4) was introduced, it got its own taghash in if_vlan.c.
This wasn't necessary as etype was already checked in the old hash
lookup.
So simplify the code again, and use the savings for some extra hash
buckets. :-)
Survives this stacked test between i386 and sparc64 (use .1 on one
On Mon, 4 Jul 2011, Camiel Dobbelaar wrote:
When svlan(4) was introduced, it got its own taghash in if_vlan.c.
This wasn't necessary as etype was already checked in the old hash
lookup.
Hmmm, etype wasn't checked in rev 1.83 so it looks like my memory is
shady... I also see a comment about
On 1-8-2011 23:59, Alexander Bluhm wrote:
On Wed, Jul 27, 2011 at 12:44:21AM +0200, Alexander Bluhm wrote:
On Fri, May 20, 2011 at 11:54:09AM +0200, Camiel Dobbelaar wrote:
I'll spend some more time on this, but maybe there's an IPv6 guru that
can lend a hand? :-)
Just removing the check
Destroying a carp interface does not restore the demote count of the
carp group.
Reason is that the interface is removed from the carp group by
if_clone_destroy() before carp_clone_destroy() is run. The second reason
is a simple bug introduced in ip_carp.c, rev 1.175.
The diff removes
Adapted from NetBSD, which in turn got the id's from Linux.
Not sure about the PUC_MAX_PORTS bump from 8 to 16 (and the comment), it
grows pucdata.o from 13k to 23k (on i386) for just one card.
Index: sys/dev/pci/pcidevs
===
RCS
M_PROTO1 is used by if_bridge on the input path. On the output path it's
used now only by if_bridge for if_gif. I think we can use it generically
to mark packets as processed by bridge in the output path.
The diff simplifies things and avoids mtag checking and allocation so is
more efficient
On 4-12-2011 13:01, Sebastian Reitenbach wrote:
the default maximum size of the tcp send and receive buffer used by the
autosizing algorithm is way too small, when trying to get maximum speed with
high bandwidth and high latency connections.
I have tweaked SB_MAX on a system too, but it was
On 5-12-2011 19:45, Sebastian Benoit wrote:
I see relayd crashes like this: (1)
fatal: relay_dispatch_pfe: invalid host id
or like this: (2)
fatal: pfe_dispatch_hce: invalid host id
There is a race of the hce and the other childs (pfe and relays)
between loading the configuration and start
On Mon, 5 Dec 2011, Camiel Dobbelaar wrote:
Another might be to inhibit the processing of IMSG_HOST_STATUS only until
the configuration has been completed (that is after receiving
IMSG_CFG_DONE):
I'm going to try this one. I'm not sure how bad it is to discard
messages though.
I tried
Sorry everyone, wrong tech@ :-(
On 6-2-2012 9:31, Camiel Dobbelaar wrote:
Vitaminstote is in 24x7 now. They are allowed to contact us now when
the server is down.
They did that anyway a few times, so not a lot changes.
What we do is solve hardware and resource problems, and maybe
On 2-3-2012 15:49, Matthieu Herrb wrote:
On Fri, Mar 02, 2012 at 03:19:34PM +0100, Camiel Dobbelaar wrote:
I think the bridge loop detection in if_ethersubr.c can be removed. It
taxes all bridge output traffic, but I don't think it ever kicks in.
It was added in 2001 by angelos:
http
I need help testing this bridge diff, as I cannot test (or even imagine)
all the possible bridge setups.
It brings a nice speed improvement and simplifies the code.
Testing especially appreciated with gif, tun and vether interfaces in the
bridge.
I can provide i386 and amd64 kernels to make
On 21-9-2012 23:40, Stuart Henderson wrote:
$ ifconfig vr0 hwfeatures|head -2
vr0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu
1500
hwfeatures=8017CSUM_IPv4,CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,WOL
No problems noticed yet. (this is running i386).
$ ifconfig
On Sun, 23 Sep 2012, Stefan Sperling wrote:
On Thu, Sep 20, 2012 at 10:11:20AM +0200, Camiel Dobbelaar wrote:
I need help testing this bridge diff, as I cannot test (or even imagine)
all the possible bridge setups.
It brings a nice speed improvement and simplifies the code
In some cases when a network port comes up, it does not indicate that
the network is ready. But on linkup, carp(4) will try to get out of the
INIT state as soon as possible. And because all is quiet it will decide
to become master.
This then leads to master-master situations.
Here are
a problem, maybe you could arping the next hop and then
activate the carp ?
On Wed, Apr 3, 2013 at 9:34 AM, Stuart Henderson s...@spacehopper.orgwrote:
On 2013/04/03 14:54, Camiel Dobbelaar wrote:
In some cases when a network port comes up, it does not indicate that
the network is ready
On 4/3/13 3:54 PM, Stuart Henderson wrote:
On 2013/04/03 15:43, Camiel Dobbelaar wrote:
On 4/3/13 3:34 PM, Stuart Henderson wrote:
In some cases when a network port comes up, it does not indicate that
the network is ready. But on linkup, carp(4) will try to get out of
the INIT state
26 matches
Mail list logo
