Is your switch a single point of failure?
I'm currently looking at growing my simple co-located setup of a single OpenBSD web server to add a separate firewall and a second web server. This would make regular upgrades much less stressful and add some welcome high availability and capacity improvements. I'm considering running dual OpenBSD firewalls on e.g. ALIX.2d3 boards with CARP and pfsync. My question relates to linking the firewalls to the servers via switches in a sensible way. I should be able to avoid the need for a switch on the upstream side by getting the ISP to provide me with two links from the rack router, one for each firewall board. These links would be CARP'd to share one external static IP. The second ethernet port on each board would be linked to the other board in the pair for pfsync. My question relates to the third port on each board, making up the CARP'd internal interface on the DMZ side. How can I avoid plugging these two ports straight into the same switch, thereby adding a really obvious single point of failure to the entire setup? I can see a couple of options but I'm thinking I must be missing something obvious. 1. Rather than CARPing the interfaces on the DMZ side, they could simply be treated as two separate gateways. Each would connect to its own switch and the servers on the inside would select between them as per RFC816. I'm not even sure this would work because if a switch failed, the firewalls would have to somehow transfer master/slave status to match. 2. Set up a couple of RSTP switches and somehow connect the CARP'd internal interface to both of them. Connect the web servers to both switches and configure just the one gateway on them. I can find heaps of good information on CARP but the described setups always show just one switch in the DMZ. Do people really just accept that single point of failure? Regards, Sam
Unique Sales Database
Hi, Are you looking for any of the following services at this time or is any of your clients looking for any of the following services at this time? 1) List Purchase - We can provide you lists from any Industry / Job title / Geography you focus on. The list will be with multi-channel marketing information like Emails, Phone and Mailing address. 2) Email Appending - If you don't have email addresses in your database we can add email addresses to your B2B and B2C in-house databases. We have the best email append match rate. 3) Phone, address and other data appending - If you want updated phone and mailing addresses or you have only contact name and company name/url we can add phone/address as well as other information in your incomplete file. 4) Contact Appending - If you have only company name/company URL and you want to add multiple contacts per company or you want specific types of job roles/titles in your file we can add their name, title, email, phone, fax, mailing address and company details for you. Industry Specific Lists: Accounting, Financial institutions - Banks Credit Unions, Insurance, Investment, Securities, Holding Companies, HR and recruiting, Government, Legal Law services, Construction, Software, Retail, Healthcare, Manufacturing, Transportation, Hospitality, Professional Services, Oil Gas, Utility, Non profit, Telecommunication, Education, media and other industries. Technology users Lists: SAP, Oracle Database, Oracle e-Business Suit, Peoplesoft, JD Edwards, Siebel, Hyperion, Microsoft Dynamic, Exchange Server, Share Point, .Net, Biz Talk, IBM Lotus Notes, File Net, Mainframe, Tivoli, WebSphere, Cognos, Sage, MAS 90/200, QuickBooks, Salesforce.com, Peachtree, NetSuite, Remedy, Baan, Mapics Application users and decision makers contact information list. Your target audience: Target Industry/Product users: Target Geography: Target title or job responsibility or specialty: Other remarks: Please let me know your thoughts to discuss further for any of these services. Best regards, Emma Thompson Lead Generation 302 235 3030 Unsubscribe by sending LEAVE OUT in subject line.
Re: Is your switch a single point of failure?
Sam, On Jul 6, 2011, at 3:31 AM, Sam Vaughan wrote: I should be able to avoid the need for a switch on the upstream side by getting the ISP to provide me with two links from the rack router, one for each firewall board. These links would be CARP'd to share one external static IP. I'd be really careful about this. The rack router may not expect to see the same IP address move between ports, and act funny if it does. Most CARP/pfsync setups put a switch in between the upstream router and the two boxes for this reason. Check with your service provider -- they may just be giving you two drops to a switch, in which case you have other single points of failure in your system already. My question relates to the third port on each board, making up the CARP'd internal interface on the DMZ side. How can I avoid plugging these two ports straight into the same switch, thereby adding a really obvious single point of failure to the entire setup? While you can use a pair of switches to do switch-level failover, it gets *expensive*. Nortel has the SMLT, DSMLT, and RSMLT protocols. Cisco has something sort of similar with their Virtual Switching System technology. http://en.wikipedia.org/wiki/Split_Multi-Link_Trunking Given the relatively high reliability of switches as well as the costs involved, most people don't bother. Of course, if you have the kind of budget that will support things like this... :-) Hope this helps. --Paul [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: OpenBGPD prepend-self/neighbor question
A) look at bgpd -nv output and check if the filter rules make sense.
They look fine, only filter rules on core2b are affected and they look
like this:
match from 159.148.214.101 set { prepend-neighbor 3 }
match to 159.148.214.101 set { prepend-self 3 }
deny from any
allow from any inet prefixlen 8 - 24
deny from any prefix 10.0.0.0/8 prefixlen = 8
deny from any prefix 172.16.0.0/12 prefixlen = 12
deny from any prefix 192.168.0.0/16 prefixlen = 16
deny from any prefix 169.254.0.0/16 prefixlen = 16
deny from any prefix 192.0.2.0/24 prefixlen = 24
deny from any prefix 224.0.0.0/4 prefixlen = 4
deny from any prefix 240.0.0.0/4 prefixlen = 4
B) use bgpctl show rib nei latnet out to see what prefixes you are
actually sending to the other side.
This is actually weird, primary router has only our network, but
secondary has all networks, but I'm not sure if it should be like that:
# core2a
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 194.143.152.0/230.0.0.0100 0 i
# core2b:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I* 31.24.192.0/21 159.148.214.101100 0 21178 21178 21178
2588 42480 8194 i
I* 31.170.16.0/21 159.148.214.101100 0 21178 21178 21178
2588 42480 5518 49191 i
... [skip] ...
I* 194.143.152.0/23 159.148.214.98 100 0 21178 21178 21178 i
... [skip] ...
I* 217.198.224.0/20 159.148.214.101100 0 21178 21178 21178
2588 42480 20910 i
I* 217.199.96.0/19 159.148.214.101100 0 21178 21178 21178
2588 42480 20797 20797 20797 20797 i
I'm not surprised. You must use filter to limit the networks you announce
when using announce all. So at least a deny to any and an allow to any
prefix 194.143.152.0/23 rule is needed.
Thanks Claudio, I've added these filters to my rules, now both my
routers announce only my network to the upstream:
# core2a:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 194.143.152.0/230.0.0.0100 0 i
# core2b:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I* 194.143.152.0/23 159.148.214.98 100 0 21178 21178 21178 i
Now, to test everything again, I removed any prepend-self and
prepend-neighbor settings on secondary router and added them to primary
router. After doing that and reloading BGPD, everything seems to be
fine:
# core2a:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 194.143.152.0/230.0.0.0100 0 21178 i
# core2b:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I* 194.143.152.0/23 159.148.214.98 100 0 i
Yet my upstream still prefers core2a as correct route to our network. I
noticed, that only core2a networks have announced flag, is that right?
Any other ideas what could be wrong?
Thanks,
Peter
Free to a good home: HP 9000/362 workstation
I've decided to part with my dear old HP 9000/362. I dusted it off, installed NetBSD-current, and am willing to ship it anywhere in the US. It comes with an HIL keyboard (no mouse) and ethernet. It's got 16 MB RAM, a 1 GB SCSI disk, and an integrated 640x480 VGA gendiofb. See below for full dmesg. I got X to start with a blank screen, but couldn't get much further without a mouse. If you want this gem of a relic, let me know! -- MW NetBSD/hp300 Primary Boot, Revision 1.18 (from NetBSD 5.99.53) HP 9000/362 SPU Enter reset to reset system. Boot: [[[le0a:]netbsd][-a][-c][-d][-s][-v][-q]] :- sd2a:netbsd 2969228+139772 [353872+228296]=0x3856c0 Start @ 0xff003400 [1=0xff2f9088-0x3856c0]... Entry point: 0xff003400 bootinfo found at 0xff002000 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 5.99.53 (GENERIC) #0: Mon Jun 27 13:29:24 UTC 2011 bui...@b7.netbsd.org:/home/builds/ab/HEAD/hp300/201106270850Z-obj/home/build s/ab/HEAD/src/sys/arch/hp300/compile/GENERIC HP 9000/362 (25MHz MC68030 CPU+MMU, 25MHz MC68882 FPU) total memory = 16372 KB avail memory = 11340 KB mainbus0 (root) intio0 at mainbus0 rtc0 at intio0 addr 0x42 hil0 at intio0 addr 0x428000 ipl 1 nhpib1 at intio0 addr 0x478000 ipl 3: internal HP-IB hpibbus1 at nhpib1 dma0 at intio0 addr 0x50 ipl 1: 98620C, 2 channels, 32-bit DMA dio0 at mainbus0 com0 at dio0 scode 9 ipl 5: ns16550a, working fifo com0: console internal parallel at dio0 scode 12 ipl 3 not configured spc0 at dio0 scode 14 ipl 4: 98265A SCSI, 32-bit DMA, SCSI ID 7 scsibus0 at spc0: 8 targets, 8 luns per target le0 at dio0 scode 21 ipl 5: address 08:00:09:10:d8:c2 le0: 8 receive buffers, 2 transmit buffers gendiofb0 at dio0 scode 132 ipl 3: 640x480x8 frame buffer wsdisplay0 at gendiofb0 kbdmux 1 scsibus0: waiting 2 seconds for devices to settle... hilkbd0 at hil0 code 1: 109-key keyboard, layout 1f wskbd0 at hilkbd0 mux 1 sd0 at scsibus0 target 0 lun 0: TEAC, FC-1 HF 07, RV A disk removable sd0(spc0:0:0:0): not ready, data = 00 00 00 00 04 00 00 00 sd0: drive offline sd0: async, 8-bit transfers sd1 at scsibus0 target 2 lun 0: SEAGATE, ST31230N, 0300 disk fixed sd1: 1010 MB, 3992 cyl, 5 head, 103 sec, 512 bytes/sect x 2069860 sectors sd1: async, 8-bit transfers sd0(spc0:0:0:0): not ready, data = 00 00 00 00 04 00 00 00 sd0(spc0:0:0:0): illegal request, data = 00 00 00 00 20 00 00 00 boot device: sd1 root on sd1a dumps on sd1b root file system type: ffs /etc/rc.conf is not configured. Multiuser boot aborted. Enter pathname of shell or RETURN for /bin/sh: [...] # disklabel sd1 # /dev/rsd1c: type: SCSI disk: ST31230N label: flags: bytes/sector: 512 sectors/track: 103 tracks/cylinder: 5 sectors/cylinder: 515 cylinders: 3993 total sectors: 2069860 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 8 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 1969660 200 4.2BSD 1024 8192 0 # (Cyl.0*- 3824*) b:10 1969860 swap # (Cyl. 3824*- 4019*) c: 2069860 0 boot # (Cyl.0 - 4019*)
OpenBSD current i386 hangs on boot in lm0.
Hi, I updated from OpenBSD current i386, built from CVS 24th March 2011, to one built from CVS on 2nd July 2011. The bsd.rd booted, and was used to upgrade, on reboot this hung. I noted lm0 was the last line, rebooting with the older kernel version the next dmesg line was lm1 detached, and the boot completed. The line in the /var/log/messages for old kernel are:- /bsd: lm1 at iic0 addr 0x2d: W83781D /bsd: lm0 at isa0 port 0x290/8: W83781D /bsd: lm1 detached Using boot -c with latest bsd, I disabled lm, this booted as normal with lm disabled. dmesg is below. I downloaded the latest snapshot bsd 29th June 2011, booted from this an hit the same problem at lm0. I booted from the bsd built from cvs, using boot -c and disabled just lm0, this booted as normal. Updated from CVS today, and rebuilt the kernel, booted from the new bsd, this hung at the same point lm0. Two other i386 systems are fine, but these don't have the lm device. Please contact me if anymore information is required, or anything you would me to try out. Regards Nigel Taylor OpenBSD 4.9-current (GENERIC) #6: Sat Jul 2 13:30:07 BST 2011 r...@lorien.asterisk.me.uk:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Celeron (GenuineIntel 686-class, 128KB L2 cache) 335 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR real mem = 267964416 (255MB) avail mem = 253394944 (241MB) User Kernel Config UKC disable lm 305 lm0 disabled 306 lm* disabled 307 lm* disabled UKC exit Continuing... mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/01/02, BIOS32 rev. 0 @ 0xf0520 apm0 at bios0: Power Management spec V1.2 pcibios0 at bios0: rev 2.1 @ 0xf/0xdb2 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0d10/160 (8 entries) pcibios0: PCI Interrupt Router at 000:04:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xb000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xe400, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Rage Magnum rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) piixpcib0 at pci0 dev 4 function 0 Intel 82371AB PIIX4 ISA rev 0x02 pciide0 at pci0 dev 4 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: MAXTOR STM380215A wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: HL-DT-ST, DVD-ROM GDR8163B, 0L23 ATAPI 5/cdrom removable cd0(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2 uhci0 at pci0 dev 4 function 2 Intel 82371AB USB rev 0x01: irq 5 piixpm0 at pci0 dev 4 function 3 Intel 82371AB Power rev 0x02: SMI iic0 at piixpm0 w83781d at iic0 addr 0x2d not configured iic0: addr 0x2d 20=7c 21=5d 22=d8 23=b9 24=ca 25=d5 26=d9 27=22 29=54 2b=89 2c=70 2d=89 2e=70 2f=ed 30=b0 31=75 32=c5 33=48 34=0a 35=8c 36=4b 37=63 38=4a 39=c2 3a=33 3b=c4 3c=92 3d=03 3e=00 3f=00 40=01 41=5a 42=0f 44=7f 45=00 46=40 47=a0 48=2d 49=00 4a=01 4b=40 4c=01 4d=95 4e=80 4f=5c 50=00 51=7f 52=00 56=00 57=80 58=11 60=7c 61=5d 62=d8 63=b8 64=ca 65=d5 66=d8 67=22 69=54 6b=89 6c=70 6d=89 6e=70 6f=ed 70=b0 71=75 72=c5 73=48 74=0a 75=8c 76=4b 77=63 78=4a 79=c2 7a=33 7b=c4 7c=92 7d=03 7e=00 7f=00 a0=7c a1=5d a2=d8 a3=bc a4=ca a5=d5 a6=da a7=22 a9=54 ab=89 ac=70 ad=89 ae=70 af=ed b0=b0 b1=75 b2=c5 b3=48 b4=0a b5=8c b6=4b b7=63 b8=4a b9=c2 ba=33 bb=c4 bc=92 bd=03 be=00 bf=00 c0=01 c1=5a c2=0f c4=7f c5=00 c6=40 c7=a0 c8=2d c9=00 ca=01 cb=40 cc=01 cd=95 ce=80 cf=5c d0=00 d1=7f d2=00 d6=00 d7=80 d8=11 e0=7c e1=5d e2=d8 e3=b8 e4=ca e5=d5 e6=d9 e7=22 e9=53 eb=89 ec=70 ed=89 ee=70 ef=ed f0=b0 f1=75 f2=c5 f3=48 f4=0a f5=8c f6=4b f7=63 f8=4a f9=c2 fa=33 fb=c4 fc=92 fd=03 fe=00 ff=00 words 00= 01= 02= 03= 04= 05= 06= 07=: w83781d iic0: addr 0x48 01=00 02=4b 03=50 05=00 06=4b 07=50 09=00 0a=4b 0b=50 0d=00 0e=4b 0f=50 11=00 12=4b 13=50 15=00 16=4b 17=50 19=00 1a=4b 1b=50 1d=00 1e=4b 1f=50 21=00 22=4b 23=50 25=00 26=4b 27=50 29=00 2a=4b 2b=50 2d=00 2e=4b 2f=50 31=00 32=4b 33=50 35=00 36=4b 37=50 39=00 3a=4b 3b=50 3d=00 3e=4b 3f=50 41=00 42=4b 43=50 45=00 46=4b 47=50 49=00 4a=4b 4b=50 4d=00 4e=4b 4f=50 51=00 52=4b 53=50 55=00 56=4b 57=50 59=00 5a=4b 5b=50 5d=00 5e=4b 5f=50 61=00 62=4b 63=50 65=00 66=4b 67=50 69=00 6a=4b 6b=50 6d=00 6e=4b 6f=50 71=00 72=4b 73=50 75=00 76=4b 77=50 79=00 7a=4b 7b=50 7d=00 7e=4b 7f=50 81=00 82=4b 83=50 85=00 86=4b 87=50 89=00 8a=4b 8b=50 8d=00 8e=4b 8f=50 91=00 92=4b 93=50 95=00 96=4b 97=50 99=00 9a=4b 9b=50 9d=00 9e=4b 9f=50 a1=00 a2=4b a3=50 a5=00 a6=4b
Re: OpenBSD current i386 hangs on boot in lm0.
On 07/06/11 07:47, Nigel Taylor wrote: Hi, I updated from OpenBSD current i386, built from CVS 24th March 2011, to one built from CVS on 2nd July 2011. The bsd.rd booted, and was used to upgrade, on reboot this hung. I noted lm0 was the last line, rebooting with the older kernel version the next dmesg line was lm1 detached, and the boot completed. The line in the /var/log/messages for old kernel are:- /bsd: lm1 at iic0 addr 0x2d: W83781D /bsd: lm0 at isa0 port 0x290/8: W83781D /bsd: lm1 detached Using boot -c with latest bsd, I disabled lm, this booted as normal with lm disabled. dmesg is below. I downloaded the latest snapshot bsd 29th June 2011, booted from this an hit the same problem at lm0. I booted from the bsd built from cvs, using boot -c and disabled just lm0, this booted as normal. Updated from CVS today, and rebuilt the kernel, booted from the new bsd, this hung at the same point lm0. Two other i386 systems are fine, but these don't have the lm device. Please contact me if anymore information is required, or anything you would me to try out. I reported the same thing in these two messages: http://marc.info/?l=openbsd-miscm=130755536116000w=2 http://marc.info/?l=openbsd-miscm=130764492616339w=2 This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. However, when I tried building kernels for that range of days I ran into other problems and haven't been able to get back to it since. Jeff
Re: OpenBSD current i386 hangs on boot in lm0.
Hi all, Medion computers, supermicro (many cheap models) motherboards are known as 'not free *unix* compatible'. Therefore most of supermicro other motherboards just seem to work well with *linux *BSD. Madion are hardware coded to be able only to boot a real windows OS, (even reactOS often fail to boot correctly), Then you need to boot other OS to have a windows installed in first partition(s) to use a multiboot, but even that can fail From: Jeff Ross jr...@openvistas.net Sent: Wed Jul 06 17:07:40 CEST 2011 To: Nigel Taylor njtay...@asterisk.demon.co.uk, OpenBSD misc@openbsd.org Subject: Re: OpenBSD current i386 hangs on boot in lm0. On 07/06/11 07:47, Nigel Taylor wrote: Hi, I updated from OpenBSD current i386, built from CVS 24th March 2011, to one built from CVS on 2nd July 2011. The bsd.rd booted, and was used to upgrade, on reboot this hung. I noted lm0 was the last line, rebooting with the older kernel version the next dmesg line was lm1 detached, and the boot completed. The line in the /var/log/messages for old kernel are:- /bsd: lm1 at iic0 addr 0x2d: W83781D /bsd: lm0 at isa0 port 0x290/8: W83781D /bsd: lm1 detached Using boot -c with latest bsd, I disabled lm, this booted as normal with lm disabled. dmesg is below. I downloaded the latest snapshot bsd 29th June 2011, booted from this an hit the same problem at lm0. I booted from the bsd built from cvs, using boot -c and disabled just lm0, this booted as normal. Updated from CVS today, and rebuilt the kernel, booted from the new bsd, this hung at the same point lm0. Two other i386 systems are fine, but these don't have the lm device. Please contact me if anymore information is required, or anything you would me to try out. I reported the same thing in these two messages: http://marc.info/?l=openbsd-miscm=130755536116000w=2 http://marc.info/?l=openbsd-miscm=130764492616339w=2 This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. However, when I tried building kernels for that range of days I ran into other problems and haven't been able to get back to it since. Jeff Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 ToulouseB FranceB +33 6 17 230 820 B +33 5 34 365 269 fpussa...@contactoffice.fr
pf ALTQ bandwidth limited to a 32bit value (4294Mb)
ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb.
This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any
higher, altq will flip back to zero. This bug was found when trying
to test 10 gigabit and 40 gigabit bandwidth models. These tests were
done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit.
If anyone else can verify this independently and agree with the
results I would be happy to register it as a bug.
How to replicate:
A quick test is setting the bandwidth to 4294Mb and doing a pfctl -sq
to check altq.
altq on $ExtIf bandwidth 4294Mb hfsc queue { ack, web}
queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web}
Now set the bandwidth to 4295Mb and notice altq has flip to zero and
add the 32.70Kb difference.
altq on $ExtIf bandwidth 4295Mb hfsc queue { ack, web }
queue root_em0 on em0 bandwidth 32.70Kb priority 0 {ack, web}
Again, we can set the bandwidth to a multiple of two(2) to 8589Mb.
The bandwidth value flips to zero once and the result is 4.29Gb.
altq on $ExtIf bandwidth 8589Mb hfsc queue { ack, web}
queue root_em0 on em0 bandwidth 4.29Gb priority 0 {ack, web}
If we add one more megabit to 8590Mb the value flips twice and we are
left with 65.41Kb.
altq on $ExtIf bandwidth 8590Mb hfsc queue { ack, web}
queue root_em0 on em0 bandwidth 65.41Kb priority 0 {ack, web}
Thanks.
--
Calomel @ https://calomel.org
Open Source Research and Reference
Re: OpenBSD current i386 hangs on boot in lm0.
On 07/06/11 09:22, Francois Pussault wrote: Hi all, Medion computers, supermicro (many cheap models) motherboards are known as 'not free *unix* compatible'. Therefore most of supermicro other motherboards just seem to work well with *linux *BSD. Madion are hardware coded to be able only to boot a real windows OS, (even reactOS often fail to boot correctly), Then you need to boot other OS to have a windows installed in first partition(s) to use a multiboot, but even that can fail This is not my experience with SuperMicro motherboards, in fact, my experience is exactly the opposite. They all work and work well. Jeff From: Jeff Rossjr...@openvistas.net Sent: Wed Jul 06 17:07:40 CEST 2011 To: Nigel Taylornjtay...@asterisk.demon.co.uk, OpenBSD misc@openbsd.org Subject: Re: OpenBSD current i386 hangs on boot in lm0. On 07/06/11 07:47, Nigel Taylor wrote: Hi, I updated from OpenBSD current i386, built from CVS 24th March 2011, to one built from CVS on 2nd July 2011. The bsd.rd booted, and was used to upgrade, on reboot this hung. I noted lm0 was the last line, rebooting with the older kernel version the next dmesg line was lm1 detached, and the boot completed. The line in the /var/log/messages for old kernel are:- /bsd: lm1 at iic0 addr 0x2d: W83781D /bsd: lm0 at isa0 port 0x290/8: W83781D /bsd: lm1 detached Using boot -c with latest bsd, I disabled lm, this booted as normal with lm disabled. dmesg is below. I downloaded the latest snapshot bsd 29th June 2011, booted from this an hit the same problem at lm0. I booted from the bsd built from cvs, using boot -c and disabled just lm0, this booted as normal. Updated from CVS today, and rebuilt the kernel, booted from the new bsd, this hung at the same point lm0. Two other i386 systems are fine, but these don't have the lm device. Please contact me if anymore information is required, or anything you would me to try out. I reported the same thing in these two messages: http://marc.info/?l=openbsd-miscm=130755536116000w=2 http://marc.info/?l=openbsd-miscm=130764492616339w=2 This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. However, when I tried building kernels for that range of days I ran into other problems and haven't been able to get back to it since. Jeff Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 ToulouseB FranceB +33 6 17 230 820 B +33 5 34 365 269 fpussa...@contactoffice.fr !DSPAM:4e147f8448271610687006!
Re: OpenBSD current i386 hangs on boot in lm0.
Jeff Ross [jr...@openvistas.net] wrote: This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. Yet, a kernel compiled again Jun 6th sources does not display this behvaior Therefore, it is caused by a change that was in the snapshots--but not committed until later I was out of town for a week, but will now narrow down when the offending code was committed since it affects my X7SBL, PDSML, and probably other supermicro boards that I use in qty...
Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb)
Calomel Org infallibilismindefeasibil...@calomel.org writes: ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any higher, altq will flip back to zero. This bug was found when trying to test 10 gigabit and 40 gigabit bandwidth models. These tests were done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit. Nice to hear you've got access to relatively high end gear for testing, I'm sure it will come in handy when the time comes to test any proposed fixes. The obvious workaround in the short term is to do the traffic shaping and filtering a bit closer to the end user, where bandwidth is a bit more scarce. In the slightly longer term, I'm sure a verified bug report (with patches against -current code if feasible) would be much appreciated. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: OpenBSD current i386 hangs on boot in lm0.
On 07/06/11 10:04, Chris Cappuccio wrote: Jeff Ross [jr...@openvistas.net] wrote: This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. Yet, a kernel compiled again Jun 6th sources does not display this behvaior Well, that explains the problem I was having. None of the kernels I built would hang so I thought I was doing something wrong. Jeff Therefore, it is caused by a change that was in the snapshots--but not committed until later I was out of town for a week, but will now narrow down when the offending code was committed since it affects my X7SBL, PDSML, and probably other supermicro boards that I use in qty... !DSPAM:4e148bfa98349598613850!
Re: OpenBSD current i386 hangs on boot in lm0.
This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. Yet, a kernel compiled again Jun 6th sources does not display this behvaior Well, that explains the problem I was having. None of the kernels I built would hang so I thought I was doing something wrong. Well, you should know the snapshot behaviour by now if you are running OpenBSD so long. :-) Therefore, it is caused by a change that was in the snapshots--but not committed until later I was out of town for a week, but will now narrow down when the offending code was committed since it affects my X7SBL, PDSML, and probably other supermicro boards that I use in qty...
Re: OpenBSD current i386 hangs on boot in lm0.
On Wed, 6 Jul 2011 17:23:08 +0200 (CEST), Francois Pussault wrote Hi all, Medion computers, supermicro (many cheap models) motherboards are known as 'not free *unix* compatible'. Therefore most of supermicro other motherboards just seem to work well with *linux *BSD. Madion are hardware coded to be able only to boot a real windows OS, (even reactOS often fail to boot correctly), Then you need to boot other OS to have a windows installed in first partition(s) to use a multiboot, but even that can fail I have to disagree about Supermicro. I have been using their motherboards since the mid-2000s, and they are neither cheap nor unfriendly to free unices. The biggest problem is that their support people are generally not unix people. I never had any trouble running OpenBSD on their products until 4.8, when it started hanging on boot, which I reported to this list previously. ~~~
Re: OpenBSD current i386 hangs on boot in lm0.
Hi, I am using a ASUS P2B motherboard, this has been running OpenBSD since 2005 could be a few years longer. With no issues other than a hard disk failure. There is no multiboot in use, it's not a Medion computer, or using a supermicro motherboard. The common issue is with the lm device hanging during boot with OpenBSD current. Regards Nigel Taylor On 07/06/11 16:23, Francois Pussault wrote: Hi all, Medion computers, supermicro (many cheap models) motherboards are known as 'not free *unix* compatible'. Therefore most of supermicro other motherboards just seem to work well with *linux *BSD. Madion are hardware coded to be able only to boot a real windows OS, (even reactOS often fail to boot correctly), Then you need to boot other OS to have a windows installed in first partition(s) to use a multiboot, but even that can fail From: Jeff Rossjr...@openvistas.net Sent: Wed Jul 06 17:07:40 CEST 2011 To: Nigel Taylornjtay...@asterisk.demon.co.uk, OpenBSD misc@openbsd.org Subject: Re: OpenBSD current i386 hangs on boot in lm0. On 07/06/11 07:47, Nigel Taylor wrote: Hi, I updated from OpenBSD current i386, built from CVS 24th March 2011, to one built from CVS on 2nd July 2011. The bsd.rd booted, and was used to upgrade, on reboot this hung. I noted lm0 was the last line, rebooting with the older kernel version the next dmesg line was lm1 detached, and the boot completed. The line in the /var/log/messages for old kernel are:- /bsd: lm1 at iic0 addr 0x2d: W83781D /bsd: lm0 at isa0 port 0x290/8: W83781D /bsd: lm1 detached Using boot -c with latest bsd, I disabled lm, this booted as normal with lm disabled. dmesg is below. I downloaded the latest snapshot bsd 29th June 2011, booted from this an hit the same problem at lm0. I booted from the bsd built from cvs, using boot -c and disabled just lm0, this booted as normal. Updated from CVS today, and rebuilt the kernel, booted from the new bsd, this hung at the same point lm0. Two other i386 systems are fine, but these don't have the lm device. Please contact me if anymore information is required, or anything you would me to try out. I reported the same thing in these two messages: http://marc.info/?l=openbsd-miscm=130755536116000w=2 http://marc.info/?l=openbsd-miscm=130764492616339w=2 This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. However, when I tried building kernels for that range of days I ran into other problems and haven't been able to get back to it since. Jeff Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 ToulouseB FranceB +33 6 17 230 820 B +33 5 34 365 269 fpussa...@contactoffice.fr
running multiple spamd instances in the same openbsd box
Hi, I know this not a supported feature. But I would like to run two or more instances of spamd on the same OpenBSD machine. This would be hosted in a cloud server. The main purpose is to be able to have different spamd.conf (blacklists) and differrent suffixes (spamd.alloweddomains) for different domains. I had a quick look at the source code, and I thought of an idea, to which I would like opinions from the more skilled users. From what I could understand, /etc/mail/spamd.conf, /etc/mail/spamd.alloweddomains and /var/db/spamd are all hardcoded. So if I rebuild the code with these values modified, I could get new binaries to read/write at the right place. I also noticed that spamd-white is hardcoded too. I could change this likewise. spamd listens on ports defined at /etc/services. I could also change that at the source code of the modified instances. spamd chroots to /var/empty. So, my first question is would I need to use different directories for the various instances? my pf.conf would look like: table spamd-white1 persist table spamd-white2 persist pass in on egress proto tcp from any to $mx-domain1 port smtp \ B B rdr-to 127.0.0.1 port spamd1 pass in on egress proto tcp from any to $mx-domain2 port smtp \ B B rdr-to 127.0.0.1 port spamd2 Each instance of spamlogd would run with -l pflogX switch pass in log (to pflog1) on egress proto tcp from spamd-white1 \ B B to any port smtp pass in log (to pflog2) on egress proto tcp from spamd-white2 \ B B to any port smtp My second question is am I missing any other possible conflict? Thanks in advance for any hint. Best regards, Joao
Re: OpenBGPD prepend-self/neighbor question
# core2a:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 194.143.152.0/230.0.0.0100 0 21178 i
# core2b:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I* 194.143.152.0/23 159.148.214.98 100 0 i
Yet my upstream still prefers core2a as correct route to our network. I
noticed, that only core2a networks have announced flag, is that right?
Any other ideas what could be wrong?
I've just upgraded both routers to 4.9, updated filters to 4.9 defaults,
but the problem still remains. Nothing has changed regarding path to
upstream ISP.
Filtering rules now look like this:
match from 159.148.214.101 set { prepend-neighbor 1 }
match to 159.148.214.101 set { prepend-self 1 }
deny from any
deny to any
allow from any inet prefixlen 8 - 24
allow from any inet6 prefixlen 16 - 48
allow to any prefix 194.143.152.0/23
deny from any prefix 0.0.0.0/8 prefixlen = 8
deny from any prefix 10.0.0.0/8 prefixlen = 8
deny from any prefix 127.0.0.0/8 prefixlen = 8
deny from any prefix 169.254.0.0/16 prefixlen = 16
deny from any prefix 172.16.0.0/12 prefixlen = 12
deny from any prefix 192.0.2.0/24 prefixlen = 24
deny from any prefix 192.168.0.0/16 prefixlen = 16
deny from any prefix 198.18.0.0/15 prefixlen = 15
deny from any prefix 198.51.100.0/24 prefixlen = 24
deny from any prefix 203.0.113.0/24 prefixlen = 24
deny from any prefix 224.0.0.0/4 prefixlen = 4
deny from any prefix 240.0.0.0/4 prefixlen = 4
deny from any prefix ::/8 prefixlen = 8
deny from any prefix 2001:2::/48 prefixlen = 48
deny from any prefix 2001:10::/28 prefixlen = 28
deny from any prefix 2001:db8::/32 prefixlen = 32
deny from any prefix 3ffe::/16 prefixlen = 16
Peter
Re: OpenBGPD prepend-self/neighbor question
On Wed, Jul 06, 2011 at 03:51:18PM +0300, peter dunaskin wrote:
A) look at bgpd -nv output and check if the filter rules make sense.
They look fine, only filter rules on core2b are affected and they look
like this:
match from 159.148.214.101 set { prepend-neighbor 3 }
match to 159.148.214.101 set { prepend-self 3 }
deny from any
allow from any inet prefixlen 8 - 24
deny from any prefix 10.0.0.0/8 prefixlen = 8
deny from any prefix 172.16.0.0/12 prefixlen = 12
deny from any prefix 192.168.0.0/16 prefixlen = 16
deny from any prefix 169.254.0.0/16 prefixlen = 16
deny from any prefix 192.0.2.0/24 prefixlen = 24
deny from any prefix 224.0.0.0/4 prefixlen = 4
deny from any prefix 240.0.0.0/4 prefixlen = 4
B) use bgpctl show rib nei latnet out to see what prefixes you are
actually sending to the other side.
This is actually weird, primary router has only our network, but
secondary has all networks, but I'm not sure if it should be like that:
# core2a
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 194.143.152.0/230.0.0.0100 0 i
# core2b:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I* 31.24.192.0/21 159.148.214.101100 0 21178 21178
21178 2588 42480 8194 i
I* 31.170.16.0/21 159.148.214.101100 0 21178 21178
21178 2588 42480 5518 49191 i
... [skip] ...
I* 194.143.152.0/23 159.148.214.98 100 0 21178 21178
21178 i
... [skip] ...
I* 217.198.224.0/20 159.148.214.101100 0 21178 21178
21178 2588 42480 20910 i
I* 217.199.96.0/19 159.148.214.101100 0 21178 21178
21178 2588 42480 20797 20797 20797 20797 i
I'm not surprised. You must use filter to limit the networks you announce
when using announce all. So at least a deny to any and an allow to any
prefix 194.143.152.0/23 rule is needed.
Thanks Claudio, I've added these filters to my rules, now both my
routers announce only my network to the upstream:
# core2a:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 194.143.152.0/230.0.0.0100 0 i
# core2b:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I* 194.143.152.0/23 159.148.214.98 100 0 21178 21178 21178 i
Now, to test everything again, I removed any prepend-self and
prepend-neighbor settings on secondary router and added them to primary
router. After doing that and reloading BGPD, everything seems to be
fine:
# core2a:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI* 194.143.152.0/230.0.0.0100 0 21178 i
# core2b:
flags: * = Valid, = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I* 194.143.152.0/23 159.148.214.98 100 0 i
Yet my upstream still prefers core2a as correct route to our network. I
noticed, that only core2a networks have announced flag, is that right?
Any other ideas what could be wrong?
If you look at the Loc-Rib aka 'bgpctl show rib 194.143.152.1 all' it will
show you that there are two networks for 194.143.152.0/23 on core2b. This
comes from the fact that core2a is announcing his network to core2b and
the route from core2a is considered better and therefor selected and
announced. The A flag is only set on local networks.
Now if the upstreams always selects one route over another then it is a
missconfiguration on their side (e.g. there is still a static route
somewhere configured or something else).
--
:wq Claudio
iwn(4) fatal firmware error
Hello misc, I am running an unmodified version of OpenBSD 4.9. The problem that I am experiencing is in regard to the iwn(4) driver, which occasionally crashes with a 'fatal firmware error' message. So far, I am unable to nail down any specific activity (browsing the web, ftp, etc) that triggers the problem, and could not locate any similar bug reports via Google or the OpenBSD bug tracking system. I am providing the complete error information as reported by the driver, along with the dmesg from the affected system. Any help or ideas would be greatly appreciated. If more information is necessary, please let me know and I will make every attempt to provide it. Thanks in advance, Mike begin error message --- Jul 5 12:56:57 asus /bsd: iwn0: fatal firmware error Jul 5 12:56:57 asus /bsd: firmware error log: Jul 5 12:56:57 asus /bsd: error type = NMI_INTERRUPT_WDG (0x0004) Jul 5 12:56:57 asus /bsd: program counter = 0x06D0 Jul 5 12:56:57 asus /bsd: source line = 0x8276 Jul 5 12:56:57 asus /bsd: error data = 0x00020363 Jul 5 12:56:57 asus /bsd: branch link = 0x059606D4 Jul 5 12:56:57 asus /bsd: interrupt link = 0x08924F50 Jul 5 12:56:57 asus /bsd: time= 2933200967 Jul 5 12:56:57 asus /bsd: driver status: Jul 5 12:56:57 asus /bsd: tx ring 0: qid=0 cur=73 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 1: qid=1 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 2: qid=2 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 3: qid=3 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 4: qid=4 cur=115 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 5: qid=5 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 6: qid=6 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 7: qid=7 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 8: qid=8 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 9: qid=9 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 10: qid=10 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 11: qid=11 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 12: qid=12 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 13: qid=13 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 14: qid=14 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 15: qid=15 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 16: qid=16 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 17: qid=17 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 18: qid=18 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: tx ring 19: qid=19 cur=0 queued=0 Jul 5 12:56:57 asus /bsd: rx ring: cur=42 Jul 5 12:56:57 asus /bsd: 802.11 state 4 --- end error message --- --- begin dmesg --- OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Genuine Intel(R) CPU U7300 @ 1.30GHz (GenuineIntel 686-class) 1.74 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3 ,CX16,xTPR,PDCM,SSE4.1,XSAVE real mem = 3184521216 (3036MB) avail mem = 3122278400 (2977MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/01/10, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xfd190 (34 entries) bios0: vendor American Megatrends Inc. version 217 date 03/01/2010 bios0: ASUSTeK Computer Inc. UL50VT acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIC ECDT DBGP BOOT OEMB HPET GSCI SSDT acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB5(S3) EUSB(S3) USB3(S3) USB4(S3) USB6(S3) USBE(S3) HDAC(S3) P0P1(S4) P0P2(S3) P0P3(S3) WLAN(S3) P0P4(S3) P0P6(S3) P0P7(S4) P0P8(S4) GLAN(S4) P0P9(S3) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU U7300 @ 1.30GHz (GenuineIntel 686-class) 1.74 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3 ,CX16,xTPR,PDCM,SSE4.1,XSAVE ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xc000, bus 0-255 acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 3 (P0P3) acpiprt3 at acpi0: bus -1 (P0P4) acpiprt4 at acpi0: bus 4 (P0P8) acpiprt5 at acpi0: bus 5 (P0P9) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpitz0 at acpi0: critical temperature 93 degC acpiac0 at acpi0: AC unit in unknown state acpibat0 at acpi0: BAT0 not present acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID_ acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: CRTD acpivout1 at acpivideo0: LCDD acpivout2 at acpivideo0: HDMI acpivideo1 at acpi0:
Re: Is your switch a single point of failure?
On 2011-07-06, Sam Vaughan samjvaug...@gmail.com wrote: I should be able to avoid the need for a switch on the upstream side by getting the ISP to provide me with two links from the rack router, one for each firewall board. These links would be CARP'd to share one external static IP. For carp to work these two interfaces need to be able to see each other (L2). On separate router interfaces (rather than switchports) this won't be the case. This is probably the side you need to think about more.. My question relates to the third port on each board, making up the CARP'd internal interface on the DMZ side. How can I avoid plugging these two ports straight into the same switch, thereby adding a really obvious single point of failure to the entire setup? I can see a couple of options but I'm thinking I must be missing something obvious. Simplest way is probably: one firewall to one switch, one to a second switch, crossconnect the switches, connect servers to both switches with a failover trunk.
Small fix to calendar.music
--- usr.bin/calendar/calendars/calendar.music Wed Jul 6 15:39:20 2011 +++ usr.bin/calendar/calendars/calendar.music.new Wed Jul 6 15:39:00 2011 @@ -282,7 +282,7 @@ 07/07 Gustav Mahler is born in Kalischt, Bohemia, 1860 07/06 The Jefferson Airplane is formed in San Francisco, 1965 07/07 Ringo Starr (Richard Starkey) born in Liverpool, England, 1940 -07/07 Leo Sowbery dies in Port Clinton, Ohio, 1968 +07/07 Leo Sowerby dies in Port Clinton, Ohio, 1968 07/08 Percy Grainger is born near Melbourne, Australia, 1882 07/08 Hans Leo Hassler is born in Nuremberg, Germany, 1564 07/09 Ottorino Respighi is born in Bologna, Italy, 1879
Re: Recompile OpenBSD without built-in Apache 1.3
Am 05.07.11 05:13, schrieb Henning Brauer: * Tito Mari Francis Escaqotitomarifran...@gmail.com [2011-06-29 03:31]: Is it possible to recompile the whole system while excluding the built-in Apache 1.3 web server? yes indeed. I was hoping to save a few more megabytes off the base installation of the system. I see. me too. In case it's not advisable indeed why? can you please discuss the bad side effects of doing so? you look like a retard. you too. we laugh about you. ha! you won't get any help. true. and much more. whut? BeSD regards, Marian PS.: Kabarett *swing swing along and sing sing along*
Re: OpenBSD current i386 hangs on boot in lm0.
On 07/06/11 17:04, Chris Cappuccio wrote: Jeff Ross [jr...@openvistas.net] wrote: This hang happens with the 4 different SuperMicro based motherboards I have that have the lm chipset. In the second message referenced above I noted that a snapshot dated May 25 booted normally and I first ran into the problem on June 6 so the window is fairly small. Yet, a kernel compiled again Jun 6th sources does not display this behvaior Therefore, it is caused by a change that was in the snapshots--but not committed until later I was out of town for a week, but will now narrow down when the offending code was committed since it affects my X7SBL, PDSML, and probably other supermicro boards that I use in qty... Hi, This might be a different fault to the previous one reported. I tried a kernel built from CVS using the follwoing dates 6th June Ok. 15th June Ok. 22nd June Hangs. 19th June Ok. 20th June Ok. 21st June Hangs. The changed between the two dates are :- cvs -R -q diff -uNp -D 2011/06/20 -D 2011/06/21 | grep Index: Index: arch/amd64/conf/GENERIC Index: arch/i386/conf/GENERIC Index: dev/softraid.c Index: dev/vnd.c Index: dev/ata/wd.c Index: dev/isa/if_lc_isa.c Index: dev/isa/if_we.c Index: dev/isa/mcd.c Index: dev/isa/radiotrack2.c Index: dev/isa/sf16fmr2.c Index: dev/isa/wdc_isa.c Index: dev/microcode/Makefile Index: dev/pci/if_myx.c Index: dev/pci/if_myxreg.h Index: kern/subr_autoconf.c Index: net/if_pflog.c Index: net/pf.c Index: net/pf_norm.c Index: net/pfvar.h I think I narrowed this down to kern/subr_autoconf.c, build a kernel extract from CVS with a date of 21st June, with kern/subr_autoconf.c kept at version 1.64. This booted without hanging. 1.65 log serialize attach and detach of device sub-trees -- only one device sub-tree may attach or detach at a time. attach and detach will sleep against each other. this is fixing (working around?) some bizzare corner cases that have been seen (but not fully diagnosed) where the device trees, disk registration subsystem, and other things could get messed up. one could argue though that this serialization is a very good thing; it is easier than adding piles of locks in various other places. ok matthew jsing In the case of lm from dmesg we have, lm1 at iic0 addr 0x2d: W83781D lm0 at isa0 port 0x290/8: W83781D lm1 detached Regards Nigel Taylor
Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb)
On Wed, Jul 06, 2011, Peter N. M. Hansteen wrote: Calomel Org infallibilismindefeasibil...@calomel.org writes: more scarce. In the slightly longer term, I'm sure a verified bug report (with patches against -current code if feasible) would be much appreciated. I would postpone making any diffs against altq for a little while. :)
