Re: OpenBGPd Route Server
Hi, at BCIX we still use OpenBGPd as transparent route server. With about 120 (IPv4 + IPv6) peering sessions it's still stable. We have multiple RIBS per peer but we don't have IRRDB prefix filtering per peer applied, as we know this brings issues regarding performance and convergence times. When you have peers like AS6939 / he.net with lots of prefixes, you also see higher convergence times even without IRRDB based prefix filtering. But a CPU with high single thread performance helps for this. Most other IXPs switched to bird as of good performance and scalability even with IRRDB prefix filtering per peer activated. Thorleif -- Thorleif Wiik, CTO thorleif.w...@bcix.de http://www.bcix.de/ https://twitter.com/bcix http://twitter.com/bcix https://www.facebook.com/BCIX.Internet.Exchange On Thu, Apr 16, 2015 at 10:40 PM, Stuart Henderson s...@spacehopper.org wrote: On 2015-04-16, Mike Hammett openbsd-m...@ics-il.net wrote: I had seen some complaints about OpenBGPd for IX RS usage, but they were all 2009 - 2011 area. I had assumed the most egregious of them had been fixed by now. I think most of the medium/larger ones have simply stopped using it unfortunately. I think most of the other bugs that would affect IXPs have been squashed now, the main remaining bgpd bug that I'm aware of won't affect this use. (filtering is just slow rather than buggy afaik; but then AIUI this wasn't supposed to be the final implementation of filters ;) Over time I expect I'll implement increasingly advanced configurations, such as separate RIBs per peer. If you allow peers fine-grained control over where their routes are announced, you need this, otherwise if they are happy for an announcement ro be sent to all MLP members then it's not necessary. At the suggestion of separate instances of OpenBGPd for v4 and v6, one could very well do a different VM for v4 and v6. Yes that would have a similar effect too. Though it does mean doing OS updates twice. I did know to get a 16 bit ASN. Is the 32 bit communities issue an OpenBGPd development issue or a lack of standards\precedent issue? Or, well, I guess something else. Standards. The 32 bit alternative to communities is extended communities and has support by most software that can use 32-bit ASNs, but because it's 32+16 bit, you can't use the common yourasn:otherasn syntax if both are 32-bit ASNs. (you can still use yourasn:[arbitrary 16-bit number] but that makes the common don't announce to AS XYZ require a lookup table to handle AS = 65536). I still don't understand why a similar method as used for AS_PATH/AS4_PATH wasn't also used for communities.
Re: tmux move-window behavior changed
 I have another fix for this which I will probably apply when I get home. Cheers Original message From: Theo Buehler t...@math.ethz.ch Date:21/04/2015 15:28 (GMT+00:00) To: misc@openbsd.org Cc: n...@openbsd.org Subject: Re: tmux move-window behavior changed On Tue, Apr 21, 2015 at 03:55:26PM +0200, LÃVAI Dániel wrote: Hi! Suddenly I realized that I can not move a window to a non-existing (new) window number? Like if I have windows at [0:mutt 1:ksh], I can not do `move-window -s 1 -t 8' anymore, it just stays at 1. This had to work before. Am I just being silly? Daniel I see the same thing. This was broken by this recent commit: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/server-fn.c?rev=1.81content-type=text/x-cvsweb-markup The following patch seems to fix the issue for me, but I'm not sure if the more involved logic as in server_kill_window() (lines 282ff) should be followed: Index: server-fn.c === RCS file: /cvs/src/usr.bin/tmux/server-fn.c,v retrieving revision 1.81 diff -u -p -r1.81 server-fn.c --- server-fn.c 19 Apr 2015 21:46:52 - 1.81 +++ server-fn.c 21 Apr 2015 14:19:53 - @@ -351,7 +351,8 @@ server_unlink_window(struct session *s, server_destroy_session_group(s); else server_redraw_session_group(s); - session_renumber_windows(s); + if (options_get_number(s-options, renumber-windows)) +session_renumber_windows(s); } void
Re: tmux move-window behavior changed
On Tue, Apr 21, 2015 at 03:55:26PM +0200, LÉVAI Dániel wrote: Hi! Suddenly I realized that I can not move a window to a non-existing (new) window number? Like if I have windows at [0:mutt 1:ksh], I can not do `move-window -s 1 -t 8' anymore, it just stays at 1. This had to work before. Am I just being silly? Daniel I see the same thing. This was broken by this recent commit: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/server-fn.c?rev=1.81content-type=text/x-cvsweb-markup The following patch seems to fix the issue for me, but I'm not sure if the more involved logic as in server_kill_window() (lines 282ff) should be followed: Index: server-fn.c === RCS file: /cvs/src/usr.bin/tmux/server-fn.c,v retrieving revision 1.81 diff -u -p -r1.81 server-fn.c --- server-fn.c 19 Apr 2015 21:46:52 - 1.81 +++ server-fn.c 21 Apr 2015 14:19:53 - @@ -351,7 +351,8 @@ server_unlink_window(struct session *s, server_destroy_session_group(s); else server_redraw_session_group(s); - session_renumber_windows(s); + if (options_get_number(s-options, renumber-windows)) + session_renumber_windows(s); } void
Re: caron no longer working in xterm
On Mar 31 19:24:00, h...@stare.cz wrote: Since about three snapshots ago, I cannot use the caron (háček) in xterm to diacritize my Czech (latin2) writings. This used to work. No really, this used to work. Now it stopped working on the machines I upgraded. Is anyone seeing the same? Jan For non-capital letters (ěščřž), there are specific keys with my setxkbmap -layout us,cz -option grp:shifts_toggle,grp_led:scroll; for capital letters, there is no way to type them in an xterm now. In firefox and other X applications I can write these without problems. Has anything changed in this regard, and have I missed it? (.x* and .X* files below, unchanged for a long time) Thank you Jan ~/.xinitrc: #!/bin/sh #gtf 1280 1024 60.0 #xrandr --newmode 1280x1024_60.00 108.88 1280 1360 1496 1712 1024 1025 1028 1060 -HSync +Vsync #xrandr --addmode VGA1 1280x1024_60.00 #xrandr --output VGA1 --mode 1280x1024_60.00 xset -b -c dpms 300 600 900 m 2 0 r rate 400 30 s blank s 120 60 xsetroot -solid black xrdb ~/.Xresources setxkbmap -layout us,cz -option grp:shifts_toggle,grp_led:scroll xmodmap ~/.xmodmaprc cwm ~/.Xresources: XTerm*termName: xterm-color XTerm*message:true XTerm*cutNewline: true XTerm*cutToBeginningOfLine: true ! these should not break a word XTerm*charClass:37:48,45-47:48,58:48,64:48,126:48 XTerm*toolBar:false !XTerm.keyboardType: vt220 XTerm*backarrowKeyIsErase:false !XTer*deleteIsDEL:true !XTerm.ptyInitialErase: true !XTerm.ttyModes: TODO XTerm*background: black XTerm*foreground: white XTerm*activeIcon: false XTerm*autowrap: true XTerm*colorMode: true XTerm*cursorBlink:true XTerm*backarrowKey: true XTerm*dynamicColors: false XTerm*loginShell: true XTerm*reverseWrap:true XTerm*scrollBar: false !XTerm*scrollKey: true !XTerm*scrollLines: 1024 !XTerm*scrollTtyOutput: false XTerm*saveLines: 1024 XTerm*selectToClipboard: true !XTerm*translations: TODO XTerm*visualBell: true XTerm*pointerMode:1 XTerm*eightBitInput: true XTerm*eightBitOutput: true !XTerm*allowC1Printable: true XTerm*locale: ISO8859-2 !XTerm*font: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-2
tmux move-window behavior changed
Hi! Suddenly I realized that I can not move a window to a non-existing (new) window number? Like if I have windows at [0:mutt 1:ksh], I can not do `move-window -s 1 -t 8' anymore, it just stays at 1. This had to work before. Am I just being silly? Daniel
groups new
0 C India P Delhi T New Delhi F irregular O New Delhi BSD User Group (NDBUG) I N.J. Thomas M i...@ndbug.in U http://ndbug.in/ N *BSD
