Re: ipv6_addrs_IF aliases in rc.conf(5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2013-07-12 09:03, Hiroki Sato pisze: > Please let me know if the existing configurations and/or the new > formats do not work. The following is a summary of the supported > rc.conf variables, FYI: > > Hiroki Sato wrote in > <201306200229.r5k2tnfr085...@svn.freebsd.org>: > [...] What is the current, non deprecated way, to configure IP addresses in rc.conf? Let's say for a dual stack, multi IP box I need to set: 10.0.0.66/28 and 10.0.0.67-78 as aliases and fdda:5cc1:23:4::1/48 and fdda:5cc1:23:4::2-f as aliases What is the best way to accomplish it? - -- best regards, Lukasz Wasikowski -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHlKqQACgkQXlaUxx+udUUtnwCfc74UJLDPnCjec+v8TP0d8ceV Pz4AnA6Nd5rwO5HL/LYdaJiPmBC1ENxC =bzG8 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2013-07-10 17:52, Kevin Oberman pisze: > On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > >> On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < >> trash...@odo.in-berlin.de> wrote: >> >> Will that patch make it into 9.2? If I am not mistaken, that patch isn't >>> in stable yet. >>> >> >> I would also like to see this patch hit 9.x sooner than later. It's so >> painful when someone forgets to fix the alias numbering on servers with >> many, many IPv4 and IPv6 addresses... >> > > Please, please, please, please, ...! > > Freeze is only two days away, so time for 9.2 is almost over and I can see > no good reason NOT to get this done. +1 to that, please commit it. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2013-04-13 22:15, Michael Grimm pisze: > On 13.04.2013, at 14:29, Kimmo Paasiala wrote: > > [great deal of simplification by ipv6_addrs_IF] > >> Sorry to resurrect this thread but since nothing has happened in about >> three months I have to ask: What can I do to have this commited to >> HEAD? > > +1 > > Nowadays -where IPv6 becomes more and more available by ISPs- I *really* > would like to see this simplification implemented, soon, very soon. The > current scheme is way to much error prone, and, its a pain in the ass! Kimmo's patch worked for me. It would be great to have ipv6_addrs_if out of the box. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-22 04:41, Kimmo Paasiala pisze: >>> It looks like the reason for the difference to ipv4_addrs_IF is that >>> the "alias" parameter for ifconfig(8) operates differently for IPv6 >>> addresses, the first address of an interface can't be added with >>> "alias", for IPv4 it does not care. I'll have to dig deeper but that's >>> what the problem seems to be. >>> >>> -Kimmo >> >> The 'alias' parameter of ifconfig(8) is not the problem on the first >> ipv6 address, I have verified that. However, there's probably >> something in network.subr or /etc/rc.d/netif that I have overlooked >> and causes my code to be skipped if there's no ifconfig_IF_ipv6 >> variable defined in rc.conf(5). >> >> -Kimmo > > Yeah, this is problem in network.subr. An interface is not recognized > as IPv6 capable if the interface is not in "ipv6_network_interfaces" > and there's no "ifconfig_IF_ipv6" in rc.conf(5), bummer. For IPv4 it > "just works" because the interface is always assumed to be IPv4 > capable. Ok, I used ifconfig_em0_ipv6="up" and it worked. So it looks like this: ipv6_activate_all_interfaces="NO" ipv6_network_interfaces="em0" ifconfig_em0_ipv6="up" ipv6_addrs_em0="2001:6a0:1cb::1-ff/64" ipv6_defaultrouter="2001:6a0:1cb::" Good job, thank you! :) -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-21 13:23, Kimmo Paasiala pisze: > On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala wrote: >> On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker wrote: >>> On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: A question related to this for those who have been doing work on the rc(8) scripts. Can I assume that /usr/bin is available when network.subr functions are used? Doing calculations on hexadecimal numbers is going to be very awkward if I can't use for example bc(1). >>> >>> You cannot assume that /usr/bin is available when setting up the >>> network. It may be that /usr is mounted via NFS. >>> >>> You can use hexadecimal numbers (prefixed with 0x) in $((...)) >>> expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can >>> use; in older versions you can use hexdigit and hexprint from >>> network.subr. >>> >>> -- >>> Jilles Tjoelker >> >> Thanks, I've rewitten my patch to support ranges. It is attached in >> this message. >> >> Again it's against a very recent 9-STABLE, I still haven't found time >> to see if it applies to CURRENT. >> >> It does allow you to do crazy stuff like >> >> ipv6_addrs_re0="2001:db8::::1-/64" >> >> However I didn't find anything to limit the number of aliases in the >> ipv4 version of the function either. >> >> Please test it :) >> >> >> Then a question about the PR >> (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I >> attach this new patch to it? The submit follow up -button fires up my >> email client and I'm not so sure how to submit a new patch for the PR >> in an email in such a way that it appears properly formatted in the >> PR. >> >> Regards, >> >> Kimmo Paasiala > > PR updated with the new patch. Your patch applied cleanly, but it's not working or I am doing something wrong. root@freebsd:~ # uname -a FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf hostname="freebsd" ifconfig_em0="up" ipv4_addrs_em0="192.168.168.20-24/24" defaultrouter="192.168.168.1" ipv6_activate_all_interfaces="YES" ipv6_addrs_em0="2001:6a0:1cb::1-6/64" ipv6_defaultrouter="2001:6a0:1cb::" sshd_enable="YES" dumpdev="NO" named_enable="YES" root@freebsd:~ # ifconfig em0: flags=8843 metric 0 mtu 1500 options=9b ether 08:00:27:02:83:71 inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1 inet 192.168.168.20 netmask 0xff00 broadcast 192.168.168.255 inet 192.168.168.21 netmask 0x broadcast 192.168.168.21 inet 192.168.168.22 netmask 0x broadcast 192.168.168.22 inet 192.168.168.23 netmask 0x broadcast 192.168.168.23 inet 192.168.168.24 netmask 0x broadcast 192.168.168.24 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=63 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 nd6 options=21 -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2012-12-19 07:14, Kimmo Paasiala pisze: >> I wrote a small patch for /etc/network.subr to add support for >> ipv6_addrs_IF aliases in rc.conf(5) to match the already existing >> ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 >> aliases can be written like: [...] > Did anyone try my patch? I thought it would be nice to have the > ipv6_addrs_IF syntax supported to complement the existing > ipv4_addrs_IF alias syntax. Can I use range syntax in it like in ipv4? I mean something like: ipv4_addrs_lagg0="x.x.x.10-30/22" That feature would be very nice to have for ipv6. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] modular kernel config
W dniu 2012-02-28 22:56, Łukasz Wąsikowski pisze: >>>>> FLOWTABLE on 8.x crashed BGP routers (kern/144917). >>>>> >>>> no crash dump, no backtrace, no follow-up whatsoever after 1 year and >>>> 2 years, what's your points ? You could really have chosen a better PR >>>> to back up your argument... >>> >>> Sorry, but I don't want to bug trace this issue, simply because lack of >>> time, resources and interest in this feature. I've run into this bug on >>> production box, went through hell because of it and turned off flowtable >>> which I do not use and not need. If this problem is still alive (it >>> might be, the PR I've mentioned is still open) then it's not a good idea >>> to turn on this feature by default. If you're interested in using this >>> feature then feel free to debug and test. >>> >> Give me a deterministic way to reproduce the issue and I will. > > Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). > You need three peers sending you full Internet routing table (3x400k > prefixes). Some people got it with only two peers. After a short while > your CPU should stuck in 100% busy. I forgot one thing which may be important. IP addresses used for BGP sessions was heartbeated. So you first need to use those addresses on another box, then move them to flowtable box and run quagga with BGP on it. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] modular kernel config
W dniu 2012-02-28 22:22, Arnaud Lacombe pisze: FLOWTABLE on 8.x crashed BGP routers (kern/144917). >>> no crash dump, no backtrace, no follow-up whatsoever after 1 year and >>> 2 years, what's your points ? You could really have chosen a better PR >>> to back up your argument... >> >> Sorry, but I don't want to bug trace this issue, simply because lack of >> time, resources and interest in this feature. I've run into this bug on >> production box, went through hell because of it and turned off flowtable >> which I do not use and not need. If this problem is still alive (it >> might be, the PR I've mentioned is still open) then it's not a good idea >> to turn on this feature by default. If you're interested in using this >> feature then feel free to debug and test. >> > Give me a deterministic way to reproduce the issue and I will. Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). You need three peers sending you full Internet routing table (3x400k prefixes). Some people got it with only two peers. After a short while your CPU should stuck in 100% busy. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] modular kernel config
W dniu 2012-02-28 19:55, Arnaud Lacombe pisze: >> FLOWTABLE on 8.x crashed BGP routers (kern/144917). >> > no crash dump, no backtrace, no follow-up whatsoever after 1 year and > 2 years, what's your points ? You could really have chosen a better PR > to back up your argument... Sorry, but I don't want to bug trace this issue, simply because lack of time, resources and interest in this feature. I've run into this bug on production box, went through hell because of it and turned off flowtable which I do not use and not need. If this problem is still alive (it might be, the PR I've mentioned is still open) then it's not a good idea to turn on this feature by default. If you're interested in using this feature then feel free to debug and test. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] modular kernel config
W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: > You cannot ship that on by default for non-tecnical reasons in a kernel. > Please do not commit a kernel config that can be booted (no LINT cannot be > booted) with these on without consulting appropriate hats upfront. > > >> - ALTQ >> - SW_WATCHDOG >> - QUOTA >> - IPSTEALTH (disabled in loader.conf) >> - IPFIREWALL_FORWARD (touches every packet, power users which need >> a bigger PPS but not this feature can recompile the kernel, >> discussed with julian@) >> - FLOWTABLE (disabled in loader.conf) > Which is not the same as it's not 100% disabled and will still allocate > memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. -- best regards, Lukasz Wasikowski ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
