Synopsis: [route] Route messages sent to all socket listeners regardless of
setfib(1)
Responsible-Changed-From-To: freebsd-net->hrs
Responsible-Changed-By: hrs
Responsible-Changed-When: Sat Jul 16 15:46:50 UTC 2011
Responsible-Changed-Why:
I'll take this.
http://www.freebsd.org/c
09.02.2011 17:56, Sergey Matveychuk wrote:
[skipped]
DST is IPv6 address, IFP and IFA I don't care and GATEWAY section is empty.
Let's see why:
$1 = {sdl_len = 54 '6', sdl_family = 18 '\022', sdl_index = 8, sdl_type
= 135 '\207', sdl_nlen = 0 '\0',
sdl_alen = 0 '\0', sdl_slen = 0 '\0', sdl_data =
Hello.
In my routing table I see entries after Neighbor Discovery Protocol
processed:
...
2a02:6b8:0:401:51:4809:8158:1dcd 00:22:fb:3d:82:fe UHLWvlan438
...
I'd like to catch them via a routing socket when they appear.
First, try to add a static entry:
ndp -s 2a02:6b8:0:403::1:1 00:0e
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: "Alexander V. Chernikov"
To: bug-follo...@freebsd.org, co...@211.ru
Cc:
Subject: Re: kern/134931: [route] Route messages sent to all socket listeners
regardless of setfib(1)
Date: Sun, 31 Oct 2010 10:2
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: "Dyadchenko Mihail, Siberian Networks"
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket
listeners regardless of setfib
Date: Mon, 5 Oct 200
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Stef Walter
To: bug-follo...@freebsd.org, co...@211.ru, m.dyadche...@sibset-team.ru
Cc:
Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket
listeners regardless of setfib
Date: Tue, 22 Sep
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: "Dyadchenko Mihail, Siberian Networks"
To: bug-follo...@freebsd.org, Stef Walter
Cc:
Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket
listeners regardless of setfib
Date: T
On Mon, Aug 31, 2009 at 05:20:08PM +, Stef Walter wrote:
> The following reply was made to PR kern/134931; it has been noted by GNATS.
>
> From: Stef Walter
> To: bug-follo...@freebsd.org, co...@211.ru
> Cc:
> Subject: Re: kern/134931:[route] [fib] Route messages
Stef Walter wrote:
I agree in principle with Mark that having future route messages might
be able to let routing daemons differentiate between various fibs and
manage them, and that this might be a feature However any
implementation of that would likely break API and ABI, and very
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Stef Walter
To: bug-follo...@freebsd.org, co...@211.ru
Cc:
Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket
listeners
regardless of setfib
Date: Mon, 31 Aug 09 17:20:06 UTC
This is a
Julian Elischer wrote:
Stanislav A Svirid wrote:
So, how routing daemon can decide in what FIB route is changed?
Or it can't now?
I believe there is a field that has been used for this purpose in
OpenBSD, but is otherwise deprecated. anyone woth ore knowledge of
teh protocls is invited t
Stanislav A Svirid wrote:
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Stanislav A Svirid
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket
listeners regardless of setfib
Date: Wed, 27 May
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Stanislav A Svirid
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket
listeners regardless of setfib
Date: Wed, 27 May 2009 12:28:58 +0700
Bruce
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Mark Linimon
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket
listeners regardless of setfib
Date: Tue, 26 May 2009 09:43:41 -0500
lini...@freebsd.org wrote:
Synopsis: [route] [fib] Route messages sent to all socket listeners regardless
of setfib
That might actually be a feature, however, the "API contract" with the
multiple routing table support might not have covered this, so it might
be "unde
Synopsis: [route] [fib] Route messages sent to all socket listeners regardless
of setfib
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 25 13:26:31 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).
h
On Wed, 2 Jul 2008, Mike Tancsa wrote:
Hi,
It works for me in the lab and on one production machine I patched early this
morning.
I just MFCed this to 7-STABLE. So if you update your trees make sure
you have rev. 1.332.2.3 of ip_input.c.
/bz
Index: sys/netinet/ip_input.c
Works for me on test machine.. I was expecting a performance increase,
but nothing changed.. Just no more route messages, zebra will be happy.
Bjoern A. Zeeb wrote:
On Wed, 2 Jul 2008, Mike Tancsa wrote:
Hi,
Index: sys/netinet/ip_input.c
At 09:51 AM 7/2/2008, Andre Oppermann wrote:
Andre, could you review this?
Yes, this should fix the problem. I haven't tested the patch though.
It works for me in the lab and on one production machine I patched
early this morning.
---Mike
--
Andre
Index: sys/netinet/ip_input.
On Wed, 2 Jul 2008, Mike Tancsa wrote:
Hi,
Index: sys/netinet/ip_input.c
===
RCS file: /shared/mirror/FreeBSD/r/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.332.2.2
diff -u -p -r1.332.2.2 ip_input.c
--- sys/netinet/ip_in
Bjoern A. Zeeb wrote:
On Tue, 1 Jul 2008, Bjoern A. Zeeb wrote:
Hi,
On Tue, 1 Jul 2008, Andre Oppermann wrote:
Hi,
Mike Tancsa wrote:
I am thinking
http://lists.freebsd.org/pipermail/cvs-src/2008-April/090303.html
is the commit ? If I revert to the prev version, the issue goes away.
Ha,
At 05:24 AM 7/1/2008, Bjoern A. Zeeb wrote:
On Tue, 1 Jul 2008, Bjoern A. Zeeb wrote:
Hi,
On Tue, 1 Jul 2008, Andre Oppermann wrote:
Hi,
Mike Tancsa wrote:
I am thinking
http://lists.freebsd.org/pipermail/cvs-src/2008-April/090303.html
is the commit ? If I revert to the prev version, the i
At 05:24 AM 7/1/2008, Bjoern A. Zeeb wrote:
So I had a very quick look at the code between doing something else.
I think the only change needed is this if I am not mistaken but my
head is far away nowhere close enough in this code.
Hi,
The patch seems to work in that there is not an RT
On Tue, 1 Jul 2008, Bjoern A. Zeeb wrote:
Hi,
On Tue, 1 Jul 2008, Andre Oppermann wrote:
Hi,
Mike Tancsa wrote:
I am thinking
http://lists.freebsd.org/pipermail/cvs-src/2008-April/090303.html
is the commit ? If I revert to the prev version, the issue goes away.
Ha, I finally know why I e
On Tue, 1 Jul 2008, Andre Oppermann wrote:
Hi,
Mike Tancsa wrote:
I am thinking
http://lists.freebsd.org/pipermail/cvs-src/2008-April/090303.html
is the commit ? If I revert to the prev version, the issue goes away.
Ha, I finally know why I ended up on Cc: of a thread I had no idea
about. S
Mike Tancsa wrote:
I am thinking
http://lists.freebsd.org/pipermail/cvs-src/2008-April/090303.html
is the commit ? If I revert to the prev version, the issue goes away.
Yes, this change doesn't look right. It should only do the route
lookup in ip_input.c when there was an EMSGSIZE error retur
t;>
>> Any ideas what changed? :) Wish there was some sort of changelog..
>> # of messages per second seems consistent with packets per second on
>> GRE interface..
>> No impact in routing, but definitely impact in cpu usage for all
>> processes monitoring the route
ere was some sort of changelog..
>> # of messages per second seems consistent with packets per second on
>> GRE interface..
>> No impact in routing, but definitely impact in cpu usage for all
>> processes monitoring the route messages.
>
>RTM_MISS is actually fairly co
UTER amd64
>> But do not get them with 7.0-RELEASE
>>
>> Any ideas what changed? :) Wish there was some sort of changelog..
>> # of messages per second seems consistent with packets per second on
>> GRE interface..
>> No impact in routing, but definitely impa
7.0-RELEASE
>>
>> Any ideas what changed? :) Wish there was some sort of changelog..
>> # of messages per second seems consistent with packets per second on
>> GRE interface..
>> No impact in routing, but definitely impact in cpu usage for all
>> processes monit
rt of changelog..
# of messages per second seems consistent with packets per second on
GRE interface..
No impact in routing, but definitely impact in cpu usage for all
processes monitoring the route messages.
RTM_MISS is actually fairly common when you don't have a default route.
Messages
impact in routing, but definitely impact in cpu usage for all
processes monitoring the route messages.
RTM_MISS is actually fairly common when you don't have a default route.
Messages which get enqueued don't necessarily get delivered -- and
very few processes actually listen to the rou
consistent with packets per second on
GRE interface..
No impact in routing, but definitely impact in cpu usage for all
processes monitoring the route messages.
RTM_MISS is actually fairly common when you don't have a default route.
Messages which get enqueued don't necessarily get delive
packets per second on GRE
interface..
No impact in routing, but definitely impact in cpu usage for all
processes monitoring the route messages.
got message of size 160 on Fri Jun 13 16:58:37 2008
RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno
0, flags:
locks: inits
34 matches
Mail list logo
