Re: svn commit: r197687 - head/sys/net
Qing Li wrote: Author: qingli Date: Thu Oct 1 20:32:29 2009 New Revision: 197687 URL: http://svn.freebsd.org/changeset/base/197687 Log: The flow-table associates TCP/UDP flows and IP destinations with specific routes. When the routing table changes, for example, when a new route with a more specific prefix is inserted into the routing table, the flow-table is not updated to reflect that change. As such existing connections cannot take advantage of the new path. In some cases the path is broken. This patch will update the affected flow-table entries when a more specific route is added. The route entry is properly marked when a route is deleted from the table. In this case, when the flow-table performs a search, the stale entry is updated automatically. Therefore this patch is not necessary for route deletion. Hi, Will this fix the issue that I see visualising its self as packet loss over a VPN tunnel? The tunnel is an openvpn (tun mode) tunnel providing a route to 192.168.201.0/24 however when I ping an address in this network with flowtable enabled I see 2-3 out of every 5-6 packets end up being sent out of bge0 (IP 172.17.XX.XX/23 GW 172.17.XX.1) to the default gateway (which responds with destination host unreachable) rather than down tun0. Thanks Tom ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r197687 - head/sys/net
I believe this patch will fix your issue. In fact two other users of openvpn reports the exact same problem symptom. Please give it a try and let me know how it works out for you. -- Qing On Thu, Oct 1, 2009 at 11:22 PM, Tom Judge t...@tomjudge.com wrote: Qing Li wrote: Author: qingli Date: Thu Oct 1 20:32:29 2009 New Revision: 197687 URL: http://svn.freebsd.org/changeset/base/197687 Log: The flow-table associates TCP/UDP flows and IP destinations with specific routes. When the routing table changes, for example, when a new route with a more specific prefix is inserted into the routing table, the flow-table is not updated to reflect that change. As such existing connections cannot take advantage of the new path. In some cases the path is broken. This patch will update the affected flow-table entries when a more specific route is added. The route entry is properly marked when a route is deleted from the table. In this case, when the flow-table performs a search, the stale entry is updated automatically. Therefore this patch is not necessary for route deletion. Hi, Will this fix the issue that I see visualising its self as packet loss over a VPN tunnel? The tunnel is an openvpn (tun mode) tunnel providing a route to 192.168.201.0/24 however when I ping an address in this network with flowtable enabled I see 2-3 out of every 5-6 packets end up being sent out of bge0 (IP 172.17.XX.XX/23 GW 172.17.XX.1) to the default gateway (which responds with destination host unreachable) rather than down tun0. Thanks Tom ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r197687 - head/sys/net
On 2009.10.02 06:22:58 +, Tom Judge wrote: Qing Li wrote: Author: qingli Date: Thu Oct 1 20:32:29 2009 New Revision: 197687 URL: http://svn.freebsd.org/changeset/base/197687 Log: The flow-table associates TCP/UDP flows and IP destinations with specific routes. When the routing table changes, for example, when a new route with a more specific prefix is inserted into the routing table, the flow-table is not updated to reflect that change. As such existing connections cannot take advantage of the new path. In some cases the path is broken. This patch will update the affected flow-table entries when a more specific route is added. The route entry is properly marked when a route is deleted from the table. In this case, when the flow-table performs a search, the stale entry is updated automatically. Therefore this patch is not necessary for route deletion. Hi, Will this fix the issue that I see visualising its self as packet loss over a VPN tunnel? The tunnel is an openvpn (tun mode) tunnel providing a route to 192.168.201.0/24 however when I ping an address in this network with flowtable enabled I see 2-3 out of every 5-6 packets end up being sent out of bge0 (IP 172.17.XX.XX/23 GW 172.17.XX.1) to the default gateway (which responds with destination host unreachable) rather than down tun0. This sounds very similar to the problem I was seeing (also with OpenVPN), which was fixed by qingli's patch. The packet is most likely actually not lost, but routed to your default gateway instead (or whatever it would be sent before the VPN was created). -- Simon L. Nielsen ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r197687 - head/sys/net
Author: qingli
Date: Thu Oct 1 20:32:29 2009
New Revision: 197687
URL: http://svn.freebsd.org/changeset/base/197687
Log:
The flow-table associates TCP/UDP flows and IP destinations with
specific routes. When the routing table changes, for example,
when a new route with a more specific prefix is inserted into the
routing table, the flow-table is not updated to reflect that change.
As such existing connections cannot take advantage of the new path.
In some cases the path is broken. This patch will update the affected
flow-table entries when a more specific route is added. The route
entry is properly marked when a route is deleted from the table.
In this case, when the flow-table performs a search, the stale
entry is updated automatically. Therefore this patch is not
necessary for route deletion.
Submitted by: simon, phk
Reviewed by: bz, kmacy
MFC after:3 days
Modified:
head/sys/net/flowtable.c
head/sys/net/flowtable.h
head/sys/net/route.c
Modified: head/sys/net/flowtable.c
==
--- head/sys/net/flowtable.cThu Oct 1 20:11:42 2009(r197686)
+++ head/sys/net/flowtable.cThu Oct 1 20:32:29 2009(r197687)
@@ -830,7 +830,7 @@ fle_free(struct flentry *fle)
}
static void
-flowtable_free_stale(struct flowtable *ft)
+flowtable_free_stale(struct flowtable *ft, struct rtentry *rt)
{
int curbit = 0, count;
struct flentry *fle, **flehead, *fleprev;
@@ -866,8 +866,14 @@ flowtable_free_stale(struct flowtable *f
curbit);
}
#endif
- while (fle != NULL) {
- if (!flow_stale(ft, fle)) {
+ while (fle != NULL) {
+ if (rt != NULL) {
+ if (__DEVOLATILE(struct rtentry *, fle-f_rt)
!= rt) {
+ fleprev = fle;
+ fle = fle-f_next;
+ continue;
+ }
+ } else if (!flow_stale(ft, fle)) {
fleprev = fle;
fle = fle-f_next;
continue;
@@ -916,6 +922,30 @@ flowtable_free_stale(struct flowtable *f
log(LOG_DEBUG, freed %d flow entries\n, count);
}
+void
+flowtable_route_flush(struct flowtable *ft, struct rtentry *rt)
+{
+ int i;
+ if (ft-ft_flags FL_PCPU) {
+ for (i = 0; i = mp_maxid; i++) {
+ if (CPU_ABSENT(i))
+ continue;
+
+ thread_lock(curthread);
+ sched_bind(curthread, i);
+ thread_unlock(curthread);
+
+ flowtable_free_stale(ft, rt);
+
+ thread_lock(curthread);
+ sched_unbind(curthread);
+ thread_unlock(curthread);
+ }
+ } else {
+ flowtable_free_stale(ft, rt);
+ }
+}
+
static void
flowtable_clean_vnet(void)
{
@@ -933,14 +963,14 @@ flowtable_clean_vnet(void)
sched_bind(curthread, i);
thread_unlock(curthread);
- flowtable_free_stale(ft);
+ flowtable_free_stale(ft, NULL);
thread_lock(curthread);
sched_unbind(curthread);
thread_unlock(curthread);
}
} else {
- flowtable_free_stale(ft);
+ flowtable_free_stale(ft, NULL);
}
ft = ft-ft_next;
}
Modified: head/sys/net/flowtable.h
==
--- head/sys/net/flowtable.hThu Oct 1 20:11:42 2009(r197686)
+++ head/sys/net/flowtable.hThu Oct 1 20:32:29 2009(r197687)
@@ -51,5 +51,7 @@ struct flowtable *flowtable_alloc(int ne
int flowtable_lookup(struct flowtable *ft, struct mbuf *m,
struct route *ro, uint32_t fibnum);
+void flowtable_route_flush(struct flowtable *ft, struct rtentry *rt);
+
#endif /* _KERNEL */
#endif
Modified: head/sys/net/route.c
==
--- head/sys/net/route.cThu Oct 1 20:11:42 2009(r197686)
+++ head/sys/net/route.cThu Oct 1 20:32:29 2009(r197687)
@@ -56,6 +56,7 @@
#include net/if_dl.h
#include net/route.h
#include net/vnet.h
+#include net/flowtable.h
#ifdef RADIX_MPATH
#include net/radix_mpath.h
@@ -996,6 +997,9 @@ rtrequest1_fib(int req, struct rt_addrin
{
int error = 0, needlock = 0;
register struct rtentry *rt;
+#ifdef FLOWTABLE
+ register
Re: svn commit: r197687 - head/sys/net
I misinterpreted the Submitted by: field.
I thought I put in the names of persons who reported the bug.
Disregard the Submitted by field for this checkin.
It's my code. Something breaks, my fault, email me ...
-- Qing
On Thu, Oct 1, 2009 at 1:32 PM, Qing Li qin...@freebsd.org wrote:
Author: qingli
Date: Thu Oct 1 20:32:29 2009
New Revision: 197687
URL: http://svn.freebsd.org/changeset/base/197687
Log:
The flow-table associates TCP/UDP flows and IP destinations with
specific routes. When the routing table changes, for example,
when a new route with a more specific prefix is inserted into the
routing table, the flow-table is not updated to reflect that change.
As such existing connections cannot take advantage of the new path.
In some cases the path is broken. This patch will update the affected
flow-table entries when a more specific route is added. The route
entry is properly marked when a route is deleted from the table.
In this case, when the flow-table performs a search, the stale
entry is updated automatically. Therefore this patch is not
necessary for route deletion.
Submitted by: simon, phk
Reviewed by: bz, kmacy
MFC after: 3 days
Modified:
head/sys/net/flowtable.c
head/sys/net/flowtable.h
head/sys/net/route.c
Modified: head/sys/net/flowtable.c
==
--- head/sys/net/flowtable.c Thu Oct 1 20:11:42 2009 (r197686)
+++ head/sys/net/flowtable.c Thu Oct 1 20:32:29 2009 (r197687)
@@ -830,7 +830,7 @@ fle_free(struct flentry *fle)
}
static void
-flowtable_free_stale(struct flowtable *ft)
+flowtable_free_stale(struct flowtable *ft, struct rtentry *rt)
{
int curbit = 0, count;
struct flentry *fle, **flehead, *fleprev;
@@ -866,8 +866,14 @@ flowtable_free_stale(struct flowtable *f
curbit);
}
#endif
- while (fle != NULL) {
- if (!flow_stale(ft, fle)) {
+ while (fle != NULL) {
+ if (rt != NULL) {
+ if (__DEVOLATILE(struct rtentry *, fle-f_rt)
!= rt) {
+ fleprev = fle;
+ fle = fle-f_next;
+ continue;
+ }
+ } else if (!flow_stale(ft, fle)) {
fleprev = fle;
fle = fle-f_next;
continue;
@@ -916,6 +922,30 @@ flowtable_free_stale(struct flowtable *f
log(LOG_DEBUG, freed %d flow entries\n, count);
}
+void
+flowtable_route_flush(struct flowtable *ft, struct rtentry *rt)
+{
+ int i;
+ if (ft-ft_flags FL_PCPU) {
+ for (i = 0; i = mp_maxid; i++) {
+ if (CPU_ABSENT(i))
+ continue;
+
+ thread_lock(curthread);
+ sched_bind(curthread, i);
+ thread_unlock(curthread);
+
+ flowtable_free_stale(ft, rt);
+
+ thread_lock(curthread);
+ sched_unbind(curthread);
+ thread_unlock(curthread);
+ }
+ } else {
+ flowtable_free_stale(ft, rt);
+ }
+}
+
static void
flowtable_clean_vnet(void)
{
@@ -933,14 +963,14 @@ flowtable_clean_vnet(void)
sched_bind(curthread, i);
thread_unlock(curthread);
- flowtable_free_stale(ft);
+ flowtable_free_stale(ft, NULL);
thread_lock(curthread);
sched_unbind(curthread);
thread_unlock(curthread);
}
} else {
- flowtable_free_stale(ft);
+ flowtable_free_stale(ft, NULL);
}
ft = ft-ft_next;
}
Modified: head/sys/net/flowtable.h
==
--- head/sys/net/flowtable.h Thu Oct 1 20:11:42 2009 (r197686)
+++ head/sys/net/flowtable.h Thu Oct 1 20:32:29 2009 (r197687)
@@ -51,5 +51,7 @@ struct flowtable *flowtable_alloc(int ne
int flowtable_lookup(struct flowtable *ft, struct mbuf *m,
struct route *ro, uint32_t fibnum);
+void flowtable_route_flush(struct flowtable *ft, struct rtentry *rt);
+
#endif /* _KERNEL */
#endif
Modified: head/sys/net/route.c
==
--- head/sys/net/route.c Thu Oct 1 20:11:42 2009 (r197686)
+++ head/sys/net/route.c Thu Oct 1 20:32:29 2009
