Re: route messages from NDP
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 = '\0' repeats 45 times}
family is AF_LINK (18), it's a correct one. But sdl_alen, sdl_data are
zeros.
I forget to mention it's for 7.3-STABLE.
Looks like L2 (ARP/NDP) entries don't generate routing message at all
for 8.x+. It's seems a feature ARP-rewritting project. Am I right?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Route messages
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 === 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_input.c 22 Apr 2008 12:02:55 - 1.332.2.2 +++ sys/netinet/ip_input.c 1 Jul 2008 09:23:08 - @@ -1363,7 +1363,6 @@ ip_forward(struct mbuf *m, int srcrt) * the ICMP_UNREACH_NEEDFRAG Next-Hop MTU field described in RFC1191. */ bzero(ro, sizeof(ro)); - rtalloc_ign(ro, RTF_CLONING); error = ip_output(m, NULL, ro, IP_FORWARDING, NULL, NULL); -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
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 issue goes away. Ha, I finally know why I ended up on Cc: of a thread I had no idea about. Someone could have told me instead of blindly adding me;-) Yes, this change doesn't look right. It should only do the route lookup in ip_input.c when there was an EMSGSIZE error returned by ip_output(). The rtalloc_ign() call causes the message to be sent because it always sets report to one. The default message is RTM_MISS. I'll try to prep an updated patch which doesn't have these issues later today. Yeah my bad. Sorry. If you do that, do not do an extra route lookup if possible, correct the rtalloc call. Thanks. 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. Andre, could you review this? 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_input.c 22 Apr 2008 12:02:55 - 1.332.2.2 +++ sys/netinet/ip_input.c 1 Jul 2008 09:23:08 - @@ -1363,7 +1363,6 @@ ip_forward(struct mbuf *m, int srcrt) * the ICMP_UNREACH_NEEDFRAG Next-Hop MTU field described in RFC1191. */ bzero(ro, sizeof(ro)); - rtalloc_ign(ro, RTF_CLONING); error = ip_output(m, NULL, ro, IP_FORWARDING, NULL, NULL); This could also potentially close http://www.freebsd.org/cgi/query-pr.cgi?pr=124540 http://www.freebsd.org/cgi/query-pr.cgi?pr=123621 ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
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, I finally know why I ended up on Cc: of a thread I had no idea about. Someone could have told me instead of blindly adding me;-) Yes, this change doesn't look right. It should only do the route lookup in ip_input.c when there was an EMSGSIZE error returned by ip_output(). The rtalloc_ign() call causes the message to be sent because it always sets report to one. The default message is RTM_MISS. I'll try to prep an updated patch which doesn't have these issues later today. Yeah my bad. Sorry. If you do that, do not do an extra route lookup if possible, correct the rtalloc call. Thanks. 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. Andre, could you review this? Yes, this should fix the problem. I haven't tested the patch though. -- Andre 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_input.c 22 Apr 2008 12:02:55 - 1.332.2.2 +++ sys/netinet/ip_input.c 1 Jul 2008 09:23:08 - @@ -1363,7 +1363,6 @@ ip_forward(struct mbuf *m, int srcrt) * the ICMP_UNREACH_NEEDFRAG Next-Hop MTU field described in RFC1191. */ bzero(ro, sizeof(ro)); - rtalloc_ign(ro, RTF_CLONING); error = ip_output(m, NULL, ro, IP_FORWARDING, NULL, NULL); ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
At 10:34 PM 6/27/2008, [EMAIL PROTECTED] wrote: On Sun, 15 Jun 2008 11:16:17 +0100, in sentex.lists.freebsd.net you wrote: Paul wrote: Get these with GRE tunnel on FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 :/usr/obj/usr/src/sys/ROUTER 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 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. Hi, I am seeing this issue as well on a pair of recently deployed boxes, one running MPD and one acting as an area router in front of it. The MPD box has a default route and only has 400 routes or so. A steady stream of those messages, upwards of 500 per second. got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default Is there a way to try and track down what is generating those messages ? Its eating up a fair bit of cpu with quagga (the zebra process specifically) I narrowed down where the change to RELENG_7 happened. It looks like a commit around April 22nd caused the behaviour to change. When a box acting as a router has a packet transit it, an RTM_MISS is generated for *each packet*... Given a setup of H1 R1 - H2 where H1 is 10.10.1.2/24 H2 is 10.20.1.2/24 and R1 has 2 interfaces, 10.10.1.1/24 and 10.20.1.1/24 Pinging H2 from H1 makes R1 generate a RTM_MISS for each packet! For routing daemons such as zebra, this eats up a *lot* of CPU. Turning on ip_fast_forwarding stops this behaviour on R1. However, if the interface routing the packet is an netgraph interface (e.g. mpd) fast_forwarding doesnt seem to have an effect and the RTM_MISS messages are generated again for each packet. The ping packet below is a valid icmp echo request and reply. e.g 0[releng7]# ping -c 2 -S 10.20.1.2 10.10.1.2 PING 10.10.1.2 (10.10.1.2) from 10.20.1.2: 56 data bytes 64 bytes from 10.10.1.2: icmp_seq=0 ttl=63 time=0.302 ms 64 bytes from 10.10.1.2: icmp_seq=1 ttl=63 time=0.337 ms --- 10.10.1.2 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.302/0.320/0.337/0.018 ms 0[releng7]# generates 4 messages on the router [r7-router]# route -n monitor got message of size 96 on Tue Jul 1 00:42:35 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 96 on Tue Jul 1 00:42:35 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 96 on Tue Jul 1 00:42:36 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 96 on Tue Jul 1 00:42:36 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default 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. kernel is just 0[r7-router]% diff router GENERIC 24,27c24 ident router makeoptions MODULES_OVERRIDE=ipfw acpi --- ident GENERIC 37,38c34,35 #options INET6 # IPv6 communications protocols #options SCTP# Stream Control Transmission Protocol --- options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol 47c44 #options NFSLOCKD# Network Lock Manager --- options NFSLOCKD# Network Lock Manager 61c58 #options STACK # stack(9) support --- options STACK # stack(9) support 303c300 #device uslcom # SI Labs CP2101/CP2102 serial adapters --- deviceuslcom # SI Labs CP2101/CP2102 serial adapters ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
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 ended up on Cc: of a thread I had no idea about. Someone could have told me instead of blindly adding me;-) Yes, this change doesn't look right. It should only do the route lookup in ip_input.c when there was an EMSGSIZE error returned by ip_output(). The rtalloc_ign() call causes the message to be sent because it always sets report to one. The default message is RTM_MISS. I'll try to prep an updated patch which doesn't have these issues later today. Yeah my bad. Sorry. If you do that, do not do an extra route lookup if possible, correct the rtalloc call. Thanks. 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. Andre, could you review this? 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_input.c 22 Apr 2008 12:02:55 - 1.332.2.2 +++ sys/netinet/ip_input.c 1 Jul 2008 09:23:08 - @@ -1363,7 +1363,6 @@ ip_forward(struct mbuf *m, int srcrt) * the ICMP_UNREACH_NEEDFRAG Next-Hop MTU field described in RFC1191. */ bzero(ro, sizeof(ro)); - rtalloc_ign(ro, RTF_CLONING); error = ip_output(m, NULL, ro, IP_FORWARDING, NULL, NULL); -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
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 RTM_MISS message generated per packet forwarded on my test box. Is it the final / correct version ? ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
On Sun, 15 Jun 2008 11:16:17 +0100, in sentex.lists.freebsd.net you wrote: Paul wrote: Get these with GRE tunnel on FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 :/usr/obj/usr/src/sys/ROUTER 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 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. Hi, I am seeing this issue as well on a pair of recently deployed boxes, one running MPD and one acting as an area router in front of it. The MPD box has a default route and only has 400 routes or so. A steady stream of those messages, upwards of 500 per second. got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 96 on Fri Jun 27 22:25:42 2008 RTM_MISS: Lookup failed on this address: len 96, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default Is there a way to try and track down what is generating those messages ? Its eating up a fair bit of cpu with quagga (the zebra process specifically) ---Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
2574 output packets discarded due to no route 2904 output datagrams fragmented 5808 fragments created not incrementing.. route monitor: got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default got message of size 160 on Tue Jun 24 10:59:04 2008 RTM_MISS: Lookup failed on this address: len 160, pid: 0, seq 0, errno 0, flags:DONE locks: inits: sockaddrs: DST default I don't get it.. :/ I do have a default route.. grr. :P Must be something to do with GRE but I can't recreate it on -RELEASE, only -STABLE and I don't see any differences in -STABLE that might cause it except maybe the EM driver? But I don't see how that would do it.. The only difference in route.c from RELEASE to STABLE is : - * $FreeBSD: src/sys/net/route.c,v 1.120.2.1.2.1 2008/01/09 15:23:36 mux Exp $ + * $FreeBSD: src/sys/net/route.c,v 1.120.2.3 2008/03/05 20:33:46 jhb Exp $ */ #include opt_inet.h @@ -396,7 +396,7 @@ error = EHOSTUNREACH; done: if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); out: if (error) rtstat.rts_badredirect++; Hrm.. what's a good way to disable the RT_MISS messages .. I guess ill have to add a check to see if msgtype=RTM_MISS and bypass the reporting... Is there a way to make it report what the source ip address it is trying to find a route for? Thanks Paul Bruce M. Simpson wrote: Paul wrote: Get these with GRE tunnel on FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 :/usr/obj/usr/src/sys/ROUTER 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 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 routing socket actively like this, so I wouldn't worry about it. If it's a real concern for you then you could try hacking in a sysctl to tell the radix trie code not to issue RTM_MISS messages on the routing socket. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
Yes but I DO have a default route.. I tried putting one in, removing it, putting it back, rebooting.. The problem is ZEBRA listens to the socket and uses 10-15% cpu because of these messages.. It doesn't happen on -RELEASE though so h.. I guess I could hack it to skip over the reporting of the message.. probably be good in the future, but something is wrong because I've added a default and removed it also so maybe something with the -STABLE code that changed something in the routing area.. Bruce M. Simpson wrote: Paul wrote: Get these with GRE tunnel on FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 :/usr/obj/usr/src/sys/ROUTER 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 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 routing socket actively like this, so I wouldn't worry about it. If it's a real concern for you then you could try hacking in a sysctl to tell the radix trie code not to issue RTM_MISS messages on the routing socket. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Route messages
Paul wrote: Get these with GRE tunnel on FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT 2008 :/usr/obj/usr/src/sys/ROUTER 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 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 routing socket actively like this, so I wouldn't worry about it. If it's a real concern for you then you could try hacking in a sysctl to tell the radix trie code not to issue RTM_MISS messages on the routing socket. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
