Re: Changes to route(8) or routing between r325235 and r326782?
On 12/12/2017 08:56 AM, Eugene Grosbein wrote: > On 12.12.2017 09:31, Thomas Steen Rasmussen wrote: > >> After upgrading to r326782 I get the following error when trying to >> delete the lo0 entry (I have an rc.d script to do it): >> >> $ sudo route delete 185.96.180.10 >> route: writing to routing socket: Address already in use >> delete host 185.96.180.10 fib 0: gateway uses the same route >> $ >> >> What gives? What do I do now? :) > You should be using jail+vnet in first place that allows you to get desired > behaviour > by assigning an interface to distinct jail. Take a look at jail(8) manual page > for vnet and vnet.interface parameters. > Hello, Thanks, I am aware of vnet and it's uses. I am looking for the reason why the current method doesn't work anymore. :) Switching 50+ jails over to vnet is not something you "just do", the rewriting of firewall rules alone will be quite a job. I am also pretty curious as to what people have been doing to solve this over the last many years while waiting for vimage to become stable? Have people just not been firewalling between jails? Thanks :) /Thomas ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
On 12.12.2017 16:44, Thomas Steen Rasmussen wrote: > On 12/12/2017 08:56 AM, Eugene Grosbein wrote: >> On 12.12.2017 09:31, Thomas Steen Rasmussen wrote: >> >>> After upgrading to r326782 I get the following error when trying to >>> delete the lo0 entry (I have an rc.d script to do it): >>> >>> $ sudo route delete 185.96.180.10 >>> route: writing to routing socket: Address already in use >>> delete host 185.96.180.10 fib 0: gateway uses the same route >>> $ >>> >>> What gives? What do I do now? :) >> You should be using jail+vnet in first place that allows you to get desired >> behaviour >> by assigning an interface to distinct jail. Take a look at jail(8) manual >> page >> for vnet and vnet.interface parameters. >> > Hello, > > Thanks, I am aware of vnet and it's uses. I am looking for the reason > why the current method doesn't work anymore. :) Loopback routes were not pinned by mistake that lead to kernel's inability to assign new address/prefix to local interface if such prefix was already installed by means of some routing daemon. This broke stable work of parallel tunnels established to same remote network via distinct WAN paths. > Switching 50+ jails over to vnet is not something you "just do", the > rewriting of firewall rules alone will be quite a job. > > I am also pretty curious as to what people have been doing to solve this > over the last many years while waiting for vimage to become stable? Have > people just not been firewalling between jails? I use ipfw for long time for this task. It filters inter-jail traffic over lo0 just fine. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
On 12.12.17 03:31, Thomas Steen Rasmussen wrote: Hello list :) "Something" which changes how routing works has landed in 11-STABLE between r325235 and r326782. Until now I have had a script which deletes routing table entries which point to lo0, in order to keep traffic from "shortcutting" over lo0, to make it possible to use pf to filter traffic between jails. This script has worked for years, but has now stopped working after upgrading from r325235 to r326782. Can someone enlighten me as to what changed, and why? Background/example: I add 185.96.180.10/32 as an alias on an interface, lagg0.1171. This creates two routing table entries: 185.96.180.10 link#11 UHS lo0 185.96.180.10/32 link#11 U lagg0.1171 If I leave this as-is the traffic from other jails use lo0 to reach 185.96.180.10 meaning they bypass pf entirely. To avoid this I simply delete the route on lo0, which makes stuff behave as I would expect - traffic to 185.96.180.10 goes via lagg0.1171 meaning I can filter in pf as needed. After upgrading to r326782 I get the following error when trying to delete the lo0 entry (I have an rc.d script to do it): $ sudo route delete 185.96.180.10 route: writing to routing socket: Address already in use delete host 185.96.180.10 fib 0: gateway uses the same route $ What gives? What do I do now? :) The FreeBSD kernel had a bug that you relied on. The bug got fixed and the fix broke your script. The proper solution is to filter on lo0. I suspect that your pf.conf includes "skip on lo0" replace this by the filtering you want to apply to traffic on lo0. Putting those rules in an anchor block probably will make your ruleset a lot easier to maintain. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 224247] [patch] RFC 6980 requires to drop fragmented IPv6 neighbour discovery
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224247 l...@donnerhacke.de changed: What|Removed |Added Attachment #188720|0 |1 is obsolete|| --- Comment #3 from l...@donnerhacke.de --- Created attachment 188749 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188749&action=edit Drop malicious packets as required by RFC 6980 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 224247] [patch] RFC 6980 requires to drop fragmented IPv6 neighbour discovery
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224247 --- Comment #4 from l...@donnerhacke.de --- Thank your for the pointer to functionality duplication in other modules. I moved the flag-setting to the fragment header removal code (which is more appropriate anyway). This code is more likely to be shared by other modules (in the case of pf, it is used). Furthermore the flag is renamed to be more self explanatory and the code was brushed up to match the existing coding style. Did I miss anything else? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 224218] Kernel panic in SCTP/IpV6 server mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218 --- Comment #23 from Michael Tuexen --- (In reply to Shreesh Holla from comment #22) I tried to install gnome3 and xorg according to the FreeBSD handbook, but gnome doesn't start. It complains about not finding the default font "fixed". I also failed to install the vmware tools, since when trying to follow the instructions given on the VMWare Website, I end up in errors. The instructions for FreeBSD as a GuestOS are also pretty old. Not sure if they still support FreeBSD. As you guess, I'm neither using the GUI on the VMs normally nor I'm using the vmware tools... So I can't test your setup, I'm sorry. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
> On 12/12/2017 08:56 AM, Eugene Grosbein wrote: > > On 12.12.2017 09:31, Thomas Steen Rasmussen wrote: > > > >> After upgrading to r326782 I get the following error when trying to > >> delete the lo0 entry (I have an rc.d script to do it): > >> > >> $ sudo route delete 185.96.180.10 > >> route: writing to routing socket: Address already in use > >> delete host 185.96.180.10 fib 0: gateway uses the same route > >> $ > >> > >> What gives? What do I do now? :) > > You should be using jail+vnet in first place that allows you to get desired > > behaviour > > by assigning an interface to distinct jail. Take a look at jail(8) manual > > page > > for vnet and vnet.interface parameters. > > > Hello, > > Thanks, I am aware of vnet and it's uses. I am looking for the reason > why the current method doesn't work anymore. :) > Switching 50+ jails over to vnet is not something you "just do", the > rewriting of firewall rules alone will be quite a job. > > I am also pretty curious as to what people have been doing to solve this > over the last many years while waiting for vimage to become stable? Have > people just not been firewalling between jails? The mistake is that the kernel is doing route decisions at all, that is the domain of a daemon and should of never been put in the kernel, for reasons exactly like this. What I have done on all my systems is I comment out all the loopback route code in the kernel and do the proper routing with either OSPF or BGP. find /sys/ | xargs grep maintain_loopback_route mostly can be fixed in net/if.c. This "routing policy" in the kernel just breaks things in so many ways. -- Rod Grimes rgri...@freebsd.org ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
[ Charset UTF-8 unsupported, converting... ] > On 12.12.17 03:31, Thomas Steen Rasmussen wrote: > > Hello list :) > > > > "Something" which changes how routing works has landed in 11-STABLE > > between r325235 and r326782. > > > > Until now I have had a script which deletes routing table entries which > > point to lo0, in order to keep traffic from "shortcutting" over lo0, to > > make it possible to use pf to filter traffic between jails. This script > > has worked for years, but has now stopped working after upgrading from > > r325235 to r326782. Can someone enlighten me as to what changed, and why? > > > > Background/example: I add 185.96.180.10/32 as an alias on an interface, > > lagg0.1171. This creates two routing table entries: > > > > 185.96.180.10? link#11??? UHS lo0 > > 185.96.180.10/32?? link#11??? U? lagg0.1171 > > > > If I leave this as-is the traffic from other jails use lo0 to reach > > 185.96.180.10 meaning they bypass pf entirely. To avoid this I simply > > delete the route on lo0, which makes stuff behave as I would expect - > > traffic to 185.96.180.10 goes via lagg0.1171 meaning I can filter in pf > > as needed. > > > > After upgrading to r326782 I get the following error when trying to > > delete the lo0 entry (I have an rc.d script to do it): > > > > $ sudo route delete 185.96.180.10 > > route: writing to routing socket: Address already in use > > delete host 185.96.180.10 fib 0: gateway uses the same route > > $ > > > > What gives? What do I do now? :) > > The FreeBSD kernel had a bug that you relied on. The bug got fixed and > the fix broke your script. The proper solution is to filter on lo0. I > suspect that your pf.conf includes "skip on lo0" replace this by the > filtering you want to apply to traffic on lo0. Putting those rules in an > anchor block probably will make your ruleset a lot easier to maintain. The FreeBSD kernel now has a BIGGER bug, it now totally ignores the user's specified routing policy and makes routing policy decissions of its own, thinking that it knows what is best for the user. The whole maintain_loopback_route should be KILLED from the kernel, it is simply the wrong thing to be doing. -- Rod Grimes rgri...@freebsd.org ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
12.12.2017 22:15, Rodney W. Grimes wrote: > The FreeBSD kernel now has a BIGGER bug, it now totally ignores the > user's specified routing policy and makes routing policy decissions > of its own, thinking that it knows what is best for the user. > > The whole maintain_loopback_route should be KILLED from the kernel, > it is simply the wrong thing to be doing. Only if you can supply alternative way to assign highest priority (administrative distance = 0) for "directly connected" routes. And ability to override dynamically received prefixes with direct interface address assignment. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
[ Charset windows-1252 unsupported, converting... ] > 12.12.2017 22:15, Rodney W. Grimes wrote: > > > The FreeBSD kernel now has a BIGGER bug, it now totally ignores the > > user's specified routing policy and makes routing policy decissions > > of its own, thinking that it knows what is best for the user. > > > > The whole maintain_loopback_route should be KILLED from the kernel, > > it is simply the wrong thing to be doing. > > Only if you can supply alternative way to assign highest priority > (administrative distance = 0) for "directly connected" routes. > And ability to override dynamically received prefixes with direct > interface address assignment. This is all done by correctly configured routing daemon running in userland over the route socket. Only being doing that for 25+ years that way, why suddenly does the kernel need to over ride what has already been done and working? If you say it is cause of its harder to filter, then you are breaking everyone else cause you dont want to do something right yourself. -- Rod Grimes rgri...@freebsd.org ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
On 13.12.2017 01:02, Rodney W. Grimes wrote: >>> The whole maintain_loopback_route should be KILLED from the kernel, >>> it is simply the wrong thing to be doing. >> >> Only if you can supply alternative way to assign highest priority >> (administrative distance = 0) for "directly connected" routes. >> And ability to override dynamically received prefixes with direct >> interface address assignment. > > This is all done by correctly configured routing daemon > running in userland over the route socket. Do we have such daemon maintaining directly connected routed in the base system? > Only being doing that for 25+ years that way, why suddenly does the > kernel need to over ride what has already been done and working? I cannot speak for 25+ years but I can for 17+ while there was NO way in FreeBSD to assign an address like 192.168.0.1/24 to an interface when such prefix already was installed to the kernel by routing daemon. Pinning loopback prefixes solved this problem at last. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
> On 13.12.2017 01:02, Rodney W. Grimes wrote: > > >>> The whole maintain_loopback_route should be KILLED from the kernel, > >>> it is simply the wrong thing to be doing. > >> > >> Only if you can supply alternative way to assign highest priority > >> (administrative distance = 0) for "directly connected" routes. > >> And ability to override dynamically received prefixes with direct > >> interface address assignment. > > > > This is all done by correctly configured routing daemon > > running in userland over the route socket. > > Do we have such daemon maintaining directly connected routed in the base > system? I believe we do, though it uses a fairly rare protocol now a days, called ripv2. man routed Both bird and quagga maintain these routes as well. I believe that openospfd does too. In fact I dont know of a routing daemon that does not try to maintain these. Also why does this need to ba a "in the base system"? Certainly sticking a route decision in the kernel that defeats any attempt to change it makes that pointless anyway. > > > Only being doing that for 25+ years that way, why suddenly does the > > kernel need to over ride what has already been done and working? > > I cannot speak for 25+ years but I can for 17+ while there was NO way > in FreeBSD to assign an address like 192.168.0.1/24 to an interface > when such prefix already was installed to the kernel by routing daemon. That is a differet issue than having the kernel install such routes. And nomally you do NOT need to do that if your routing protocol is doing the right things, as it well see the net interface, recompute its rib and correct the fib > Pinning loopback prefixes solved this problem at last. No, it only breaks people that run real routing protocols like OSPF and BGP. Also fixing one problem only to create others is not the way we should be attacking things, that just leaves sizeof(bugs) at N. You can no longer deny that this creates a problem for someone, as we now have a user that had a working system get borked by these changes. I am no longer a sole, as warner well certainly put it, whiner on this issue. Again, the maintain_loopback_route stuff was added because someone couldnt deal with the fact that you loose all routes via an interface when you down it and then bring it back up. That behavior is what you WANT to happen. Having the kernel magically add routes when an interface comes back up is just bad for a real router. The kernel can not possibly know what my policy is about that route. It now does what someone thinks is the best policy, and that is in direct conflict with what most routing protocols are going to try and do. I do not know of any other system that does this, but then I dont fuss with Linux much. -- Rod Grimes rgri...@freebsd.org ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
> > >>> The whole maintain_loopback_route should be KILLED from the kernel, > > >>> it is simply the wrong thing to be doing. > > >> > > >> Only if you can supply alternative way to assign highest priority > > >> (administrative distance = 0) for "directly connected" routes. > > >> And ability to override dynamically received prefixes with direct > > >> interface address assignment. > > > > > > This is all done by correctly configured routing daemon > > > running in userland over the route socket. > > > > Do we have such daemon maintaining directly connected routed in the base > > system? > > I believe we do, though it uses a fairly rare protocol now a days, > called ripv2. man routed Both bird and quagga maintain these > routes as well. I believe that openospfd does too. In fact > I dont know of a routing daemon that does not try to maintain > these. > > Also why does this need to ba a "in the base system"? Certainly > sticking a route decision in the kernel that defeats any attempt > to change it makes that pointless anyway. Being a router jockey at my daytime job I can symphatize with both views here. - I *expect* that a route pointing out an interface will disappear when that interface goes down, and reappear again when the interface comes back up. This behavior is extremely consistent across all the major router brands. - The standard FreeBSD behavior where a static route (added by a manual "route add -net ...") does *not* reappear when an interface comes back up, simply feels incredibly wrong and inconsistent. But I also want the kernel to handle packet *forwarding*, and not routing policy. I guess I'm looking for a a simplified routed which will handle my static routes and can be turned on with a only an xxx_enable in rc.conf and then basically forgotten. If I want something more complicated (typically BGP) I'll install quagga. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
On 13.12.2017 01:33, Rodney W. Grimes wrote: >>> This is all done by correctly configured routing daemon >>> running in userland over the route socket. >> >> Do we have such daemon maintaining directly connected routed in the base >> system? > > I believe we do, though it uses a fairly rare protocol now a days, > called ripv2. man routed I've tried to use routed for RIPv2, it was badly broken for very-very long time. Unusable at least since FreeBSD 4.x era. Anyway, you misunderstood my question. Again, in other words: do we have routing daemon installing prefixes of addresses assigned to system interfaces to kernel forwarding database (FIB) in the base system? > Also why does this need to ba a "in the base system"? Because Unix routing machine is supposed to perform static routing out-of-the-box. >> I cannot speak for 25+ years but I can for 17+ while there was NO way >> in FreeBSD to assign an address like 192.168.0.1/24 to an interface >> when such prefix already was installed to the kernel by routing daemon. > > That is a differet issue than having the kernel install such routes. > And nomally you do NOT need to do that if your routing protocol > is doing the right things, as it well see the net interface, recompute > its rib and correct the fib It it pretty normal and routine for system administrator or daemon such as ppp(8) to assign new address to an interface. You cannot say "don't do that". And failure of such basic task is unacceptable. >> Pinning loopback prefixes solved this problem at last. > > No, Yes, it did :-) > it only breaks people that run real routing protocols like > OSPF and BGP. Also fixing one problem only to create others is > not the way we should be attacking things, that just leaves > sizeof(bugs) at N. Please describe some practical case when pinning breaks OSPF or BGP. > You can no longer deny that this creates a problem for someone, > as we now have a user that had a working system get borked by > these changes. That setup is easily fixed with small correction of packet filtering rules and did not require loopback route removal in first place. > Again, the maintain_loopback_route stuff was added because someone > couldnt deal with the fact that you loose all routes via an > interface when you down it and then bring it back up. It solves much more problems than that. > That behavior is what you WANT to happen. Having the kernel magically > add routes when an interface comes back up is just bad for > a real router. Cisco and others do the same. This behaviour is "standard de-facto". Deviations should be possible, of course - as alternatives. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
> > > >>> The whole maintain_loopback_route should be KILLED from the kernel, > > > >>> it is simply the wrong thing to be doing. > > > >> > > > >> Only if you can supply alternative way to assign highest priority > > > >> (administrative distance = 0) for "directly connected" routes. > > > >> And ability to override dynamically received prefixes with direct > > > >> interface address assignment. > > > > > > > > This is all done by correctly configured routing daemon > > > > running in userland over the route socket. > > > > > > Do we have such daemon maintaining directly connected routed in the base > > > system? > > > > I believe we do, though it uses a fairly rare protocol now a days, > > called ripv2. man routed Both bird and quagga maintain these > > routes as well. I believe that openospfd does too. In fact > > I dont know of a routing daemon that does not try to maintain > > these. > > > > Also why does this need to ba a "in the base system"? Certainly > > sticking a route decision in the kernel that defeats any attempt > > to change it makes that pointless anyway. > > Being a router jockey at my daytime job I can symphatize with both > views here. > > - I *expect* that a route pointing out an interface will disappear > when that interface goes down, and reappear again when the interface > comes back up. This behavior is extremely consistent across all the > major router brands. On a hardware router this is always handled by a configured protocol, try turning off all configured protocols and see what happens. > - The standard FreeBSD behavior where a static route (added by a > manual "route add -net ...") does *not* reappear when an interface > comes back up, simply feels incredibly wrong and inconsistent. Again, your use to that behavior because on the hardware router you always have a routing protocol running. Try a router fresh out of the box with no protocols and see if it instantiats a loop back route, hech, I am not even sure if lo0 exists on some routers unless you create it! > But I also want the kernel to handle packet *forwarding*, and not > routing policy. I guess I'm looking for a a simplified routed which > will handle my static routes and can be turned on with a only an > xxx_enable in rc.conf and then basically forgotten. routed -q Need to test that, but if the code hasnt been broken that should just do the right thing about routes via local interfaces having the local IP added as a lo0 loopback route. I also think that if you use /etc/rc.d/netif and have your variables properly set in /etc/rc.conf that your routes well come and go as you down and up with /etc/rc.d/netif. > If I want something more complicated (typically BGP) I'll install > quagga. One of the problems now is that these programs are fighting with the kernel over these routes and just fill your logs with lots of useless messages and you can not reliably predict the loop back routes even if you ARE running a routing protocol daemon. I also find it hillarious that the code emits a bogous console message when I down an interface that it could not delete the loopback route, that is because it went away when the if went down and it is nonsense to call maintain_loopback_route with a delete flag in this instance. This clearly informs one that the code was not well thought out. Probably written by someone that does not understand what is happening in the kernel automatically when an interface goes down. > Steinar Haug, Nethelp consulting, sth...@nethelp.no -- Rod Grimes rgri...@freebsd.org ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
On 13.12.2017 02:30, sth...@nethelp.no wrote:
> But I also want the kernel to handle packet *forwarding*, and not
> routing policy. I guess I'm looking for a a simplified routed which
> will handle my static routes and can be turned on with a only an
> xxx_enable in rc.conf and then basically forgotten.
>
> If I want something more complicated (typically BGP) I'll install
> quagga.
You can still install quagga with simple "pkg install" command
and run "zebra" daemon only to get exactly what you want, and no routing
protocols:
quagga_enable="YES"
quagga_daemons="zebra"
Then change all your "kernel routes" ("route add") to "static routes" in terms
of quagga
storing them in the /usr/local/etc/quagga/zebra.conf like I do:
ip route 192.168.0.0/16 reject
ip route 192.168.2.0/24 10.0.0.2
And so on. This works just as you need.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
On 13.12.2017 03:00, Rodney W. Grimes wrote: >> If I want something more complicated (typically BGP) I'll install >> quagga. > > One of the problems now is that these programs are fighting with > the kernel over these routes and just fill your logs with lots > of useless messages and you can not reliably predict the loop > back routes even if you ARE running a routing protocol daemon. quagga does not do that. It plays nice with our kernel. > I also find it hillarious that the code emits a bogous console > message when I down an interface that it could not delete the > loopback route This is already fixed. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
> On 13.12.2017 02:30, sth...@nethelp.no wrote:
>
> > But I also want the kernel to handle packet *forwarding*, and not
> > routing policy. I guess I'm looking for a a simplified routed which
> > will handle my static routes and can be turned on with a only an
> > xxx_enable in rc.conf and then basically forgotten.
> >
> > If I want something more complicated (typically BGP) I'll install
> > quagga.
>
> You can still install quagga with simple "pkg install" command
> and run "zebra" daemon only to get exactly what you want, and no routing
> protocols:
>
> quagga_enable="YES"
> quagga_daemons="zebra"
>
> Then change all your "kernel routes" ("route add") to "static routes" in
> terms of quagga
> storing them in the /usr/local/etc/quagga/zebra.conf like I do:
>
> ip route 192.168.0.0/16 reject
> ip route 192.168.2.0/24 10.0.0.2
>
> And so on. This works just as you need.
Flap your intgerfaces and see what happens when quagga and the kernel fight
over who gets to install the local MTU route via lo of the ip address for
the interface you flapped.
I must stress this is not about static routing, this is about the MTU route
that typically is done in /etc/rc.d/ at boot time. This is a route to
the local IP address of an interface to route its packets via lo0 so that
we pickup the larger MTU.
The code I am talking of here is *_maintain_loopback_route() in the kernel,
that code just needs to die, it creates more problems that in solves. It
has been dead in all my kernels since I found it in my syslogs fighting
with bird.
You should be able to run totally without these routes, they are there only
to optimize local MTU.
This has nothing to do with ppp, or the above routes, those are NOT
lo0 or loopback routes.
I am going to repeat that. You can run without these routes at all,
totally not needed for a functional system. It might be non optimal
as your connections to a local IP address are going to use the interface
MTU rather than the MTU of lo0. Usually 1500 vs 16k. But then things
should not really be using this route anyway, it would always be better
to open 127.0.0.1 rather than an interface ip.
The other thing these routes break is what the user complained of that
started this whole thread, his pf or firewall no longer behaves as it
did, because now we are forcing packets via lo0 that he was expecting
to go via an interface. AND we have left this user no way to turn
that function off reliably as he can delete the pinned route, but if
his interface flaps it is gona come right back!
--
Rod Grimes rgri...@freebsd.org
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Changes to route(8) or routing between r325235 and r326782?
> On 13.12.2017 03:00, Rodney W. Grimes wrote: > > >> If I want something more complicated (typically BGP) I'll install > >> quagga. > > > > One of the problems now is that these programs are fighting with > > the kernel over these routes and just fill your logs with lots > > of useless messages and you can not reliably predict the loop > > back routes even if you ARE running a routing protocol daemon. > > quagga does not do that. It plays nice with our kernel. I believe quagga silently ignores that it doesnt own the route it tried to install and bangs on the route socket, but maybe that got fixed. > > > I also find it hillarious that the code emits a bogous console > > message when I down an interface that it could not delete the > > loopback route > > This is already fixed. In what commit? -- Rod Grimes rgri...@freebsd.org ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] ifaddr leak when modifying a route
On Thu, Dec 7, 2017 at 4:59 PM, Ryan Stone wrote: > https://reviews.freebsd.org/D13417 I still haven't received any feedback on this review. If nobody raises an objection by Thursday, I will commit it. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221919 Garrett Wollman changed: What|Removed |Added CC||woll...@freebsd.org --- Comment #6 from Garrett Wollman --- Applied the patch from #c3 to my 11.1 source tree and found that it did not improve matters. It would be better if this "feature" could simply be disabled, as the Linux drivers (apparently?) allow. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221919 --- Comment #7 from Ryan Stone --- Sorry, there was a mistake in the patch. I think that something got lost in translation when I ported it forward. I've regenerated the patch at the same location, or you can replace this line in ixl_pf_main.c: ifp->if_hw_tsomaxsegpermss = IXL_MAX_TX_SEGS; with ifp->if_hw_tsomaxsegpermss = IXL_SPARSE_CHAIN; Sorry for the confusion. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 208007] [patch] Int overflow in dhclient(1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208007 --- Comment #1 from Michael McConville --- Hi guys. Just a reminder that hasn't been applied yet. It's a very simple fix. Thanks for your time, Michael -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
