Hi,
I tried to keep the route messages to be legacy compatible due to reported
breakage at the time. Let me revisit the code and get back to you.
I haven't run the quagga code for years, so please don't mind me request
some information from you offline.
--Qing
The problem you described here seemed familiar so I checked into the svn
history,
and found I have in fact fixed this issue in other parts of the code.
Please see
http://svnweb.freebsd.org/base?view=revision&revision=186708
So I think similar fix should be applied here as well.
--Qing
__
Hi,
>
> I can confirm I get these messages as well:
>
> Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
> 86.58.122.125
> Mar 7 19:40:25 opole kernel: arpresolve: can't allocate llinfo for
> 86.58.122.125
>
> IP 86.58.122.125 is not from IP pool used by me.
>
This kernel
>
> > V>
> > V> Could this be
> http://svnweb.freebsd.org/base/head/sys/netinet/in.c?r1=226120&r2=22622
> 4&pathrev=226331
> >
> > Why do you suspect this one?
>
> I was hitting a similar issue in 8.2. After down/up on the interface
> to the default gateway, I saw this message and arpresolve woul
>
> got message of size 184 on Wed Sep 12 00:15:49 2012
> RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0,
> flags:
> locks: inits:
> sockaddrs:
> default default default ### <- This looks normal, I
> usually see it when customers connect to
>
It is not working properly in one case, of load balancing among physical
interfaces having a single prefix, all are attached to the same physical
link, and reaching a single first-hop router.
The feature itself, of installing (/removing) multiple routing entries of
varying
first-hop to the same
and try to come up with a patch.
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of David DeSimone [f...@verio.net]
Sent: Tuesday, May 15, 2012 4:14 PM
To: freebsd-net@freebsd.org
Subject: Re: [stable-9]
Li, Qing
The route selection is based on a hash function of source-ip and destination-ip
when
RADIX_MPATH is enabled. You do not need to perform specific actions, other than
perhaps
setting varying weights on each entry as an option. So depends on the traffic
destination
the chosen route may always be
Okay, this is good information. I will look into it now.
Thanks,
--Qing
> -Original Message-
> From: Ryan Stone [mailto:ryst...@gmail.com]
> Sent: Thursday, April 26, 2012 7:03 AM
> To: Li, Qing
> Cc: freebsd-net
> Subject: Re: Removing an IPv6 address does not rem
The patch is located at
http://people.freebsd.org/~qingli/nd6_prefix.diff
Please give it a try. I did only basic testing as of now and
will do more tomorrow.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Beh
> >
> > I have a patch that has been sitting around for a long time due to
> > review cycle latency that caches a pointer to the rtentry (and
> > llentry) in the the inpcb. Before each use the rtentry is checked
> > against a generation number in the routing tree that is incremented
> on
> > every
Yup, all good points. In fact we have considered all of these while doing
the work. In case you haven't seen it already, we did write about these
issues in our paper and how we tried to address those, flow-table was one
of the solutions.
http://dl.acm.org/citation.cfm?id=1592641
--Qing
> >
> >
>
>From previous tests, the difference between flowtable and
>routing table was small with a single process (about 5% or 50ns
>in the total packet processing time, if i remember well),
>but there was a large gain with multiple concurrent processes.
>
Yes, that sounds about right when we did the te
>
> [rstone@vm-head ~]ndp -a
> Neighbor Linklayer Address Netif ExpireS
> Flags
> 1::2 08:00:27:1e:b8:16em0 7sR
> fe80::a00:27ff:fefa:8732%em0 08:00:27:fa:87:32em0 permanent R
> rstone@vm-head ~]uname -a
> Fre
-Qing
From: Ryan Stone [ryst...@gmail.com]
Sent: Monday, April 09, 2012 4:50 PM
To: Li, Qing
Cc: freebsd-net
Subject: Re: Removing an IPv6 address does not remove NDP entries on that subnet
On Mon, Apr 9, 2012 at 5:46 PM, Li, Qing wrote:
> Could you plea
test case that uncovers the issue ?
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> Sent: Monday, April 02, 2012 10:54 AM
> To: Ryan Stone
> Cc: freebsd-net
> Subject: RE: Removing
>
> On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing wrote:
> >> * In a way this is a good thing as in6_lltable_prefix_free() is
> >> guaranteed to crash your kernel in two different ways, and that's
> not
> >> counting the race conditions that it's su
>
> Currently, if you remove an IPv4 address from an interface, all ARP
> cache entries on its subnet are invalidated. However, the same thing
> is not done for NDP cache entries when an IPv6 address is removed*.
> Is this correct behaviour? It seems weird to have IPv4 and IPv6
> behave differen
Yes, what you are trying to do is allowed and is supported. In fact several
bugs
were fixed to support such configuration properly. For example, see these
commits:
http://svnweb.freebsd.org/base?view=revision&revision=225947
http://svnweb.freebsd.org/base?view=revision&revision
Hmm... I don't see this problem until multiple FIBs are enabled.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Steven Hartland
> Sent: Wednesday, February 08, 2012 11:13 AM
> To: Gary Palmer
> Cc: freebsd-net@fr
So you have RADIX_MPATH option enabled in the kernel configuration, and booting
up OpenBGPD triggers the crash immediately ?
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Joe Holden [li...@rewt.org.uk]
Sent: Monday
Could you please apply this patch
http://svnweb.freebsd.org/base?view=revision&revision=227002
and let me know how it works out for you ?
Thanks,
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Slono Slono [sl
First thing comes to mind is to check if "rl0" is running in promiscuous mode.
Check ifconfig output, and do a "ifconfig rl0 -promisc" just for good measure
and
see what happens.
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org]
The host-id/interface-id can have a specific value and is properly masked out
when
adding a prefix route. As in
route add -net 192.103.54.9/24 10.9.44.1
OR for IPv6
route add -inet6 -net 2001:db8:1::1/48 2001:418:1800::1
The problem is when deleting the route, simpl
>
> Yep found that, but it was post 8.2 so don't have it here and tbh if its
> that broken that an IP move doesn't work it could also do with some
> serious warning if enabled, otherwise some unsuspecting sole is going
> to end up in a similar situation to us tonight, scratching their heads
> thing
> net.inet.flowtable.stats: net.inet.flowtable.nmbflows: 197632
> net.inet.flowtable.tcp_expire: 86400
> net.inet.flowtable.fin_wait_expire: 600
> net.inet.flowtable.udp_expire: 300
> net.inet.flowtable.syn_expire: 300
> net.inet.flowtable.enable: 1
> net.inet.flowtable.debug: 0
>
> This mean y
You don't have the flowtable component enabled, do you ?
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Steven Hartland [kill...@multiplay.co.uk]
Sent: Friday, October 21, 2011 4:44 PM
To: freebsd-net@freebsd.org
S
This failure showed up in the IPv6 Ready Logo test suites and I am fixing it.
I already made a checkin recently on this front, and more is coming.
http://svnweb.freebsd.org/base?view=revision&revision=226451
I will be posting the test results soon so we know where we are.
--Qing
__
Hi,
I believe I have identified the root cause based on the data provided by Larry
Baird, but I am
still verifying the patch against the mpd5 code. In a nutshell, the host route
installed by mpd5
appears to be missing a flag resulting in the crash.
In the meantime, please try the following fi
Here is one of my specific responses to the PRs.
http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026506.html
-- Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Friday, October 07
The important thing is if you have questions, just ask me.
You can start from this email thread.
http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026423.html
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on
Hi,
Yes, I believe this patch will be part of RC1. I just need to follow
through with the release process. I will let you know once confirmed.
--Qing
> -Original Message-
> From: Matt Smith [mailto:m...@xtaz.co.uk]
> Sent: Tuesday, October 04, 2011 12:21 PM
> To: Li, Qing
&
Hi,
Please download the newer patch from
http://people.freebsd.org/~qingli/in6.c.diff
This patch ought to fix both problems.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> S
I believe there is actually another bug needs fixing. Let me confirm and will
provide
another patch later.
--Qing
From: Matt Smith [m...@xtaz.co.uk]
Sent: Tuesday, October 04, 2011 3:33 AM
To: Li, Qing
Cc: freebsd-net@freebsd.org
Subject: Re: gif
Hi,
This address is for IPv6 Node Information Query, called the NI Group Address.
For example, you can issue the command
ping6 -w fe80::250:fcff:feb8:5443%rl0
you can get your hostname back.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freeb
>
> Just to let you know that I was doing a lot of testing off of the
> mailing list with Hiroki Sato and we basically discovered that I was
> missing an alias on my lo0 interface. He first advised me to try
> testing with adding a /126 to gif0 rather than a /128 which worked
> successfully. Then
Hi,
I saw the thread but I was traveling the whole of last week, did not
have a system to work on.
The problem you encountered on gif was due to a bug in the IPv6 code.
I believe have a patch but I need to do more testing. I will post it shortly.
--Qing
> -Original Message-
> From: o
Do you have a FBSD version # ?
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of jerome zh
> Sent: Monday, September 19, 2011 5:36 AM
> To: freebsd-net@freebsd.org
> Subject: ICMPv4/v6 redirect pkt received but route
Thank you Chris for the verification. I will wait a few days before committing
the patch.
--Qing
From: Chris Miller [mailto:chrismiller@gmail.com]
Sent: Monday, August 29, 2011 7:31 PM
To: Li, Qing
Cc: freebsd-net@freebsd.org
Subject: Re: arpresolve: can't allocate llinfo
Qing-
Hi,
Yes, the address alias and its associated prefix installation code changed.
Operationally it makes sense because all addresses of that same prefix go
through one route utilizing that given interface.
The side effect is you can have two separate interfaces on the same prefix,
but only a singl
Hi,
Could you please try the patch sitting at
http://people.freebsd.org/~qingli/in.c.diff
and let me know if it works for you?
Thanks,
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Chris Miller
> Sen
This issue should have been fixed quite a while ago.
I need to go through my past commits and see if everything has been merged back
into the 8.1 branch.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Chris Mill
First of all, are you encountering any issues ?
There is an outstanding issue with the address alias and improper routing
table update that I am actively working on.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of
2, 2011 9:06 AM
> To: Li, Qing
> Cc: freebsd-net@freebsd.org; Ingo Flaschberger
> Subject: Re: interface ip arp
>
> Hi,
>
> On Mon, May 2, 2011 at 4:03 AM, Li, Qing wrote:
> > Please give this patch a try for IPv4 ARP
> >
> > http://people.freebsd.org/~qingli
Please give this patch a try for IPv4 ARP
http://people.freebsd.org/~qingli/arp2.patch
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Monday, May 02, 2011 12:45 AM
To: Arnaud Lacombe
Cc: freebsd
rking patch for IPv4, just going over the IPv6 code.
I will post the patch in a few minutes.
-- Qing
From: Arnaud Lacombe [lacom...@gmail.com]
Sent: Monday, May 02, 2011 12:41 AM
To: Li, Qing
Cc: Ingo Flaschberger; freebsd-net@freebsd.org
Subject: Re: interfa
jeez, this bug has been around for quite a while ...
Please try patch at http://people.freebsd.org/~qingli/arp.patch
-- Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Sunday, May 01, 2011 4:54 PM
To
That's not the expected behavior, probably a bug, I will take a look ...
-- Qing
On May 1, 2011, at 4:51 PM, "Ingo Flaschberger" wrote:
>> is it expected behaviour that the static, permanent arp entry of the
>> interface ip disappear after ifdown/ifup at 8.x release?
>>
>> ifconfig em0 10.
I see,
What you are saying is the "rtalloc()" call does not have an indicator whether
it should be searching
for an interface route or not.
In the case when RADIX_MPATH is enabled, in_lltable_rtcheck() needs to walk the
ECMP route chain
to find an interface route.
yes ?
-- Qing
kern/155772 can be resolved using RADIX_MPATH.
>
> regarding kern/155772:
> at stock 8.2 FreeBSD the system panics after ifconfig down / ifconfig up /
> ifconfig down with 1 route and 1 interface route (multipath).
>
What's the exact step and a specific example that triggers a panic ?
>
> A
The self-pointing route 10.0.5.1 should have multiple references set on
it, and that route won't be deleted from the routing table until the
last reference is removed.
You can verify that by checking the "netstat" output, the "Ref" column
after tun1 has been created.
The above has been verifie
As I am revising the ECMP code and reviewing the work done
by Ingo Flaschberger, I come to the conclusion that I need
to make one more enhancement to ECMP.
I want to implement the "inetCidrRouteProto" concept as the
2nd variable that differentiates among the ECMP routes.
I have already started on
There are a couple of items I need to take care of
in this area, including the documentation, so I will get
it done this weekend.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Zeus V Panchenko
> Sent: Thursday, A
>
> > Sure, but such a configuration did not make much sense.
>
> Why not?
> Use CARP and OSPF and you have such a configuration.
>
Okay, I will try that.
>
> I hoped, that now, as freebsd has multi-route support (as other unix
> really have for a long long time) everything would be easie
>
> > I am trying to figure out, if the routing table have
> >
> > 10.13.13.0/24 10.11.11.1
> > 10.13.13.0/24 link#1
> >
> > And if I do "ssh 10.13.13.2", which route should be used?
>
> the route with the lower weight.
> if they have the same weight, use any of them.
>
I get the pr
Tuesday, August 24, 2010 11:28 AM
> To: Li, Qing
> Cc: n...@freebsd.org
> Subject: RE: funny ECMP
>
> Dear Li,
>
> > The indirect route is colliding with the interface route, both have
> > the same mask.
> >
> > How do you expect this to work ?
> >
Hi,
The indirect route is colliding with the interface route, both have
the same mask.
How do you expect this to work ?
How would the routing code differentiate between on-link nodes and
the those needing to be routed through 10.11.11.1 ?
-- Qing
>
> one of the problems:
> sysctl -w net.inet.
> >
> >> As Qing Li mentioned months ago, there are problems with static
> routes
> >> and interfaces.
> >>
> >
> > Do you have the exact link to the email thread?
> > There were no pending ECMP related issues since my last round of
> > commits
> > as far as I can remember.
>
>
http://lists.fre
Hi,
>
> I have changed the route selection code of ecmp to
> balance only between routes of the same weight.
> (see attached file)
>
>
> As Qing Li mentioned months ago, there are problems with static routes
> and interfaces.
>
Do you have the exact link to the email thread?
There were
Hi Ruslan,
>
> Doesn't seem to have any effect. Please see
> http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024728.html
> on how to reproduce.
>
Could you please try the patch at:
http://people.freebsd.org/~qingli/ng-patch.diff
I was able to reproduce the problem and the p
Hi Ruslan,
Yes, I can reproduce this issue. The patch is still necessary, however,
it does not resolve the if_ng issue because if_ng is a virtual interface
that is not really associated with any physical nic. The physical NIC is
where all of the entries (including the proxied entries) are kept.
>
> Yes, it's still broken (it's a regression compared to 7.x). A
> workaround I've found working after analyzing the newer kernel
> code is to ALWAYS use the same IP address for the local end of
> the tunnel as of the corresponding ARP capable interface.
>
Are you using VLANs?
Were you
I have been monitoring the tcpm ML debate about this draft for
the past year. Frankly for the past two months the volume of
tinygrams on the subject is so overwhelming I stopped reading
any email relating to this topic.
I think Mark Allman's email titled "TCPM" posted on March 2
put things into p
This topic has come up quite a few times. Please search into the ML
archive
(as recent as 2 weeks ago) and read about the details.
>
> I get an ugly error message on current, but at least it setups the
> address:
> [98]chipmunk.cicely.de# arp -an
> ? (10.1.1.9) at 00:1c:c0:94:2c:d7 on vlan0 expir
Please try this patch
http://people.freebsd.org/~qingli/nd6.c.diff
and let me know if it works out for you.
Thanks,
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> Sent: Tuesday,
Okay, I read through your core file and I think I see the problem now.
Let me try to get you a patch later tonight.
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org on behalf of Doug Barton
Sent: Tue 2/23/2010 12:38 PM
To: freebsd-net@freebsd.org
Subject: Apparent IPv6 bu
Okay, well, I need to pack. So will get back to it in a week.
-- Qing
-Original Message-
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 6:22 PM
To: Li, Qing
Cc: n...@freebsd.org; Li, Qing; Luiz Otavio O Souza
Subject: RE: Routing problems on VPN servers running FreeBSD
Read the manpage. "only" just require a host route to be present.
I don't think it will make a difference here.
-- Qing
-Original Message-
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 6:30 PM
To: Li, Qing
Cc: n...@freebsd.org; Li, Qing; Luiz Otavio
>
> It'd be good to resolve this as soon as possible, because I have
> two clients who need servers installed this weekend. (They wanted
> them last week, but I was trapped away from the office by a
snowstorm.)
>
Luiz Otavio and I have been discussing offline about an issue with
the file /usr.sb
reebsd.org , and whatever other pieces of information you are
willing to share.
Thanks,
-- Qing
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 4:04 PM
To: Li, Qing
Cc: n...@freebsd.org
Subject: RE: Routing problems on VPN servers running F
org/viewvc/base/stable/8/sys/netinet/in.c?view=log
Then please report back the result of your verification.
--Qing
From: Brett Glass [mailto:br...@lariat.net]
Sent: Fri 2/12/2010 2:39 PM
To: David Horn
Cc: Li, Qing; n...@freebsd.org
Subject: Re: Routing problems
Can you at least build one 8-stable system and see if the latest
patches resolve your problems before we carry on with the
"merge into 8-release" or other alternatives discussion ?
-- Qing
Date: Thu, 04 Feb 2010 22:41:38 -0700
From: Brett Glass
To: "Li, Q
The ECMP (indirect) routes are installed into the FIB just fine, and
load balancing works fine with these routes.
The problem is with interface prefix routes. See my other email for details.
Because only a single prefix route was installed, obviously there is no
load balancing.
-- Qing
>
> I
I told you the ECMP code is probably not the best
piece to start with, but you seem to ignore whatever I have
said completely ...
-- Qing
From: owner-freebsd-curr...@freebsd.org on behalf of Balaji G
Sent: Thu 2/11/2010 12:21 AM
To: Li, Qing
Cc: qin...@freebsd
One of the advantages of enabling ECMP is to allow for connection load
balancing.
Currently the address alias handling method is colliding with the ECMP code.
For example, when two interfaces are configured on the same prefix, only
one prefix route is installed. So connection load balancing is no
>
> Sure enough, that fixes this warning. Yea. But, sadly, it causes
> other problems. If you look at sbin/atm/atmconfig/natm.c you'll see
> code like:
>
> static void
> store_route(struct rt_msghdr *rtm)
> {
> ...
> char *cp
> struct sockaddr *sa;
> ...
>
> cp = (char
>
> Not since the ARP table and the routing table have been split.
> However, the addresses for which the machine is doing proxy ARP do
> need to show up there, and they do not.
>
You described a bug symptom that should have been fixed.
The proxy ARP entry should be displayed in the ARP table
a
>
> The problems seem to be that (a) proxy ARP doesn't get set
> up in either the ARP table or the routing table, and
>
Proxy ARP entries are not installed into the routing table.
I believe I have fixed this issue in svn r201282 and merged
into 8-STABLE
http://svn.freebsd.org/viewvc/base?view=
Few of the symptoms you described here were present in the vanilla
8.0-RELEASE but I have been fixing these in 8-STABLE since the official
announcement.
Could you please try 8-STABLE and report back if these problems
persist there?
-- Qing
> -Original Message-
> From: owner-freebsd-...@
Just an update on this issue and to letting you know your
report is not ignored.
I have been working with Sherin George offline and we have
Been pulling information off Sherin's server box.
The box becomes unresponsive after about 4 days. The routing
table is fine is properly accessed. The ARP ta
ECMP support is only available in FreeBSD 8.0.
I have not received any request to merge that feature back
into 7.x branch.
In FreeBSD 8.0, currently there is no association between interface
link state and the route availability RTF_UP flag, so ECMP cannot
be used as a failover mechanism effect
I have been consumed by day job 200% of my time.
I have some free time tonight and can work with you off-line.
Is it possible for you to update to the latest stable-8 kernel
and we start from there ?
-- Qing
-Original Message-
From: owner-freebsd-...@freebsd.org on behalf of Sherin Ge
Yes, the failure is due to route installation. To make a long story short, many
of the
scripts that worked before not necessary because of the right reasons.
I have been very busy at work, but I do have a patch and I will try to get it
finalized shortly.
-- Qing
__
>
> We only need one 'me' option that matches v4 and v6, because the
> other two can be implemented as 'ip4 me' and 'ip6 me' at no extra
> cost (the code for 'me' only scans the list corresponding to the
> actual address family of the packet). I would actually vote for
> removing the 'me6' microi
Sorry, I didn't even see your original email until today.
Please send problem reports directly to qin...@freebsd.org
instead of my work email to get faster response.
Thanks,
-- Qing
>
> On Sun, Jan 3, 2010 at 12:18 AM, David Horn
wrote:
> > Qing --
> >
> > I have been having some issues with
Hi,
Could you please tell us what version you are running?
>
> If the tcp_output just have some error, for example: when alloc mbuf,
> it returns NULL, and then the snd_nxt number will not be return to
> normal.
> If just in this time, SYN Ack arrives, freeBSD can't handle this
> situdition.
>
I
t;
> Adam Jacob Muller
> a...@adam.gs
> 201-616-0620
>
> On Dec 16, 2009, at 6:39 PM, Li, Qing wrote:
>
> > Hi,
> >
> > You have reported issues regarding openbgp/bgpd exiting
> > abnormally. Please apply patch:
> >
> >http://people.
Thanks for reporting back and the detailed description.
>
> - bgpd don't terminate, it's OK
>
Okay, making progress.
>
> but there appeared some new problems:
>
Interestingly enough, my patch is to resolve the issue where adding
and removing address aliases are not reported. This issue appears
Hi,
You have reported issues regarding openbgp/bgpd exiting
abnormally. Please apply patch:
http://people.freebsd.org/~qingli/bgpd-patch-121615.diff
and let me know if it fixes your issue. I performed limited
unit testing.
Thanks,
-- Qing
_
Hi,
Recently there have been several reports regarding issues with ppp, mpd5
and proxy-arp configuration over the ppp links. I read through the
various postings and the problems seem to be:
1. Unable to add proxy-arp entries for the remote ppp clients.
2. Log showing "ifa_add_loopback_route: ins
ebsd-
> sta...@freebsd.org] On Behalf Of Li, Qing
> Sent: Tuesday, December 15, 2009 1:46 PM
> To: Tom Pusateri
> Cc: freebsd-net@freebsd.org; freebsd-sta...@freebsd.org
> Subject: RE: patch: bad ipv6 neighbor solicitation
>
> Thanks for reporting back. I asked you for a routing table du
Thanks for reporting back. I asked you for a routing table dump
in my previous email, would you mind emailing it to me privately?
-- Qing
> -Original Message-
> From: Tom Pusateri [mailto:pusat...@bangj.com]
> Sent: Tuesday, December 15, 2009 1:28 PM
> To: Li, Qing
>
apply the
patch and report back.
Thanks,
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> Sent: Monday, December 14, 2009 3:00 PM
> To: Dennis Glatting; JASSAL Aman
> Cc: freeb
You don't need to perform all that route-foo. I believe the root cause of
this issue may be due to a bit of regression in the IPv6 prefix management
code, and I am in the process of putting together a permanent fix.
The issue as it stands today, is due to how the prefix was inserted in
the first
>
> Hmm, the entry for fd7c:3f2b:e791:1:0:1:ac13:a0a looks suspect. I was
> expecting bce1 rather than lo0, I suppose you were as well :)
>
This loopback route is necessary for short circuiting traffic to
local address within a node.
-- Qing
>
> If I'm not mistaken, the
Please try the temporary patch at:
http://people.freebsd.org/~qingli/nd6-ns.diff
and it should fix your problem.
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> Sent: Monday,
I will take a look at it later today.
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Dennis Glatting
> Sent: Sunday, December 13, 2009 1:59 PM
> To: freebsd-net@freebsd.org
> Subject: Understanding multiple IPv6
sd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> Sent: Sunday, November 22, 2009 10:40 AM
> To: Adam Jacob Muller; freebsd-net@freebsd.org
> Subject: RE: openbgpd + 8.0
>
> I am not sure if what you are observing is a side effect of
> svn-r196714. In parti
I am not sure if what you are observing is a side effect of
svn-r196714. In particular, the code I added for:
- Routing messages are not generated when adding and removing
interface address aliases.
If my memory serves me right, I put in the above patch
I will look into it and get back to you.
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Harti Brandt
> Sent: Sunday, November 22, 2009 5:09 AM
> To: freebsd-net@freebsd.org
> Subject: ARP regression in releng-8
>
1 - 100 of 177 matches
Mail list logo
